The problem in plain language
A design review approves a deviation from a security standard because of a business constraint. The architecture diagram records the technical choice, while the exception is captured in a ticket, spreadsheet or email. Months later the business can see what was built but not easily why the risk was accepted, who owns it or when the exception should be reconsidered.
What the buyer is actually trying to solve
The buyer needs a defensible chain from architecture decision to risk statement, treatment, accountable owner, compensating controls and review date. This lets future change teams distinguish deliberate accepted risk from accidental drift.
Evidence and system mechanism
NIST IR 8286 Rev. 1 describes cybersecurity risk registers as a mechanism for documenting and communicating cybersecurity risk within enterprise risk management. NIST’s RMF Authorize step emphasises accountability through a senior official’s determination of whether system security and privacy risk is acceptable, supported by authorization evidence and risk responses. The operational implication is that risk acceptance should remain connected to the system decision it governs.
Problem owner and why now
Security architecture, system ownership and enterprise risk functions share responsibility. Urgency rises after incidents, audits, architecture changes, mergers or staff turnover, when teams must explain why a control is absent or different from the standard.
Economic consequence
Disconnected exception records create repeated review effort, weak audit evidence and the risk that temporary deviations become permanent without reassessment. They also slow change because new teams cannot tell which design constraints are intentional. Useful measures include exceptions without owners, exceptions past review date, architecture decisions without linked risk records and compensating controls that cannot be evidenced.
Root cause
The root cause is usually fragmented governance tooling. Architecture, risk, tickets and compliance evidence are managed as separate records without durable identifiers or relationships between them.
Practical intervention
- Define a unique identifier for each material security exception or accepted-risk decision.
- Link the affected architecture component, system and business service.
- Record risk description, owner, response, compensating controls and review trigger.
- Make exception status visible in architecture and change-review workflows.
- Reassess the decision when dependencies, threats, control capability or business context change.
- Retire the exception explicitly when the underlying condition no longer exists.
Diagnostic questions
- Can an architect see the active risk exceptions affecting a system?
- Can a risk reviewer see the exact architecture decision an exception authorises?
- Does every exception have an accountable owner and review trigger?
- Are compensating controls linked to evidence?
- Can temporary deviations expire without anyone noticing?
What good looks like
Architecture and risk records form one traceable decision chain, so deliberate exceptions remain visible, owned and reviewable throughout the system lifecycle.
Where Mellorca fits
Mellorca can map architecture and risk workflows, establish linked governance records, automate review triggers and improve evidence traceability across security, infrastructure and application change.
Sources and further reading
- NIST IR 8286 Rev. 1 — Integrating Cybersecurity and Enterprise Risk Management
- NIST RMF — Authorize Step
Method note
NIST guidance establishes risk-governance principles; it does not prescribe a specific commercial architecture repository or exception-management platform. The relationship model should fit the organisation’s governance environment.