Canonical Exception Management Process
Formal, cross-cutting and authoritative process for the management of exceptions to security requirements and controls in SbD-ToE
Formal, cross-cutting and authoritative process for the management of exceptions to security requirements and controls in SbD-ToE
Binary control checklist of the application of governance practices per project
Specifics of exception management in the context of secure deployment - emergency deploy, break glass and deviations from promotion gates
Organisational policy that defines the formal process for reviewing and approving IaC execution plans (terraform plan or equivalent) before any apply in staging or production environments, including segregation of duties, plan signing, dual approval and execution windows, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the formal go/no-go decision process for software releases, including approval authorities by criticality level, separation between automatic signal and human decision, formal acceptance of residual risk and recording of evidence, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for the deployment process (DPL-001 to DPL-011), with applicability by risk level and acceptance criteria for formal approval, artefact provenance, automated gates, rollback, deployment credentials, staging, post-deployment monitoring, release gates for agentic systems and end-to-end traceability.
Organisational policy that defines the requirements for the formal approval of software releases, including a pre-release security checklist, an automated compliance gate, go/no-go criteria, an immutable decision artefact and end-to-end commit→pipeline→release traceability, proportional to the criticality level (L1, L2, L3).
Cross-cutting organisational policy that defines the formal process for the submission, assessment, approval, recording and reassessment of exceptions to mandatory security controls, with approval authorities proportional to the application's risk level. It applies to all SbD-ToE chapters in which there are controls with formal mandatory status.
Responsibilities of the Tech Lead in SbD-ToE