Security Steering vs Board Risk Committee

Most organisations have both a security steering committee and a board risk committee, yet few can say which one is allowed to accept a cyber risk, which one sets the appetite and what has to travel from one to the other. This guide compares the two bodies as governance mechanisms: their mandates, membership, decision rights, escalation paths and reporting cadence, with a worked scenario and a decision checklist for designing or fixing the pair. It is for CISOs, company secretaries, chief risk officers and heads of internal audit. Board reporting content is covered in the Board Cyber Risk Reporting Guide and the line-of-defence roles in the Three Lines Model for Cyber Risk Guide; this page focuses on how the two committees divide the work.

Key takeaways

Different questions, different owners. The steering committee is a management body that decides how cyber risk is treated within appetite; the board risk committee is a board body that recommends the appetite and oversees whether management is staying inside it.
Appetite flows down, exceptions flow up. The board approves the appetite and tolerances, the steering committee works inside them, and anything outside tolerance escalates to the risk committee with a recommendation, not a request for help.
Risk acceptance needs a written ladder. Every acceptance tier needs a named approver, a ceiling expressed in the same units as the appetite, and an expiry date; without it the steering committee becomes the default acceptor of everything.
Cadence should match the decisions. Monthly or six-weekly for the steering committee, quarterly for the risk committee (the UK Cyber Governance Code of Practice asks boards for formal reporting at least quarterly), and an out-of-cycle trigger list for both.
Regulators look at the board end. NIS2 Article 20, DORA Article 5 and the SEC's Item 106 all place approval or oversight duties on the management body or board, which cannot be delegated away to a management committee.

What each committee is for

The two bodies sit on different sides of the line between management and oversight. Confusing them is the root of most of the failure patterns later in this guide.

Security steering committee

A security steering committee (sometimes called an information security committee, cyber risk committee at executive level, or security governance forum) is a management committee. It is usually chaired by the CISO's executive sponsor (the CIO, COO or CRO) with the CISO as secretary or co-chair. Members are business and technology executives who own the systems and processes where cyber risk materialises: heads of business units, infrastructure, engineering, data, HR, legal, privacy and procurement. Its job is to turn the board-approved appetite into a programme: prioritise the security roadmap, allocate budget within the envelope the board approved, approve policies below board level, decide treatment for risks inside tolerance, accept risks within its delegated ceiling, and clear cross-functional blockers. In NIST SP 800-53 terms it is often the working form of the risk executive (function) that control PM-29 asks organisations to establish "to view and analyze risk from an organization-wide perspective".

Board risk committee

A board risk committee is a committee of directors. In listed companies and regulated financial firms it is typically chaired by an independent non-executive director, with a majority of independent members. The Basel Committee's corporate governance principles for banks say the risk committee should have an independent chair who is not the chair of the board or of any other committee, should be distinct from the audit committee, should advise the board on current and future risk appetite and oversee its implementation, and should receive regular reporting from the CRO on risk profile, appetite utilisation and limit breaches. Outside banking the same function may sit with the audit committee, an audit and risk committee, or a technology committee. Whatever its name, it oversees rather than manages: it recommends the cyber risk appetite to the full board, challenges whether management's assessment is complete, approves or recommends acceptance of risks outside tolerance, and confirms that assurance (internal audit, external testing) covers the material cyber risks.

Side-by-side comparison

Dimension	Security steering committee	Board risk committee
Nature	Management committee; executives acting under delegated authority	Board committee; directors exercising oversight
Typical chair	CIO, COO, CRO or CISO's executive sponsor	Independent non-executive director
Core question	How do we treat cyber risk within appetite, and are we delivering the programme?	Is the appetite right, is management staying within it, and is the assurance credible?
Decides	Roadmap priority, budget allocation within envelope, policy approval below board level, risk treatment and acceptance within delegated ceiling	Recommends appetite and tolerances to the board; approves or recommends acceptance above management ceilings; directs assurance
Does not decide	The appetite itself; acceptance above its ceiling; its own assurance	Which control or product to deploy; day-to-day prioritisation
Inputs	Risk register, control and project status, exception register, incident and threat reports, audit findings	Appetite dashboard, tolerance breaches, top risks with trend, material incidents, internal audit opinion, regulator correspondence
Cadence	Monthly or six-weekly, plus extraordinary sessions	Quarterly at minimum, plus out-of-cycle briefings
Output	Minuted decisions and actions, accepted risks with expiry, escalations to the risk committee	Minuted challenge and conclusions, recommendations to the board, requests for assurance
Regulatory hook	Evidence of a functioning governance structure (for example ISO/IEC 27001 clause 5 leadership)	Board duties: NIS2 Article 20 approval and oversight, DORA Article 5 management body responsibility, SEC Item 106 board oversight disclosure

