CSF 2.0’s biggest addition was the one a security team could not deliver

The week

On Monday, February 26, 2024, the National Institute of Standards and Technology released version 2.0 of its Cybersecurity Framework: the first major rewrite in a decade of a document almost nobody outside a specialist field reads, and one that much of regulated industry relies on.

NIST is a US federal agency best known for weights, measures and technical standards. It introduced the Cybersecurity Framework, usually shortened to the CSF, in 2014. A framework, in this sense, is neither a law nor a product but an organized checklist of outcomes: the things a well-run organization should be able to say about how it protects its computers and data. It works like a building code for cybersecurity, except that following it is voluntary.

The framework had a specific origin. Executive Order 13636, issued by President Obama in February 2013, directed NIST to work with industry on a voluntary framework for critical infrastructure, and version 1.0 followed in February 2014. Congress gave NIST’s role a statutory footing later that year in the Cybersecurity Enhancement Act of 2014. Version 1.1, in April 2018, added material on supply chain risk and on self-assessment. In May 2017, Executive Order 13800 went further for one audience: it required federal agencies to use the framework to manage their own cyber risk.

Version 2.0 came out of a public process that ran for about two years. NIST requested information from the public in 2022, published a concept paper in early 2023 and a full draft in August 2023, then revised the text after comments on that draft. The final document dropped the old title, “Framework for Improving Critical Infrastructure Cybersecurity,” and became simply the NIST Cybersecurity Framework 2.0.

Three changes in version 2.0 stood out.

First, the audience grew. The original framework was written with critical infrastructure in mind: power grids, water systems, banks and hospitals. Version 2.0 broadened its stated audience to organizations of all sizes and sectors, from a small credit union to a large federal agency.

Second, it added a sixth core function. The framework had always been built around five verbs: Identify (know what you have), Protect (guard it), Detect (notice when something goes wrong), Respond (act on it) and Recover (get back to normal). Version 2.0 added Govern, alongside the other five. Govern has six categories: organizational context, risk management strategy, roles and responsibilities, policy, oversight, and cybersecurity supply chain risk management.

The core grew to six functions, 22 categories and 106 subcategories, the detailed outcome statements that organizations assess themselves against. Govern was not built from nothing. Version 1.1 had governance, risk management strategy and supply chain categories, all filed under Identify. Version 2.0 lifted them out, expanded them and drew Govern at the center of its diagram, explaining that it informs how an organization implements the other five functions.

The document also described its readers differently. Its audience section lists, beyond the people who run security programs, executives, boards of directors, acquisition professionals, lawyers, human resources specialists, risk managers and auditors. That list was the clearest signal of where NIST expected the new work to land.

Third, NIST made the framework easier to use. It published implementation examples, quick-start guides and an online reference tool mapping the framework to other standards, so organizations could see how CSF outcomes lined up with rules they already followed.

Two older tools were reworked as well. Organizational Profiles let an organization describe its current posture and a target posture in the framework’s terms, then plan to close the gap. Community Profiles let a sector or other group publish a shared target. Tiers, numbered one to four and named Partial, Risk Informed, Repeatable and Adaptive, describe how rigorous an organization’s risk governance and risk management practices are. NIST encouraged moving to a higher Tier when risks or mandates are greater, or when a cost-benefit analysis supports it, rather than as an end in itself.

The framework remained voluntary. The release came in the same week that the Change Healthcare outage was spreading through the health sector, a vivid reminder of what happens when a single supplier sits at the center of an industry.

UnitedHealth Group, which owns Change Healthcare, had disclosed the intrusion in a securities filing on February 22. By the end of the month the company had attributed it to the ransomware group known as ALPHV or BlackCat. Pharmacies were struggling to process prescription claims, and providers were starting to worry about payments. NIST had not designed Govern with that incident in mind, but the timing made its supply chain category hard to read in the abstract.

The Cybersecurity Framework is a shared vocabulary across regulated industries. Banks map to it alongside their examiners’ expectations. Health systems use it with HIPAA, the federal health privacy and security law, and the HHS cybersecurity performance goals. Many states reference it in policy. When a bank’s chief information security officer talks to a hospital’s, or a regulator talks to either, the CSF is often the common language.

