NIST Cybersecurity Framework | Cybersecurity Policy

Slide 1 of 14 | CSP-W4-01 | Week 4

NIST Cybersecurity Framework
Five Functions, Profiles, Tiers, CSF 2.0

EO 13636 • Identify • Protect • Detect • Respond • Recover • Govern • Profiles • Tiers • Crosswalks

The NIST Cybersecurity Framework is the most widely adopted risk-management framework in the United States and increasingly across the globe. Originally created under Executive Order 13636 to protect critical infrastructure, it has evolved into a universal language for communicating cybersecurity posture across sectors, supply chains, and regulatory boundaries. CSF 2.0 adds a sixth function -- Govern -- elevating organizational leadership and accountability to the same level as technical controls. This deck covers the complete framework: its origin, all six functions, subcategories, profiles, implementation tiers, and how organizations map it to existing standards like ISO 27001 and CIS Controls.

14 Slides CSP-W4-01 Week 4 CIS2208 -- Cybersecurity Policy

Slide 2 of 14

What Is the NIST CSF?

Origin, purpose, and design principles -- a voluntary, sector-agnostic framework for managing cybersecurity risk.

Voluntary Framework

The CSF is not a regulation -- it is a voluntary risk-management framework. No organization is legally required to adopt it (unless mandated by sector-specific regulation or contract). Its power comes from ubiquity: when everyone speaks the same framework language, supply chain assurance, audits, and board communication become dramatically simpler.

Sector-Agnostic Design

Unlike HIPAA (healthcare) or PCI-DSS (payment cards), the CSF applies to any organization of any size in any sector. A hospital, a bank, a school district, and a defense contractor can all describe their cybersecurity posture using the same framework structure. This universality is its greatest strength.

Risk-Based Approach

The CSF does not prescribe specific controls or technologies. It provides a structure for organizations to assess their own risk, determine their target state, and prioritize investments accordingly. Two organizations in the same sector may implement the framework differently based on their unique risk profiles and business objectives.

Executive Order 13636

Signed by President Obama on February 12, 2013, EO 13636 -- "Improving Critical Infrastructure Cybersecurity" -- directed NIST to develop a voluntary framework for reducing cyber risks to critical infrastructure. NIST held workshops with over 3,000 participants from industry, academia, and government to build the framework collaboratively. The result was not a government mandate but a consensus document -- owned by the community that built it.

Slide 3 of 14

CSF 2.0 -- The Govern Function

Six functions, expanded scope beyond critical infrastructure, and governance elevated to a core pillar.

What Changed in 2.0

The Govern function was added as the sixth and overarching function, elevating governance from an implicit assumption to an explicit requirement. The scope expanded from "critical infrastructure" to "all organizations." New emphasis on supply chain risk management, improved guidance for small and medium enterprises, and better integration with other NIST publications (SP 800-53, SP 800-221).

Why Govern Matters

In CSF 1.0/1.1, governance was embedded within the Identify function. CSF 2.0 recognized that governance is not one activity among many -- it is the foundation that informs and directs all other functions. Without explicit governance, organizations had technical controls but lacked the strategic direction, accountability, and oversight to deploy them effectively. Govern wraps around all five operational functions.

Expanded Scope

CSF 1.0 was explicitly targeted at critical infrastructure sectors -- energy, water, financial services, healthcare, and transportation. CSF 2.0 drops this limitation entirely. The title changed from "Framework for Improving Critical Infrastructure Cybersecurity" to simply "The NIST Cybersecurity Framework." Any organization -- a startup, a nonprofit, a university, a local government -- can now adopt the framework without the implicit question of whether they qualify as critical infrastructure.

Slide 4 of 14

Identify (ID) -- Know Your Environment

Asset management, business environment, governance, risk assessment, risk strategy, and supply chain risk management.

Asset Management (ID.AM)

You cannot protect what you do not know about. ID.AM requires inventorying all physical devices, software platforms, data flows, and external information systems. This includes shadow IT -- systems deployed without IT approval that still process organizational data.