Mandates and decision rights

The most useful single document for either committee is a decision rights matrix that sits behind the terms of reference. It should cover at least the decisions below. The split shown is a common pattern, not a rule; regulated firms will find some items fixed by their regime.

Decision	Steering committee	Risk committee	Full board
Cyber risk appetite statement and tolerances	Drafts with the CISO and CRO	Reviews and recommends	Approves
Cyber strategy and multi-year investment envelope	Drafts and prioritises	Challenges alignment with appetite	Approves
Top-level security policy	Recommends	Notes or recommends	Approves where the regime requires
Standards and supporting policies	Approves	Informed by exception	Not involved
Risk acceptance within tolerance	Approves above the risk owner's ceiling	Informed in quarterly summary	Not involved
Risk acceptance outside tolerance	Recommends with options and cost	Approves or recommends to board	Approves where above the committee's authority
Annual cyber assurance plan	Proposes scope from the risk register	Approves with the audit committee	Informed
Material incident disclosure decision	Prepares the materiality assessment	Briefed out of cycle	Decides where disclosure is a board matter

Write ceilings in the appetite's units: if the appetite is expressed as annualised loss exposure, the steering committee's acceptance ceiling must be too (for example, single risks up to a stated loss figure); if it is qualitative, use the same likelihood and impact scale. A ceiling in different units cannot be checked. The Cyber Risk Appetite Statement Template gives a structure.
Separate acceptance from exceptions: a policy exception (one system cannot meet a standard) is usually decided by the CISO or steering committee; a risk acceptance (the organisation will live with a residual risk) needs the ladder above. The Security Exceptions and Risk Acceptance Guide covers the workflow itself.
Keep the board's non-delegable items explicit: under NIS2 Article 20(1) the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Article 21 and oversee their implementation, and can be held liable for infringements. Under DORA Article 5(2) the management body bears the ultimate responsibility for managing ICT risk, sets and approves the digital operational resilience strategy including the ICT risk tolerance level, and approves the ICT third-party policy, the budget and the ICT internal audit plans. These can be prepared by management committees but not approved by them.

What each committee guards against

Each committee exists to stop a particular kind of governance failure. Designing them well starts from those failures, not from a template.

Failure the committee prevents	Steering committee control	Risk committee control
Security programme drifts from business priorities	Business owners in membership; roadmap reprioritised against the risk register each quarter	Checks strategy against appetite (Code action B2)
Risk accepted by someone without authority	Acceptance ladder enforced; register shows approver and expiry	Reviews accepted risks above a threshold; samples acceptance records
Management marks its own homework	Not the steering committee's job	Directs independent assurance; meets the CISO and head of internal audit without executives present
Cross-functional blockers stall remediation	Owners resolve blockers or escalate with dates	Sees ageing of overdue remediation as a tolerance metric
Board learns of a material risk from the press	Defined out-of-cycle escalation triggers	Agreed out-of-cycle briefing route to the chair
Appetite exists on paper only	Treatment decisions cite the appetite clause they rely on	Tolerances tracked each quarter; breaches require a management plan

The independence point matters. Basel's principles say the CRO should have direct access to the board or its risk committee without impediment and be able to meet them without executive directors present. Many organisations extend the same practice to the CISO, which the UK Code supports through action E3's call for regular two-way dialogue between the board and the CISO or equivalent. Where the CISO reports to the CIO, a private session with the risk committee chair once or twice a year is the cheapest safeguard against a filtered picture. See Where Should the CISO Report for the reporting line question.

Escalation paths

Escalation should be rule-based so that nobody has to judge in the moment whether the board needs to know. A workable design has three routes.

