NIST CSF 2.0 Guide: Identify, Protect and Detect Cybersecurity Risks

In Part 1 of this series, we dissected the Govern function, the flagship addition to NIST CSF 2.0 that elevates cybersecurity governance to the strategic center of the framework.

In Part 2 of this series, we explored the Three-Tier Cybersecurity Hierarchy, explaining how it operates. Followed by Board-Level Reporting Under CSF 2.0, an overview of Microsoft’s Integration Playbook, Regulatory Alignment, and Strategic Implementation Recommendations.

In this part, we continue to focus on the three functions that form the preventive backbone of CSF 2.0: Identify, Protect, and Detect. These are where strategy meets operations, where risk appetite statements translate into asset inventories, access control policies, encryption standards, SIEM configurations, and detection engineering.

The Identify Function (ID): Knowing What You’re Defending

The Identify function focuses on understanding the organization’s current cybersecurity risks. In CSF 2.0, this function has been significantly reorganized. The previous version had five categories under Identify (Asset Management, Business Environment, Governance, Risk Assessment, and Risk Management Strategy). CSF 2.0 moved Governance and Risk Management Strategy into the new Govern function, added a new Improvement category, and refined the remaining categories.

CSF 2.0 Identify Categories

ID.AM — Asset Management: You Cannot Protect What You Cannot See

Asset management is foundational. Without comprehensive visibility into hardware, software, data, services, and human resources, every subsequent control is built on sand. CSF 2.0’s seven asset management subcategories require organizations to:

• ID.AM-01: Maintain inventories of hardware managed by the organization.
• ID.AM-02: Maintain inventories of software, services, and systems managed by the organization.
• ID.AM-03: Document representations of the organization’s authorized network communication and internal/external network data flows.
• ID.AM-04: Maintain inventories of services provided by suppliers.
• ID.AM-05: Prioritize resources based on classification, criticality, business functions, and value.
• ID.AM-06: Establish, communicate, and coordinate roles and responsibilities for asset management internally and with external stakeholders.
• ID.AM-07: Maintain inventories of data and corresponding metadata for designated data types.

From a GRC leadership perspective, the challenge is not technical. Most organizations have CMDBs, discovery tools, and software asset management platforms. The challenge is completeness, accuracy, and currency. In my experience, asset inventories in large enterprises are at best 60–70% accurate. Shadow IT, cloud sprawl, SaaS proliferation, and IoT/OT convergence create blind spots that no amount of governance policy can overcome without automated, continuous discovery mechanisms.

Strategic recommendation: Deploy agent-based and agentless discovery tools in parallel, integrate with cloud provider APIs (AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory), and establish a quarterly asset reconciliation cycle tied to financial procurement data.

ID.RA — Risk Assessment: The Engine of Prioritization

Risk Assessment in CSF 2.0 contains 10 subcategories, the most of any category in the Identify function. This reflects NIST’s emphasis on making risk assessment the analytical engine that drives all downstream decisions.

The risk assessment methodology should follow NIST SP 800–30, which defines four elements:

• Threat sources and events — Who or what could cause harm, and through what actions?
• Vulnerabilities — What weaknesses exist in systems, processes, or configurations?
• Predisposing conditions — What environmental factors increase susceptibility?
• Likelihood and impact — How probable is the event, and what are the consequences?

Each risk should be documented in a risk register tied to CSF subcategories, affected assets, risk owners, likelihood/impact scores, and planned responses. Risk register data can then be aggregated to generate CSF Current Profiles based on verified control evidence.

For organizations seeking more precision, the FAIR (Factor Analysis of Information Risk) model translates cybersecurity risks into financial terms like annualized loss exposure, enabling data-driven prioritization that resonates with boards and CFOs. FAIR was mapped to the CSF as an Informative Resource in 2019, and the FAIR Institute has since published guidance on using FAIR to build a NIST CSF 2.0-based Cyber Risk Management Program (CRMP).