Version 2.0 kept the familiar functions, so most organizations responded the usual way: the security team updated its control mapping. A control mapping is a spreadsheet that lines up each framework outcome against the specific safeguards the organization has in place, such as “we require two-factor login for remote access.” It is useful, careful work, and it is almost entirely the security team’s job.

NIST made that response easy. It published material showing how the version 1.1 outcomes moved into version 2.0, and its reference tool exported the core in formats a spreadsheet could absorb. A team could load the new outcomes, re-point its existing controls, flag the handful of new subcategories and report the upgrade complete. For many teams that was a sensible first step. It was also incomplete, because a mapping records which controls exist, and Govern is mostly about who decides.

That missed what Govern changed. Almost nothing in its six categories can be delivered by a security team alone. They sort into four groups of work, each owned somewhere else: direction, set by executives; people, shared with human resources; suppliers, shared with procurement and legal; and oversight, owned by the board. Together they cover every Govern category once.

Five functions a security team can run, and one it cannot

The original five functions describe the work of a well-run security department. Identify is the inventory: what computers, data and services do we have, and which matter most? Protect is the locks and alarms: passwords, encryption, staff training. Detect is the monitoring: noticing an intruder. Respond is the incident plan. Recover is getting systems and services back.

All five are things a competent security team can largely do, given budget. So for its first decade the framework mostly lived inside IT.

Govern is different in kind. It is not about what the security team does, but about the decisions that should frame its work: how much risk the organization is willing to take, who is accountable for what, which suppliers the business depends on, and how leadership checks that things are working. A security team can choose good tools and run them well. It cannot decide how much the organization should spend, how much risk to accept, or who answers for each piece. Govern covers that part of the job.

What moved, and what was new

Part of Govern was reorganization. Version 1.1 already asked for governance policies, a risk management strategy and supply chain risk management. It filed them under Identify, where they read as inputs to the security team’s inventory work. Placing them in their own function, and drawing that function at the center of the framework’s wheel, changed their status. Everything else now follows from them.

Part of it was new. The subcategories ask that leadership be responsible and accountable for cyber risk, and that resources match the strategy. They ask that cybersecurity be built into human resources practice, and that cyber risk enter enterprise risk management through a standardized method. Each is aimed at people outside the security team. One subcategory even asks organizations to consider positive risk: the strategic opportunities a stronger security posture might open up. That conversation belongs to a business strategist more than an engineer.

The Tiers changed meaning too. Each Tier now describes governance practice separately from risk management practice. An organization can run Detect and Respond with real rigor while its governance remains ad hoc, with risk strategy applied case by case and supplier risk largely unknown. Plenty of CISOs would recognize that combination: capable security operations under disengaged leadership. The framework now gives them a way to describe it.

The strongest objection

A fair objection holds that Govern adds paperwork and little else. Large banks already had risk appetite statements. Federal agencies already had authorizing officials who formally accept the risk of each system. Public companies were already describing board oversight to the SEC. For those organizations, a framework function changes no legal duty.

The objection holds for the documents and fails for the connections between them. A bank may have a risk appetite statement with no cyber tolerance in it. An agency may have authorizing officials signing system-level risk acceptances that nobody ever adds up at the enterprise level. Govern’s value lies in joining artifacts that already exist, and that joining is exactly the work that falls between departments.

Treating CSF 2.0 as a mapping update therefore missed what was new. The new categories describe work that, in most organizations, nobody had formally been asked to do.

Direction: context, strategy and policy

Three categories set direction. Organizational context asks what the mission is, which stakeholders and legal obligations matter, and which services others depend on. Risk management strategy asks for risk appetite and tolerance, stated and communicated. Policy asks for a cybersecurity policy that follows from both.

Two terms are worth pausing on. Risk appetite is the broad amount of risk an organization is willing to accept in pursuit of its goals; it is a statement of attitude, such as “we have low appetite for disruption to customer payments.” Risk tolerance turns that attitude into numbers, such as “payments may be unavailable for no more than four hours.”

In many organizations the CISO set cyber risk tolerance by default, through what got funded and which exceptions were signed. Enterprise risk management, the function that looks at all of an organization’s risks together, set appetite for everything else, on a different scale. Govern asks for the two to meet.

