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:

1. Explain what security governance is and how it differs from security management.

2. Describe the role of the CISO and the security organization structure.

3. Explain the policy hierarchy: policy, standard, procedure, and guideline.

4. Write a policy document that is enforceable and auditable.

5. Describe board-level reporting of cybersecurity risk and metrics.

6. Design a security awareness program that changes behavior, not just knowledge.

7. Explain how to build and sustain a positive security culture.

8. Describe common certification and compliance frameworks and their governance implications.

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.

• 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.

---

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 CIO, 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 best practice 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). The CISO ideally reports to the CEO or the board audit committee. In practice, the CISO reporting line varies widely by organization size and maturity.

---

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.

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.

---

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	US defense contractors	Mandatory for DoD supply chain
FedRAMP	US federal cloud	Mandatory for cloud services to US federal government
NERC CIP	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 / 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, 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 27001 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 (SaaS, PaaS, or IaaS) 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 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:

1. Govern (GV) establishes the organizational cybersecurity strategy, risk-management policy, roles and responsibilities, oversight, and cybersecurity supply-chain risk management.

2. Identify (ID) manages asset inventory, risk assessment, and improvement.

3. Protect (PR) implements identity management, access control, awareness training, data security, and platform security.

4. Detect (DE) provides continuous monitoring and adverse-event analysis.

5. Respond (RS) executes incident management, analysis, communication, and mitigation.

6. 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:

1. 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).

2. Map, establishing the context and identifying the risks of an AI system across its lifecycle.

3. Measure, analyzing, assessing, benchmarking, and monitoring AI risk with quantitative and qualitative methods.

4. 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

1. What function did NIST CSF 2.0 add in 2024, and why is it depicted at the center of the framework?

2. Why did keyword-based classification fail specifically on the Protect function in the Maryland study?

3. 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 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 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 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 27001 Annex A, the 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 now depend on countless vendors and cloud providers, so governance must extend beyond the perimeter through vendor security assessments, contractual requirements (the business associate agreements and right-to-audit clauses above), continuous monitoring of critical suppliers, and an inventory of who has access to what data. The SolarWinds and MOVEit incidents (Chapter 17) showed that an organization’s security is bounded by its weakest vendor, which is exactly why CSF 2.0 elevated supply-chain risk to the Govern function.

Second, governance ultimately runs on people and culture (the culture material above): a security program is only as strong as the everyday behavior it produces, so governance includes the security-awareness program (training, phishing simulations from Chapter 4, and metrics on their effect), a just culture that encourages reporting over blame (Chapter 14), and visible tone at the top. 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; with it, security becomes sustainable.

Knowledge Check

1. How do governance, risk management, and compliance reinforce one another in a GRC program?

2. 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?

3. 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.

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 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. 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: SEC Enforcement Against CISOs and Boards

SEC enforcement actions against public company CISOs and boards following breaches have established that cybersecurity is a material business risk requiring accurate disclosure. Companies that misrepresented their security posture to investors, or where boards failed to provide adequate governance oversight, have faced civil enforcement. This regulatory development is driving boards to demand substantive security briefings and CISOs to produce board-quality risk reporting rather than technical metrics.

---

# 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

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

Answers: Q1 B, Q2 B, Q3 D, Q4 B, Q5 B, Q6 A, Q7 B, Q8 C, Q9 B, Q10 B.

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

1. 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

2. Trivedi, D. (2025). Benchmarking Municipal Cybersecurity Readiness Through Automated Policy Analytics: Evidence from Maryland Local Governments. CCSC Eastern. (see Appendix E)

3. Executive Office of the President (2021). Executive Order 14028: Improving the Nation’s Cybersecurity. 86 FR 26633.

4. Cybersecurity and Infrastructure Security Agency (2024). Cross-Sector Cybersecurity Performance Goals.

5. AICPA SOC 2; ISACA COBIT; CMMI; NIST CSF 2.0 implementation tiers.

6. NIST SP 800-53; ISO/IEC 27001 Annex A; CIS Critical Security Controls.