Chapter 19: Security Governance, Policy, and Culture

Chapter 19: Security Governance, Policy, and Culture#

“Culture eats strategy for breakfast.” Peter Drucker (applied to security: a security program without a supportive culture will be circumvented, not adopted.)

On legal currency and jurisdiction. Laws, regulations, and enforcement practices discussed in this chapter vary by jurisdiction and change over time. The descriptions here are for education and are not legal advice, and they may not reflect the latest amendments or local rules. Verify the current text of any law or regulation, and consult qualified counsel, before relying on it for a real decision. Instructors should review this material for currency each edition.

Learning Objectives#

After completing this chapter, you will be able to:

Explain what security governance is and how it differs from security management.
Describe the role of the CISO and the security organization structure.
Explain the policy hierarchy: policy, standard, process, procedure, and guideline, and trace one real rule through all five levels.
Write a policy document that is enforceable and auditable.
Describe board-level reporting of cybersecurity risk and metrics.
Design a security awareness program that changes behavior, not just knowledge.
Explain how to build and sustain a positive security culture.
Describe common certification and compliance frameworks and their governance implications.
Build and defend a security budget, and separate a tool’s sticker price from its total cost of ownership.
Express risk appetite and tolerance as numbers a board can act on.
Run an exception and risk-acceptance process, and read the metrics that show whether it is working.
State what the SEC cybersecurity disclosure rules and the New York cybersecurity regulation require of officers, and what they do not.
Measure security culture from observed behavior rather than asserting it.

Key Terms#

Governance: the framework of policies, roles, and processes by which an organization is directed and controlled.
CISO: Chief Information Security Officer; executive responsible for the security program.
Policy: a high-level statement of intent, direction, and principle.
Standard: mandatory requirements derived from policy; technology-specific and measurable.
Process: a set of interrelated activities, each with an owner, inputs, and outputs, that delivers an intended result; procedures spell out how its individual activities are done.
Procedure: step-by-step instructions for implementing a standard.
Guideline: recommended but non-mandatory advice.
KRI: Key Risk Indicator; a metric that signals changing risk levels.
KPI: Key Performance Indicator; a metric measuring program effectiveness.
Security culture: the collective values, beliefs, and behaviors relating to security within an organization.
Security awareness: programs designed to change employee knowledge and behavior.
Tone at the top: the demonstration by senior leadership that security is a genuine priority.
Risk appetite: the amount and type of risk an organization is willing to pursue or retain.
Risk tolerance: the acceptable deviation around a specific objective; what staff work to day to day.
Risk capacity: the most risk an organization could absorb before it fails; a fact, not a preference.
Exception: an approved, time-bound, compensated departure from a stated requirement.
Three lines model: the separation of those who own controls, those who challenge them, and those who independently assure them.
Materiality determination: the dated decision that an incident is material, which starts a disclosure clock.

19.1 What Security Governance Is#

Security governance is the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring objectives are achieved, and verifying that risk is managed appropriately. It is distinct from security management (day-to-day operational decisions) and security operations (implementing controls).

Why Governance Matters#

Without governance, security is a collection of ad hoc technical activities rather than a disciplined program aligned with organizational objectives. Governance answers: What are we protecting, and why? What level of risk is acceptable? Who is accountable when things go wrong? How do we know our controls are working?

19.2 The CISO Role#

Strategic Responsibilities#

The CISO is the executive accountable for the security program. Strategic responsibilities include: defining the security strategy and roadmap, obtaining and allocating budget, reporting risk to the board and executive leadership, ensuring regulatory compliance, overseeing vendor and third-party risk, and building the security organization.

Organizational Models#

Centralized Security Function#

A centralized security function reports to the chief information officer (CIO), chief financial officer (CFO), or CEO and has direct authority over security policy and standards across the organization. This model provides consistent policy enforcement but can create friction with business units that feel security slows them down.

Federated Security Model#

In a federated model, a central security function sets policy and standards, but embedded security personnel in each business unit implement and enforce them locally. This model balances central consistency with business-unit agility.

Reporting Lines and Independence#

Security governance guidance commonly recommends that the CISO not report to the CIO, because security and IT delivery have inherent conflicts of interest (security may slow releases or block systems that IT needs to keep online). On that reasoning, the CISO reports to the CEO or the board audit committee. The recommendation rests on that conflict-of-interest argument rather than on evidence that one reporting line produces better security outcomes. In practice, the CISO reporting line varies widely by organization size and maturity, and Section 19.20 sets out the survey figures, the counter-argument, and what the evidence does and does not support.

19.3 The Policy Hierarchy#

Policy#

A policy is a high-level statement of management’s intent. It answers: what must be done and why, without specifying how. Policies are technology-neutral and long-lived. An information security policy states that the organization is committed to protecting the confidentiality, integrity, and availability of information assets; it does not specify which encryption algorithm to use.

Policy Characteristics#

An enforceable policy must be: written and approved by the appropriate authority, communicated to all affected parties, specific enough to be auditable (not vague platitudes), reviewed periodically (typically annually), and have a clear violation consequence.

Standard#

A standard derives specific, measurable, mandatory requirements from the policy. The encryption policy says data at rest must be protected; the encryption standard says that data classified Confidential or above must be encrypted using AES-256-GCM. Standards are technology-specific and updated more frequently than policies as technology evolves.

Process#

A process is the flow of work that turns policy into results: which activities happen, in what order, who performs each one, and what each activity takes in and hands on. ISO 9000:2015 defines a process as a set of interrelated or interacting activities that use inputs to deliver an intended result, and a procedure as a specified way to carry out an activity or a process. The difference is altitude. The incident response lifecycle of Chapter 14 is a process: it runs from preparation through detection and analysis, containment, eradication and recovery, to post-incident activity, and it assigns an owner to each stage. A playbook step for one activity inside it, such as isolating an infected laptop, is a procedure, with the exact console steps and commands. Processes change when the organization or its roles change, procedures change when the tools change, and an auditor tests a process by following one real case through every stage.

Procedure#

A procedure is a step-by-step instruction set for implementing a standard. The encryption standard says to use AES-256-GCM; the encryption procedure specifies exactly which tool to use, which configuration flags to set, how to store the key, and how to verify the encryption is working. Procedures are the operational instructions that technical staff follow.

Guideline#

A guideline is recommended, non-mandatory advice that helps users follow policy in situations not covered by standards and procedures. Guidelines use the word “should” rather than “shall” or “must.” A password guideline might recommend using a password manager, without mandating a specific product.

A Worked Example: When Claude Ends an Abusive Chat#

On October 8, 2026, Anthropic announced an update to the Usage Policy that governs how people may use its Claude models, taking effect on November 12, 2026. Beside new language on weapons software, surveillance and elections, it added what TechCrunch called perhaps the most attention-getting change: a ban on prolonged abuse of the model itself. The story is useful here because every level of the hierarchy can be seen in public documents, from a one-line prohibition at the top to the single action the model takes inside one conversation at the bottom. Anthropic does not label its documents with this section’s five levels. Sorting its public statements into them is the same exercise an auditor performs on any organization’s paperwork.

Policy: what is forbidden, and why#

The policy is a single line in the Usage Policy, listed under the heading Do Not Engage in Cruel, Abusive, or Psychologically Harmful Conduct:

Engage in sustained and needless abusive or cruel behavior toward our models.

It says what is forbidden and nothing about how a violation will be detected, so it would survive a complete change of technology. The announcement sets its scope: the rule is meant only for extreme cases, where users repeatedly act cruelly toward the models with no discernible purpose, and it does not reach ordinary frustration, pushback, dark creative themes, or model testing and research. The rule builds on a capability introduced in August 2025, when Anthropic wrote that it remains highly uncertain about the potential moral status of Claude and other large language models and described letting a model leave a distressing interaction as a low-cost precaution. Measured against the policy characteristics above, the rule passes: it is written and approved by the organization that owns it, communicated publicly with an effective date, specific enough to test, revised as evidence accumulates (the announcement says the update reflects misuse patterns from the past year), and backed by consequences, since the Usage Policy allows Anthropic to warn a user or to throttle, limit, suspend, or terminate access.

One naming trap is worth noticing. Anthropic files this rule under a heading called Universal Usage Standards, yet by the definitions in this section it is a policy statement: it states intent and does not specify any technology. Classify a document by what it says, not by what it is called.

Standard: the conditions that make the rule testable#

The policy says what; the standard says exactly when the enforcement mechanism may act. The conditions that Anthropic has published, in its August 2025 post on ending conversations and in the 2026 announcement, read like one:

Claude may end a conversation only as a last resort, when multiple attempts at redirection have failed and hope of a productive exchange is exhausted, or when the user explicitly asks it to.
Claude must not end a conversation when the user might be at imminent risk of harming themselves or others.
Ending applies to that conversation only; the user’s other chats are untouched, and a new chat can start at once.
The ability runs in the Claude app and in Claude Code, and it is the primary enforcement mechanism for the abuse rule.

Each line can be checked against a transcript, which is what separates a standard from an aspiration. Like any standard it is tied to technology and revised as the technology moves: the August 2025 version applied to two models, Claude Opus 4 and Claude Opus 4.1.

Process: from rule to enforcement and back#

The process is the loop that connects the policy to the model’s behavior and brings evidence back to the people who own the policy. Anthropic’s description of how its Safeguards team works, together with the Claude Opus 4 system card, shows these stages:

Write the policy. The Safeguards team drafts the Usage Policy, weighs potential harms across physical, psychological, economic, societal, and individual-autonomy dimensions, and has outside experts probe the rules with challenging prompts.
Train the behavior. Safeguards works with the teams that fine-tune Claude, and problems found later can change the reward models used in training or the system prompts of deployed models.
Test before release. Before Claude Opus 4 shipped, a Claude-based auditor played 850 simulated users in 18 categories of behavior, abusive users among them, while the model was free to end any conversation. It most often ended categories such as harmful content requests and privacy violations, and least often ordinary work such as coding.
Enforce inside the conversation. The procedure below.
Collect feedback. Users can flag an ending they think was a mistake, and Anthropic describes the feature as an ongoing experiment.
Revise. The capability first released in August 2025 became an explicit rule in the 2026 update.

Each stage hands the next one something concrete: a policy text, a trained model, a test result, an ended conversation, a feedback record. Each also has a different owner: policy writers, training teams, evaluators, the model, the user. A process map shows that division of labor. It does not tell anyone which button to press.

Procedure: the exact steps inside one conversation#

The procedure is the step-by-step level, where the actual mechanisms appear. Inside a single chat the published behavior runs as follows:

Answer and redirect. A user who is merely rude or unhappy gets a normal reply. Claude’s published system prompt lets it mention the thumbs-down feedback button to an unhappy user and tells it not to become increasingly submissive if the user turns abusive. Claude names the problem and offers to continue productively, more than once.
Check the exclusion. If anything suggests the user may be at imminent risk of harming themselves or others, Claude does not end the conversation, whatever else has been said.
Decide. Claude moves on only when repeated redirection has failed and nothing productive remains, or when the user asks it to end the chat.
Call the action. Claude ends the chat with an action, not a sentence. In Anthropic’s published test transcript the action appears as <end_conversation>, issued after two replies that tried to steer an abusive simulated user back to a task. Anthropic has not published the product’s internal wiring, but a named action that the model chooses and the application carries out is what its developer documentation calls a tool: Claude returns a structured tool call, and the application, not the model, executes it.
Close the thread. The Claude app or Claude Code stops accepting new messages in that conversation. Nothing else on the account changes: the user can start a new chat at once, or edit and retry an earlier message to branch the conversation.
Capture feedback. The user can react to Claude’s last message with the thumbs icon or the Give feedback button, which feeds stage 5 of the process.