What that looks like varies by sector.

• In a regional bank, it means a cyber section in the board-approved risk appetite statement, with measurable tolerances such as maximum tolerable downtime for payments.
• In a health system, it means an executive decision on acceptable clinical system downtime against the cost of resilience.
• In an agency, it means tying cyber to the agency’s enterprise risk profile under existing federal risk guidance.

The practical test is simple. The organization should be able to name the executive who accepted its largest cyber risk, and the document where that acceptance is recorded. If the answer is the CISO and a ticket, direction has not been set. (A ticket is an entry in the IT team’s work-tracking system, which is not where a board would expect to find a decision of that weight.)

There is a trade-off. Executives who formally accept cyber risk will ask harder questions about cost, and some will accept more risk than the CISO would like. The framework intends exactly that. A tolerance the business has chosen, and can be held to, is more durable than a stricter one that only the security team believes in. It also gives the CISO a clear basis for escalation when actual exposure drifts past the agreed line.

Putting cyber risk on the enterprise scale

The framework asks for a standardized method for calculating, documenting, categorizing and prioritizing cyber risk, and for cyber risk to be included in enterprise risk management. NIST’s companion series on the subject, Interagency Report 8286 and its follow-on volumes, describes the plumbing. Each system or business unit keeps a cybersecurity risk register. Those registers roll up into an enterprise risk register. The enterprise risk profile then compares the total against appetite.

The hard part is the scale. Enterprise risk teams usually rate likelihood and impact on a five-point scale, with impact defined in money, customers, regulatory standing or patient harm. Security teams often rate vulnerabilities by technical severity. A critical vulnerability on an isolated test server and one on the payments gateway look identical in a scanner report. They look very different on an enterprise scale, and only the business can say how different.

Some organizations go further and quantify cyber risk in dollars, using loss-event models. That can help a finance committee compare a resilience investment against other uses of capital. It also invites false precision when loss data are thin. A sensible middle path uses dollar ranges for the few services that matter most and qualitative ratings elsewhere.

How the task differs by type of organization

• Large national banks. The OCC’s heightened standards, which apply to national banks with $50 billion or more in assets, already required a written, board-approved statement of risk appetite. For them the task is to put measurable cyber limits inside a document that exists.
• Community banks and credit unions. Few have a formal appetite statement. A short board resolution setting outage limits for core banking, card processing and online banking can serve, as long as the board reviews it each year.
• Health systems. Clinical leaders must be part of the decision, because downtime is measured in diverted ambulances and paper charting as well as revenue. The tolerance should be set alongside the downtime procedures clinicians actually rehearse.
• Federal agencies. OMB Circular A-123 already requires an enterprise risk management program and a risk profile, and each information system has an authorizing official. Govern points at the missing link between those system decisions and the agency-wide profile.
• State and local governments. Authority is often split between an elected executive, a central IT department and separately elected officials who run their own systems. Setting direction may require an executive order or an interagency agreement before anyone can own a tolerance.

How a lender might set its limits

Suppose a mid-sized lender’s security team has long worked to an informal goal of restoring online banking within two hours of any outage. Nobody outside IT has ever approved that number. Meeting it reliably would require a second data center that the bank has twice declined to fund.

Under Govern, the chief operating officer takes the question to the executive committee. Say the committee decides that eight hours is acceptable for online banking, but that wire payments to business customers must be back within four. That decision goes into the risk appetite statement, which the board approves. Now the security team knows what it is building toward, the finance team knows what it is funding, and the board knows what it signed up for. If a test shows that wires would take ten hours to restore, the gap is visible and someone with authority owns closing it.

People: roles, responsibilities and authorities

The roles category asks that cybersecurity roles be established, communicated, resourced and tied to human resources practice. Those roles are spread across the business. Application owners own access reviews for their systems, meaning a periodic check of who can log in and whether they still should. Business unit heads own acceptance of risk exceptions in their areas. Managers own timely notice when staff and contractors leave.

Most organizations had a responsibility chart for incident response and little else. A workable approach is a short register of cyber accountabilities by role, published by HR alongside job descriptions, with time allocated. The last part matters: a responsibility with no time attached tends to become an afterthought.