ID.IM — Improvement: The New Continuous Improvement Mandate

CSF 2.0 introduces Improvement (ID.IM) as a new category under Identify, a significant architectural decision. In CSF 1.1, improvement subcategories were scattered across Respond (RS.IM) and Recover (RC.IM), treating improvement as a post-incident activity. CSF 2.0 consolidates improvement into a unified mandate under Identify, signaling that continuous improvement should be an element of the entire cybersecurity program, not just incident response and recovery.

Get Prem S’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The four ID.IM subcategories cover improvements derived from:

• Evaluations and audits
• Security tests and exercises (penetration testing, red teaming, tabletop exercises)
• Operational incidents and near-misses
• Strategic planning and lessons learned from industry events

This philosophical shift, borrowed from quality management disciplines (PDCA/Deming), enables more dynamic responses to identified gaps. Progress toward closing gaps can begin immediately without waiting for complete policy development cycles that can take weeks or months.

The Protect Function (PR): Building the Defensive Architecture

The Protect function implements safeguards to manage cybersecurity risks. It ensures that once assets are identified and risks assessed, appropriate measures are in place to limit the impact of cybersecurity events. CSF 2.0 reorganized the Protect function into five categories with 28 subcategories:

PR.AA — Identity Management, Authentication, and Access Control

The augmentation of Identity Management under PR.AA marks a strategic pivot in CSF 2.0 towards more structured management of identities and credentials. The six subcategories span:

• PR.AA-01: Structured approach to identity and credential management across the entire identity lifecycle (provisioning, modification, deprovisioning).
• PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions.
• PR.AA-03: Users, services, and hardware are authenticated using multi-factor authentication (MFA) or equivalent mechanisms.
• PR.AA-04: Identity assertions (tokens, tickets, certificates) are protected and verified.
• PR.AA-05: Access permissions, entitlements, and authorizations are defined and managed following the principles of least privilege and separation of duties.
• PR.AA-06: Physical access controls are aligned with risk assessments.

Technical implementation priorities for GRC leaders:

• MFA everywhere: Deploy MFA for all privileged access, remote access, cloud console access, and federated identity scenarios. Phishing-resistant MFA (FIDO2/WebAuthn) is the gold standard.
• Privileged Access Management (PAM): Implement just-in-time (JIT) and just-enough-access (JEA) models for administrative access. Vault and rotate all service account credentials.
• Identity Governance and Administration (IGA): Automate access certification reviews on a quarterly cycle, with risk-weighted frequency for high-privilege accounts.
• Zero Trust Alignment: CSF 2.0’s access control requirements align naturally with Zero Trust Architecture principles. NIST SP 800–207 (Zero Trust Architecture) provides the complementary technical blueprint.

PR.DS — Data Security: Protecting the Crown Jewels

Data Security in CSF 2.0 contains 10 subcategories, the most of any Protect category. This reflects the reality that data is both the primary target of adversaries and the primary regulatory concern. The category covers:

• Data at rest: Encryption (AES-256, volume-level and file-level), secure storage, hardware security modules (HSMs).
• Data in transit: TLS 1.3 enforcement, certificate management, secure API gateways.
• Data in use: Confidential computing, secure enclaves, memory encryption.
• Data classification: Sensitivity labelling (Confidential, Internal, Public) mapped to handling requirements.
• Data Loss Prevention (DLP): Endpoint DLP, network DLP, cloud DLP (CASB integration) to prevent unauthorized exfiltration.
• Data backups and resilience (PR.DS-11): Immutable backups, offline/air-gapped copies, regular restoration testing.

The inclusion of PR.DS-11 (data backups and resilience) as a dedicated subcategory under Data Security is a direct response to the ransomware epidemic. Organizations must ensure backups are encrypted, stored in secure off-site locations (including air-gapped copies), and regularly tested for recoverability.

PR.PS — Platform Security: Hardening the Foundation

Platform security addresses the security of hardware, software, and services that make up the organization’s technology platforms. The six subcategories cover:

• PR.PS-01: Secure configuration management and configuration baselines (CIS Benchmarks, DISA STIGs).
• PR.PS-02: Maintenance of software and hardware, including end-of-life tracking.
• PR.PS-03: Prevention of unauthorized software installation and execution (application whitelisting).
• PR.PS-04: Log generation and integrity (feeding into the Detect function).
• PR.PS-05: Installation and management of security software (EDR, AV, HIPS).
• PR.PS-06: Secure software development practices (integrating with NIST’s Secure Software Development Framework — SSDF).

For enterprises with hybrid cloud environments, platform security must extend to cloud-native configurations like AWS Security Hub findings, Azure Security Center recommendations, and GCP Security Command Center and be normalized into a unified posture management view.

PR.AT — Awareness and Training

Though only two subcategories exist under Awareness and Training, their operational importance is outsized. CSF 2.0 emphasizes role-based training, not generic annual compliance e-learning, but targeted programs calibrated to each role’s specific risk exposure. Developers need secure coding training; executives need social engineering awareness; privileged administrators need advanced threat recognition.

PR.IR — Technology Infrastructure Resilience

This category addresses redundancy, failover capabilities, capacity planning, and the ability of technology infrastructure to withstand and recover from adverse events. The four subcategories here form the bridge between the Protect function and the Recover function, ensuring that resilience is designed into the architecture rather than bolted on post-incident.

The Detect Function (DE): The Bridge Between Prevention and Response

The Detect function enables timely discovery and analysis of anomalies, indicators of compromise, and other potentially adverse events. CSF 2.0 significantly enhanced Detect, emphasizing continuous, comprehensive monitoring across all cyber assets and networks.

CSF 2.0 Detect Categories

DE.CM — Continuous Monitoring: Beyond Checkbox Log Collection

One of the most prominent enhancements in CSF 2.0 is the emphasis on continuous monitoring. While CSF 1.1 acknowledged monitoring’s importance, CSF 2.0 focuses on the need for continuous, comprehensive monitoring of all cyber assets and networks. The nine DE.CM subcategories cover:

• DE.CM-01: Networks and network services are monitored to find potentially adverse events.
• DE.CM-02: The physical environment is monitored.
• DE.CM-03: Personnel activity and technology usage are monitored.
• DE.CM-06: External service provider activities and services are monitored.
• DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored.

Technical architecture for effective continuous monitoring:

1. SIEM as the Correlation Engine: Deploy a Security Information and Event Management (SIEM) platform as the central correlation engine. Ingest logs from network devices, endpoints (EDR telemetry), cloud services (CloudTrail, Azure Monitor, GCP Logging), identity providers (Azure AD/Entra ID, Okta), and applications.
2. Detection Engineering: Move beyond vendor-provided rules. Build custom detection logic mapped to MITRE ATT&CK techniques. Continuously tune detection rules to reduce false positive rates and mean time to detect (MTTD).
3. User and Entity Behavior Analytics (UEBA): Baseline “normal” behavior for users, service accounts, and systems. Apply machine learning models to detect anomalous patterns like lateral movement, privilege escalation, and data staging that rule-based detection misses.
4. Threat Intelligence Integration: Enrich monitoring data with threat intelligence from commercial feeds, ISACs, government sources (CISA, FBI), and open-source intelligence (OSINT). DE.AE-07 specifically requires integration of cyber threat intelligence into analysis.

DE.AE — Adverse Event Analysis: From Alerts to Intelligence

The Adverse Event Analysis category is responsible for identifying and evaluating suspicious activity and adverse occurrences. The eight subcategories require organizations to:

• Establish known baselines of network operations and expected data flows.
• Analyze potentially adverse events to understand associated activities.
• Correlate information from multiple sources — system logs, network traffic, security alerts, threat intelligence feeds — to gain a comprehensive understanding of threats.
• Determine the estimated impact and scope of adverse events.
• Integrate cyber threat intelligence and contextual information into analysis (DE.AE-07).