The other rules in the same update are enforced by different machinery, a reminder that one policy can rest on many procedures. The Safeguards team runs classifiers, which are prompted or fine-tuned Claude models that examine traffic in real time. Their findings can steer a response by adding instructions to the system prompt, in a narrow set of cases stop Claude from responding at all, or lead to account actions ranging from a warning to termination, and known child sexual abuse material is caught by hash matching. Over longer periods, a privacy-preserving tool called Clio groups conversations into topic clusters, hierarchical summarization rolls conversations up into account-level summaries that reveal patterns such as influence operations, and a threat-intelligence function hunts for misuse those systems miss. For the abuse rule, though, the 2026 announcement names the model’s own ability to end the conversation as the primary enforcement mechanism.

Guideline: advice that binds no one#

Two parts of the story are advice rather than obligation. Anthropic encourages users who meet a surprising ending to send feedback, and nothing requires them to. The announcement’s scope note also works as guidance for anyone judging their own behavior: frustration, pushback, dark creative themes, and model testing and research are expected uses, not violations. Guidance like this helps people apply the policy well, and departing from it breaks no rule.

The Story at Five Levels#

Level	Question it answers	In this story	Changes when
Policy	What is required, and why?	No sustained, needless abuse or cruelty toward the models	The organization’s values or obligations change
Standard	What exactly must be true?	End only as a last resort or on request, never when someone may be at imminent risk	The technology or the evidence changes
Process	Who does what, in what order?	Write, train, test, enforce, collect feedback, revise	The organization or its roles change
Procedure	How is one step done, and with which tools?	Redirect, check for risk, call the end-conversation action, close the thread, capture feedback	A product, tool, or screen changes
Guideline	What is recommended?	Send feedback on a surprising ending; frustration and dark themes are fine	Experience suggests better advice

Exercises#

Classify each statement as policy, standard, process, procedure, or guideline.
- A. Claude must not end a conversation when a user may be at imminent risk of harming themselves or others.
- B. The Claude app stops accepting messages in an ended conversation, and the user can edit an earlier message to branch it.
- C. Users should send feedback when an ending surprises them.
- D. Users may not engage in sustained and needless abuse of the models.
- E. Misuse observed during the year feeds a revised policy, which is then trained, tested, and enforced.
A help desk wants its staff to be able to end abusive phone calls. Write one sentence at each of the five levels.

Answer Key#

A is a standard, B a procedure, C a guideline, D the policy, and E the process.
One possible set. Policy: staff are not required to endure abusive conduct from callers. Standard: an agent may end a call only after two recorded warnings, and never when the caller reports an emergency. Process: warn, escalate to a supervisor, end the call, log it, and review ended calls weekly with the team lead. Procedure: in the telephony console, read the scripted warning, select End Call, and choose the reason code Abuse so the call is logged. Guideline: agents should take a short break after an abusive call.

19.4 Board-Level Security Reporting#

Communicating Risk in Business Language#

Boards are not technical audiences. Effective board reporting translates technical risk into business impact: potential financial exposure (ALE), regulatory liability, reputational risk, and operational disruption. A chart showing “number of vulnerabilities patched this month” means nothing to a board; a statement that “our mean time to patch critical vulnerabilities has improved from 21 to 7 days, reducing our exposure window by 66%” communicates progress against a business outcome.

Key Metrics for Board Reporting#

Metric	What it measures
Mean time to detect (MTTD)	Detection capability; lower is better
Mean time to respond (MTTR)	Response effectiveness
Patch compliance rate	Vulnerability management hygiene
Phishing simulation click rate	Human layer risk
Critical/high open findings	Remediation backlog
Third-party risk assessment coverage	Supply chain risk management
Audit findings closure rate	Compliance posture

Key Risk Indicators#

KRIs are leading indicators that signal changing risk levels before an incident occurs. Examples: a spike in failed login attempts (credential stuffing campaign beginning), an increase in employees clicking phishing simulations (awareness declining), a large number of unpatched critical vulnerabilities past SLA (remediation program breaking down).

19.5 Security Culture#

What Culture Is and Why It Matters#

Security culture is the sum of employee attitudes, beliefs, and behaviors toward security. A positive security culture produces employees who: report suspicious activity without fear of punishment, follow security policies not because they are forced to but because they understand the reason, and treat security as a shared responsibility rather than a blocker.

A negative or absent security culture produces employees who: find workarounds for security controls they find inconvenient, do not report incidents out of fear of blame, and view the security team as adversaries rather than allies.

Tone at the Top#

Culture change cannot be mandated from the middle of the organization. Leadership behavior signals what the organization truly values. If the CEO publicly skips MFA enrollment because it is inconvenient, no amount of policy enforcement will produce employee MFA adoption. Conversely, when the CEO publicly champions security, completes the same training as all staff, and backs the CISO’s budget requests, security becomes a genuine organizational priority.

Building a Positive Security Culture#

From Compliance to Commitment#

Compliance-based approaches create minimum-viable security behavior: employees do exactly what is required to pass the audit and no more. Commitment-based approaches create employees who genuinely care about security outcomes. The difference is explanation: when employees understand why a control exists and what harm it prevents, they are more likely to follow it and to extend the principle to novel situations.

Just Culture and Incident Reporting#

A just culture distinguishes between human error, at-risk behavior, and reckless behavior, and responds proportionately. Punishing every security mistake drives incidents underground. A just culture encourages reporting: near-misses are learning opportunities; punitive responses to honest mistakes prevent the organization from learning from them.

19.6 Common Compliance Frameworks#

Framework	Sector	Mandate
ISO/IEC 27001	All sectors	Voluntary; certification by accredited auditor
NIST CSF	All sectors; US federal	Voluntary for most; referenced in regulations
SOC 2 Type II	Technology/SaaS	Voluntary; required by many enterprise customers
HIPAA	US healthcare	Mandatory for covered entities
PCI DSS	Payment card processing	Mandatory for card handling organizations
GDPR	EU personal data	Mandatory for organizations in scope
CMMC (Cybersecurity Maturity Model Certification)	US defense contractors	Mandatory for the Department of Defense (DoD) supply chain
FedRAMP (the Federal Risk and Authorization Management Program)	US federal cloud	Mandatory for cloud services to US federal government
NERC CIP (North American Electric Reliability Corporation)	North American bulk power and electric grid	Mandatory for bulk electric system operators

GRC: integrated Governance, Risk, and Compliance management.
Risk register / exception process: tracked risks with owners/treatment; documented, approved policy deviations.
SOC 2 Type II / audit / assurance: independent verification that controls operate effectively over time.
Maturity model (CMMI, Capability Maturity Model Integration, and CSF tiers): scales rating a program’s capability and trajectory.

Frameworks, Methodologies, and Tools#

These three terms are often used loosely but mean different things. A framework gives high-level direction (standards, guidelines, and best practices) while leaving an organization free to choose how to implement it; the NIST CSF and ISO/IEC 27001 are frameworks. A methodology prescribes a structured process with defined steps and less flexibility; the threat-modeling methods of Section 5.8 and the NIST Risk Management Framework’s seven-step lifecycle are methodologies. A tool is the tactical implementation that automates or supports a specific task, such as a vulnerability scanner, a SIEM, or a GRC platform. In practice the three nest: a framework sets the goals, a methodology defines the repeatable process to reach them, and tools carry out the work.

NIST CSF, the Risk Management Framework (RMF), ISO/IEC 27001, and the RMF Compared#

The three governance frameworks most often weighed against one another serve overlapping but distinct purposes.

Framework	Nature	Scope and use	Outcome
NIST CSF 2.0	Voluntary, outcome-based framework	Flexible risk management across any sector; widely used in the US	A risk-informed profile across Govern, Identify, Protect, Detect, Respond, Recover
ISO/IEC 27001	Certifiable international standard	A formal Information Security Management System (ISMS), recognized globally	Accredited certification of an operating ISMS
NIST RMF (SP 800-37)	Mandatory process for US federal systems	Step-by-step authorization of a system to operate using SP 800-53 controls	An authorization to operate (ATO) with continuous monitoring

In broad terms, the CSF is the flexible framework for prioritizing and communicating risk, ISO/IEC 27001 is the certifiable management-system standard that customers and partners recognize worldwide, and the RMF is the rigorous, control-driven process required for federal systems and increasingly adopted by private organizations with high-value assets. They are complementary: an organization can run an ISO/IEC 27001:2022 ISMS or the RMF as its operating process while using the CSF to set priorities and report to leadership.

FISMA in Depth#

The Federal Information Security Modernization Act (FISMA) is the US law that makes information security a legal obligation for federal agencies. It was first enacted as the Federal Information Security Management Act of 2002 and updated as the Federal Information Security Modernization Act of 2014. FISMA requires each agency to develop, document, and operate an agency-wide program to secure the information and systems that support its operations, including those run on its behalf by contractors and other agencies.

FISMA assigns responsibilities across the government. The Office of Management and Budget (OMB) oversees and enforces agency compliance and reports to Congress. The National Institute of Standards and Technology (NIST) writes the mandatory standards and guidance that agencies follow. The Cybersecurity and Infrastructure Security Agency (CISA) provides operational support such as threat information and incident coordination. Within each agency, the head of the agency is ultimately accountable, and that responsibility is delegated to a Chief Information Officer and a Senior Agency Information Security Officer (often the CISO).

In practice FISMA compliance follows the lifecycle this book describes elsewhere. Agencies categorize each system by the impact a breach would have using FIPS 199 (low, moderate, or high for confidentiality, integrity, and availability), apply the minimum security requirements of FIPS 200, select and implement controls from NIST SP 800-53 through the Risk Management Framework (SP 800-37), and grant an Authority to Operate only after the residual risk is judged acceptable. Agencies then perform continuous monitoring and report their security posture annually, and agency Inspectors General conduct independent audits. FISMA is therefore the legal engine that drives the categorize, select, implement, assess, authorize, and monitor cycle across the federal government.

NIST SP 800-53 in Depth#

NIST Special Publication 800-53, titled Security and Privacy Controls for Information Systems and Organizations, is the control catalog that the rest of this federal ecosystem draws on. It is currently at Revision 5 (released September 2020). Rather than a checklist, it is a large library of controls that an organization selects from based on the impact level of the system being protected.

The controls are organized into 20 control families, each identified by a two-letter code. Examples include Access Control (AC), Audit and Accountability (AU), Identification and Authentication (IA), Configuration Management (CM), System and Communications Protection (SC), System and Information Integrity (SI), Incident Response (IR), Contingency Planning (CP), Risk Assessment (RA), and Supply Chain Risk Management (SR). Each family groups related requirements; for example, Access Control covers least privilege, separation of duties, session management, and remote access.

Revision 5 introduced several important changes. It made the controls outcome-based by removing the assumption that a specific kind of organization implements them, so the same catalog applies to federal agencies, private companies, and others. It integrated privacy controls directly alongside security controls rather than keeping them separate. It added the Supply Chain Risk Management (SR) family in recognition of third-party and software-supply-chain threats. SP 800-53 is used together with companion documents: SP 800-53B defines the low, moderate, and high control baselines, and SP 800-53A provides the procedures for assessing whether controls are implemented correctly and operating as intended. Because FISMA, the Risk Management Framework, and FedRAMP all build on this single catalog, SP 800-53 is effectively the common vocabulary of US government security control.