Risk Assessment (ID.RA)

Identify threats and vulnerabilities to organizational assets, determine the likelihood of exploitation, and assess potential business impact. Risk assessment is not a one-time activity -- it must be continuous, reflecting changes in the threat landscape and the organization's attack surface.

Supply Chain RM (ID.SC)

Assess and manage cybersecurity risk introduced by suppliers, partners, and service providers. SolarWinds demonstrated that a compromised vendor can bypass every internal control. Supply chain risk management requires due diligence, contractual requirements, and ongoing monitoring of third-party security posture.

Identify Is the Foundation

Every other function depends on the Identify function. You cannot protect assets you have not inventoried, detect threats to systems you do not know exist, respond to incidents affecting business processes you have not mapped, or recover services whose dependencies you have not documented. Identify is where cybersecurity begins.

Slide 5 of 14

Protect (PR) -- Safeguard Critical Services

Access control, awareness training, data security, information protection, maintenance, and protective technology.

PR.AC -- Access Control

Identities and credentials are managed. Physical and logical access is limited to authorized users, processes, and devices. Principles of least privilege and separation of duties are enforced. This includes identity management, multi-factor authentication, remote access controls, and network segmentation.

PR.AT -- Awareness & Training

All users -- including privileged users, executives, and third parties -- receive cybersecurity awareness education. Training is role-based: a system administrator receives different training than an HR generalist. The goal is a security-aware culture where people are the first line of defense, not the weakest link.

PR.DS -- Data Security

Data at rest is protected through encryption, access controls, and integrity checks. Data in transit is protected through TLS, VPNs, and secure protocols. Assets are formally managed through removal, transfer, and disposal processes. Data leakage prevention mechanisms are in place for sensitive information.

PR.IP -- Information Protection

Security baselines for technology assets are established and maintained. Configuration management ensures systems are hardened. Backups are conducted, tested, and stored securely. Response and recovery plans are tested. Change control processes prevent unauthorized modifications to production systems.

PR.MA -- Maintenance

Maintenance and repair of organizational assets is performed in a controlled manner with approved tools. Remote maintenance is logged, monitored, and conducted through secure channels. Maintenance personnel are authorized and supervised. Equipment removed for off-site maintenance is sanitized first.

PR.PT -- Protective Technology

Audit and log records are determined, documented, and reviewed. Removable media is restricted. Communications and control networks are protected. Resilience requirements are established and implemented. Systems operate in least-functionality mode -- unnecessary services, ports, and protocols are disabled.

The Protect function is where most organizations spend the majority of their cybersecurity budget. Firewalls, endpoint protection, encryption, IAM systems, training programs, and patch management all fall under Protect. The trap is spending 90% of the budget on Protect while neglecting Detect, Respond, and Recover -- because no Protect control is 100% effective. Assume breach, then build the other functions accordingly.

Slide 6 of 14

Detect (DE) -- Find Threats Early

Anomalies and events, security continuous monitoring, and detection processes.

Why Detection Fails

Alert fatigue is the number one reason detection fails. A SOC receiving 10,000 alerts per day cannot investigate them all. Tuning detection rules, reducing false positives, and automating triage are essential. An untuned SIEM is worse than no SIEM -- it creates a false sense of security while burying real threats in noise.

Continuous Monitoring

Point-in-time assessments (annual pen tests, quarterly vulnerability scans) are necessary but insufficient. The threat landscape changes daily. Continuous monitoring means real-time visibility into network traffic, user behavior, system configurations, and external threat intelligence feeds. Automation is not optional -- it is the only way to achieve actual continuity.

Detection Technologies

SIEM (Security Information and Event Management), IDS/IPS (Intrusion Detection/Prevention Systems), EDR (Endpoint Detection and Response), NDR (Network Detection and Response), and UEBA (User and Entity Behavior Analytics) are the primary tools. Each covers a different detection surface -- logs, network, endpoint, and behavior respectively.

The Dwell Time Problem

