How to Codify Cyber Risk Decisions 2

Legal liability of the boards

Board members occupy a particular position in the information chain: they sit at the end of it while carrying disproportionate exposure — reputational, financial, and regulatory — when threats they were never properly told about materialize. That exposure is now formally codified, and it is worth being precise about how, because the three instruments most often cited in the same breath do different things.

DORA, in force across the EU since January 2025, places ultimate responsibility for managing ICT risk on the management body itself under Article 5 — not on a delegate, and not on a function. NIS2 goes further in Article 20: management bodies of essential and important entities must approve cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements. The SEC’s 2023 rule is a different animal and is regularly overstated. It requires a registrant to disclose how its board oversees cyber risk, and to report material incidents within four business days. It creates a disclosure obligation on the company rather than a duty on the director, and the Commission explicitly dropped the proposed requirement to disclose board-level cybersecurity expertise, reasoning that cyber risk is not intrinsically different from other risks directors assess without subject-matter expertise.

The European instruments are the ones that changed the position. Working from the same incentive logic that governs the rest of this problem, the legislator made the absence of a strategic risk evaluation capability something other than an organisational weakness. It is now an exposure carried personally by the people at the top.

Part of that capability lives at the level of mental models and situational awareness, and comes only with experience. Some of it can be codified. But codification presupposes an answer to a question most organisations have never settled: who is making the decision in the first place. That is where this has to start.

Classification errors mimicking faulty culture

Ask most organisations about what security measures they need and the answer arrives as a threshold. A certification to hold, a framework to satisfy, a maturity level to reach. Then the managerial work becomes optimising the cost of getting there. That logic is coherent, widely taught, and wrong at the root — the question that produces the threshold belongs to a category information security does not fit.

Most organizations manage security as though it were a support function, in something close to the sense Michael Porter gave the term when he separated support activities from primary ones in the value chain: an activity that generates no revenue directly but enables the primary activities to run. On that reading the managerial logic follows. Define the minimum the function must reach, the target ceiling, and optimize the cost of reaching it. This is where the popularity of standards and certifications comes from. They define an externally verifiable ceiling at minimal definitional effort on the organization’s part.

I observed leadership conflicts regarding cyberrisk for more than 15 years, and came to the conclusion that this reading is fundamentally wrong. Security is not a support function. It is the operational capability of every function in the organization to perform its work within acceptable boundaries. The objection to the support-function reading is not that information security matters to the business. Every support activity matters to the business — procurement stops the factory, payroll stops the workforce. The objection is about independence.

You can set a cost target for procurement without changing what the factory is able to build. You can specify a service level for facilities without narrowing what any department is permitted to do. That separability is the precondition under which “define the ceiling, optimize the cost” is a coherent instruction at all. Information security has no such separability. The level of protection on a system is a parameter of what the owner of that system is allowed to do with it. Raise it and the sales team loses speed. Lower it and they gain speed and carry the exposure. Since it impacts data flow and thus processes, there is no protection level you can set without simultaneously setting the operating envelope of the function it covers. This correlation can be illustrated in more detail using the traditional CIA model:

Confidentiality determines the organization’s capacity to hold competitive advantage, avoid regulatory penalties, and keep its reputation. All three bear directly on market position and finances, and none of them sits inside the security team’s remit.

Availability follows directly from system resilience. An incident that paralyzes the ERP, the production line, or the customer service platform is not primarily an IT problem. It is an operational problem for every unit that depends on those systems, and those units conduct the primary activities.

Integrity of data and processes decides whether the systemic mechanisms underpinning business functions work as designed: whether analyses come out right, whether decisions rest on true data, whether processes execute the way they were built to. An organisation with compromised integrity does not know it is making bad decisions, which is the failure mode that costs the most and shows the least.

Each of those is a business decision wearing technical clothing. The security team is responsible for execution. The business owns the risk, and it is the only party positioned to say where the line between risk and opportunity falls and to carry the uncertainty that line involves. The uncertainty is not an accident - much of it is produced by people with reasons to produce it.

Turning the intruder into an advisor

The significance of this seemingly trivial perception shift becomes clearer when you look at how it lands on mid-level leadership and their structural incentives.

In an organisation where the CISO is solely responsible for data protection, conflict with the sales or marketing director is merely a matter of time. When it arrives, the CISO is often perceived as an intruder who complicates the process of how business achieves its goals. Because every incident is his responsibility, his political position deteriorates with each one, which makes the next conflict harder to solve and the work less effective. He becomes a service provider to business area owners, expected to understand and anticipate needs he is not told about. Sales protects revenue, the CISO protects data. Cooperation is enforced and rarely effective.