FedRAMP in Depth#

The Federal Risk and Authorization Management Program (FedRAMP), established in 2011, gives the US government a single, standardized way to assess, authorize, and continuously monitor the security of cloud products and services. A commercial provider that wants to sell a cloud offering (software as a service, platform as a service, or infrastructure as a service) to a federal agency must hold a FedRAMP authorization. Its guiding principle is do once, use many times: before FedRAMP, a vendor had to pass a separate security review for every agency it sold to, so the program replaced that duplication with one rigorous assessment whose result is placed in a central repository and reused across agencies.

FedRAMP does not invent its own controls. It builds on the NIST SP 800-53 control catalog (now Revision 5) and tailors it for cloud environments. Systems are categorized by the impact that a breach of confidentiality, integrity, or availability would cause, which sets the baseline of controls that must be implemented:

Impact level	Typical data	Approximate controls (Rev 5)
Low	Public or low-sensitivity data; a loss has limited effect	156
Moderate	Non-public agency data and personally identifiable information (PII); a loss has serious effect (most authorizations land here)	323
High	Highly sensitive unclassified data in law-enforcement, healthcare, financial, or emergency systems; a loss is severe or catastrophic	410

A lighter LI-SaaS (Low-Impact Software-as-a-Service) baseline covers low-risk applications with a reduced control set.

Authorization follows four stages. In preparation, the provider documents its security posture in a System Security Plan (SSP). In assessment, an accredited Third-Party Assessment Organization (3PAO) independently tests the system and records results in a Security Assessment Report (SAR), with open items tracked in a Plan of Action and Milestones (POA&M). In authorization, the provider receives an Authority to Operate (ATO), historically through either an individual agency sponsorship or a central board review, with recent modernization emphasizing agency sponsorship. Finally, continuous monitoring (ConMon) requires ongoing vulnerability scans, patching, and annual assessments, because authorization is not a one-time event.

FedRAMP sits within a larger compliance landscape: FISMA is the federal law that requires agencies to secure their information systems, NIST SP 800-53 supplies the control catalog, and FedRAMP applies those controls specifically to cloud services. Because its requirements are demanding, vendors that earn authorization often cite it to private-sector customers such as banks and hospitals as evidence of mature security.

19.7 NIST Cybersecurity Framework 2.0 and the Govern Function#

The frameworks table above lists NIST CSF as one option among many, but its 2024 revision deserves closer attention because it elevated governance itself to a first-class concern, which is the central theme of this chapter. The original framework (CSF 1.1, 2018) organized controls around five functions: Identify, Protect, Detect, Respond, and Recover. On February 26, 2024, NIST released CSF 2.0, the first major update since 2014, and added a sixth function, Govern (GV), while expanding the framework’s scope from critical infrastructure to organizations in any sector.

The six core functions are:

Govern (GV) establishes the organizational cybersecurity strategy, risk-management policy, roles and responsibilities, oversight, and cybersecurity supply-chain risk management.
Identify (ID) manages asset inventory, risk assessment, and improvement.
Protect (PR) implements identity management, access control, awareness training, data security, and platform security.
Detect (DE) provides continuous monitoring and adverse-event analysis.
Respond (RS) executes incident management, analysis, communication, and mitigation.
Recover (RC) restores operations after incidents.

Govern is not just another peer function; NIST depicts it at the center of the wheel because it informs how an organization implements the other five. Its introduction explicitly acknowledges that technical controls alone are insufficient without organizational commitment and executive accountability, which is precisely the argument this chapter has been building. Crucially, supply-chain risk management (GV.SC) is integrated under Govern, reflecting the recognition that third-party risk must be owned at the governance level rather than treated as a procurement afterthought.

        flowchart TB
    GV[GOVERN GV<br/>strategy, policy, roles,<br/>oversight, supply-chain risk]
    GV --- ID[Identify]
    GV --- PR[Protect]
    GV --- DE[Detect]
    GV --- RS[Respond]
    GV --- RC[Recover]

The NIST AI Risk Management Framework (AI RMF 1.0)#

As organizations adopt artificial intelligence, a parallel NIST framework addresses the risks that AI systems themselves create. The NIST AI Risk Management Framework (AI RMF 1.0), published as NIST AI 100-1 on January 26, 2023, is a voluntary, sector-agnostic framework for managing risks to individuals, organizations, and society from the design, development, deployment, and use of AI. It has two parts: a foundational part that frames AI risk and defines the characteristics of trustworthy AI, and a Core that, like CSF, is built from functions, categories, and subcategories and is supported by a companion AI RMF Playbook.

The seven characteristics of trustworthy AI that the framework works to cultivate are that a system be valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed.

The AI RMF Core has four functions:

Govern, a cross-cutting culture of AI risk management, with policies, accountability, roles, and oversight that inform the other three (mirroring the central Govern role in CSF 2.0).
Map, establishing the context and identifying the risks of an AI system across its lifecycle.
Measure, analyzing, assessing, benchmarking, and monitoring AI risk with quantitative and qualitative methods.
Manage, prioritizing and acting on risks by allocating resources to treat, monitor, and respond to them.

NIST has continued to extend the AI RMF rather than replace it; notably it released a Generative AI Profile (NIST AI 600-1) in July 2024 to address the distinct risks of generative systems.

CSF 2.0 versus AI RMF 1.0#

The two frameworks are complementary, not competing. Both are voluntary NIST products, both are function-based, and both elevate Govern to a cross-cutting role. They differ in scope and in what kind of risk they manage.

Dimension	NIST CSF 2.0	NIST AI RMF 1.0
Purpose	Manage cybersecurity risk to systems and data	Manage risks from AI systems to people, organizations, and society
Released	February 2024	January 2023 (Generative AI Profile, 2024)
Functions	Six: Govern, Identify, Protect, Detect, Respond, Recover	Four: Govern, Map, Measure, Manage
Central goal	Protect against and recover from cyber threats	Build and sustain trustworthy AI
Risk lens	Confidentiality, integrity, availability	Validity, safety, security, accountability, transparency, explainability, privacy, fairness
Lifecycle focus	Operating and defending systems	The AI lifecycle from design through deployment and monitoring

In practice an organization that builds or uses AI applies both: CSF 2.0 to secure the systems, networks, and data the AI runs on, and the AI RMF to manage AI-specific harms such as bias, unsafe behavior, and lack of transparency. Because both center Govern, they fit the same governance program described in this chapter, and NIST publishes crosswalks that map the AI RMF to other frameworks so the two can be run together rather than as silos.

19.8 Cybersecurity Governance at the Municipal Level#

Governance frameworks are usually discussed in the context of well-resourced enterprises, but the hardest governance problems often appear where resources are thinnest. Local governments have become attractive targets because of limited budgets, aging infrastructure, and growing reliance on digital services, and the consequences are concrete. The 2019 Baltimore ransomware attack disrupted city services for weeks at an estimated cost of about $18 million, and Atlanta’s 2018 attack required roughly $17 million in recovery. Supply-chain compromises compounded the exposure: the 2020 SolarWinds backdoor reached an estimated 18,000 organizations, including state and local agencies, and the 2023 MOVEit Transfer exploitation affected thousands of organizations through a single unpatched file-transfer platform. Federal guidance, including Executive Order 14028 and the CISA Cybersecurity Performance Goals, pushed comprehensive governance at all levels of government, but adoption among resource-constrained municipalities remains uneven.

Benchmarking Readiness with Automated Policy Analytics#

How would one even measure whether a city’s policies align with a framework like CSF 2.0? Manual policy audits are expensive and hard to replicate across jurisdictions, which motivates automated, reproducible assessment. The author’s study Benchmarking Municipal Cybersecurity Readiness Through Automated Policy Analytics assembled a corpus of 51 Maryland government documents and compared two methods of mapping policy text to the six CSF 2.0 functions: a keyword-based baseline using predefined term lists, and an AI-assisted approach using a large-language-model classifier.

The comparison is instructive for anyone who would automate governance assessment. The keyword method achieved high recall (0.857) but poor precision (0.222, F1 = 0.353), generating 21 false positives because context-free term matching flagged workforce reports, business plans, and meeting agendas as cybersecurity-relevant. The AI-assisted method reached perfect recall (1.000) with substantially higher precision (0.583, F1 = 0.737), cutting false positives by 76% and eliminating the false negative. Overall accuracy rose from 56.9% to 90.2%.

Method	True pos.	False pos.	False neg.	F1	Accuracy
Keyword-based	6	21	1	0.353	56.9%
AI-assisted	7	5	0	0.737	90.2%

The most telling result is the Protect function: keyword and AI scores were uncorrelated there ($r = 0.151$, $p = 0.291$, not significant), because the term training appears constantly in non-security documents (correctional vocational programs, apprenticeship and workforce policies). Keyword matching on Protect was essentially noise, and a workforce-development report even out-ranked three genuine cybersecurity policies. The lesson generalizes: when a policy corpus contains heterogeneous document types, keyword frequency systematically distorts coverage statistics, while a context-aware classifier correctly scores a technical security policy whose vocabulary matches no keyword list, and correctly zeroes a workforce report full of security-adjacent words. The trade-off is computational cost and reduced transparency.

Governance and Supply-Chain Gaps#

Beyond method comparison, the study surfaced two substantive governance findings. First, a governance deficit at the municipal level: AI classification showed consistent Govern coverage in state policies, but targeted searches surfaced no standalone public cybersecurity policy from any of Maryland’s 23 counties or the city of Baltimore, suggesting that formal accountability structures and executive cybersecurity ownership remain underdeveloped locally. Second, a supply-chain risk-management gap: although supply-chain keywords appeared in 34 of 51 documents, most occurrences were vendor-of-record references in procurement language that imposed no security obligations, and municipal documents contained no dedicated supply-chain cybersecurity requirements, a structural vulnerability given the SolarWinds and MOVEit precedents.

The study’s recommendations are low-cost and governance-first, mirroring this chapter’s thesis that governance, not gadgetry, is the foundation: (1) formally adopt CSF 2.0 Govern provisions, documenting risk appetite and executive cybersecurity roles with minimal technical investment; (2) embed cybersecurity requirements (vendor certification, incident-notification, right-to-audit clauses) in standard procurement templates; (3) establish regional incident-response partnerships so resource-constrained jurisdictions can share detection and response capacity; and (4) publish governance policies to create external accountability. For analysts, AI-assisted classification should be preferred over keyword matching whenever the corpus is heterogeneous.

Knowledge Check

What function did NIST CSF 2.0 add in 2024, and why is it depicted at the center of the framework?
Why did keyword-based classification fail specifically on the Protect function in the Maryland study?
Name two governance-level (low-cost) actions a small municipality can take before buying any new security technology.

Answers: (1) Govern (GV); it informs and ties together the other five functions, encoding the principle that technical controls require organizational commitment and executive accountability, and it now houses supply-chain risk management (GV.SC). (2) The keyword training appears heavily in non-security documents (workforce, vocational, apprenticeship), so context-free matching produced many false positives and the keyword/AI scores were uncorrelated ($r = 0.151$, $p = 0.291$). (3) Adopt CSF 2.0 Govern provisions (document risk appetite and executive roles) and embed cybersecurity clauses (vendor certification, incident notification, right-to-audit) in standard procurement templates; publishing the policy publicly adds accountability at no technical cost.