Dwell time is the duration between initial compromise and detection. Longer dwell times mean more data exfiltrated, more lateral movement, and more damage. Reducing dwell time from months to hours is the primary objective of the Detect function. Organizations that invest in detection capabilities proportional to their protection controls consistently achieve better breach outcomes.

Slide 7 of 14

Respond (RS) -- Act on Detected Incidents

Response planning, communications, analysis, mitigation, and improvements.

Respond Subcategories

RS.RP

Response Planning

Execute the incident response plan during or after an event

RS.CO

Communications

Coordinate with stakeholders, law enforcement, ISACs

RS.AN

Analysis

Investigate notifications, understand impact, perform forensics

RS.MI

Mitigation

Contain the incident, eradicate the threat, prevent expansion

RS.IM

Improvements

Incorporate lessons learned into future response activities

Response Planning in Practice

A response plan that exists only as a document in SharePoint is not a plan -- it is a liability. Response plans must be exercised through tabletop exercises, red team engagements, and simulated incident scenarios. Everyone must know their role before an incident occurs. During a real breach, there is no time to read the manual for the first time. Plans must include decision trees for escalation, communication templates for stakeholders, and pre-authorized containment actions.

Communications During Incidents

RS.CO is where many organizations fail catastrophically. Who notifies the board? When does legal get involved? At what point do you inform customers? Is there a regulatory notification deadline (72 hours under GDPR, "without unreasonable delay" under most US state breach notification laws)? Crisis communications must be pre-planned with approved templates, designated spokespersons, and clear escalation thresholds.

Analysis and Forensics

RS.AN requires that organizations have the capability to investigate incidents -- not just detect them. This means preserving evidence (chain of custody), conducting root cause analysis, correlating events across multiple data sources, and determining the full scope of compromise. Many organizations outsource forensic capabilities to incident response retainer firms (CrowdStrike, Mandiant, Secureworks) because building in-house forensic expertise is expensive and underutilized in peacetime.

Lessons Learned

RS.IM -- Improvements -- is the most frequently skipped subcategory. After an incident, organizations are exhausted and want to move on. But without a formal after-action review, the same root causes produce the same incidents. Every incident response should conclude with a blameless post-mortem that documents what happened, what worked, what failed, and what changes are required to prevent recurrence.

Slide 8 of 14

Recover (RC) -- Restore Normal Operations

Recovery planning, improvements, and communications -- restoring capabilities impaired during an incident.

RC.RP -- Recovery Planning

Recovery plans are executed during or after an incident to restore systems and assets affected by a cybersecurity event. This includes restoration priorities (which systems come back first), backup verification, system rebuilding procedures, and validation testing to confirm restored systems are clean and functional. Recovery time objectives (RTO) and recovery point objectives (RPO) define acceptable thresholds.

RC.IM -- Improvements

Recovery strategies are updated based on lessons learned. If a ransomware event revealed that backups were also encrypted because they were on the same network segment, the recovery plan must be updated to include air-gapped or immutable backups. Continuous improvement applies to recovery just as it does to detection and response.

RC.CO -- Communications

Reputation management and stakeholder communication during recovery. Public relations, customer notifications, regulatory status updates, and internal morale management. Recovery communications differ from response communications -- the message shifts from "we are under attack" to "we are restoring operations and here is our timeline." Transparency builds trust; silence destroys it.

Recovery vs. Business Continuity

The Recover function is about restoring cybersecurity capabilities specifically -- not general disaster recovery. However, it overlaps heavily with Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP). The distinction matters: BCP keeps the business running during disruption (alternate sites, manual processes), while the CSF Recover function focuses specifically on restoring the security of systems and data. Both are necessary; neither is sufficient alone.

Slide 9 of 14

Govern (GV) -- CSF 2.0 Leadership Pillar

Organizational context, risk management strategy, roles and responsibilities, policy, oversight, and supply chain risk management.

GV.OC -- Organizational Context

The organization's mission, stakeholder expectations, legal and regulatory requirements, and dependencies are understood and used to inform cybersecurity risk decisions. Context determines what risks matter -- a hospital protects patient data differently than a defense contractor protects classified designs.

