Skip to main content

Exceptions to Secure Architecture Requirements

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 architecture catalogue: ARC-001 to ARC-013.

Triggers specific to this domain​

  • phased migration between environments or architectures with a bounded window of non-compliance and a completion plan;
  • integration of a legacy or third-party component with no possibility of architectural modification within the scope of the project;
  • cost of architectural refactoring disproportionate to the effective risk level of the context (L1);
  • architecture decision documented in an ADR with explicit and approved risk acceptance.

Identification of the affected requirement​

  • canonical ID from the catalogue (e.g. ARC-003, ARC-008);
  • operational tag (e.g. SEC-L2-ARC-003);
  • reference to the associated ADR, if one exists.

Integration with architectural traceability​

Exceptions to ARC requirements must be reflected in the traceability matrix (06-rastreabilidade.md), with:

  • identification of the threat not mitigated by the missing control;
  • reference to the ADR that documents the decision and the conditions for reversal;
  • expiry date aligned with the architecture plan.

Exceptions not recorded in the traceability matrix are treated as a coverage gap.

Normative alignment​

  • ISO/IEC 27001 A.18.1.4 - formal acceptance of residual risks
  • SSDF GV.3 - approval of exceptions and deviations from security processes
  • OWASP SAMM Governance - recording and lifecycle of exceptional decisions

Cross-references​

DocumentRelation
01-catalogo-requisitos.mdCatalogue ARC-001..013 - requirements that may have exceptions
06-rastreabilidade.mdTraceability matrix where the exception is recorded
Ch. 14 - addon/12-processo-excecoes.mdCanonical exception management process