Compliance Reports, Certifications, and Agreements#

Frameworks describe what good security looks like; organizations prove they meet them through a variety of compliance artifacts, and a security leader must know which document does which job. Three families recur, especially when one organization must trust another (the vendor and supply-chain risk of Chapter 5 and 17).

ISO/IEC certifications. An accredited third party audits an organization against an ISO/IEC standard, most commonly ISO/IEC 27001 (information security management systems), and issues a certificate valid for a fixed period with periodic surveillance audits. The certificate is portable evidence that a documented, audited security program exists, which is why customers request it during procurement.
PCI DSS reports. Any organization that stores, processes, or transmits payment-card data must comply with the Payment Card Industry Data Security Standard (PCI DSS). Depending on transaction volume, compliance is demonstrated by a Self-Assessment Questionnaire (SAQ) or, for large merchants, a Report on Compliance (ROC) produced by a Qualified Security Assessor, often accompanied by an Attestation of Compliance (AOC). These reports are shared with acquiring banks and partners as proof that cardholder data is handled to standard.
HIPAA business associate agreements. Under the U.S. Health Insurance Portability and Accountability Act (HIPAA), a covered entity (such as a hospital) that shares protected health information with a vendor (a “business associate,” for example a cloud provider or billing service) must sign a Business Associate Agreement (BAA), a contract that legally binds the vendor to safeguard the data and report breaches. The BAA is what extends HIPAA’s obligations down the supply chain.

The common thread is assurance through evidence: a certificate, an audit report, or a contractual agreement lets one party rely on another’s controls without inspecting them directly. Related artifacts a governance program will encounter include SOC 2 Type II reports (independent attestation of a service organization’s controls over time), FedRAMP authorizations for cloud services sold to the U.S. government, and the software bill of materials (SBOM) and right-to-audit clauses of Chapter 17. Tracking which agreements are in force, and when they expire or need renewal, is itself a governance responsibility.

19.9 Governance, Risk, and Compliance (GRC) as an Integrated Discipline#

The governance, frameworks, and compliance artifacts above are usually managed together under the umbrella of Governance, Risk, and Compliance (GRC), and seeing them as one integrated discipline is what makes a security program coherent rather than a pile of disconnected controls. Governance sets direction (strategy, policy, roles, and accountability, the CISO and board material above); risk management identifies, assesses, and treats risk in business terms (Chapter 5), feeding governance the information it needs to prioritize; and compliance demonstrates that the resulting controls meet legal, regulatory, and contractual obligations (the ISO/PCI/HIPAA artifacts above). The three reinforce one another: governance decides risk appetite, risk assessment drives which controls to implement, and compliance evidences them, with audit results feeding back into governance, the same Govern-centered loop as NIST CSF 2.0.

Mature programs operationalize GRC with a few standard mechanisms: a risk register tracking each risk, its owner, treatment, and residual level; an exception (or risk-acceptance) process so deviations from policy are documented, approved at the right level, time-bound, and reviewed rather than silently tolerated; a security steering committee that gives security cross-functional authority; and GRC tooling that maps one control to the many frameworks it satisfies (so a single control can be evidenced for ISO/IEC 27001, SOC 2, and PCI at once). The goal is to make security a managed, measurable, repeatable business function rather than a series of heroic, ad-hoc efforts.

19.10 Audits, Assurance, and Security Maturity#

Governance is only credible if it is verified, which is the role of audit and assurance. Internal audits (independent of the security team) and external/third-party audits check that controls exist and operate as documented; the result may be a certification (ISO/IEC 27001) or an attestation (a SOC 2 Type II report, which tests controls over a period, not just at a point in time). Audits work against a control framework (NIST SP 800-53, ISO/IEC 27001 Annex A, the Center for Internet Security (CIS) Controls) so that “are we secure?” becomes the answerable “do these specific controls operate effectively?” Auditors prize evidence and separation of duties, which is why logging, change management, and access reviews matter as much as firewalls.

To track progress over time, programs use maturity models. A capability-maturity scale (such as CMMI’s levels from Initial, ad-hoc, through Managed and Defined to Quantitatively Managed and Optimizing) or the NIST CSF implementation tiers (Partial, Risk-Informed, Repeatable, Adaptive) lets an organization rate where each function stands today and set a target, turning governance into a roadmap. Maturity is not the same as compliance: an organization can be compliant yet immature (passing an audit by heroics) or mature in areas a given regulation does not cover. The board-level reporting discussed earlier should communicate both, current risk and the maturity trajectory, in the business language executives can act on.

19.11 Third-Party Risk and the Human Layer of Governance#

Two governance frontiers deserve emphasis because they are where programs most often fail. First, third-party and supply-chain risk governance (Chapters 5 and 17): organizations depend on vendors and cloud providers, so governance must extend beyond the perimeter through vendor assessment, contractual requirements, continuous monitoring of critical suppliers, and an inventory of who can reach what data. The SolarWinds and MOVEit incidents showed that an organization’s security is bounded by its weakest vendor, which is why CSF 2.0 elevated supply-chain risk to the Govern function. Section 19.19 works through the capacity arithmetic that decides how much of this a program can actually do.

Second, governance ultimately runs on people and culture: a security program is only as strong as the everyday behavior it produces, so governance includes the awareness program, a just culture that encourages reporting over blame (Chapter 14), and visible tone at the top. Section 19.23 turns that claim into something measurable. The recurring lesson of this chapter is that governance is the connective tissue that turns technical controls, risk decisions, compliance obligations and human behavior into one accountable system: without it security depends on individual heroics, and with it security becomes sustainable.

Knowledge Check

How do governance, risk management, and compliance reinforce one another in a GRC program?
What does a SOC 2 Type II report test that a point-in-time check does not, and why use a control framework for audits?
Why did NIST CSF 2.0 place supply-chain risk under the Govern function?

Answers: (1) Governance sets risk appetite and policy, risk assessment determines which controls to implement, and compliance evidences them; audit results feed back into governance, forming a continuous loop. (2) SOC 2 Type II tests whether controls operated effectively over a period of time, not just existed at one moment; a control framework turns the vague question “are we secure?” into auditable, specific control objectives. (3) Because organizations’ security depends on their vendors (SolarWinds, MOVEit), third-party risk must be owned and governed at the strategic level, not treated as a procurement afterthought.

19.12 What a Security Program Costs, and How It Gets Funded#

Everything above this point describes authority. Money is where authority is tested, and a CISO who cannot describe the budget cycle submits good requests at the wrong time, to the wrong body, in the wrong category, and loses them for reasons unconnected to their merits. One distinction matters most: operating expense recurs (salaries, subscriptions, managed services, cloud), while capital expense is a purchase depreciated over several years. The approval threshold, the approving body and the lead time often differ between the two, so a three-year software-as-a-service contract and an equivalent appliance can cost the same and still travel different paths.

A build-up, with numbers#

Take a 1,200-employee company with a $24 million technology budget. A defensible submission itemizes drivers rather than quoting a total:

Line	Basis	Annual cost
Staff, 8 full-time employees	fully loaded average of $185,000	$1,480,000
Managed detection and response	1,200 endpoints at $95	$114,000
Identity platform, security tier	1,300 identities at $72	$93,600
Vulnerability management	subscription	$85,000
Logging and analytics platform	400 GB per day, tiered	$420,000
External testing and assessment	3 engagements	$150,000
Awareness, training, certification		$60,000
Subtotal		$2,402,600
Contingency at 8 percent		$192,208
Total		$2,594,808

That is 10.8 percent of the technology budget and $2,162 per employee per year. Published benchmarks for both ratios vary widely by sector and by what each survey counts, so compute your own and say what is inside it. Every line has a unit and a quantity, so a reviewer argues with the quantity rather than with the CISO.

Sticker price is not cost#

A tool quoted at $85,000 a year also needs implementation, integration, tuning and an operator. If implementation is $40,000 once and running it consumes 0.4 of an engineer at a loaded $185,000, three-year total cost of ownership is 3 × 85,000 + 40,000 + 3 × 74,000 = $517,000, not the $255,000 of license fees. The staffing line is the one most often omitted from a business case, and the one that decides whether the tool is still in use a year later.

The case that survives a finance review is marginal, not absolute. Using the annualized loss expectancy machinery of Chapter 5, a control that cuts the annualized rate of occurrence of a $2.4 million event from 0.25 to 0.05 takes expected annual loss from $600,000 to $120,000, a $480,000 reduction against its cost. Present the frequency estimate as a range, because it is the weakest number in that sentence.

Exercises#

The submission above is approved at $2,594,808 and then cut by 12 percent. If staff costs are protected, what percentage reduction must the remaining lines absorb?
A tool is quoted at $60,000 a year, implementation is $30,000 once, and operating it takes 0.3 of an engineer at a loaded $185,000. Give the three-year total cost of ownership.

Answer Key#

The cut is $311,377. Non-staff lines total $1,114,808, so they absorb 311,377 / 1,114,808 = 27.9 percent.
License $180,000, operating 0.3 × 185,000 = $55,500 a year or $166,500, plus $30,000 implementation, for $376,500, which is 2.1 times the license fees.

19.13 Risk Appetite and Tolerance, Written So a Board Can Act on Them#

“Our appetite for cyber risk is low” is a mood, not a decision rule. Nobody can breach it and nothing escalates because of it. A board is entitled to a statement it can act on, which means numbers, thresholds and a named consequence for crossing them.

Three terms are not synonyms. ISO Guide 73:2009, the vocabulary accompanying the ISO 31000 risk management guidelines, defines risk appetite as the amount and type of risk an organization is willing to pursue or retain; note the word type, because appetite is never one number. Risk capacity is the most the organization could absorb before failing, which follows from its liquidity, insurance and contracts; it is an arithmetic fact rather than a preference, and appetite must sit at or below it. Risk tolerance is the acceptable deviation around a specific objective, and it is what staff actually work to.

Writing appetite in numbers#

A usable statement fits on one page: expected cyber-related losses not to exceed $5 million in a fiscal year; modeled loss at the 95th percentile not to exceed $20 million; no single event to cause more than 72 hours of unavailability of tier-1 revenue services; and no tolerance for missing a statutory notification deadline.

Now it drives decisions. If the loss exceedance curve puts the 95th percentile at $31 million against an appetite of $20 million, the gap is $11 million of tail, and the board’s question becomes which combination of control investment, contractual transfer and insurance closes $11 million at that percentile, and at what price. That is answerable; “are we secure?” is not.

The third line then cascades into a tolerance band on something measurable: restore a tier-1 service from backup within 24 hours, tested quarterly. At or under 24 hours is green. Between 24 and 48 hours is amber, triggering a remediation plan with a named owner and a date. Over 48 hours is red, reported to the board at its next meeting regardless of the reporting calendar. The escalation rule is the part people omit, and it is the part that turns a metric into governance.

One test before publishing: an appetite line you cannot evidence is worse than none, because it creates the appearance of control. Zero tolerance for a missed notification deadline is measurable only if every incident record carries the time of determination and the time of notification, which makes those two timestamps mandatory fields in the incident process.

19.14 The Three Lines Model, and the Criticisms of It#

The recurring argument inside a security program is not what the control should be. It is who owns it. The three lines model is the standard vocabulary for that argument, and a student needs both the model and the objections.