Small banks, rural hospitals and local agencies, where one person may hold four roles, benefit most, because writing it down shows where coverage is thin. If the register reveals that the same person approves access, reviews access and is the only one who can revoke it, that is a finding worth having before an auditor makes it.

Offboarding, the process of removing access when someone leaves, is the clearest example. Accounts left active after people leave remain a common finding in audits across all three sectors. A former employee’s login that still works is an unlocked door, whether or not that person ever intends to use it, and attackers who steal old credentials look for exactly these. Under Govern this becomes a joint HR and IT process with a defined handoff. It also gets a metric, such as the share of accounts disabled within a day of separation, a number a chief executive can understand, track and ask about.

Joiners, movers and leavers

Identity teams describe the access lifecycle as joiners, movers and leavers. Joiners need access on day one. Leavers need it removed on their last day. Movers are the hardest case: people who change roles, gain new access and keep the old. Over years, a long-serving employee can accumulate rights from four or five jobs.

The fix depends on a trigger HR owns. When the human resources system records a hire, transfer or termination, that event should drive access changes automatically through the identity platform. Where automation is not possible, a ticket with a deadline is the fallback. Either way, HR data quality becomes a security control. A termination entered a week late means a week of open access.

Contractors and other non-employees are the usual gap, because many never appear in the HR system. A sponsor model closes it. Each contractor account has a named internal sponsor and an end date, and it expires automatically unless the sponsor renews it.

The evidence an auditor will ask for

An examiner or auditor testing this area will usually take a sample of people who left during the period. For each, they compare the departure date with the date the accounts were disabled, checking privileged accounts and remote access first. They will ask for the latest access review of a critical system, who performed it, and what was removed as a result. A review that removes nothing year after year suggests reviewers are approving lists without reading them.

Where the sectors differ

Health systems carry the widest population of non-employees: affiliated physicians, residents rotating between hospitals, agency nurses, students and vendor technicians. Each group needs clinical access quickly, often at odd hours, and many leave without a clean HR event. Banks face tighter separation-of-duties expectations, because the same person should not be able to initiate and approve a payment. Federal agencies tie access to identity cards and a formal separation clearance process, which helps with leavers and does little for movers.

Small organizations face a trade-off that larger ones do not. Full separation of duties may be impossible with a two-person IT team. The usual answer is a compensating control: a periodic independent review by internal audit, an outside firm or a board member, with the result recorded.

Suppliers: cybersecurity supply chain risk management

Every modern organization runs on other organizations: cloud providers, software vendors, payment processors, outsourced call centers, claims clearinghouses. Each one is a potential weak point. Supply chain risk management is the discipline of knowing which suppliers matter most and making sure they are held to the right standards.

Supply chain risk management moved under Govern as its own category, with outcomes covering supplier criticality, contract requirements, due diligence, monitoring and offboarding. Each outcome has a natural owner outside security. Business owners decide which services are critical. Procurement selects and onboards suppliers. Legal writes the clauses on notification, audit and exit. Security assesses controls and monitors.

In most organizations these pieces existed without coordination. The questionnaire belonged to security, the contract to legal, and the criticality rating to no one. The result was a familiar gap: a supplier could pass a security questionnaire while sitting on a contract with no right to audit and no plan for what happens if the supplier fails.

Govern gives a structure for assigning each piece and making the handoffs visible. A useful single metric is the share of critical suppliers with a current criticality rating, a contract meeting the organization’s standard clauses and a tested exit plan. Few organizations could report it in early 2024.

The Change Healthcare outage, spreading through hospitals and pharmacies that same week, showed what an unrated, single-threaded supplier dependency costs. “Single-threaded” means there is only one path: if that supplier stops, the work stops. The outage demonstrated the risk this category exists to manage.

Ten outcomes across the supplier lifecycle

The supply chain category is the largest in Govern, with ten subcategories. Read in order, they trace a supplier relationship from start to finish. A program and strategy are agreed. Roles are set for suppliers, customers and partners. Supplier risk is folded into enterprise risk. Suppliers are known and ranked by criticality. Requirements go into contracts. Due diligence happens before signing. Risk is monitored over the life of the relationship. Relevant suppliers join incident planning, response and recovery. Security practices are monitored across the product life cycle. Plans cover what happens after the relationship ends.