Alert triage and escalation architecture:

The handoff from Detect to Respond is one of the most failure-prone processes in cybersecurity operations. CSF 2.0 addresses this through clear thresholds and criteria. Once an anomaly is detected, analysts triage, validate context, and determine whether it constitutes a true incident. This decision point should be driven by clear thresholds, playbooks, and automation. Once criteria are met, the event is formally declared an incident, and ownership transfers to incident response with active containment and recovery procedures.

For organizations building or maturing their Security Operations Center (SOC), the Detect function provides the architectural blueprint:

The Identify → Protect → Detect Pipeline: Operational Integration

These three functions do not operate in isolation, they form a tightly coupled pipeline. In practice, the flow works as follows:

1. Identify discovers and classifies assets (ID.AM), assesses risks against those assets (ID.RA), and identifies improvement opportunities (ID.IM).
2. Protect implements controls proportional to the risk level — access controls (PR.AA), data security (PR.DS), platform hardening (PR.PS), and resilience (PR.IR) — informed by the risk assessment outputs.
3. Detect continuously monitors the effectiveness of those protections by looking for bypasses, gaps, anomalies, and indicators of compromise (DE.CM, DE.AE).

When Detect identifies a failure in a Protect control (e.g., a compromised credential bypassing MFA), that finding feeds back into Identify (specifically ID.IM — Improvement) and Govern (GV.OV — Oversight), triggering a governance review of the control’s effectiveness and a possible risk appetite recalibration.

This closed-loop architecture is what separates organizations that treat CSF 2.0 as a living program from those that treat it as a compliance checklist.

Technical Implementation Challenges and Recommendations

Common Pitfalls for ID, PR, and DE

• Asset Inventory Drift: CMDBs become stale within weeks of population. Without automated, continuous discovery, asset management is perpetually incomplete.
• Over-Reliance on Vendor Defaults: Many organizations deploy SIEM, EDR, and cloud security tools with default configurations and detection rules. CSF 2.0 demands tailored detection engineering mapped to the organization’s specific threat landscape.
• Data Classification Paralysis: Organizations stall on PR.DS because they cannot complete enterprise-wide data classification. Start with known regulated data (PII, PHI, PCI cardholder data) and expand iteratively.
• Alert Fatigue in SOC: Without proper tuning and UEBA, SOC analysts drown in false positives. Invest in detection engineering and automated enrichment before adding headcount.
• Tool Sprawl Without Integration: Multiple security tools that do not feed into a unified correlation engine create visibility gaps. Consolidate telemetry into the SIEM and ensure bidirectional integration with ticketing, SOAR, and vulnerability management platforms.

Quick-Win Priorities

For organizations beginning their CSF 2.0 journey across these three functions:

1. ID.AM: Deploy automated asset discovery (agents + agentless scanning + cloud API integration) within 60 days.
2. ID.RA: Conduct a risk assessment against the top 20 critical assets using NIST SP 800–30 methodology within 90 days.
3. PR.AA: Enforce MFA for all privileged and remote access immediately.
4. PR.DS: Implement immutable, tested backups for all critical systems within 30 days.
5. PR.PS: Deploy CIS Benchmark-aligned configuration baselines across all server and endpoint fleets.
6. DE.CM: Ensure SIEM coverage spans at least 90% of in-scope assets with log retention meeting regulatory requirements.
7. DE.AE: Validate at least 10 high-confidence detection rules mapped to the top MITRE ATT&CK techniques relevant to your sector.

In Part 4, we address what separates organizations that survive major cyber incidents from those that don’t. The Respond and Recover functions, and the operationalization mechanisms

Subscribe to my newsletter to receive all the parts on this NIST 2.0 Journal. Each part ends with a preview of the next, creating a natural series flow in the technical document. Just to have a approx. idea, this journal may have 5–6 parts in total with deep dive analysis and findings. You can also visit my LinkedIn profile and Portfolio to explore more.