The Institute of Internal Auditors published the Three Lines of Defence position paper in 2013, replaced it in 2020 with The IIA’s Three Lines Model, dropping the word defence because it framed risk management as purely protective, and on 8 July 2026 replaced the position papers again with a Statement of Position on the Three Lines Model. The current statement names the board as its primary audience and reaffirms that where the chief audit executive takes on second-line responsibilities, safeguards must protect the internal audit function’s independence and its auditors’ objectivity.

        flowchart TB
    B[Board and audit committee<br/>accountability and oversight]
    B --- M[Executive management]
    M --- L1[First line<br/>owns and operates controls]
    M --- L2[Second line<br/>sets policy, monitors, challenges]
    B --- L3[Third line<br/>independent assurance]

The first line owns and operates: engineering, IT operations, application teams. The second line sets policy and challenges: security, risk and compliance, which do not own the systems, and that is the point. The third line provides independent assurance: internal audit, reporting to the audit committee rather than to management, so its findings cannot be edited by the people they concern.

Where it breaks, and what its critics say#

The commonest failure is a security function occupying the first and second lines at once. It runs the security operations center, the identity platform and the endpoint agent, which is first-line work, and it also writes the standards those systems are measured against and reports compliance with them, which is second-line work. If the function must both operate and assure, say so in writing, separate the people who report compliance from the people who run the tooling, and give internal audit an explicit mandate over the services security operates.

Davies and Zhivitskaya, in Global Policy in 2018, observed that the model’s origins are opaque and its effectiveness untested, and that diffusing responsibility across three lines can reduce accountability rather than increase it, because when three groups are responsible it is not obvious that anyone is. Valkenburg and Bongiovanni published the first systematic literature review of the model in cybersecurity in Computers and Security in 2024. The practical reading is narrow: the model is good vocabulary for separating who operates from who challenges from who assures, and a poor substitute for naming one accountable person per control.

19.15 One Control at Four Levels, and the Metadata That Makes It Auditable#

Section 19.3 defined policy, standard, process, procedure and guideline, and traced one real rule through all five. The definitions are easy and the drafting is not, so here is one control written as policy, standard, procedure and guideline, the four levels that carry its text.

Policy. “Access to company information systems shall be authenticated in a manner commensurate with the sensitivity of the information and the privilege of the account. The Chief Information Security Officer shall issue the standards that implement this requirement.” Technology-neutral, names an authority, still true in ten years.

Standard. “Accounts with administrative privilege over production systems must authenticate with a phishing-resistant authenticator conforming to WebAuthn or FIDO2. All other accounts must use at least a time-based one-time password or a push authenticator with number matching. Short message service and voice calls must not be used as a second factor. Administrative sessions must re-authenticate at least every 12 hours.” Specific, testable, due for revision when the technology moves.

Procedure. “1. In the identity provider console, open Security, then Authentication methods. 2. Set the policy named Admin-Phishing-Resistant to Enabled and scope it to the group prod-admins. 3. Confirm the change appears in the audit log. 4. Record the change ticket in the control register.” Names products and menus, and changes whenever a vendor redesigns a screen.

Guideline. “Where both a hardware security key and a platform authenticator are available, a hardware key is generally preferable for accounts used from more than one device, because it travels with the person rather than the machine.” Advice, not obligation.

The verb decides everything, and the header block proves it#

The standard says must; the guideline says should and generally. Mixing them is the commonest defect in real policy sets, because an auditor cannot test a “should” and a reader cannot tell which sentences bind them. Adopt the convention most standards bodies use: must and shall create an obligation, should is a recommendation that may be departed from with a documented reason, and may grants permission. Search your own policy set for should and read every hit.

A document nobody can date is not evidence. Every policy and standard carries a header block: identifier, version, owner expressed as a role rather than a person, approver, approval date, effective date, next review date, classification, audience, and the route for requesting an exception. An auditor checks that block before reading the content, because it answers whether the document was in force during the period under review. This is also why a policy must never name a product: a vendor rename would then force a policy revision and re-approval at executive level for what should be a one-line edit to a procedure.

19.16 Exceptions and Risk Acceptance, Where Governance Usually Fails#

Every real program deviates from its own standards. A program reporting no exceptions has either no standards or no honesty. The question is never whether deviations exist but whether they are visible, owned, time-bound and counted, and this is where otherwise competent programs most often fail, because the process is easy to write and tedious to run.

        flowchart LR
    A[Request:<br/>requirement, scope,<br/>business reason] --> B[Compensating<br/>control proposed]
    B --> C[Residual risk<br/>rated]
    C --> D[Approved at the level<br/>the rating requires]
    D --> E[Expiry date and<br/>remediation plan]
    E --> F{Expired?}
    F -->|Remediated| G[Closed]
    F -->|Not remediated| C

Six fields make a request reviewable: the requirement departed from, cited by document and clause; the business reason; the scope as named systems rather than “the finance department”; the compensating control; the residual risk rating; and an expiry date with the remediation plan that ends it. A request with no compensating control is a risk acceptance wearing the wrong label, and it should be routed as one rather than refused, because refusal drives the deviation underground where nobody owns it. Tie approval to the appetite statement of Section 19.13 rather than to seniority: low residual risk to the service owner, moderate to the CISO, high to the executive risk committee, and anything breaching an appetite line to the board, which set the line.

The arithmetic that decides whether the register survives#

Suppose a program grants 12 exceptions a month and closes 8. The register grows by 4 a month, so one starting at 200 holds 344 after three years, at which point nobody reads it. Two numbers keep it alive. The close rate must be tracked as a metric in its own right. And the expiry date is the only mechanism that forces closure, because an exception that expires compels a decision while one “reviewed annually” is renewed annually. Note the load: 200 open items on twelve-month expiries is roughly 17 renewal decisions a month, which is a staffing cost and must be budgeted as one.

Two anti-patterns finish the picture. An exception renewed four times is not an exception but the actual standard, and if the same exception has been granted to thirty teams the written standard is wrong; fixing it is cheaper than thirty review cycles a year. And every expired, unremediated exception should reconcile to an accepted risk with a named owner in the risk register. If those two records do not reconcile, risk is leaking out of the picture the board is being shown.

19.17 Metrics That Survive an Executive Audience#

Section 19.4 lists metrics a board might see. This section is about which of them earn the page. A metric belongs only if a different value would change a decision, if it has a denominator, and if it comes with a comparison: a target, a trend or a threshold. Apply those three filters and most dashboards lose two thirds of their tiles.

Why the mean misleads, worked#

Take twenty incidents in a quarter. Fifteen were detected within 1 hour, three within 12 hours, and two took 400 hours. The mean time to detect is (15 × 1 + 3 × 12 + 2 × 400) / 20 = 851 / 20 = 42.6 hours. The median is 1 hour. The maximum is 400 hours.

All three are true and none is the report. The mean describes no incident that happened, and the median conceals the only two that mattered. What an executive needs is the threshold count: if the appetite statement requires detection within 24 hours, the reportable fact is that 2 of 20 incidents exceeded the threshold, and both involved the same log source, which had stopped forwarding. That sentence contains a decision.

Denominators do the same work. A patch compliance figure of 94 percent invites one question: 94 percent of what? If the inventory holds 4,000 hosts and the real population is nearer 5,000, then 94 percent of the known 4,000 is 3,760 compliant out of 5,000, which is 75.2 percent, and the 1,000 unmanaged hosts are almost certainly worse than average. Report coverage beside compliance always.

The vanity metric this field cannot let go of#

Phishing simulation click rate appears on nearly every dashboard and the evidence that it measures anything actionable is poor. Ho and colleagues reported an eight-month randomized controlled trial at UC San Diego Health (the University of California, San Diego health system) covering ten campaigns and more than 19,500 employees, published at the IEEE Symposium on Security and Privacy in 2025. They found no significant relationship between recent completion of annual awareness training and failing a simulation, and an absolute difference in failure rates between trained and untrained users averaging about 1.7 percentage points. More than half of embedded training sessions ended within ten seconds and only 24 percent were completed. Cumulatively, 9.7 percent clicked in the first month and 56 percent had clicked at least one lure by the eighth.

Lain, Kostiainen and Capkun reached a compatible conclusion from a fifteen-month study of more than 14,000 employees at the same venue in 2022: embedded training as commonly deployed did not make employees more resilient, and in some conditions was associated with greater susceptibility. Their positive finding lay elsewhere, in a reporting button that turned the workforce into a collective detector at an operational load the organization could absorb.

Click rate is therefore the wrong number for a board. Replace it with three that pass the decision test: the reporting rate, the median time from delivery to first report, and the share of genuine campaigns first surfaced by a person rather than a tool.

Exercises#

A quarter contains twelve incidents: nine contained within 4 hours, two within 30 hours, one within 260 hours. Compute the mean and median, and state what you would put in the board pack.
A team reports 98 percent endpoint agent coverage. What is the one question you ask?

Answer Key#

The mean is (36 + 60 + 260) / 12 = 29.7 hours and the median is 4 hours. Report instead that one incident of twelve exceeded the tolerance threshold, name it, and say what changed as a result.
Ask for the denominator. If the management console is populated by the agent itself, the figure is circular and can only approach 100 percent, because uncovered devices are invisible to it.

19.18 Committees, Decision Rights, and Who Actually Decides#

A committee is not a decision. It is a place where a decision can be recorded. Most security governance failures, traced back far enough, are failures to have written down, before the meeting, who was allowed to say yes.

Three bodies do three jobs. The board or its audit and risk committee exercises oversight: it satisfies itself that a program exists, is resourced, reports honestly, and carries only risks the board is content to carry. The executive steering committee prioritizes and funds, arbitrates between business units, and owns exceptions above the CISO’s authority; its force comes from members who own the affected budgets. Technical bodies, such as a change advisory board, apply the standards the first two set. A charter that works specifies purpose, membership by role rather than by name, quorum, the decision rule, the decisions the body may take alone and the threshold above which it must escalate, cadence, and who keeps the minutes. Minutes are evidence: a decision taken but not minuted did not happen as far as the record is concerned.

Decision rights on one real decision#

An internet-facing system cannot be patched before a release freeze. Accountable, meaning one named person who carries the consequence, is the system owner. Responsible for the compensating controls is the platform team. Consulted are security, which rates the residual risk, and legal, where there is regulatory exposure. Informed is the steering committee, through the exception register. Escalation follows Section 19.16. The test of whether this is real is to ask three people to name the accountable person; more than a minute, or more than one name, means the model is decorative.

New York’s Department of Financial Services wrote board oversight into the New York Codes, Rules and Regulations (NYCRR), and the text reads as a checklist. Under 23 NYCRR 500.4(d) the senior governing body must exercise oversight of cybersecurity risk management, including by having sufficient understanding of cybersecurity matters to do so, which may include the use of advisers; requiring executive management to develop, implement and maintain the program; regularly receiving and reviewing management reports; and confirming that management has allocated sufficient resources to maintain an effective program. That last clause is unusual: a regulator has made the adequacy of the security budget an explicit board duty, which connects Section 19.12 to the boardroom.

19.19 Third-Party and Supply-Chain Governance#

Section 19.11 established that an organization’s security is bounded by its weakest vendor. The part that defeats most programs is that assessment capacity is finite and vendor counts are not, so tiering is arithmetic before it is philosophy.