Two of those outcomes were rarely done well in early 2024. Including suppliers in incident planning means a critical supplier joins the organization’s tabletop exercises, and the organization joins the supplier’s. Planning for the end of a relationship means knowing how to get data back, in what format, and how fast another provider could take over.

Which supplier rules applied to whom

• Banks. The federal banking agencies issued joint guidance on third-party risk management in June 2023. It expects oversight in proportion to risk, with more rigor for relationships that support critical activities.
• Credit unions. The NCUA expects due diligence on vendors. Unlike the bank regulators, it lacks statutory authority to examine third-party service providers directly, so contract terms carry more of the weight.
• Broker-dealers. FINRA reminded member firms in 2021 that outsourcing an activity does not relieve them of the duty to supervise it.
• Health systems and practices. HIPAA requires business associate agreements with vendors that handle protected health information. Those agreements address the privacy and security of the data. They say little about keeping a service running, which is the gap the Change Healthcare outage exposed. Clearinghouses such as Change are themselves HIPAA covered entities.
• Federal agencies. Cloud services generally need a FedRAMP authorization, and NIST Special Publication 800-161 sets a detailed supply chain baseline for federal systems.

Concentration and fourth parties

Criticality ratings usually look at one supplier at a time. The harder risk is concentration: many critical services depending on the same provider, or on the same provider’s provider. A health system may contract with one clearinghouse directly and then find that its revenue cycle vendor routes claims through the same one. Mapping these fourth parties is laborious and never complete. A useful start is to ask each critical supplier, at renewal, to name its own critical dependencies.

The trade-off is cost. A second clearinghouse, a backup payment processor or a secondary cloud region costs money every year to guard against an event that may never happen. Govern does not say how much redundancy to buy. It says the business should decide, on the record, and revisit the decision when the facts change.

Oversight: closing the loop with the board

The oversight category asks that results of cyber risk management be reviewed and used to adjust strategy. This is the loop through senior leadership and the board.

It matched where regulation was already heading. The SEC’s disclosure rule required public companies to describe board oversight of cyber risk, and banking supervisors had long expected regular board reporting. CSF 2.0 gave health systems, agencies and private firms a reference for the same expectation.

Oversight fails when board reporting is a list of activities: phishing tests run, patches applied, training completed. Those numbers say the team is busy. They do not say whether the organization is within the limits it set.

It works when the board sees a few measures tied to the tolerances set under direction, each with a named owner. Examples include recovery times achieved in tests, critical supplier coverage and overdue risk acceptances. A board that approved a four-hour limit for wire payments should see, each quarter, how long restoration took in the last test, and whose job it is to close any gap.

Designing the board page

A workable board page has three kinds of measure. Key risk indicators show exposure, such as the number of critical services without a recent recovery test inside tolerance, or critical suppliers lacking exit plans. Key performance indicators show whether controls work, such as offboarding timeliness or patch times for internet-facing systems. A short list of open risk acceptances shows decisions management has taken, each with an owner and an expiry date.

Each measure needs a threshold agreed in advance and tied to the tolerances the board approved. Green, amber and red mean something only when everyone agreed beforehand what red is. Trend matters as much as the current value. A board should also see when internal audit last tested the numbers, because self-reported metrics tend to drift toward green.

Who plays the board’s role

The oversight body differs by organization. Banks and credit unions already had a specific duty: federal guidelines under the Gramm-Leach-Bliley Act require the board to approve the written information security program and to receive a report on it at least annually. Public companies had to describe board oversight in annual reports for fiscal years ending on or after December 15, 2023. Nonprofit health systems have boards, often with little technology expertise, that usually route cyber through the audit or quality committee. Federal agencies have no board. The agency head, a risk management council and the inspector general’s annual FISMA evaluation together fill the role.

Credit unions add a twist. Their directors are largely volunteers, often without a technology or risk background and with limited time between meetings. For them a short page with agreed thresholds matters even more, because it tells a volunteer director exactly which number should prompt a question.