In an organisation where the CISO acts as a consultant and an architect, building tools for the department heads who are responsible for protecting the data they process, a completely different dynamic emerges. The business proactively looks for risk and consults the security team willingly, because the risk is theirs. Incidents become a shared responsibility — the CISO’s if he built faulty protection for the risks described to him, the business unit’s if it withheld information, failed to provide complete requirements, or ignored the rules. Neither side can settle the question alone, which is exactly why they have to cooperate and find common language.

What separates the two organisations is where the ownership of risk was placed when the operating model was drawn. That is why the first case reads as a culture problem and never resolves like one. Replace the people and the dynamic returns within a year, because the structure that produced it is still there.

Placement follows one rule, and the rule scales. Ownership sits with the function that creates the exposure, and it travels upward with the size of what is exposed. A decision that puts one team’s quarter at stake belongs to the person running that team. A decision that puts a product line, a market, or the operating licence at stake belongs further up, and at the top of that scale it belongs to the management body — which is where the legal instruments described above have now placed it explicitly. The security function owns the existence of the mechanism: that there is a way for the question to be framed, priced, and put in front of whoever the impact says should answer it. GRC owns that the mechanism runs: that the decision was actually taken, recorded, and revisited when conditions moved.

Compliance as a substitute for strategy

Compliance, as an instrument for standardizing solutions to complex problems, is a rational answer to informational chaos. Where a balanced compromise between cost, responsibility and threat is hard to reach, standardization supplements judgment. It confers a sense of control, simplifies internal and external communication and, importantly, transfers responsibility. An organization holding ISO 27001 certification at the moment of an incident has a procedural argument in its favor, and under GDPR and NIS2 documented compliance can genuinely narrow the range of regulatory sanction. It is even more attractive from the service provider’s side. Every consulting company strives to productize, or at least standardize, delivery. Bespoke, first-principles implementations require rare talent and price themselves above what most clients expect to pay. That approach narrows the addressable market, makes sales far harder, makes scaling nearly impossible, and strengthens the employee’s position relative to the board. No sane operator volunteers for that.

But the problem does not lie in the compliance mechanism itself. One can argue that some requirements could have been drafted with more care, but no system applied at that scale is going to be perfect. The problem is that compliance distorts leaders’ perception: it covers the question “do we respond to our actual exposure?” with the question “do we meet a general set of requirements?”, and presents the two as equivalent. Nearly every other actor in the cybersecurity decision chain will advocate for that substitution, since most of them benefit from it — except the leader, the one legally responsible for the actual outcome. That substitution is what corrupts strategic thinking.

A particularly stark example of this mechanism is supply chain security. In the vendor-buyer relationship, the certificate serves as a substitute for verification: the buyer stops at its presence, and the supplier optimizes the process for the cost of obtaining it instead of for resilience. When a security model is implemented to minimize the cost of certification and not to reduce exposure, the result is mechanisms that simulate resilience in place of mechanisms that provide protection. The consequence is worse than an unverified supplier, because it removes attention instead of merely failing to add it. Without the certificate, the buyer knows the risk is open: the security team monitors the cooperation environment, defines its boundaries with controls, and keeps a remediation plan for incidents. With a certificate on the supplier side and a compliance-shaped third-party management process on the buyer’s, the relationship looks settled and the security team’s attention goes elsewhere. The organisation is not merely exposed. It is operating based on a threat model that is not true.

How this impacts decision making

A conclusion is just as obvious as it is uncomfortable to state publicly: nobody manages cybersecurity risk out of abstract responsibility. It gets managed because incidents take down critical systems, drive customers away, and trigger regulatory fines, and if those consequences did not exist, neither would the interest. It is the starting point for a proper conversation about risk, because it identifies who actually bears the consequence and therefore who has to make the call.

Under the operational-capability model, the decision about the level of protection is inseparable from the decision about the scope and quality of what each function can deliver. Every increment of protection is paid for in flexibility, speed, or freedom to innovate, and every increment declined is paid for somewhere else. Balancing between the two deliberately is what makes risk management a strategic function, and it is what unlocks the organization’s full potential instead of capping it.

If supplemented with a formalized decision framework it allows for adequate distribution of responsibilities by deconstruction of unmanageable overloads at the very top. It aligns decisions of the person who runs the function and owns the risk with the person who understands the threat. Structured form ensures continuity in case of personnel rotation and allows traceability within the decision chain.

Notice what liability under these instruments actually attaches to. Neither DORA nor NIS2 makes a director answerable for an incident. They make the management body answerable for the oversight — for whether the exposure was considered, by someone competent to consider it, on grounds that can be stated afterwards. An incident on its own establishes nothing. What establishes a breach is the inability to show that anyone decided.