Suppose 1,400 third parties under contract, a full assessment consuming roughly 12 hours across questionnaire review, evidence review and follow-up, and two analysts at 1,400 productive hours each. That is 2,800 hours, or 2,800 / 12 = 233 full assessments a year, which is 17 percent of the portfolio. A policy saying “all third parties are assessed annually” is false on the day it is signed. The credible policy assesses tier 1 annually, tier 2 on a three-year cycle or on material change, and tier 3 through contract clauses alone. Put the capacity calculation in the supporting analysis, because it is the argument that wins more analysts when the vendor count grows.

Four questions separate the tiers: the highest classification of data the vendor can reach; the access they hold, from none through read and privileged to the ability to execute code in your environment; whether a 48-hour outage there would stop revenue or a regulated process; and concentration, meaning how many tier-1 vendors sit on the same cloud provider, region or upstream component. The fourth is the one most registers omit, and it is what turns one provider incident into a correlated failure across a dozen suppliers.

What the artifacts prove, and which clauses work#

A SOC 2 Type II report covers a stated period and a stated scope, so read the scope description and the list of exceptions before the opinion. A bridge letter covers the interval since the report period ended and is an assertion by the vendor’s management rather than an audit. An ISO/IEC 27001 certificate rests on a statement of applicability, so ask for that, not just the certificate.

A notification deadline matching your own regulatory clock is the first clause to fight for. If a rule obliges you to notify a regulator within 72 hours of determining that an incident occurred, a vendor clause granting them 30 days makes your obligation unmeetable, and no internal process fixes it. Add the right to evidence on demand, flow-down to subcontractors, a software bill of materials, and a defined exit process with a deadline for data return and deletion.

NIST CSF 2.0 placed cybersecurity supply chain risk management inside the Govern function as GV.SC, as Section 19.7 describes. In European Union financial services the Digital Operational Resilience Act, which has applied since 17 January 2025, requires financial entities to maintain a register of information on their contractual arrangements for the use of information and communication technology services, turning the vendor inventory into a regulatory filing.

19.20 The CISO Reporting Line, and What the Evidence Actually Says#

Section 19.2 states the received view: the CISO should not report to the CIO. It deserves a harder look, because the evidence behind it is thinner than the confidence with which it is asserted.

The case for independence is the three lines case of Section 19.14. A CIO is measured on availability, delivery speed and cost, and security work can degrade all three in the short run, so placing the assuring function inside the assured one creates an incentive to soften the message without anyone acting in bad faith. The counter-argument is rarely stated and is not weak: a CISO outside the technology organization loses proximity to the engineering decisions that create risk, often loses influence over the platform budget where controls are implemented, and can decay into a compliance office issuing standards nobody implements.

What the data shows, and what it does not#

The most current public figures come from the Heidrick and Struggles 2025 Global Chief Information Security Officer Compensation Survey, fielded in summer 2025 among 371 CISOs. Of the 231 who answered the reporting-line question, 42 percent reported to the CEO, 30 percent to a CIO, chief data officer (CDO), CTO or equivalent technology executive, 15 percent to another security executive, 6 percent to a chief operating officer (COO) or chief administrative officer, and 7 percent elsewhere. The report notes the CEO figure is about three times the prior year’s.

Three caveats matter more than the numbers. This is a self-selected panel skewed toward large organizations. A year-over-year swing that large in such a panel can reflect a change in who answered as much as a change in the world. And, decisively, no public dataset establishes that the reporting line causes better outcomes, because doing so would require controlling for size, sector, regulatory exposure and threat environment. State the independence argument as reasoning, which it is, and not as an empirical finding.

Regulators, meanwhile, have legislated the information path rather than the organization chart. Under 23 NYCRR 500.4(b) the CISO must report in writing at least annually to the senior governing body on material cybersecurity risks, the overall effectiveness of the program, material events during the period, and plans for remediating material inadequacies, and under 500.4© must timely report material issues as they arise. The SEC’s Regulation S-K Item 106©(2) similarly requires a description of which management positions are responsible, their expertise, how they are informed, and whether they report to the board. Neither says who the CISO reports to administratively. The practical resolution is to separate administrative reporting, which sets objectives and pay, from functional reporting, which determines who receives the risk picture unedited, and to write the second into a charter. The test is whether the CISO can put an unwelcome number in front of the board without an intermediary editing it.

19.21 Duties That Reach Officers Personally#

For most of this field’s history a governance failure was a corporate problem. Several regimes now attach duties to named individuals. This section states what each rule requires and when it took effect; it does not predict enforcement, and where litigation is unresolved it says so.

The SEC cybersecurity disclosure rules#

The Commission adopted the rules on 26 July 2023 (Release Nos. 33-11216 and 34-97989, published at 88 FR 51896), effective 5 September 2023.

Item 1.05 of Form 8-K. A registrant that determines a cybersecurity incident is material must describe the material aspects of its nature, scope and timing and its material impact or reasonably likely material impact, generally within four business days of the determination. An instruction requires the materiality determination to be made without unreasonable delay after discovery, which is the operative constraint: a registrant cannot stop the clock by declining to decide. Disclosure may be delayed where the United States Attorney General determines it poses a substantial risk to national security or public safety and notifies the Commission in writing, for up to 30 days, extendable by a further 30, and in extraordinary circumstances by a final 60.

Regulation S-K Item 106. The annual report describes processes for assessing, identifying and managing material risks from cybersecurity threats, including whether third parties are engaged and whether processes exist to oversee risks from third-party service providers. Item 106© requires a description of the board’s oversight, identifying any responsible committee, and of management’s role, including which positions are responsible, their relevant expertise, how they are informed, and whether they report to the board. Compliance ran from annual reports for fiscal years ending on or after 15 December 2023, and from 18 December 2023 for Form 8-K, with smaller reporting companies given an additional 180 days.

What the rules do not require. The Commission proposed, and then did not adopt, a requirement at Item 407(j) to disclose the cybersecurity expertise of board members; the adopting release says so in terms. The opposite is asserted often enough to be worth memorizing. A petition filed in May 2025 asks the Commission to rescind Item 1.05; it is pending and the rules remain in effect, so verify before relying on this.

SolarWinds, and what it established#

The Commission filed SEC v. SolarWinds Corp. and Timothy G. Brown, No. 1:23-cv-09518-PAE (S.D.N.Y.), on 30 October 2023, naming the company and its chief information security officer over statements about the company’s security posture. In July 2024 the court dismissed most of the claims. On 20 November 2025 the Commission filed a joint stipulation dismissing the remainder against both defendants with prejudice, stating that the decision was taken “in the exercise of its discretion” and “does not necessarily reflect the Commission’s position on any other case” (Litigation Release No. 26423).

The case therefore established no precedent about personal liability and produced no judgment against the individual. What it changed is durable: it made public statements about security posture, including trust center pages and white papers, into governance artifacts with an owner, a review date and sign-off from legal and security.

New York’s Part 500, where governance produces a signature#

23 NYCRR Part 500, whose second amendment took effect 1 November 2023, is more specific about individuals than the federal rules. Section 500.17(a) requires notice to the superintendent as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, an affiliate or a third-party service provider. Section 500.17(b) requires an annual submission by 15 April, either a certification of material compliance for the prior calendar year, based on data and documentation sufficient to demonstrate it, or a written acknowledgment identifying every section not complied with and giving a remediation timeline; either must be signed by the entity’s highest-ranking executive and its CISO, with supporting records kept five years. Section 500.17© requires notice of an extortion payment within 24 hours and, within 30 days, a written description of why payment was necessary, the alternatives considered and the diligence performed, including on Office of Foreign Assets Control compliance. Two named individuals sign an annual compliance statement, which is why the evidence trail must be maintained through the year rather than assembled in April.

One conviction, and two duties abroad#

In October 2022 a federal jury convicted Joseph Sullivan, formerly chief security officer of Uber, of obstruction of a Federal Trade Commission proceeding and misprision of a felony over the concealment of a 2016 breach affecting roughly 57 million users and drivers; in May 2023 Judge William H. Orrick of the Northern District of California sentenced him to three years of probation and a $50,000 fine. The conduct at issue was concealment from a federal agency, not a failure to prevent an intrusion, and losing that distinction teaches the wrong lesson.

The NIS2 (Network and Information Security) Directive requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures taken by their entities and oversee their implementation, provides that they can be held liable for infringements, and requires those members to follow cybersecurity training. The Digital Operational Resilience Act, applying to European Union financial entities since 17 January 2025, places responsibility for the information and communication technology risk management framework on the management body. By contrast the Cyber Incident Reporting for Critical Infrastructure Act of 2022, which requires CISA to make rules obliging covered entities to report covered incidents within 72 hours and ransom payments within 24 hours, is not yet in force: CISA has not issued the final rule, its own guidance states that reports are not required under the Act until that rule’s effective date, and the rulemaking slipped further during 2026. It is worth teaching because it shows the difference between a statute that exists and an obligation that binds an organization today.

Exercises#

A registrant discovers an incident on Thursday 12 March and determines it material on Tuesday 17 March. With no holidays and no Attorney General delay, what is the Item 1.05 filing deadline, and which date starts the clock?
True or false: the SEC rules require disclosure of whether any director has cybersecurity expertise.
A covered entity under 23 NYCRR Part 500 makes an extortion payment on 3 June. State its two obligations and their deadlines.

Answer Key#

The clock runs from determination, so four business days from Tuesday 17 March gives Wednesday, Thursday, Friday and Monday, making the deadline Monday 23 March. Discovery still matters, because a long gap before determination would breach the without-unreasonable-delay instruction.
False. That was the proposed Item 407(j), which was not adopted. The rules require a description of management’s relevant expertise under Item 106©(2).
Notice of the payment within 24 hours, so by 4 June, and by 3 July a written description of why payment was necessary, the alternatives considered and the diligence performed, including on Office of Foreign Assets Control compliance.

19.22 Tabletop Exercises at Board Level#

A technical tabletop tests responders. A board tabletop tests the decisions only officers and directors can take, and running the technical scenario in front of the board produces a pleasant hour and no findings.

Five decisions recur: the materiality determination and its clock, which Section 19.21 shows is where several regimes attach; whether to pay an extortion demand, who may authorize it, and what diligence must precede it; what is said, to whom and in what order, across customers, regulators, the market and employees; when outside counsel is engaged and what that means for privilege; and who speaks publicly. The design follows: ninety minutes, a one-page scenario issued in advance, three injects roughly twenty minutes apart that each remove an assumption the room has just made, no slides from the security team, a facilitator who is not the CISO because the CISO is a player, and one observer recording which decisions could not be taken.

A worked inject#

Discovery at 16:00 on a Friday, partial information across the weekend, and a materiality determination on Tuesday. Under Item 1.05 the filing is due four business days later: Wednesday, Thursday, Friday, Monday. Now the inject. A journalist calls on Monday morning, a week before the deadline, quoting a post on a leak site. Does the company speak? Who speaks? Is a holding statement already drafted and approved, and who may release it without reconvening the committee? That one question surfaces more gaps than an hour of network diagrams, and none can be closed by the security team alone.

CISA publishes Tabletop Exercise Packages, customizable templates with exercise objectives, situation manuals, discussion questions and a facilitator slide template, covering ransomware, insider threat, phishing and industrial control system compromise. They are a sound starting point provided the questions are rewritten for an officer audience.

The deliverable is not a score but a list of decisions that could not be taken, and in practice every reason reduces to one of four: no delegation, no contact, no number, or no decision rule. Each converts into a governance change, respectively an amended delegation of authority, a named person and an out-of-hours number in the incident plan, an appetite line under Section 19.13, and an escalation threshold in a charter. Run it annually and open each year with last year’s findings.

