Board leadership should own the definition of risk tolerance, because it sets the boundary within which CIO and CISO decisions must operate. That shared framework prevents one function from optimising for speed while the other optimises only for control. Clear ownership also makes accountability visible, which helps teams resolve trade-offs faster and reduces political conflict over security decisions.
Why Risk Tolerance Belongs at the Board Level
risk tolerance is not a technical tuning parameter, it is a business decision about how much uncertainty the organisation is willing to carry in pursuit of speed, resilience, cost, and growth. IT and security both execute inside that boundary. When the board owns the boundary, CIO and CISO decisions can be compared against the same threshold instead of competing as separate priorities.
That matters because operational trade-offs are rarely purely technical. A faster release cadence, broader access, or delayed remediation may be acceptable in one business context and unacceptable in another. Board ownership creates a consistent decision frame, so the organisation does not end up with one function optimising for delivery while the other optimises for control in isolation.
It also clarifies accountability. If risk tolerance sits with management, the question of who accepted the residual exposure can become blurred after the fact. A board-owned tolerance statement gives executives a decision boundary they can apply when weighing exceptions, compensating controls, and investment timing.
How the CIO and CISO Fit Within That Boundary
The CIO and CISO should inform, recommend, and operationalise the tolerance set by leadership. The CIO brings knowledge of business enablement, architecture, reliability, and delivery constraints. The CISO brings threat exposure, control effectiveness, and consequences if trust is broken. Their roles are complementary, but neither should redefine the organisation’s acceptable level of risk on their own.
For practitioners, the practical test is whether a decision changes the organisation’s exposure in a way the board would recognise as material. If it does, the decision belongs in the governance conversation, not as an isolated IT or security preference. If it stays within the approved tolerance, IT and security can execute using their normal delegated authority.
- Use the board-approved tolerance to resolve disputes about acceptable delay, temporary exceptions, and compensating controls.
- Let CIO and CISO own implementation choices, control design, and escalation thresholds inside that boundary.
- Require both functions to report the same trade-off in business terms, not separate technical narratives.
That approach reduces the common failure mode where IT treats a risk as an availability issue and security treats the same issue as an unacceptable exposure. A shared tolerance frame forces the organisation to decide once, then act consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Defines enterprise risk appetite and tolerance governance for security decisions. |
| GV.OV — Oversight | Places governance oversight with leadership for accountable security decision-making. | |
| GV.SC — Cybersecurity Supply Chain Risk Management | Board-level tolerance often determines acceptable third-party and dependency exposure. | |
| Recommendation — Align IT and security decisions to the board-approved risk management strategy. Assign oversight to leadership so tolerance decisions are visible and enforceable. Set risk thresholds for third-party exposure and dependency acceptance. | ||
| CIS Controls v8 | 17 — Incident Response Management | Requires leadership-backed decisions for escalation and acceptance of security exposure. |
| 14 — Security Awareness and Skills Training | Governance decisions rely on shared understanding of risk, roles, and accountability. | |
| Recommendation — Use leadership-approved thresholds to decide when exceptions require escalation. Train executives and managers on their roles in risk acceptance and escalation. | ||
Practitioner Guidance
What to verify: The tolerance statement should be explicit enough that CIO and CISO can apply it without re-litigating intent for every exception. If the boundary cannot be used to approve, reject, or escalate a decision, it is too vague to be operationally useful.
Decision rule: If a proposed action crosses a material risk threshold or changes the residual exposure profile, escalate it to the board or the board committee that owns risk oversight. If it stays inside the approved tolerance, keep execution with management and document the decision trail.
Common mistake: Treating risk tolerance as a security policy artifact. Policy can express controls, but tolerance defines how much controlled exposure the organisation is willing to accept in exchange for business outcomes.
Practitioner takeaway: The most effective model is board-owned tolerance, executive-owned execution. That separation keeps accountability visible, prevents function-level optimisation from distorting decisions, and gives IT and security a stable decision boundary to work within.
Related resources from NHI Mgmt Group
- Who should own data risk remediation when security teams cannot fix every issue themselves?
- Who should own access decisions when security policy is centralised but each application has different business requirements?
- Who should own risk appetite decisions in identity and security programmes?
- Who should own insider risk decisions when signals span security, HR, and legal?
