Exceptions in Secure Deployment
The base process, approval authorities, mandatory fields, chain of authority and lifecycle are defined in Ch. 14 -
addon/12-processo-excecoes.md. This file defines only the specifics of this domain.
Scope
Exceptions to requirements of the secure deployment catalogue: DPL-001 to DPL-009. This includes the emergency deploy (break glass) scenario as a case of immediate exception with post-facto evidence.
Triggers specific to this domain
- an emergency deployment (critical hotfix, response to an incident in production) that cannot wait for the normal approval and gates process - "break glass" (DPL-001, DPL-003);
- an artefact without verifiable provenance in a disaster recovery context where the normal pipeline is unavailable (DPL-002);
- staging not sufficiently representative of production for a given type of validation, with documented technical justification (DPL-007);
- rollback not testable for a given legacy component - with operational compensation (DPL-005);
- progressive deployment architecturally unfeasible for a specific component, with technical justification (DPL-009).
Emergency deploy - break glass
The emergency deploy is the only scenario in which the exception may be approved post-facto, immediately after the deployment and before the end of the deployment window. It is not a permanent bypass - it is a one-off, traceable exception.
Specific requirements:
| Element | Mandatory |
|---|---|
| Reference to the incident or emergency reason | Yes |
| Notification to the CISO or equivalent before or during the deployment | Yes |
| Emergency change record in the change management system | Yes |
| Post-facto approval within a maximum of 24h after the deployment | Yes |
| Documented post-mortem with cause analysis and corrective actions | Yes |
| Process review to prevent recurrence | Recommended |
The absence of an emergency change record or of the notification to the CISO invalidates the emergency deploy as an exception - it becomes an unauthorised deployment.
Additional mandatory fields (deployment)
| Field | Mandatory | Notes |
|---|---|---|
| Deployment / release ID | Yes | Unique traceable identifier |
| Affected environment | Yes | staging / production / etc. |
| Promoted artefact(s) | Yes | Name, version, commit SHA |
| Gates not executed | Yes | Which gates were skipped and why |
| Reference to the incident (if emergency) | Conditional | Mandatory in break glass |
Cross-references
| Document | Relation |
|---|---|
00-catalogo-requisitos.md | DPL-001..009 catalogue - requirements that may have exceptions |
04-validacoes-pre-deploy.md | Security gates that may be the object of an exception |
06-controle-versao-e-rollback.md | Rollback as compensation in deployment exceptions |
Ch. 07 - addon/09-controle-excecoes-visibilidade.md | Bypass of CI/CD gates - distinct from the emergency deploy to production |
Ch. 14 - addon/12-processo-excecoes.md | Canonical exception management process |