Security Governance Committee Charter Template: Mandate, Membership and Reporting

Many organisations have a security steering committee that meets, reviews slides and decides nothing, because no document says what it is allowed to decide, who must attend or what it owes the board. A charter fixes that. NIST CSF 2.0 expects roles, responsibilities and authorities for cybersecurity risk management to be established, communicated, understood and enforced (GV.RR-02), the UK Cyber Governance Code of Practice asks boards to establish a cyber governance structure with clearly defined roles (action E.1) and formal reporting at least quarterly (E.2), and US registrants must describe which management committees assess and manage material cybersecurity risk under SEC Regulation S-K Item 106(c)(2). This template gives an executive-level security governance committee a mandate, decision rights, membership, quorum, reporting lines and a self-assessment cycle, including oversight of non-human identities and AI agents. It is written for CISOs, chief risk officers, company secretaries and general counsel setting up or rewriting a committee.

How to use this template

• Replace text in square brackets, such as [Organisation], [Committee name] and [Board risk committee], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
• This charter is for a management committee that reports to a board committee. Board committee terms of reference are set by the board and company secretary; align the two so that escalation routes match.
• Decide early whether one committee covers cyber, privacy and AI risk, or whether separate committees exist. If they are separate, define the hand-offs in section 2 to avoid gaps, for example for AI agents that hold credentials and process personal data.
• Keep the decision rights in section 4.2 consistent with your risk appetite statement and delegated authorities. See the Cyber Risk Appetite Statement Template.
• Have legal and the company secretary review the charter before approval, particularly where minutes may be relevant to regulatory disclosures.

1. Purpose

The [Security Governance Committee] ("the Committee") is established by [Executive committee / Chief Executive Officer] to direct and oversee the management of cyber and information security risk at [Organisation]. Its purpose is to:

• Set security strategy and priorities within the risk appetite approved by the [Board of directors].
• Take the security risk decisions delegated to it, and escalate those outside its authority.
• Monitor security performance, key risk indicators (KRIs) and remediation against agreed tolerances.
• Provide the [Board risk committee] with accurate, timely information on cyber risk, incidents and the effectiveness of security controls.

2. Scope

The Committee's remit covers cyber and information security risk across [Organisation] and its subsidiaries, including:

• Information systems, cloud services, operational technology and data, wherever hosted or processed.
• Identity and access risk for workforce, customer and non-human identities, including service accounts, API keys, tokens, certificates and AI agents.
• Supplier, SaaS and supply chain security risk.
• Security aspects of new products, acquisitions, major change programmes and AI deployments.
• Incident preparedness, response and lessons learned for cyber incidents.

Out of scope: [physical security / fraud / privacy compliance], which are governed by [other committee]. Where a matter falls under more than one committee, [Chair] agrees with the other chair which committee leads and records the decision.

3. Roles and responsibilities

3.1 Membership

Members may nominate one named deputy of appropriate seniority. Deputies count towards quorum no more than [twice] per year per member.

3.2 Responsibilities

• Chair: sets agendas with the CISO, ensures decisions are recorded and actions owned, and reports to [Board risk committee].
• CISO: issues papers at least [5] business days before meetings, maintains the decision and action logs, and reports KRIs against tolerance.
• Members: attend, prepare, take decisions in the interest of [Organisation] as a whole, and drive actions in their areas.
• Risk owners: attend when their risks, exceptions or remediation plans are discussed.

For how first, second and third lines should sit on the Committee, see the Three Lines Model for Cyber Risk Guide.

4. Policy statements

4.1 Authority

1. The Committee acts under authority delegated by [Executive committee] and within the risk appetite and tolerances approved by the [Board of directors].
2. The Committee may request any information, and the attendance of any employee or supplier, it needs to perform its duties.
3. The Committee may commission independent reviews or external advice within a budget of [£X] per year.

4.2 Decision rights

4.3 Meetings and quorum

1. The Committee meets at least [monthly / every six weeks], and at least quarterly before each [Board risk committee] meeting.
2. The quorum is [four] voting members including the Chair (or a nominated alternate chair) and the CISO or deputy, and at least one member from outside technology.
3. Decisions are taken by consensus; if consensus is not reached the Chair decides and any dissent is minuted. Matters where the CISO dissents on a risk acceptance must be reported to the [Board risk committee].
4. Extraordinary meetings may be called by the Chair or CISO at [24] hours' notice, for example during a major incident. Decisions may be taken by written resolution if all voting members respond.
5. Members must declare conflicts of interest, for example in supplier decisions, and do not vote on those matters.

4.4 Standing agenda

