Acceptance and Go‑Live

19. Acceptance and Go‑Live #

19.1 Purpose #

Acceptance and Go‑Live confirm that the solution meets business requirements, security/privacy controls, and operational readiness before production activation. No deployment proceeds without formal acceptance and Go‑Live authorization.

19.2 Acceptance criteria (business) #

The Product/Process Owner must validate that:

  • All business requirements are met and traceable to executed test cases.

  • UAT has passed with acceptable results and no unresolved Critical/High defects affecting core workflows.

  • User documentation and training materials (if applicable) are complete and available to intended users.

  • Operational reporting/exports required by the business are available and accurate.

    Evidence: UAT report, acceptance checklist, test artifacts (screenshots/recordings), and signed acceptance. PENDING: UAT template link; minimum evidence list

19.3 Acceptance criteria (security/privacy) #

The ISO must validate that:

  • Pre‑Production evidence is complete and approved (SBOM, SAST/SCA/DAST summaries, secrets/IaC/container scans as applicable).

  • Open findings are within approved SLAs; any waivers have compensating controls, owner, and expiry.

  • Identity/SSO, MFA, roles, and least‑privilege service accounts are implemented as designed.

  • Logging is SIEM‑ready; required event families and fields are emitted; redaction tested.

  • Residency constraints are satisfied (Canada‑only by default) or an approved exception (with DPIA if PI involved) is in place.

    Evidence: security review record, log samples, waiver list (if any), residency/DPIA documentation where applicable. PENDING: Log sample format; residency exception package contents

19.4 Operational readiness #

IT Operations must validate that:

  • Monitoring dashboards, alerts, and on‑call routing are active; alert paths tested.

  • Backups are configured, recent, and restorable; rollback and restore runbooks are ready.

  • Deployment/rollback plans are current; dry‑run or tabletop completed for high‑risk releases.

  • Access for admin/support roles has been granted per least privilege; break‑glass accounts sealed.

  • Runbooks (start/stop, common issues) and support contacts are documented and accessible.

    Evidence: monitoring/alert test results, backup snapshot references and recent restore evidence, runbooks, access review record. PENDING: On‑call targets (Sev1/Sev2); restore evidence location

19.5 Go‑Live authorization #

Approvals required:

  • Product/Process Owner: business acceptance confirmed.

  • ISO: security/privacy readiness confirmed.

  • IT Operations: operational readiness confirmed.

  • Executive Sponsor: required when residual risk/exception exists or when designated by change class.

    All approvals must be recorded in the release record/ticket with date/time and any conditions.

19.6 Cutover plan #

The vendor must present a concise cutover plan that includes:

  • Deployment steps and expected duration; validation tests for success.

  • Rollback triggers and steps; responsible decision‑maker identified.

  • Communication plan (pre‑notice, in‑flight status, completion notice).

  • On‑call/escalation contacts for vendor and CLD during the window.

    PENDING: Status update cadence (e.g., every __ mins); communication channels

19.7 Production smoke tests #

Immediately after deployment, execute smoke tests covering critical flows: authentication (including MFA), role‑based access, file upload and AV scan/disposition, key business transactions, log emission to SIEM, and alert generation for test events. Document results and obtain ISO/IT Ops concurrence to lift heightened monitoring.

19.8 Heightened monitoring window #

Maintain heightened monitoring for an initial period after Go‑Live to catch regressions (e.g., 24–72 hours). Define thresholds for rapid rollback or fix‑forward. PENDING: Duration and thresholds

19.9 Acceptance of residual risk #

If any residual risk remains (e.g., an approved waiver), document it in the release record with owner, compensating controls, review date, and expiry. The Executive Sponsor must explicitly accept residual risk in writing prior to Go‑Live.

19.10 Records and retention #

Store all acceptance and Go‑Live artifacts—approvals, acceptance checklist, UAT results, security evidence confirmations, cutover plan, smoke test results, monitoring notes—in the release record and retain per the Records Management and Retention Schedule. PENDING: Repository/path for storing acceptance/Go‑Live artifacts

19.11 Exceptions #

Any deviation from this section (e.g., reduced acceptance evidence, expedited Go‑Live) requires a documented exception stating scope, rationale, compensating controls (e.g., extended monitoring, rollback readiness), owner, ISO recommendation, Executive Sponsor approval, and expiry.