Canada Luggage Depot - Secure SDLC
Governance and Gates

6. Governance and Gates #

This section defines the minimum decision points (“gates”) every vendor change must pass. Each gate requires specific approvals and evidence. No production change may bypass a gate without an approved exception.

6.1 Intake Gate (initiate) #

Purpose Confirm the business need, data sensitivity, residency, and high‑level risk before design/build.

Required inputs

  • Business case and high‑level requirements (owner, scope, success criteria).
  • Data classification overview (what PI is processed; whether images are captured; expected volumes).
  • Residency statement (Canada‑only by default; any known cross‑border touchpoints).
  • Initial risk/privacy triggers (e.g., new PI, new purpose, new integration).

Approvals

  • Product/Process Owner: business need and initial requirements.
  • ISO: initial security/privacy posture; gate to Design or request more info.
  • Legal/Privacy when privacy triggers exist (DPIA required or not).
    PENDING: DPIA trigger checklist location/link

Deliverables (store with project record)

  • Intake form (one page), high‑level data flow sketch, decision and next steps.

6.2 Design Gate (approve to build) #

Purpose Ensure security, privacy, and operational patterns are correct before implementation.

Required evidence

  • Updated requirements mapped to acceptance criteria.
  • Data flow diagram (systems, stores, integrations, subprocessors) and residency map.
  • Identity design (SSO/MFA, roles, service accounts), logging design (events/fields), crypto and key handling.
  • API and file‑upload protections; WAF posture; rate limits; secure headers; error handling.
  • Privacy elements (minimization, retention/deletion, subject‑rights enablement).
  • Operational patterns (monitoring/alerts, backups/restore approach, rollback concept).

Approvals

  • Product/Process Owner: business fit.
  • ISO: security/privacy design approval.
  • Legal/Privacy: when DPIA/residency exception is required.
  • IT Operations: feasibility and observability acceptance.
PENDING: Identity specifics — IdP/protocols, standard roles; Logging/SIEM specifics — forwarding method; Residency exception package contents and approval workflow

6.3 Pre‑Production Gate (approve to release) #

Purpose Verify the build is secure, tested, observable, and reversible.

Required evidence (minimal release package)

  • SBOM for the release build. PENDING: Format — SPDX/CycloneDX; delivery location
  • Security test summaries: SAST, SCA, secrets scan, DAST (web/API), container/IaC scans when applicable.
  • Open findings register with POA&M; waivers (if any) approved by ISO and time‑bound.
  • Change log (functional, security, operational impacts).
  • Deployment plan and rollback plan (pre‑checks, triggers, steps, validation).
  • Logging schema (if changed) and SIEM routing verified; dashboards/alerts defined.
  • Data‑flow update (if changed); updated admin/user guides (if changed).
  • UAT evidence and acceptance sign‑off by Product/Process Owner.

Approvals

  • Product/Process Owner: UAT complete, acceptance confirmed.
  • ISO: security evidence and risk posture.
  • IT Operations: operational readiness (monitoring, runbooks, backups/restore).
PENDING: Fail‑gate thresholds (e.g., block on Critical/High); CLD log forwarding decision; UAT evidence minimums; release notice periods

6.4 Go‑Live Gate (deploy to production) #

Purpose Confirm final readiness and authorize production deployment.

Readiness checks

  • Deploy window/notice met; on‑call and escalation paths active.
  • Backups verified recent; recovery steps known; rollback rehearsed (tabletop minimum).
  • WAF/API protections enabled; alerts routed and tested.
  • Access reviews completed for admin/support roles; break‑glass controls sealed.

Approvals

  • ISO + Product/Process Owner (joint).
  • Executive Sponsor when residual risk/exception remains.
PENDING: Change windows by risk; on‑call acknowledgment SLOs

6.5 Post‑Go‑Live Review (stabilize and learn) #

Purpose Validate stability/security post‑deployment and capture improvements.

Activities (within 30 days)

  • Review incidents, alerts, error rates, and performance; confirm no new PII exposure.
  • Verify completion of outstanding POA&M items; close waivers or re‑justify with new expiry.
  • Update runbooks, dashboards, and training where needed; feed backlog with improvement items.

Ownership

  • ISO coordinates; Product/Process Owner and Vendor provide data; IT Operations supplies telemetry.

6.6 Exceptions at Gates #

Any attempt to pass a gate with missing evidence or unmitigated risk requires a documented exception that includes scope, rationale, risk assessment, compensating controls, owner, and expiry. ISO recommends; Executive Sponsor approves. Privacy‑impacting exceptions require Legal/Privacy review. PENDING: Exception template location

Gate artifacts retention All gate decisions and evidence packages must be retained with the project/release record per the Records Management and Retention Schedule. PENDING: Repository/path for storing gate artifacts