A common objection here is that boards should not manage cyber at all. Directors are not engineers, and a board that debates patch metrics is doing management’s job. The objection is right about detail and wrong about limits. A board that sets a tolerance and checks results against it is doing oversight in the classic sense. The page should be short precisely so that directors can hold management to account without being drawn into operations.

That ties the four groups together. Direction sets the tolerances, people and suppliers carry them out, and oversight checks the result.

An order that works: direction first, the board last

The four groups suggest a natural order. The work needs no new software, and most of it can be done with existing committees.

Start with direction. Ask the business, not IT, to name the handful of services the organization most depends on: for a bank, perhaps payments and online banking; for a health system, the electronic health record, pharmacy and scheduling; for an agency, benefits payments or permit processing. For each, ask the accountable executive how long it could be unavailable before the harm became serious. Those answers, approved and written down, are your first tolerances. They will be imperfect, and that is fine; a rough number owned by the business beats a precise one owned by nobody.

Then people. With the critical services named, ask HR and the security team together to draft a one-page register: who owns access to each critical system, who can accept a risk exception, who must tell IT when someone leaves, and how much time each role is expected to spend on it. Circulate it to the people named. Many will be surprised to learn they hold a cyber responsibility, which is itself a sign the work is needed.

Then suppliers. Ask procurement for the list of suppliers that support the critical services. For each, ask three questions: has the business rated how critical it is, does the contract meet our standard terms on breach notification, audit and exit, and have we ever tested what we would do without it? The answers become the supplier metric described above.

Finally oversight. Replace, or at least supplement, the board’s security activity report with a short page showing each tolerance, the latest test result against it, the supplier coverage figure, the offboarding figure and any overdue risk acceptances, each with an owner. The first version will show gaps, which is what it is for: the board can now see them and ask who is closing them.

The order matters because each step feeds the next. Without tolerances, roles have nothing to aim at. Without named critical services, supplier ratings are guesswork. Without both, board reporting falls back on activity counts.

Using a Profile to run the work

The framework’s own Profile mechanism fits this sequence. A team can scope a Current Profile to the Govern function and the handful of critical services, record honestly where the organization stands, and write a Target Profile the executive committee approves. The gap between the two becomes an action plan. Federal agencies already have a format for that plan in the plan of action and milestones, and banks can use their existing issue-tracking process.

A realistic set of deliverables for the first cycle is short: a list of critical services with business owners; a tolerance for each; a one-page accountability register; a ranked list of critical suppliers with contract and exit status; and a quarterly board page. Each has an owner outside security. Security drafts most of them and owns none of the decisions.

The target Tier deserves the same discipline. Few organizations need Adaptive governance everywhere. A regional bank might aim for Repeatable across the board and accept Risk Informed for low-impact business lines. Writing that choice down is itself a Govern decision.

The effort is real but bounded. In a large organization this is a few months of part-time work for a small group drawn from risk, HR, procurement, legal and security. In a small one it can be a handful of meetings. In both cases the main cost is executive attention, which is exactly what Govern is asking for.

Short documents and clear names

Good Govern work is mostly short documents and clear names. In a well-run organization, a director could quickly find out the tolerance for an outage of the most important service, who approved it, who is accountable for each critical supplier, how fast access is removed when someone leaves, and what the last recovery test showed.

The ways it goes wrong are predictable.

• Treating it as a mapping exercise. Updating the spreadsheet without changing who decides anything.
• Leaving tolerance with the CISO. The security chief ends up both setting and meeting the target, which means nobody is really checking.
• Writing policy before strategy. A policy that does not follow from a stated appetite tends to be either unenforceable or ignored.
• Orphaned supplier risk. Questionnaires collected by security, contracts written by legal, and nobody deciding which suppliers matter most.
• Activity reporting. Boards shown effort rather than outcomes against agreed limits.
• Ignoring small-organization reality. In a small entity, assuming roles are covered because everyone is busy, rather than writing down who does what.

Three objections, and where they have force

The framework is voluntary. True for most private organizations. Voluntary frameworks gain weight through other routes, though. A January 2021 amendment to the HITECH Act requires HHS to consider whether a regulated health organization had recognized security practices in place for the previous twelve months. HHS weighs that when it decides HIPAA penalties and audit outcomes, and the NIST framework counts as such a practice. Several states, Ohio among them, give businesses an affirmative defense in some data breach lawsuits if they maintained a program that reasonably conforms to a recognized framework.