Scheduled escalation: the steering committee's last meeting before each risk committee produces a short escalation paper: tolerance breaches, risks recommended for acceptance outside tolerance, overdue high-risk remediation, and decisions the steering committee could not make. It is the only steering committee paper the risk committee needs as a matter of course.
Threshold escalation: a defined list of events that go to the risk committee chair within an agreed time, without waiting for the next meeting. Typical triggers: a risk moving outside tolerance with no funded plan; an incident assessed against the organisation's materiality criteria; a regulator's information request or notice; a critical supplier incident affecting key services; a significant audit finding the business disputes.
Incident escalation: during a live incident the crisis management team informs the board directly, not through either committee. The Briefing the Board During a Cyber Incident guide covers that route. Afterwards, the steering committee owns the lessons learned and the risk committee checks that they changed the risk assessment (the Code's action D4).

Where SEC rules apply, the materiality assessment for a cyber incident is time-critical: a Form 8-K Item 1.05 filing is generally due four business days after the registrant determines the incident is material. The escalation design should name who convenes the materiality decision and how directors are reached, so neither committee's calendar slows it. See the SEC Cybersecurity Disclosure Rules Guide.

Reporting cadence and packs

Item	Steering committee	Risk committee
Frequency	Monthly or six-weekly	Quarterly (UK Code action E2 asks for formal reporting at least quarterly)
Pack length	Working pack with detail and appendices	Short paper: decisions first, then appetite dashboard, then context
Metrics	Operational and programme metrics: patch and remediation ageing, control coverage, project milestones, exception counts	Tolerance metrics and trend: risks outside tolerance, top risks with direction, material incidents, assurance results
Risk register view	Full register for owned risks, with treatment status	Top risks and those outside tolerance only
Annual items	Policy review, roadmap refresh, budget proposal	Appetite review and recommendation, assurance plan approval, committee effectiveness review

Align the calendars so the steering committee meets two to three weeks before each risk committee. That gives time to write the escalation paper, have the CRO or second line add an independent view, and circulate papers a week ahead. The Board Cyber Report Template can be adapted for the risk committee paper; the steering committee pack should not simply be forwarded upwards.

Choosing the right design for your organisation

Small or unlisted organisations: one executive security and risk forum plus a standing cyber item on the board or audit committee agenda is usually enough. The key is still the written acceptance ladder and the appetite; a separate risk committee is not required by most non-financial regimes.
Listed companies outside financial services: cyber oversight often sits with the audit committee or an audit and risk committee. Under the UK Corporate Governance Code 2024, Provision 29 asks the board to monitor the risk management and internal control framework, review its effectiveness at least annually and, for financial years beginning on or after 1 January 2026, declare on the effectiveness of material internal controls. If cyber controls are judged material, the committee that prepares that declaration needs evidence from the steering committee's control monitoring.
Banks and insurers: a separate board risk committee is the norm and in many regimes expected; cyber sits within operational and ICT risk. DORA in-scope entities also need an independent ICT risk control function (Article 6(4)), which typically feeds the risk committee directly rather than through the steering committee.
Technology-intensive firms: some boards add a technology or cyber committee. Where they do, write a boundary into both terms of reference: the technology committee oversees strategy and delivery, the risk committee owns appetite and tolerance. Two board committees overseeing the same tolerance invites gaps.

Worked scenario: an unsupported platform outside tolerance

A payments business runs a core settlement application on an operating system that will reach end of vendor support in nine months. Migration needs eighteen months and a budget the current year does not hold. The appetite statement says the organisation has low appetite for unpatched systems supporting important business services, with a tolerance of no internet-reachable critical system without vendor support.

Risk owner assessment: the business owner and CISO assess the residual risk after compensating controls (network isolation, application allow-listing, extended support where available, enhanced monitoring). It remains above the owner's acceptance ceiling.
Steering committee: considers three options: fund accelerated migration by deferring two roadmap projects; buy extended support and accept a reduced residual risk; accept the risk as is. It approves the compensating controls, reprioritises the roadmap, and concludes that even with extended support the system will sit outside tolerance for about nine months. It cannot accept that, so it records a recommendation.
Escalation paper: one page to the risk committee: the tolerance breached, residual risk in the appetite's units, options with cost and timeline, the steering committee's recommendation, the expiry date for any acceptance and the metrics that will show progress.
Risk committee: challenges whether isolation has been tested, asks internal audit to validate the compensating controls within the quarter, and approves time-limited acceptance until the migration date with a monthly progress update to the chair. Because the service is in scope for operational resilience rules, it also asks whether the regulator needs to be informed.
Follow-through: the accepted risk enters the register with the risk committee as approver, an expiry date and a review trigger if the date slips. The steering committee reports progress monthly; the risk committee sees the trend each quarter until closure.

The steering committee did the option analysis and owned delivery; the risk committee owned the decision to operate outside tolerance and the assurance over it.

Implementing or fixing the pair

Inventory current bodies: list every forum that makes security decisions (architecture boards, change boards, data councils) and what they actually decided in the past year, from minutes.
Draft the decision rights matrix: start from the table above, mark non-delegable board items from your regulatory regime, and agree the acceptance ladder with the CRO and company secretary.
Rewrite both terms of reference: purpose, membership, quorum, decision rights by reference to the matrix, escalation triggers, cadence, secretariat, annual effectiveness review.
Align the appetite and metrics: make sure each tolerance has a metric the steering committee tracks monthly and the risk committee sees quarterly.
Pilot one cycle: run one quarter with the new escalation paper and acceptance ladder; ask risk committee members and the head of internal audit whether the paper told them what they needed.
Review and adjust: after two cycles, review decision latency and acceptances; retire any forum whose decisions are now covered elsewhere. If the new structure causes bottlenecks, raise the steering committee's ceiling rather than adding ad hoc approvals.

Measuring whether it works

Decision latency: median days from a risk being escalated to a decision being minuted, by committee.
Acceptance hygiene: percentage of accepted risks with an approver at the right tier, an expiry date and an open review; target 100%.
Expired acceptances: count of acceptances past expiry without renewal or closure.
Tolerance breaches with a plan: percentage of breaches reported to the risk committee with a funded, dated management plan.
Escalation timeliness: threshold events reaching the risk committee chair within the agreed time.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	GV.RM-01, GV.RM-02	Risk objectives agreed; appetite and tolerance statements established and maintained
NIST CSF 2.0	GV.RR-01, GV.RR-02	Leadership accountability; roles, responsibilities and authorities established
NIST CSF 2.0	GV.OV-01, GV.OV-02, GV.OV-03	Oversight of strategy outcomes and risk management performance
NIST SP 800-53 Rev 5	PM-9, PM-28, PM-29	Risk management strategy, risk framing, senior accountable official and risk executive (function)
UK Cyber Governance Code of Practice	A2, A3, E1, E2, E3, E4	Senior ownership, appetite, governance structure, quarterly reporting, CISO dialogue, assurance
NIS2	Article 20	Management body approval and oversight of Article 21 measures; training
DORA	Articles 5 and 6(4)	Management body responsibility for ICT risk; independent control function
SEC	Regulation S-K Item 106	Disclosure of board oversight and management's role

Common failure patterns

The risk committee as a second steering committee: directors receive the full operational pack, discuss tooling choices and never see a tolerance metric.
Acceptance by default: overdue remediation is silently treated as accepted. The register should show any open high risk without a treatment date as a breach, not an acceptance.
No expiry: accepted risks remain accepted for years after the conditions that justified them changed. Every acceptance needs an expiry and an owner.
Membership without authority: the steering committee is attended by delegates who cannot commit budget or people, so decisions are deferred. Require members who own the budgets at stake.
Filtered reporting: the only route to the board is through executives whose programmes are being assessed. A private session between the CISO and the risk committee chair closes it.

Practitioner checklist

Publish terms of reference for both committees that refer to one decision rights matrix.
Write the risk acceptance ladder in the same units as the appetite, with ceilings, approvers and expiry.
List the board's non-delegable cyber approvals from your regulatory regime and keep them off the steering committee's agenda.
Schedule the steering committee two to three weeks before each risk committee.
Replace forwarded packs with a one-page escalation paper and an appetite dashboard.
Agree threshold triggers for out-of-cycle escalation to the risk committee chair.
Give the CISO a private session with the risk committee chair at least annually.
Track decision latency, acceptance hygiene and expired acceptances each quarter.
Review both committees' effectiveness annually and adjust ceilings where decisions bottleneck.

Security Steering Committee vs Board Risk Committee: Mandates, Escalation and Reporting Cadence