In companies and public administrations, boards approve a cyber risk appetite, yet many cyber risks are accepted lower down the hierarchy. Of twelve standards and regulations reviewed, in force on 1 September 2026, none requires the acceptance record to name the threshold and its version.
The US National Institute of Standards and Technology (NIST) observes that many cyber incidents became well known because senior leaders did not know that lower levels of management were accepting serious risks (Quinn et al., 2025).
A security patch is available for the remote-access VPN gateway that a managed service provider runs for its clients. The provider weighs the disruption of applying it against the security benefit. It decides not to patch for now, documents its reasons and takes additional measures.
Regulation (EU) 2024/2690, which sets out how the NIS2 Directive (the EU law on the security of network and information systems) applies to providers such as this one, allows this under two conditions: the drawbacks of patching must outweigh the cybersecurity benefits, and the reasons must be documented and substantiated. The residual risk is then accepted, with adequate reporting to the management body. In European cybersecurity law, the management body is accountable for cyber risk. It includes the board.
In our example, one level up the hierarchy, the missing patch becomes “compromise of remote access“. Higher still, it becomes part of “interruption of client services“. At the top, it falls under one of the principal cyber risks for which the management body approved a risk appetite.
At board level, the VPN gateway vulnerability is no longer visible
Given our exemple, facing the principal cyber risk, a board should then ask: does this decision stay within the appetite it approved? Nothing in the regulation ensures that the board can answer. Reading “interruption of client services” in a report does not reveal that a VPN gateway was left unpatched. Beyond the documented reasons, the regulation does not say what the record of the decision, or the report to the management body, must contain.
Slapničar, Axelsen and Eulerich (2026) studied five large organisations, three in Australia and two in the European Union. Security managers in the second line of defence escalated a problem only when an exception exceeded a risk appetite threshold. The chair of the board risk committee at the bank in the study told the researchers: “if it’s not communicated to me, then I have to assume it’s not well managed.“
Academic research on board oversight has mostly focused on directors’ expertise. A field study finds that directors without cybersecurity expertise supervise cybersecurity in a mainly symbolic way (Lowry et al., 2026). In our view, expertise helps a board judge what it sees, but is not the definite nor the complete answer.
A question that comes before expertise
As part as our research stream at XRATOR, we asked: what must the record of an acceptance decision contain so that the board, or the level above, can check it?
We built a conceptual model with four levels of authority. The first three are the levels at which NIST places cyber risk management: the information system, the organisation (for example, a division, business unit or department) and the enterprise (the top level, such as a whole company). The fourth is the management body. We then reviewed twelve standards and regulations, including guidance documents such as NIST reports, that assign the authority to accept cyber risk, or organise risk management across these levels, in their versions in force on 1 September 2026.
Thresholds pass down, and each level regroups the risk
In the standards and regulations we reviewed, authority moves down as thresholds. In our example, the management body approves a risk appetite and a risk tolerance. The enterprise sets thresholds for priority risks. The organisation turns them into risk acceptance criteria, which the system owner applies.
The risk moves up: in these standards and regulations, risk registers are aggregated, and each level renames and regroups the risks of the level below.
In the study by Slapničar and colleagues, the chief information security officer of an insurer said: “We identified 957 risks, of which 29 are unacceptable, and others are within the tolerance.” The authors observed that cyber risk managers worked from their own registers. As a result, the enterprise risk register had become “rather obsolete”.
Two references an acceptance record should carry
An acceptance record is the signed record of one decision to accept a cyber risk. We argue that a decision taken lower down the hierarchy can be checked from above only if its acceptance record carries two references to higher levels. We call them links:
- the object link: the identifier of the higher-level risk to which the accepted risk belongs;
- the threshold link: the threshold that applied, in the version in force when the decision was taken.
In our model, a record without the object link cannot be attributed to one of the higher-level risks. When a level has set several thresholds, a record without the threshold link cannot be judged against the right one. Thresholds change over time: one study finds that firms lower their risk appetite after a successful cyberattack (Kamiya et al., 2021). When thresholds change, the record must also give the version, unless the record is dated and the level keeps a dated history of its thresholds. A link may skip a level. Where the chain of links breaks, every acceptance below the break is hidden from the levels above. Boards may still learn of such decisions through briefings or committee discussion; our research does not examine these channels.
None of the twelve texts requires a versioned threshold in each record
None of the twelve texts we examined requires an acceptance record to name the threshold that applied and its version. Two partly provide the object link :
- One NIST report, IR 8286C Rev. 1, specifies a required identifier that traces an aggregated risk entry back to its original register.
- The regulatory technical standards under DORA, the EU Digital Operational Resilience Act, link each information and communication technology (ICT) asset to the business functions it supports. They do not link it to a named higher-level risk.
The same DORA standards come closest to the threshold link. A review report, approved by the management body, explains the criteria used to accept the residual risk of uncorrected weaknesses, but not in each record and without a version.
Besides the two links (objet and threshold), these standards and regulations offer other tools, among them the date of the decision, a periodic review of accepted risks, and risk limits. In our analysis, none of these replaces the two links in general.
The date of the decision is enough when one threshold applies and its history is kept. When several thresholds exist at the same time, the date does not say which one the decision relied on. Nor does it say whether the decision was an override: an acceptance beyond the threshold, with a justification and the approval of a designated person.
The DORA technical standards require a review of accepted residual risks at least once a year. In our reading, such a review judges each acceptance against the threshold in force on the day of the review. Between two reviews, it says nothing.
Risk limits compare the level of risk held at one point in time with a threshold. A risk level is a state, not a decision. The same level can come from an acceptance within the threshold, from an override, or from an implicit acceptance. NIST uses the term implicit acceptance for a risk that has no clear, recorded response, for example when its treatment was postponed or never planned.
From a missed vulnerability patch to the board report
An acceptance record is the signed record of one decision to accept a cyber risk, such as a decision not to patch. In our model, each level may accept a risk only up to a threshold set by the level above, for example in its risk acceptance criteria. Going beyond it, with a justification and the approval of a designated person, is an override. At the top of the hierarchy sit the principal cyber risks, for which the management body approved an appetite. Two things should exist first: stable identifiers for enterprise risks, each attached to a principal risk, and versioned, or dated, risk acceptance criteria. An organisation can then make three changes (Figure 4).
1. Treat a missed patching deadline as a decision. If a security patch was due and has not been applied, ask the system owner for an acceptance record. This turns some implicit acceptances into explicit ones. We would start with overdue patches on critical or internet-facing systems. In the UK financial sector, the 2025 round of CBEST, attack simulations led by the financial regulators, found unpatched systems open to simulated exploitation (Bank of England et al., 2026).
2. Add two fields to every acceptance record: the object link and the threshold link. Keep the usual fields: system, reason, additional measures, signer, date and end date. Add the identifier of the enterprise risk that the decision belongs to, for example “ER-04, interruption of client services”. Add the reference and version of the risk acceptance criteria that applied, for example “AC-2, version 3”. Use stable identifiers, because labels change from level to level. Fill in both fields when the decision is taken.
3. Report three numbers to the board for each principal cyber risk:
- how many acceptances are in force;
- how many went beyond their threshold, with or without an approved override;
- how many were granted under a threshold that has since been made stricter.
Acceptances within their thresholds matter too. Ten of them can together exceed the tolerance of the level above, and systems that share a vulnerable component or a provider can fail together. With the enterprise risk identifier in each record, and each enterprise risk attached to a principal risk, these acceptances can at least be counted under the principal risk they belong to. For the UK National Cyber Security Centre (NCSC), one sign that a board understands cyber risk is knowing “how many risks are within the agreed threshold” (NCSC, 2023, reviewed 2025). The three numbers apply the same idea to decisions.
Two traps remain even with the two fields. First, the threshold field helps only if the threshold can be checked. In the five organisations studied by Slapničar and colleagues, cyber risk was measured qualitatively behind a “quantitative veneer”: the appearance of quantitative methods. Second, a risk owner can attach a decision to the higher-level risk with the least strict threshold, and the record will still look complete. Someone, for example the second line of defence or internal audit, should review what the two fields say. In our model, the two fields are necessary but not sufficient for a board to check these decisions. We make no claim about their effect on incidents.
An organisation does not need a new rule to start: it can write the two fields into its own risk procedure, and internal audit can then test against it. The danger is that the new fields become a formality.
Questions left open
The three changes say what to record and report. How to run them is for each organisation to decide, starting with questions such as these:
- Who asks for the record when a patching deadline is missed, who may sign it at each level of authority, and who compiles the numbers for the board?
- How often do the numbers reach the board: at each risk committee meeting, or once a year, for example with the yearly review of accepted risks that DORA requires of financial entities?
- Which tool holds the records, the enterprise risk identifiers and the versions of the criteria: the governance, risk and compliance (GRC) tool, the vulnerability management tool, or a spreadsheet?
- What happens to acceptances already in force: are the two fields added after the fact, and marked as such?
- How does the level above judge acceptances that add up within one principal risk, beyond counting them?
The answers decide whether the two fields become a working control or one more column in a register.
Conclusion : one number hides two kinds of decision
The “Beyond threshold” number in Figure 4 adds up two different counts:
- approved overrides: the person who accepted the risk went beyond their threshold, justified it, and a designated person approved the decision;
- unapproved excesses: the person who accepted the risk went beyond their threshold without the approval that the rules require, and so beyond what they were authorised to decide.
In our view, these two counts tell a board different things. In Figure 4, the “2” for operational disruption may be two approved overrides, two unapproved excesses, or one of each. Approved overrides show the rules at work. An unapproved excess shows a decision taken beyond the authority of the person who took it. One number cannot tell them apart.
Telling them apart takes two pieces of information in each acceptance record. The threshold link, the reference and version of the threshold that applied, shows that a decision went beyond its threshold, at least when a level has set several thresholds. The approval recorded beside it then separates the two counts. As our paper puts it, “An override needs this link most, because it is defined by the threshold it exceeds.”
A board report can keep one number and let the board’s risk committee ask for the detail, or it can report approved overrides and unapproved excesses side by side. Which of the two serves a board better is beyond the scope of our paper; we intend to examine this split in future research.
Further reading
- Mouchoux, R., & Moerman, F. (2026). Tracing cyber risk acceptance from the information system to the management body: A multilevel model (Working paper, version 2.3). XRATOR. SSRN: https://ssrn.com/abstract=7611320
- Slapničar, S., Axelsen, M., & Eulerich, M. (2026). Cyber risk management: An illusion of a risk-based approach. Journal of Management Control, 37(2), 359–394. https://doi.org/10.1007/s00187-025-00401-z
- Kamiya, S., Kang, J.-K., Kim, J., Milidonis, A., & Stulz, R. M. (2021). Risk management, firm reputation, and the impact of successful cyberattacks on target firms. Journal of Financial Economics, 139(3), 719–749. https://doi.org/10.1016/j.jfineco.2019.05.019
- Lowry, M. R., Vance, A., & Vance, M. D. (2026). Inexpert supervision: Field evidence on boards’ oversight of cybersecurity. Management Science, 72(2), 783–804.
- National Cyber Security Centre. (2023, reviewed 2025). Risk management for cyber security. In Cyber security toolkit for boards.
- Bank of England, PRA, & FCA. (2026). 2025 CBEST thematic.
- Quinn, S., Ivy, N., Barrett, M., & Witte, G. (2025). Prioritizing cybersecurity risk for enterprise risk management (NIST IR 8286B-upd1).
- Quinn, S., Ivy, N., Barrett, M., Smith, M., Gardner, R., & Witte, G. (2025). Staging cybersecurity risks for enterprise risk management and governance oversight (NIST IR 8286C Rev. 1).
- Commission Implementing Regulation (EU) 2024/2690, Annex, points 2.1 and 6.6.
- Commission Delegated Regulation (EU) 2024/1774, Articles 3, 4 and 27.