1. KRIs against tolerance, with amber and red items and remediation plans.
2. Significant incidents and near misses since the last meeting, and lessons learned.
3. Risk acceptances and exceptions for decision, and the exception register summary.
4. Programme delivery against the roadmap.
5. Threat and regulatory changes requiring action. See the Regulatory Change Management Guide.
6. Identity risk, including NHI ownership coverage, secrets exposure and the AI agent register [quarterly].
7. Audit findings and their status.

4.5 Reporting

1. The Chair and CISO report to the [Board risk committee] at least quarterly, covering KRIs against tolerance, material risks, decisions taken under delegated authority, incidents and audit findings.
2. Matters outside the Committee's authority, KRIs in red for Averse categories and incidents that may be material or notifiable must be escalated to [Board risk committee chair] within [X] business days, without waiting for the next scheduled meeting.
3. Minutes, the decision log and the action log are retained for [7] years and made available to internal and external audit.

5. Exceptions

Where the Committee cannot meet quorum or timing requirements, for example during a major incident, the Chair and CISO may take urgent decisions jointly. Each such decision must be recorded with its reason and ratified at the next quorate meeting. Variations to this charter itself may only be made under section 7.

6. Compliance and monitoring

• Attendance: the secretary records attendance; members below [75%] attendance over a year are raised with the Chair.
• Self-assessment: the Committee assesses its own effectiveness annually, using member questionnaires and a review of decisions and outcomes, and reports the results to [Board risk committee].
• Independent review: [Internal audit] reviews the Committee's operation against this charter at least every [two] years. See the Internal Audit for Cybersecurity Guide.
• Measures: quorate meetings as a percentage of scheduled; papers issued on time; actions closed by due date; average age of open risk acceptances; red KRIs with an approved plan within [30] days; escalations made within the required time.

7. Review and approval

This charter is owned by the [Chair] and approved by [Executive committee], with the [Board risk committee] informed of changes. It is reviewed at least annually and after any significant change in governance structure, regulation or a major incident.

Implementation guidance

Setting up the committee

1. Map existing forums first. List every group that already takes security decisions (architecture board, change board, risk committee, AI review board). Merge or retire overlaps before creating another meeting.
2. Agree decision rights before membership. Fill in section 4.2 with the CRO and company secretary, aligned with the delegated authority matrix and risk appetite. Membership follows from who must be present for those decisions to stick.
3. Pick a business chair. A chair from outside the security function signals that the risk belongs to the business, and lets the CISO present and challenge rather than mark their own homework.
4. Design the pack. Keep it to KRIs against tolerance, decisions required and exceptions. Reuse the board format so the quarterly report is a summary, not a rewrite. See the Board Cyber Risk Reporting Guide.
5. Pilot for one quarter. Run three meetings under a draft charter, then adjust cadence, quorum and decision thresholds before formal approval.
6. Exercise it. Include the Committee in an annual incident exercise, which also supports action D.2 of the Cyber Governance Code of Practice. See the Tabletop Exercise Guide.
7. Review after a year. Use the self-assessment to drop agenda items that never lead to decisions.

One committee or several: decision guidance

For AI review bodies, see the AI Ethics Board and AI Review Committee Guide.

Common failure patterns

• Information-only meetings: without decision rights, the committee receives updates and nothing changes. Section 4.2 must list real decisions.
• CISO as chair and sole voice: the business never owns the risk and acceptances look self-approved.
• Delegates of delegates: unlimited deputies hollow out authority; cap them as in section 3.1.
• Machine identities invisible: the agenda covers patching and phishing but never service accounts, keys or AI agents. See the NHI Ownership Guide.
• No escalation between meetings: a material incident waits for the quarterly cycle. Section 4.5 rule 2 prevents this, and SEC Form 8-K Item 1.05 requires disclosure generally within four business days of a materiality determination for US registrants.

Mapping to frameworks and governance requirements

Item 106(c)(1) asks registrants to describe the board's oversight of cybersecurity risk, including any board committee responsible and how it is informed; (c)(2) covers management positions or committees, their expertise, how they monitor prevention, detection, mitigation and remediation, and whether they report to the board. A charter and minutes in this form give the evidence behind that description.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• UK Government: Cyber Governance Code of Practice
• NCSC: Board Toolkit
• eCFR: 17 CFR 229.106 (Regulation S-K Item 106) Cybersecurity
• SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure fact sheet
• FRC: UK Corporate Governance Code 2024

This template is provided for guidance and must be adapted to your organisation. It summarises governance requirements and is not legal advice. Related NHI Mgmt Group resources: Board Cyber Risk Reporting Guide · Security Policy Framework Guide · Identity Security Programme Guide · AI Governance Guide · CISO Guide: First 90 Days