I have been sitting with this question for some time. Maybe writing it down — in public — will help me think more clearly. And if it helps anyone else in the same chair, even better.
Some context first. I moved into Enterprise Architecture from an operations-heavy background, drawn by the chance to influence decisions earlier — before they harden into systems we eventually have to operate, scale, and pay for.
In organizations where business strategy drives technology — not the other way around — Business Architecture often does not live inside IT. It is distributed across the directorates that own the customer, the product, the channel, the revenue. Those are the people with the deepest grip on capability, value chain, and outcome. The Federated EA model does not cause this distribution; it formalizes a reality that was already there, and gives it a working language. IT Enterprise Architecture, the business domain architects, and Security Architecture — typically a peer domain in its own right, sometimes embedded inside IT, sometimes reporting separately to a CISO function — then operate side by side. Each guards its own slice, all aligned to the same corporate north star: the Corporate Strategic Plan (CSP) and the Roadmap Strategic Plan (RSP).
That third voice matters for the rest of this article. Risk management — particularly the security risk conversations I am about to describe — sits squarely under Security Architecture. Security architects are usually the ones holding the pen on residual risk decisions; IT EA and business domain architects are usually the ones whose designs are being assessed against them. The federation only works when those three voices are genuinely peers in the same room — not when one of them is treated as an upstream owner and the others as downstream supplicants, and not when one of them is invited only at the end to bless or block what the others have already shaped.
On slides, this collaboration looks elegant. In practice, it surfaces tensions that no architecture framework resolves neatly. The sharpest of these, for me, is risk.
The contradiction nobody wants to name out loud
Security risk and business risk are not always on the same axis. Sometimes they are openly contradictory.
A control that closes a security gap may close a customer experience window at the same time. Latency added by deeper inspection can erode a conversion path the business spent two quarters optimizing. A "secure by design" decision that delays go-to-market by a quarter can hand a competitor a window they will never give back. Conversely, a business shortcut that captures the quarter may quietly accumulate technical and regulatory debt that compounds for years.
Let me make it concrete with a deliberately generic illustration. Imagine a digital channel team that wants to ship a new flow that materially improves activation. The security review flags a low-probability, low-impact data exposure pattern. The "intolerable risk" doctrine kicks in. Mitigation is mandated. The mitigation adds two steps to the user journey, drops the funnel by a measurable percentage, and the activation gain — which was the whole point — is now neutralized. Security closed a tiny door. Business lost a real window. Who is accountable for the net outcome?
This is the question I keep getting stuck on.
So when "every risk is intolerable" meets reality
When an organization declares — with the best of intentions — that "every risk is intolerable," I find myself genuinely stuck.
What do we do with a risk rated low impact and very low likelihood? Do we mitigate it until the residual is zero? Is zero residue even physically possible in any system that humans actually use? Do we avoid it entirely — walking away from a business opportunity whose benefit clearly outweighs the exposure?
And here is the part that quietly bothers me: every mitigation has a cost. Sometimes financial. Sometimes friction in the user journey. Sometimes the mitigation itself creates a new business risk. We solve one threat and quietly birth another. A kind of conservation of risk.
Qualitative scales — high / medium / low — make this worse, not better. Two risks both labelled "low" can sit a couple of orders of magnitude apart in actual expected loss. When the scale cannot tell those apart, "intolerable" becomes a moral stance rather than an analytical one. And moral stances are notoriously hard to negotiate against.
A technical detour I cannot ignore — contextual residual
Before I get to Risk Acceptance, I want to put one engineering question on the table. I have been carrying it for a while and have not heard a satisfying answer.
A meaningful share of the "low likelihood, low impact" security risks that still demand a waiver or a Risk Acceptance signature appear to be assessed inherently at the application layer — Layer 7, in OSI terms — without crediting the controls that already exist at Layer 3 and Layer 4 beneath them.
Take a generic illustration. Suppose an application-layer vulnerability could, in isolation, only be exploited by an actor with direct network reachability to the service. In production, that service sits behind network segmentation, identity-aware access controls, and enforced mTLS at the transport layer. Those L3 and L4 controls already reduce the population of actors who could even attempt the L7 exploit to a small, controlled, and monitored set. In what world is the contextual likelihood at L7 still meaningfully above zero?
If the honest answer is "in some extreme world, technically, yes" — fine. But if the practical answer is "for operational purposes, no" — then the real question is not whether the risk exists. The real question is whether it is operationally meaningful. And if it is not, why are we still generating a Risk Acceptance signature for it?
This is what I mean by contextual residual risk. Inherent likelihood, assessed in isolation, is a theoretical artifact. Residual likelihood with compensating controls properly credited is much closer to the truth of what could actually happen in production. Defense in depth is not only a security posture — it is, mathematically, a multiplier of small numbers. Three independent controls each with a 10% failure rate combine to roughly a 0.1% compound failure rate. That is not absolute zero, but it is also not "we need a senior VP signature" territory.
So one practical move I keep coming back to — and would love to see more rigor around — is explicitly modelling compensating controls inside the residual likelihood calculation, not just listing them in a control register as decoration. If a Layer 7 finding has a credible mitigation path through existing L3 and L4 controls, the contextual residual should reflect that, and the administrative threshold for approval should scale accordingly. Otherwise we are treating defense in depth as a checkbox we got credit for once during architecture review and then never again during risk review.
This is not an argument against rigour. Compensating controls do fail. They drift. They get misconfigured. They get bypassed during incident response. The honest answer to "can the residual ever reach absolute zero?" is no — not in any system humans operate. But residual likelihood can get small enough that the administrative cost of clearing it formally exceeds any conceivable loss avoided. At that point, we are no longer managing risk. We are managing paperwork. And the difference between low in theory and unmitigated in practice versus low in theory and further dampened by three independent control layers already in place is, I suspect, where a lot of the friction between security and delivery is actually generated.
Risk Acceptance as the organization's unofficial landfill
Even with rigorous contextual modelling, some residuals will genuinely remain — and those are the ones worth a real conversation. So we land — predictably — at Risk Acceptance, signed off by some tier of management depending on residual severity.
This is where I want to ask the uncomfortable question: why has management — at any tier — become the place where risks go to be quietly buried?
Business outcomes are not management's private interest. They are the shared interest of every person from the most junior engineer to the CEO. Yet the ritual we have built treats Risk Acceptance as if it were a personal liability transfer — a signature that absorbs the residual so the rest of the organization can move on.
That feels both unfair to the signatory and intellectually dishonest about how risk actually behaves in a complex enterprise. And it has a second-order cost we rarely talk about: it teaches the organization that risk is somebody else's signature, not everybody's decision. The further you sit from the document with the signature line, the less you feel responsible for the risk you helped create — even though the consequences will land on shared P&L, shared customers, shared reputation.
If Risk Acceptance is the default exhaust valve, then what, honestly, is the function of Risk Management? A filter? A gatekeeper? A producer of registers nobody re-reads after the audit closes?
I do not think that is the intent. But I am increasingly worried it is becoming the practice.
A disclaimer before I propose anything
I am not a risk expert. I am certainly not a security expert. I am an architect who is trying to think clearly about a problem I run into every week. I am writing this not to prescribe — and not to expose how any specific organization handles it — but to invite sharper thinking from people who have spent more time on the risk side of the table than I have.
Where I suspect contextual risk quantification might help
A caveat upfront: what follows is a list of references I keep returning to when I try to think about this problem — not a list of frameworks I have personally deployed at enterprise scale. I am sharing them because they sharpen my thinking, and because I genuinely want to hear from people who have put them to work.
The idea I find most compelling in principle is FAIR — Factor Analysis of Information Risk [1]. The premise is to move beyond qualitative labels and toward quantified loss exposure in monetary terms. Done well, the trade-off should become visible: this control costs X; the loss event frequency it reduces is Y; the magnitude is Z. The conversation stops being "secure versus fast" and becomes "this much security buys us this much risk reduction at this cost." Decisions stop being moral arguments and start being economic ones. Doug Hubbard's work on measuring cybersecurity risk [2] sits alongside this, with the broader argument that anything that matters is measurable in some way, however imperfectly — and "we cannot measure it" is rarely true, just inconvenient.
Layered on top, ISO 31000:2018 [3] offers governance discipline and NIST RMF (SP 800-37 Rev. 2) [4] offers systematic categorization. And the often-skipped step — explicitly defining Risk Appetite and Risk Tolerance at enterprise level, in advance, traceable to the CSP and RSP — at least in theory would mean many "intolerable" judgments never need to reach a management desk. They would already be inside appetite (proceed) or outside it (redesign), with the criteria visible to everyone.
For the federation point specifically, the ArchiMate Risk and Security Overlay [5] is described as giving a shared vocabulary to model risk as a first-class concern alongside business capability, data, application, and technology — exactly where IT EA and business domain architects could use common ground. SABSA [6] — Sherwood Applied Business Security Architecture — is interesting on paper because it claims to treat security as a business architecture problem from the start, traceable from business attributes downward. And COSO ERM [7] frames risk, at the strategic layer, as something that should be integrated with strategy and performance rather than stapled to them after the fact.
Where I suspect these ideas hit their limits
Again, I have not pressure-tested any of these in production at enterprise scale, so I am repeating concerns I have read from practitioners more than claims I can defend from experience. With that caveat, the recurring caveats seem to be:
- FAIR is only as useful as the loss data and frequency estimates fed into it — and most enterprises reportedly have very little high-quality data on either.
- Risk Appetite statements, when written as marketing-style prose rather than decision-grade specificity, appear to do little useful work in the room.
- SABSA is praised for traceability but commonly described as heavy and slow to implement.
- ArchiMate overlays sound powerful but apparently demand modelling discipline most teams struggle to sustain.
I would love to be corrected, qualified, or pointed in a better direction by people who have actually run any of these at scale.
So I am not arguing for a tool. I am arguing for a habit: making the trade-off explicit — in numbers when possible, in shared language when not — before a single person is asked to absorb the residual on behalf of everyone else.
One provocative question — please push back
If a company genuinely believes every risk is intolerable, and yet every mitigation costs business value, and Risk Acceptance is just management absorbing what the framework cannot resolve —
Are we managing risk, or are we just redistributing it onto whoever signs last?
I would genuinely value hearing from CROs, CISOs, business architects, and fellow EAs — especially those who have made this work pragmatically, without turning Risk Acceptance into a quiet tax on senior leaders' inboxes. What changed in your organization when this started working? What should I be reading that I haven't?
The conversation is the point.
References
[1] Freund, J. & Jones, J. Measuring and Managing Information Risk: A FAIR Approach. Butterworth-Heinemann, 2014. See also: The Open Group, Risk Taxonomy (O-RT) Standard. https://www.opengroup.org/
[2] Hubbard, D. W. & Seiersen, R. How to Measure Anything in Cybersecurity Risk (2nd ed.). Wiley, 2023.
[3] ISO 31000:2018 — Risk management — Guidelines. International Organization for Standardization. https://www.iso.org/standard/65694.html
[4] NIST SP 800-37 Revision 2 — Risk Management Framework for Information Systems and Organizations. National Institute of Standards and Technology, 2018. https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final
[5] The Open Group. ArchiMate® 3.2 Specification — Risk and Security Overlay. https://pubs.opengroup.org/architecture/archimate3-doc/
[6] Sherwood, J., Clark, A. & Lynas, D. Enterprise Security Architecture: A Business-Driven Approach (SABSA). CMP Books, 2005. https://sabsa.org/
[7] COSO. Enterprise Risk Management — Integrating with Strategy and Performance, 2017. https://www.coso.org/
Views are my own and reflect personal reflection from practice — not the position of any organization I am affiliated with.