GV.RM -- Risk Mgmt Strategy

The organization's priorities, constraints, risk tolerance, and assumptions are established, communicated, and used to support operational risk decisions. Risk appetite is defined at the board level and cascaded through the organization. Every security investment decision traces back to this strategy.

GV.RR -- Roles & Responsibilities

Cybersecurity roles, responsibilities, and authorities are established to foster accountability, performance assessment, and continuous improvement. This includes the CISO reporting structure, security committee charters, and individual accountability for risk owners across all business units.

GV.PO -- Policy

Organizational cybersecurity policy is established, communicated, and enforced. Policy is the codification of governance intent -- it translates board-level risk appetite into actionable requirements. Policies must be reviewed periodically, updated after incidents, and accessible to all personnel they apply to.

GV.OV -- Oversight

Results of organization-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy. This is the feedback loop -- without oversight, governance is a paper exercise. Board-level reporting, KPI dashboards, and independent audits provide oversight data.

GV.SC -- Supply Chain RM

Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organizational stakeholders. CSF 2.0 elevated supply chain from a subcategory within Identify to a governance-level concern, reflecting lessons from SolarWinds, Log4j, and Kaseya.

Govern is the function that answers: Who is accountable for cybersecurity? What risk level is acceptable? How do we know our program is working? These are not technical questions -- they are leadership questions. CSF 2.0 recognizes that cybersecurity programs without strong governance produce inconsistent outcomes regardless of technical investment. A well-governed program with modest tools outperforms an ungoverned program with unlimited budget.

Govern Wraps All Functions

Unlike the other five functions which operate sequentially (Identify, then Protect, then Detect, then Respond, then Recover), Govern operates continuously and wraps around all other functions. It sets the strategy that Identify follows, the requirements that Protect implements, the thresholds that Detect monitors, the plans that Respond executes, and the priorities that Recover restores. Governance is not a phase -- it is the operating environment.

Slide 10 of 14

Framework Profiles -- Current vs Target

Gap analysis between where the organization is today and where it needs to be.

Current Profile

Documents the organization's present cybersecurity posture by mapping existing activities to CSF subcategories. This is a factual assessment -- not aspirational. It captures what the organization is actually doing today, including gaps. Current profiles reveal where investment has been concentrated (usually Protect) and where it has been neglected (usually Detect, Respond, Recover, and now Govern).

Target Profile

Documents the desired cybersecurity outcomes based on business requirements, risk tolerance, regulatory obligations, and available resources. The target profile is not "all subcategories at maximum maturity" -- it is the right level of maturity for this organization at this time. A small nonprofit has a different target profile than a Fortune 500 bank. The gap between current and target drives the roadmap.

Gap Analysis Drives Investment

The gap between the current and target profiles is the organization's cybersecurity roadmap. It answers the question every CISO faces from the board: "Where should we spend our next dollar?" Gap analysis enables risk-prioritized investment decisions rather than reactive spending driven by the latest headline breach. A profile-based approach also provides a measurable progress metric -- the board can see the gap narrowing over time.

Slide 11 of 14

Implementation Tiers -- Maturity Levels

Partial, Risk Informed, Repeatable, Adaptive -- how mature is the organization's risk management?

Tier 1: Partial

Risk management is ad hoc and reactive. Cybersecurity activities are performed irregularly, not informed by organizational risk objectives. Limited awareness of cybersecurity risk at the organizational level. No formalized processes -- individuals do what they think is right without coordination.

Tier 2: Risk Informed

Risk management practices are approved by management but may not be organization-wide policy. Awareness of cybersecurity risk exists at the organizational level, but a consistent approach has not been established. Some external participation (ISACs, vendor advisories) but not systematic.

Tier 3: Repeatable

Risk management practices are formally approved and expressed as policy. Organizational approach to managing cybersecurity risk is consistent, well-documented, and regularly updated. Personnel have the knowledge and skills to perform their roles. Active participation in information sharing with external partners.

Tier 4: Adaptive