19.23 Measuring Culture Instead of Asserting It#

Section 19.5 describes what a good security culture looks like. It does not say how an organization would know it had one, and “we have a strong security culture” is an assertion that costs nothing to make.

Self-report instruments. A validated questionnaire beats one written in an afternoon, because its structure and reliability have been published and can be criticized. The Human Aspects of Information Security Questionnaire (HAIS-Q), developed by Parsons and colleagues with further validation studies in Computers and Security in 2017, measures knowledge, attitude and self-reported behavior across seven focus areas. The Security Behavior Intentions Scale (SeBIS), from Egelman and Peer at CHI 2015, measures intentions across device securement, password generation, proactive awareness and updating. Both share one limitation that is fundamental rather than fixable: they measure what people say they know or intend, not what they do at 17:45 on a Friday when the message appears to come from their manager.

Observed behavior, which is where to invest, because the data already exists in the operation. The reporting rate, as reports per 1,000 employees per month, always beside its true-positive fraction. The median time from delivery to first report, which determines whether a live campaign can be pulled before it spreads. The share of genuine campaigns first surfaced by a person rather than a tool, which, at zero, means the awareness program is not contributing to detection whatever the survey says. And exception requests per quarter, read carefully: a rising rate often means a standard has become unworkable and people are asking rather than working around it. The pattern to fear is falling requests alongside rising incidents.

What the evidence says about the standard intervention#

The two studies in Section 19.17 bear directly here. Ho and colleagues found no significant relationship between recent completion of annual awareness training and failing a phishing simulation, an absolute difference of about 1.7 percentage points between trained and untrained groups, and no benefit from completing more sessions. Lain, Kostiainen and Capkun found embedded training as commonly deployed did not improve resilience, while a reporting button made the workforce an effective collective detector.

The implication is a reallocation, not an abolition: move effort from teaching people to recognize messages toward making the reporting path one click deep and visibly safe to use, and toward controls that remove the decision from the person, of which the phishing-resistant authenticators of Section 19.15 are the clearest example. One caution on surveys: a response rate below about half measures the people who chose to answer, so publish the rate beside every result, segment by function, and refuse to run a survey whose results you have no plan to act on.

Exercises#

Over two quarters the reporting rate rises from 8 to 19 reports per 1,000 employees per month while the true-positive fraction falls from 0.31 to 0.11. Compute true positives per 1,000 per month in each period and say what the pair shows.
Your board asks for one number to represent security culture. What do you give them, and what do you say about it?

Answer Key#

Before, 8 × 0.31 = 2.5 true positives per 1,000 per month; after, 19 × 0.11 = 2.1. Reporting volume more than doubled while genuine detections slightly fell, so the change is in reporting behavior rather than in detection. That is a triage cost, and it argues for better feedback to reporters rather than for celebrating the rate.
Median time from delivery to first report, with the reporting rate beside it. Say that no single number measures culture, that this one is observed rather than self-reported, and that the exception trend and near-miss count will accompany it next quarter.

Chapter Summary#

This chapter framed security as a matter of governance and culture. It defined security governance and the CISO role, laid out the policy hierarchy, tracing Anthropic’s 2026 rule against abusing its Claude models from policy down to the procedure that enforces it, and board-level reporting, and addressed how to build a security culture. It surveyed common compliance frameworks, the NIST Cybersecurity Framework 2.0 and its Govern function, and governance at the municipal level, then treated governance, risk, and compliance as an integrated discipline alongside audits, assurance, and security maturity, and third-party risk and the human layer. It then turned to the machinery that makes a program real: how security is funded and what a tool actually costs; risk appetite and tolerance written as numbers; the three lines model and its documented critics; one control drafted as policy, standard, procedure and guideline; the exception process, where governance most often fails; metrics that survive an executive audience and the vanity metrics that do not; committees and decision rights; third-party assessment capacity; the evidence behind the CISO reporting-line debate; the regulatory duties that now reach officers personally; board-level tabletop exercises; and how culture is measured rather than asserted. The recurring lesson is that technical controls succeed only when leadership, policy, accountability, and culture align behind them.

Why This Matters#

Security governance determines whether a security program is sustainable and effective or depends on the heroics of individual practitioners. Governance provides the authority to enforce policy, the budget to implement controls, the executive backing to prioritize security over short-term convenience, and the accountability structure that ensures security decisions are owned at the right level. Without governance, security is reactive, underfunded, and fragile.

News in Focus: What the SolarWinds Case Did and Did Not Settle#

In October 2023 the Securities and Exchange Commission sued SolarWinds and its chief information security officer over statements about the company’s security posture, and the filing was widely read as the moment security leaders became personally exposed. In July 2024 a federal court dismissed most of the claims, and on 20 November 2025 the Commission filed a joint stipulation dismissing the remainder with prejudice, noting that the decision was taken in the exercise of its discretion and does not necessarily reflect its position on any other case. No precedent about personal liability survives the dismissal.

What survives is narrower and more useful. The Commission’s 2023 disclosure rules remain in effect and require a registrant to file a Form 8-K generally within four business days of determining that a cybersecurity incident is material, and to describe board oversight and management’s role each year. Separately, New York’s Department of Financial Services requires a covered entity’s highest-ranking executive and its CISO to sign an annual compliance certification or acknowledgment. Boards now demand substantive briefings because rules oblige them to describe what they receive, not because a court held anyone liable. Section 19.21 sets out both regimes and their dates.

# Chapter 19 -- Security governance: policy validator and metrics dashboard

import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import numpy as np
from io import BytesIO
from IPython.display import display, Image
from dataclasses import dataclass
from typing import List, Optional

# ── Policy quality checker ─────────────────────────────────────────────────────
@dataclass
class SecurityPolicy:
    title: str
    version: str
    owner: str
    approved_by: str
    review_date: Optional[str]
    applies_to: str
    body: str
    has_violation_consequence: bool
    has_exception_process: bool

    def quality_check(self) -> List[str]:
        issues = []
        if not self.owner:              issues.append("Missing policy owner")
        if not self.approved_by:        issues.append("No approval authority listed")
        if not self.review_date:        issues.append("No review date specified")
        if not self.has_violation_consequence:
            issues.append("No violation consequence defined -- not enforceable")
        if not self.has_exception_process:
            issues.append("No exception process defined")
        vague = ["should", "may wish to", "as appropriate", "reasonable"]
        found_vague = [v for v in vague if v in self.body.lower()]
        if found_vague:
            issues.append(f"Vague language found: {found_vague} -- replace with 'must' or 'shall'")
        if len(self.body.split()) < 100:
            issues.append("Policy body too short -- likely missing requirements")
        return issues

policies = [
    SecurityPolicy(
        "Acceptable Use Policy", "2.1", "CISO", "CEO",
        "2027-01-01", "All employees and contractors",
        ("All users must use company-issued devices for company data. "
         "Users must not install unauthorised software. "
         "Internet access is logged and subject to monitoring. "
         "Violations may result in disciplinary action up to and including termination. "
         "Exceptions require written approval from the CISO. " * 8),
        has_violation_consequence=True, has_exception_process=True,
    ),
    SecurityPolicy(
        "Password Policy", "1.0", "", "IT Manager",
        None, "IT systems",
        "Passwords should be complex and should not be shared. Users may wish to use a password manager.",
        has_violation_consequence=False, has_exception_process=False,
    ),
]

print("=== Policy Quality Audit ===\n")
for p in policies:
    issues = p.quality_check()
    grade = "PASS" if not issues else "FAIL"
    print(f"  [{grade}] {p.title} v{p.version}")
    if issues:
        for iss in issues:
            print(f"         [!] {iss}")
    else:
        print(f"         All quality checks passed")
    print()

# ── Board-level security metrics dashboard ────────────────────────────────────
months = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun']
mttd   = [18, 15, 14, 12, 10, 8]        # hours; lower is better
mttr   = [48, 42, 36, 30, 24, 18]       # hours; lower is better
patch  = [72, 78, 81, 86, 90, 94]       # % compliance; higher is better
phish  = [22, 18, 16, 12, 9,  7]        # % click rate; lower is better

fig, axes = plt.subplots(2, 2, figsize=(11, 7))
fig.suptitle("Figure 19.1  Board Security Metrics Dashboard", fontsize=12, fontweight="bold")

for ax, data, label, target, good_direction in [
    (axes[0,0], mttd,  "MTTD (hours)",          8,  "lower"),
    (axes[0,1], mttr,  "MTTR (hours)",          24,  "lower"),
    (axes[1,0], patch, "Patch compliance (%)",  95,  "higher"),
    (axes[1,1], phish, "Phishing click rate (%)", 5, "lower"),
]:
    color = "#3a7ebf"
    ax.plot(months, data, marker='o', color=color, lw=2, markersize=7)
    ax.fill_between(months, data, alpha=0.12, color=color)
    ax.axhline(target, color="#e05a4e", ls="--", lw=1.2)
    ax.text(months[-1], target, f" Target: {target}", color="#e05a4e", va="center", fontsize=8)
    ax.set_title(label, fontsize=9, fontweight="bold")
    ax.set_ylim(0, max(data) * 1.2)
    trend = "Improving" if (good_direction=="lower" and data[-1]<data[0]) or \
                           (good_direction=="higher" and data[-1]>data[0]) else "Degrading"
    ax.set_xlabel(f"Trend: {trend}", fontsize=8, color="#333")
    ax.tick_params(labelsize=8)
    ax.grid(axis='y', alpha=0.3)

plt.tight_layout()
_buf = BytesIO()
plt.savefig(_buf, format="png", dpi=120, bbox_inches="tight")
plt.close(); _buf.seek(0)
display(Image(data=_buf.read()))
print("Figure 19.1 rendered.")

=== Policy Quality Audit ===

  [PASS] Acceptable Use Policy v2.1
         All quality checks passed

  [FAIL] Password Policy v1.0
         [!] Missing policy owner
         [!] No review date specified
         [!] No violation consequence defined -- not enforceable
         [!] No exception process defined
         [!] Vague language found: ['should', 'may wish to'] -- replace with 'must' or 'shall'
         [!] Policy body too short -- likely missing requirements

../../_images/b3f4f5c34f59d895c4327a9379c78ac4a188766beee3aa22d65dd5ba99882865.png

Figure 19.1 rendered.

Review Questions (MCQ)#

Q1. Security governance differs from security management in that governance: A. Handles day-to-day technical operations B. Provides strategic direction and accountability at the executive and board level C. Writes security policies D. Manages firewall rules

Q2. A security standard differs from a policy in that a standard: A. Is written by the CISO B. Is technology-specific, measurable, and mandatory C. Is non-mandatory D. Is reviewed only once every five years

Q3. The word that belongs in a mandatory policy statement is: A. “should” B. “may” C. “could” D. “must” or “shall”

Q4. Effective board-level security reporting should use: A. Technical CVE identifiers and CVSS scores B. Business-language risk framing with financial exposure C. Log excerpts from the SIEM D. Nmap output

Q5. A Key Risk Indicator (KRI) is best described as: A. A metric measuring past performance B. A leading indicator signaling changing risk levels before an incident C. A compliance audit result D. A count of firewall rules

Q6. Tone at the top is most effective when: A. Senior leaders publicly champion security and model the required behaviors B. The CISO sends all-staff emails C. Policies are posted on the intranet D. Annual training is mandatory