Regulators already require this. For large banks and public companies, much of it, yes. For a rural hospital, a county or a mid-sized wealth manager, the expectations are looser. Govern is useful for them precisely because nothing else forces the questions.

Executives will not engage. Sometimes true. The fallback is to write the tolerances as the security team’s proposal, present them for approval, and record any refusal to decide. An unanswered request for a risk decision is still evidence, and it moves accountability to where it belongs.

The fixes are cheap: mostly a few meetings and a few signatures. What they require is that executives outside IT accept that some of this work is theirs.

Where cyber ownership should be on record

1. Which executive accepted our largest cyber risk, and where is that decision written down?
2. What share of accounts are switched off within a day of someone leaving? Who reports that number?
3. Which of our suppliers are critical, who decided, and how many of them have the right contract terms and a tested exit plan?
4. What does the board see about cyber each quarter: a list of activities, or a few measures against limits it approved?

With hindsight

CSF 2.0 quickly became the reference version. NIST continued to add quick-start guides and mappings through 2024 and 2025, making the framework easier for smaller organizations to pick up without specialist help.

The most significant follow-on came from banking. In August 2024, the Federal Financial Institutions Examination Council, the interagency body that coordinates how US bank examiners work, announced that it would retire its Cybersecurity Assessment Tool on August 31, 2025. For years, many banks had used that tool as their main way of measuring their own cyber maturity. In announcing the retirement, the council pointed institutions to resources including NIST CSF 2.0 and CISA’s Cybersecurity Performance Goals. (CISA is the federal Cybersecurity and Infrastructure Security Agency.)

That made the framework, Govern included, a common starting point for bank self-assessments. Its use remained voluntary, and examiners continued to apply their own risk-based approach. But for a bank board, the practical effect was that the questions Govern asks became the questions it was most likely to hear.

Other rules moved in the same direction without citing the framework. In May 2024 the SEC adopted amendments to Regulation S-P, which covers broker-dealers, investment advisers, investment companies and transfer agents. They required written incident response programs, oversight of service providers, and notice from those providers within 72 hours of a breach affecting customer information. Larger firms had until December 2025 to comply and smaller ones until June 2026. For that part of financial services, the supplier outcomes in Govern became rule text.

In Europe, the NIS2 directive, due to be written into national law by October 2024, made management bodies responsible for approving and overseeing cybersecurity risk measures. The Digital Operational Resilience Act, which applied to EU financial entities from January 2025, gave the management body final responsibility for ICT risk. US banks and insurers with European operations met the ideas behind Govern there as law.

The Change Healthcare incident became the clearest case study of what Govern is for. In congressional testimony in May 2024, UnitedHealth’s chief executive confirmed that the attackers had used stolen credentials on a remote access portal that lacked multifactor authentication, and that the company had paid a ransom. UnitedHealth later put the number of people whose data was affected at about 190 million. A missing control on one acquired subsidiary’s portal became an outage for much of the industry. The questions that followed were governance questions: who at the parent was accountable for confirming that an acquired company met the group’s standards, and which customers had a tested plan for doing without it.

In health care, HHS proposed a major update to the HIPAA Security Rule at the end of December 2024. Among other things, it would require a written technology asset inventory and network map, multifactor authentication, and annual written verification from business associates that they have deployed required safeguards. Hospital groups objected to its cost. Organizations should check its current status with counsel. Whatever its final form, its supplier verification follows the same logic as Govern’s supply chain category.

The structure of Govern has held up as a planning tool. Its value lies in the question it forces: when a supervisor, auditor or director asks who owns a given cyber risk, the answer should be a named executive and a document. That question applies equally to a hospital, an agency or a manufacturer.

The framework itself now matters less than the shift it captured. Cybersecurity used to be framed as a technical function that executives funded and boards occasionally heard about. Govern frames it as a set of business decisions about appetite, accountability, suppliers and oversight, which happen to need technical people to carry them out. Organizations that made that shift in 2024 had a head start. Those that have not yet made it can still do so with a few meetings and a few signatures.