The organization adapts its cybersecurity practices based on lessons learned and predictive indicators derived from previous and current activities. Continuous improvement incorporating advanced technologies and practices. Active contribution to the broader cybersecurity ecosystem through information sharing and collaboration.

Tiers Are Not Scores

Implementation tiers are not maturity scores and do not represent a compliance checklist. Not every organization needs to be Tier 4 -- the appropriate tier depends on the organization's risk environment, mission, and resources. A Tier 2 organization that understands its risk posture and makes informed decisions may be more secure than a Tier 3 organization with documented processes that are not actually followed. Tiers describe how well risk management is integrated into organizational decision-making, not how many tools are deployed.

Slide 12 of 14

Using the CSF -- Crosswalks & Mapping

Mapping the CSF to ISO 27001, COBIT, CIS Controls, and regulatory frameworks for unified compliance.

Crosswalk Examples

CSF Subcategory	ISO 27001	CIS Controls	NIST 800-53
ID.AM-1	A.8.9 (Config mgmt)	CIS 1 (HW Inventory)	CM-8 (System Component Inventory)
PR.AC-1	A.9.2 (User access)	CIS 6 (Access Control)	AC-2 (Account Management)
DE.CM-1	A.8.16 (Monitoring)	CIS 13 (Network Monitor)	SI-4 (System Monitoring)
RS.RP-1	A.5.24 (IR planning)	CIS 17 (IR Mgmt)	IR-1 (IR Policy/Procedures)

Why Crosswalks Matter

Most organizations face multiple compliance obligations simultaneously -- HIPAA and PCI-DSS, or SOX and CMMC, or GDPR and ISO 27001. Without crosswalks, each framework is a separate compliance effort with separate assessments, separate documentation, and separate budgets. The CSF serves as a Rosetta Stone -- implement controls once, map them to every framework, and demonstrate compliance across all simultaneously. This "comply once, report many" approach reduces audit fatigue and eliminates redundant work.

Slide 13 of 14

Key Takeaways

The essential points from this presentation on the NIST Cybersecurity Framework.

01 The NIST CSF is a voluntary, sector-agnostic, risk-based framework -- not a compliance checklist. It provides structure for managing cybersecurity risk without prescribing specific technologies or controls.

02 CSF 2.0 added the Govern function as the sixth and overarching function, recognizing that governance is the foundation for all other cybersecurity activities. The scope expanded from critical infrastructure to all organizations.

03 The five operational functions form a lifecycle: Identify (know your assets), Protect (safeguard them), Detect (find threats), Respond (contain incidents), Recover (restore operations). Govern wraps around all five.

04 Framework Profiles (current vs target) enable gap analysis -- the difference between where you are and where you need to be drives investment decisions and roadmap prioritization.

05 Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how well risk management is integrated into organizational decision-making -- not how many tools are deployed.

06 Crosswalks map CSF subcategories to ISO 27001, CIS Controls, NIST 800-53, HIPAA, PCI-DSS, and other frameworks -- enabling a "comply once, report many" approach that reduces audit fatigue.

07 Supply chain risk management is elevated in CSF 2.0 to a governance-level concern (GV.SC), reflecting lessons from SolarWinds, Log4j, and Kaseya that third-party risk can bypass every internal control.

08 Most organizations over-invest in Protect and under-invest in Detect, Respond, and Recover. The CSF framework structure makes this imbalance visible and provides a language to address it with leadership.

What Comes Next

The NIST CSF provides the organizational framework for cybersecurity risk management. In the next module, you will examine how the framework translates into specific policy documents -- information security policies, acceptable use policies, incident response plans, and data classification schemes -- the artifacts that operationalize framework intent into enforceable organizational requirements.

Slide 14 of 14 | Complete

Presentation
Complete

NIST Cybersecurity Framework -- 14 slides

EO 13636 • CSF 2.0 • Identify • Protect • Detect • Respond • Recover • Govern • Profiles • Tiers • Crosswalks

CIS2208 Cybersecurity Policy Week 4