That is the practical value of codifying the decision, and it runs in two directions at once. Downward, it moves the judgment to the function owners who hold the information, which is the only place it can be made well. Upward, it converts an open-ended personal exposure into a bounded one: not an obligation to have foreseen the incident, but a record of who weighed what, against which alternatives, and why the answer was reasonable at the time. The board stops carrying the whole of a risk it was never positioned to see, and starts carrying the part it actually controls — whether the mechanism that produces those decisions exists and works.

No certification delivers that, because the record it produces describes conformance to somebody else’s requirements. The record you need describes your own reasoning.

Which raises the obvious question of what that record looks like. No published framework describes such a system end to end. ISO 31000, COSO ERM and the GOVERN function added to NIST CSF in 2024 all establish that the decision has to be made and who approves it. None of them supplies the apparatus for making it when the probabilities underneath cannot be defended. A few reference models cover parts of that gap.

Do not focus on loss minimisation alone

Cyber risk management methods in common use are built around one dimension: how to cover the highest-priority threats within an imposed budget while accepting the smaller ones. This is loss-minimization logic, optimizing against a single ranked threat set. Where the goal is fixed and probabilities can be estimated and defended, it is the right instrument. Here it fails for two reasons.

It degrades exactly where cybersecurity is hardest. Ranking threats by likelihood presumes a distribution nobody in the chain can substantiate — which is the deep uncertainty problem the whole domain sits inside, not a defect of any particular method. I set out how that uncertainty gets produced in The Uncertainty Is Not an Accident article.

Board members face a different, complex problem. Their objective function is not minimizing expected loss but optimizing the relationship between exposure and opportunity. Taking on more risk sometimes pays, when measurable business gains follow. The question “should we secure ourselves further?” cannot be settled without simultaneously answering “what do we surrender in flexibility, speed, and capacity to innovate?”.

Consider hypothesis-driven development as an illustration — the approach used in the early stages of development of innovative products. Deliberately accepting certain gaps in security architecture while critical business hypotheses are still being tested can, in some cases, be the robust choice. The cost of an incident at an early stage may fall below the cost of a slow, defensive development process for a product that turns out to be unprofitable, in financial terms and in reputational ones. What separates this decision logic from negligence is one thing: the first is conscious, calibrated, and bounded in time. The second is not.

It is worth keeping in mind this is also the exact point at which function directors notoriously forget to update the evidence trail of what was accepted and why — particularly when the acceptance sits close to a legal or ethical boundary.

Reference architecture models

Between them, these two models cover more of a decision framework than their reputations suggest. FAIR supplies the measurement layer: a disciplined way to express exposure in money and set it against the gain being pursued. RDM supplies the selection criterion: a way to choose between options when the distributions underneath them cannot be defended. Those are two of the three parts you need, and both are well documented.

FAIR — Factor Analysis of Information Risk. As a quantification framework it is a more adequate instrument than ISO 27005 for this problem, because it permits analysis of exposure against potential gain rather than exposure alone. It also integrates readily into ISO-based risk processes, which already work with likelihood, impact and control effectiveness in a form FAIR can consume. It has a boundary worth stating plainly. FAIR handles parameter uncertainty — ranges and distributions over inputs that a calibrated estimator can bound. By itself it does not handle disagreement about the model, which is the harder case and the more common one.

Robust Decision Making. Developed at RAND for problems where forecasts cannot be trusted, RDM answers the harder case by inverting the question. It does not ask which future is most likely. It asks under which conditions a given strategy fails, how plausible those conditions are, and which alternative performs acceptably across the widest range of them. The criterion shifts from expected loss to regret: not what will this cost me on average, but which choice would I most regret across the futures I cannot rule out. RDM does not slot into an ISO process the way FAIR does — it came out of public policy analysis and assumes an analytical apparatus most organisations do not run. What transfers is the shape of the question, and the shape is the part that matters.

The third part is the one no published model provides: who decides what, at which level, and on whose record. That is not an oversight in the literature. It follows from the fact that this layer sits on your operating model — on your delegation limits, your governance calendar, your existing risk and control functions. Any version of it written without those produces a template people comply with instead of a framework they use, which returns you to the problem this article opened with.

The rest is the part nobody can codify on your behalf: knowing which of the signals reaching you have been shaped, by whom, and in whose interest. Codification does not remove that judgment. It records it — so that a year later, when the conditions have moved, someone can reconstruct what was decided, on what basis, and whether the reasoning still holds.