Q7. A just culture improves security by: A. Punishing all security mistakes equally B. Encouraging incident reporting by responding to errors proportionately, not punitively C. Removing all security policies D. Automating all responses

Q8. SOC 2 Type II is primarily demanded by: A. US healthcare regulators B. Payment card brands C. Enterprise customers of technology/SaaS companies D. EU supervisory authorities

Q9. An exception process in a security policy is important because: A. It allows any user to bypass any control B. It provides a documented, risk-accepted mechanism for legitimate deviations C. It reduces the number of controls required D. It eliminates audit findings

Q10. The CISO ideally reports to the CEO or board audit committee rather than the CIO because: A. The CISO earns more than the CIO B. Security and IT delivery have inherent conflicts of interest C. The CIO lacks authority to approve budgets D. GDPR requires it

Q11. Under the SEC rules adopted in July 2023, the four-business-day Form 8-K clock for a material cybersecurity incident starts on: A. Discovery of the incident B. Determination that the incident is material C. Containment D. The end of the fiscal quarter

Q12. The SEC’s final cybersecurity rules: A. Require disclosure of directors’ cybersecurity expertise B. Did not adopt the proposed board expertise disclosure C. Apply only to banks D. Replaced Regulation S-K

Q13. Risk capacity differs from risk appetite in that capacity: A. Is chosen by the board each year B. Is the most the organization could absorb before failing C. Applies only to operational risk D. Is identical to tolerance

Q14. Three-year total cost of ownership for a tool licensed at $85,000 per year, with $40,000 of one-time implementation and 0.4 of an engineer at a loaded $185,000, is: A. $255,000 B. $295,000 C. $517,000 D. $740,000

Q15. Randomized controlled studies of embedded phishing training in large organizations have found that: A. It halves failure rates B. Its effect on failure rates is small in absolute terms, while employee reporting is an effective detection mechanism C. It eliminates credential theft D. It works only in healthcare

Q16. Anthropic’s 2026 Usage Policy forbids sustained and needless abusive or cruel behavior toward its models, and files the rule under a heading called Universal Usage Standards. By this chapter’s definitions, that sentence is a: A. Standard B. Procedure C. Policy D. Guideline

Q17. Which of these is a procedure rather than a process? A. Claude redirects the user, checks for imminent risk, then calls the end-conversation action, and the app closes the thread B. Policy writing, training, testing, enforcement, feedback, and revision, each owned by a different team C. A yearly review that folds observed misuse into an updated policy D. The split of responsibility between policy writers and evaluators

Answers: Q1 B, Q2 B, Q3 D, Q4 B, Q5 B, Q6 A, Q7 B, Q8 C, Q9 B, Q10 B, Q11 B, Q12 B, Q13 B, Q14 C, Q15 B, Q16 C, Q17 A.

Lab Assignment#

Part A – Policy writing: Write a complete Acceptable Use Policy for a fictional 300-person company. Include: purpose, scope, policy statements (at least 8 “must” requirements), violation consequences, exception process, review date, and approval authority. Run it through the policy quality checker above.

Part B – Board metrics report: Using the metrics dashboard above as a template, add two additional metrics of your choice (e.g., third-party risk assessments completed, security incidents by severity). Write a two-paragraph executive narrative for the board explaining the trend in MTTD and phishing click rate in business language.

Part C – Policy hierarchy: For a fictional cloud-first company, create the full hierarchy for data encryption: one policy statement, three derived standards (for data at rest, data in transit, and key management), and one procedure for encrypting an S3 bucket in AWS. Show how each level derives from the level above.

Part D – Culture assessment: Design a 10-question survey to measure security culture in a 500-person organization. For each question, specify: the construct being measured (awareness, attitude, or behavior), the response scale, and what a low score indicates should be addressed in the awareness program.

References#

National Institute of Standards and Technology (2024). The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29
Trivedi, D. (2025). Benchmarking Municipal Cybersecurity Readiness Through Automated Policy Analytics: Evidence from Maryland Local Governments. CCSC Eastern. (see Appendix E)
Executive Office of the President (2021). Executive Order 14028: Improving the Nation’s Cybersecurity. 86 FR 26633.
Cybersecurity and Infrastructure Security Agency (2024). Cross-Sector Cybersecurity Performance Goals.
AICPA (American Institute of Certified Public Accountants) SOC 2; ISACA COBIT; CMMI; NIST CSF 2.0 implementation tiers.
NIST SP 800-53; ISO/IEC 27001 Annex A; CIS Critical Security Controls.
Securities and Exchange Commission (2023). Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure. Release Nos. 33-11216, 34-97989; 88 FR 51896 (August 4, 2023).
Securities and Exchange Commission (2025). SolarWinds Corp. and Timothy G. Brown. Litigation Release No. 26423 (November 20, 2025); No. 1:23-cv-09518-PAE (S.D.N.Y., filed October 30, 2023).
New York State Department of Financial Services. 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies; second amendment effective November 1, 2023.
United States Department of Justice, Northern District of California (2023). Former Chief Security Officer of Uber Sentenced to Three Years’ Probation for Covering Up Data Breach.
Institute of Internal Auditors (2026). Statement of Position: Three Lines Model, published July 8, 2026, superseding the 2020 position paper The IIA’s Three Lines Model.
Davies, H. and Zhivitskaya, M. (2018). Three Lines of Defence: A Robust Organising Framework, or Just Lines in the Sand? Global Policy 9(S1), 34-42. https://doi.org/10.1111/1758-5899.12568
Valkenburg, B. and Bongiovanni, I. (2024). Unravelling the three lines model in cybersecurity: a systematic literature review. Computers and Security 139, 103708.
Ho, G., Mirian, A., Luo, E., et al. (2025). Understanding the Efficacy of Phishing Training in Practice. IEEE Symposium on Security and Privacy. https://doi.org/10.1109/SP61157.2025.00076
Lain, D., Kostiainen, K. and Capkun, S. (2022). Phishing in Organizations: Findings from a Large-Scale and Long-Term Study. IEEE Symposium on Security and Privacy. arXiv:2112.07498
Parsons, K., Calic, D., Pattinson, M., et al. (2017). The Human Aspects of Information Security Questionnaire (HAIS-Q): Two further validation studies. Computers and Security 66, 40-51.
Egelman, S. and Peer, E. (2015). Scaling the Security Wall: Developing a Security Behavior Intentions Scale (SeBIS). CHI 2015. https://doi.org/10.1145/2702123.2702249
Heidrick and Struggles (2025). 2025 Global Chief Information Security Officer Compensation Survey.
ISO Guide 73:2009, Risk management - Vocabulary; ISO 31000:2018, Risk management - Guidelines.
Cybersecurity and Infrastructure Security Agency. CISA Tabletop Exercise Packages; Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) rulemaking status.
Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), applying from January 17, 2025; Directive (EU) 2022/2555 (NIS2), Article 20.
Anthropic (2026, October 8). 2026 Usage Policy update. https://www.anthropic.com/news/2026-usage-policy-update
Anthropic (2026). Usage Policy, effective November 12, 2026. https://www.anthropic.com/legal/aup
Anthropic (2025, August 15). Claude Opus 4 and 4.1 can now end a rare subset of conversations. https://www.anthropic.com/research/end-subset-conversations
Anthropic (2025, August 12). Building safeguards for Claude. https://www.anthropic.com/news/building-safeguards-for-claude
Anthropic (2025). System Card: Claude Opus 4 & Claude Sonnet 4, Section 5.7, Conversation termination with simulated users, and Transcript 5.7.A. https://www.anthropic.com/claude-4-system-card
Anthropic (2026). System prompt release notes: Claude Opus 5.5, prompt dated September 22, 2026. https://platform.claude.com/docs/en/release-notes/system-prompts/claude-opus-5-5
Anthropic. Tool use with Claude. Claude Platform Docs. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
Brandom, R. (2026, October 8). Anthropic changes usage policy to ban model abuse and election interference. TechCrunch. https://techcrunch.com/2026/10/08/anthropic-changes-usage-policy-to-ban-model-abuse-and-election-interference/
International Organization for Standardization (2015). ISO 9000:2015, Quality management systems: Fundamentals and vocabulary, definitions 3.4.1 (process) and 3.4.5 (procedure); definition 3.4.5 and its note are reproduced in the NIST glossary, https://www.nist.gov/glossary-term/47981

Chapter 19: Security Governance, Policy, and Culture

Contents

Chapter 19: Security Governance, Policy, and Culture#

Learning Objectives#

Key Terms#

19.1 What Security Governance Is#

Why Governance Matters#

19.2 The CISO Role#

Strategic Responsibilities#

Organizational Models#

Centralized Security Function#

Federated Security Model#

Reporting Lines and Independence#

19.3 The Policy Hierarchy#

Policy#

Policy Characteristics#

Standard#

Process#

Procedure#

Guideline#

A Worked Example: When Claude Ends an Abusive Chat#

Policy: what is forbidden, and why#

Standard: the conditions that make the rule testable#

Process: from rule to enforcement and back#

Procedure: the exact steps inside one conversation#

Guideline: advice that binds no one#

The Story at Five Levels#

Exercises#

Answer Key#

19.4 Board-Level Security Reporting#

Communicating Risk in Business Language#

Key Metrics for Board Reporting#

Key Risk Indicators#

19.5 Security Culture#

What Culture Is and Why It Matters#

Tone at the Top#

Building a Positive Security Culture#

From Compliance to Commitment#

Just Culture and Incident Reporting#

19.6 Common Compliance Frameworks#

Frameworks, Methodologies, and Tools#

NIST CSF, the Risk Management Framework (RMF), ISO/IEC 27001, and the RMF Compared#

FISMA in Depth#

NIST SP 800-53 in Depth#

FedRAMP in Depth#

19.7 NIST Cybersecurity Framework 2.0 and the Govern Function#

The NIST AI Risk Management Framework (AI RMF 1.0)#

CSF 2.0 versus AI RMF 1.0#

19.8 Cybersecurity Governance at the Municipal Level#

Benchmarking Readiness with Automated Policy Analytics#

Governance and Supply-Chain Gaps#

Compliance Reports, Certifications, and Agreements#

19.9 Governance, Risk, and Compliance (GRC) as an Integrated Discipline#

19.10 Audits, Assurance, and Security Maturity#

19.11 Third-Party Risk and the Human Layer of Governance#

19.12 What a Security Program Costs, and How It Gets Funded#

A build-up, with numbers#

Sticker price is not cost#

Exercises#

Answer Key#

19.13 Risk Appetite and Tolerance, Written So a Board Can Act on Them#

Writing appetite in numbers#

19.14 The Three Lines Model, and the Criticisms of It#

Where it breaks, and what its critics say#

19.15 One Control at Four Levels, and the Metadata That Makes It Auditable#

The verb decides everything, and the header block proves it#

19.16 Exceptions and Risk Acceptance, Where Governance Usually Fails#

The arithmetic that decides whether the register survives#

19.17 Metrics That Survive an Executive Audience#

Why the mean misleads, worked#

The vanity metric this field cannot let go of#

Exercises#

Answer Key#

19.18 Committees, Decision Rights, and Who Actually Decides#

Decision rights on one real decision#

19.19 Third-Party and Supply-Chain Governance#

What the artifacts prove, and which clauses work#

19.20 The CISO Reporting Line, and What the Evidence Actually Says#

What the data shows, and what it does not#

19.21 Duties That Reach Officers Personally#