Canada Luggage Depot - Secure SDLC
Exceptions, Risk Acceptance, and Enforcement

26. Exceptions, Risk Acceptance, and Enforcement #

26.1 Purpose #

Define how temporary deviations from this policy are handled, who can approve them, how residual risk is accepted, and how non‑compliance is enforced. Exceptions enable controlled progress when a control cannot be met immediately; they do not waive the control’s intent.

26.2 When an exception is required #

An exception is required when a requirement in this policy or an approved standard cannot be met as written, including (but not limited to): missing evidence at a gate, deferred remediation beyond SLA, use of non‑approved data residency, non‑standard identity/logging integrations, reduced testing coverage, or temporary operational shortfalls (e.g., reduced support coverage). Emergency waivers used during an active incident must also be documented as exceptions post‑facto.

26.3 Exception request content (minimum) #

Each request must use the approved template and include:

  • Scope: exact system/component, environments, data categories, and controls affected.

  • Rationale: why the requirement cannot be met now; business impact of delay.

  • Risk assessment: likelihood/impact, affected threat scenarios, and any privacy impact (attach DPIA excerpt if applicable).

  • Compensating controls: concrete, measurable safeguards to reduce risk (e.g., WAF rule, reduced token TTLs, IP allowlists, heightened monitoring, restricted roles, manual approvals).

  • Owner: named individual responsible for remediation and ongoing monitoring.

  • Duration: start date and an expiry/review date (shortest practical; default maximum PENDING: __ days ).

  • Remediation plan: specific steps and target date to meet the original control (POA&M entry ID).

  • Approvals requested: ISO recommendation and Executive Sponsor approval; Legal/Privacy review if privacy‑impacting.

    PENDING: Exception request template location/link

26.4 Approval workflow #

ISO reviews the request, validates risk and compensating controls, and recommends approval/rejection or modifications. Legal/Privacy reviews exceptions involving PI, cross‑border storage/access, or retention/deletion deviations. The Executive Sponsor grants or denies final approval. No exception is valid until recorded in the Exception Register with all approvals.

26.5 Duration and review #

Exceptions must be time‑bound and reviewed at or before expiry.

  • Maximum initial duration: PENDING: __ days unless otherwise justified.

  • Review cadence: at least monthly for Critical/High‑risk exceptions; at least quarterly for Medium/Low.

  • Renewal: requires updated risk assessment, evidence of progress, and explicit re‑approval; serial renewals are discouraged. Exceptions with no evidence of progress may be revoked.

26.6 Monitoring and conditions #

Compensating controls must be in place before an exception is active and must be monitored continuously (e.g., SIEM alerts for WAF rule hits; dashboards for abuse spikes). If conditions worsen (e.g., exploitation observed, greater exposure, new data categories added), the exception must be re‑evaluated immediately and may be revoked.

26.7 Registers and traceability #

Maintain an Exception Register and a Risk Acceptance Register with: ID, title, system, data categories, environments, rationale, risk rating, compensating controls, owner, start date, expiry, approvals, and links to POA&M items and relevant tickets. References to approved exceptions must appear in the related release records and in Post‑Deployment Reviews until closure. PENDING: System/repository for the registers

26.8 Residual risk acceptance #

When residual risk remains after compensating controls, the Executive Sponsor must accept it in writing, with clear articulation of the risk, conditions, and review/expiry dates. ISO countersigns. Risk acceptance never replaces the remediation plan; it documents the risk until remediation.

26.9 Emergency waivers #

During active incidents, the ISO (or delegate) and IT Operations may authorize temporary waivers to implement immediate containment or fixes. Emergency waivers must be documented within PENDING: __ hours after stabilization with scope, actions taken, risks introduced, compensating controls, owner, and expiry, and must follow the approval workflow retroactively.

26.10 Enforcement and consequences #

Non‑compliance without an approved exception, or failure to honor exception conditions, may result in:

  • Release block or rollback until requirements are met.

  • Suspension of privileged access for responsible parties until training or remediation is complete.

  • Contractual remedies for vendors (credits, formal corrective action plan, up to termination under contract terms).

  • Escalation to the Executive Sponsor and, if applicable, client notification per contractual obligations.

26.11 Escalation #

If an exception is denied and the business still requires movement, the Product/Process Owner may escalate to the Executive Sponsor with ISO input. The Sponsor’s decision is final. Privacy‑impacting exceptions require Legal/Privacy concurrence.

26.12 Closure #

An exception is closed when the original control is met and compensating controls are removed (if desired). Closure requires ISO confirmation and update of the Exception Register and linked POA&M. Evidence of remediation (e.g., scan results, configuration diffs, release references) must be attached.

26.13 Reporting #

The ISO reports exception metrics to leadership per Section 24: count by severity, average age, approaching expiries, overdue items; highlight any with repeated renewals or SLA‑breaching risks.

26.14 Relationship to contracts and law #

Nothing in this section permits deviation from contractual or legal requirements without explicitly addressing those obligations in the exception (e.g., client approvals where mandated). Where law or client contract is stricter, that standard prevails; exceptions that would violate law or contract cannot be approved.