NIST CSF 2.0's Govern Function, Read as a Bank Board's Job Description

Bank directors who still treat cyber risk as an IT matter are behind both the framework and the regulator. NIST's Cybersecurity Framework 2.0 put governance at the center by adding a Govern function. In Sri Lanka, the Central Bank's Banking Act Directions No. 16 of 2021 already converts most of Govern's outcomes into board-level duties for licensed banks. Use Govern as the structure for the board's cyber agenda and CBSL's Direction as the minimum it must cover.

What Govern asks for

NIST CSWP 29, published 26 February 2024, organizes the CSF Core into six functions: Govern, Identify, Protect, Detect, Respond and Recover. NIST says CSF 2.0 "contains new features that highlight the importance of governance and supply chains." It defines Govern this way: "The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored."

Govern has six categories:

• Organizational Context (GV.OC): mission, stakeholder expectations, dependencies, and legal, regulatory and contractual requirements are understood
• Risk Management Strategy (GV.RM): priorities, constraints, risk tolerance and appetite statements are established and used for operational decisions
• Roles, Responsibilities, and Authorities (GV.RR): accountability is established and communicated
• Policy (GV.PO): cybersecurity policy is established, communicated and enforced
• Oversight (GV.OV): results of risk management activities are used to adjust the strategy
• Cybersecurity Supply Chain Risk Management (GV.SC): supplier risk is managed by organizational stakeholders

Three subcategories describe board work most directly. GV.RR-01: "Organizational leadership is responsible and accountable for cybersecurity risk." GV.RM-02: "Risk appetite and risk tolerance statements are established, communicated, and maintained." And GV.OV-01 through GV.OV-03, which require that strategy outcomes and risk management performance are reviewed and used to adjust direction.

Where CBSL has already made it mandatory

The Monetary Board issued Banking Act Directions No. 16 of 2021 on 9 December 2021. It applies to all licensed banks, including operations run through agents and third-party service providers. The regulatory framework on technology risk management and resilience sits in Schedule I. Direction 4.1 states that the Board of Directors "shall establish adequate oversight measures to ensure implementation" of that framework.

Mapping Govern to the Schedule I framework:

• GV.RM-02 (risk appetite and tolerance) → Framework 4.6.2: the Board "shall ensure technology risk appetite is defined through a framework of clearly delineated and measurable technology risk indicators with approved risk tolerance levels." Framework 4.6.3 adds that technology risk is assessed within the bank's ICAAP.
• GV.RR (roles and accountability) → Framework 4.1: an Information Security Committee (ISC) is the apex management body for information security and technology resilience, chaired by the CEO, with the COO, CISO, CIO and SOC manager as ex-officio members.
• GV.OV (oversight) → Framework 4.1.6: the ISC reports to the Board through the Board Integrated Risk Management Committee (BIRMC) at least quarterly. Framework 4.5: banks must regularly report their information security and technology risk profile, together with incidents, to the Board through BIRMC "using both standard risk indicators and ad-hoc reports." Direction 7.1: internal audit assesses compliance and reports to the Board through the Board Audit Committee at least annually.
• GV.RR-01 (leadership accountability) → Framework 5.1.1: an annual training and awareness program for the Board, consisting of at least one structured training program and one or more awareness sessions every year, aimed at enabling effective oversight.

The ISC must meet at least once every two months under framework 4.1.7. That gives the board a reporting rhythm without inventing one.

Govern supplies the structure. CBSL's Direction sets the minimum the structure has to carry.

The failure mode: dashboard theater

One way this goes wrong is dashboard theater. The board receives a quarterly pack full of activity counts: patches applied, phishing tests run, alerts closed, training completion. The numbers move. Nobody can say whether the bank is inside or outside its approved risk tolerance, because no tolerance was ever expressed in those terms.

Framework 4.6.2 rules this out on paper. It requires measurable indicators tied to approved tolerance levels. A pack of activity counts satisfies 4.5's reporting duty in form and fails 4.6.2 in substance. When an incident happens, the record will show a board that was informed and could not have known.

Building a board pack that works

Ordered steps for the CISO and company secretary:

1. Write the tolerance statements first. For each critical service, state the tolerance in business terms: maximum acceptable outage, data loss, or fraud exposure. These are your GV.RM-02 statements and your 4.6.2 tolerance levels.
2. Pick indicators that measure distance from tolerance. Each indicator should answer "how close are we to the line?" Activity counts can stay in the appendix.
3. Build a current and target profile. CSF 2.0 Organizational Profiles describe current and target outcomes. A one-page gap between the two gives the board something to approve and fund.
4. Fix the reporting chain. ISC to BIRMC quarterly (4.1.6), incidents and risk profile to the Board (4.5), audit through the Board Audit Committee annually (Direction 7.1). Put the dates in the board calendar.
5. Record the decisions. Minutes should show what the board accepted, rejected, or asked to change. Oversight that leaves no record cannot be evidenced later.
6. Schedule board training against the gaps. Use the 5.1.1 sessions to cover what the board needs to challenge management, not a generic threat briefing.
7. Add the supply chain line. GV.SC covers supplier risk. Schedule I also applies the requirements through agents and third-party providers. Report critical supplier exposure in the same pack.

Questions a director should be able to answer

• What is our approved technology risk tolerance for each critical service, and are we inside it today?
• Which indicators would tell us first if we were drifting outside it?
• When did the ISC last report to BIRMC, and what did BIRMC escalate?
• What did internal audit last report on technology risk compliance, and what has been closed since?
• Which third parties could cause an outage beyond tolerance?

A director who can answer these is doing what Govern describes and what CBSL requires. Incident reporting is a separate CBSL obligation with its own clock, covered in Building a Two-Hour Incident Response Engine.