The Five Core Functions

The NIST CSF Framework Core was famous for its five concurrent and continuous functions: Identify, Protect, Detect, Respond, and Recover. With CSF 2.0 (February 2024), a sixth function — Govern — joined them, wrapping around the other five to set strategy, expectations, and policy. Together, the six functions provide a strategic view of the entire cybersecurity lifecycle. A mature program invests in all of them; organizations that pour everything into protection and nothing into detection or recovery discover the gap at the worst possible moment.

This lesson walks through each function, the categories inside it, what implementation actually looks like, and how to spot and fix imbalance in your own program.

How the Functions Fit Together

Think of the functions as answers to six questions a board member might ask:

• Govern — who decides, and against what strategy and risk appetite?
• Identify — what do we have, and what could go wrong?
• Protect — what stops bad things from happening?
• Detect — how do we know when something bad is happening anyway?
• Respond — what do we do about it?
• Recover — how do we get back to normal?

In the official CSF 2.0 visualization, Govern sits at the center of the wheel, informing all five operational functions. The functions are not sequential phases — they run concurrently, all the time.

Govern (GV)

Govern is CSF 2.0's headline addition, and it exists because a decade of incidents proved that cybersecurity fails most often at the leadership layer, not the firewall layer. Govern establishes and monitors the organization's cybersecurity risk management strategy, expectations, and policy.

Its categories cover organizational context (mission, stakeholders, legal and contractual requirements), risk management strategy (risk appetite, how risk decisions get made and escalated), roles, responsibilities, and authorities (who owns what, with resources to match), policy (established, communicated, enforced, updated), oversight (leadership reviews outcomes and adjusts strategy), and — significantly — cybersecurity supply chain risk management, promoted to a full category after years of vendor-driven breaches.

In practice, Govern work looks like: a named executive owner for security risk, a documented risk appetite statement, a risk register that leadership actually reviews, an approved policy suite reviewed annually, a vendor security review process, and security as a recurring board agenda item. For founders, the honest starting point is often "governance lives in one person's head." Writing it down is the first Govern win.

Identify (ID)

Identify develops the organizational understanding needed to manage risk to systems, people, assets, data, and capabilities. You cannot protect what you do not know about, and every breach retrospective that begins "there was a forgotten server" is an Identify failure.

Key categories are Asset Management (inventories of hardware, software, services, data, and the people and facilities that matter, prioritized by criticality), Risk Assessment (identifying threats and vulnerabilities, estimating likelihood and impact, and tracking them to decision), and Improvement (learning from assessments, tests, and incidents to improve the program — moved into Identify in CSF 2.0).

Practical implementation: automated asset discovery rather than a spreadsheet nobody updates, a data inventory that tags where sensitive data lives, recurring vulnerability scanning, an annual (at minimum) risk assessment with documented treatment decisions, and SBOM or dependency tracking for software you build.

Protect (PR)

Protect implements safeguards to prevent or limit the impact of cybersecurity events. This is where most security budgets go, and most tooling lives.

CSF 2.0 reorganized Protect around: Identity Management, Authentication, and Access Control (unique identities, MFA, least privilege, access reviews), Awareness and Training (general and role-based), Data Security (encryption at rest and in transit, data loss protections, secure disposal, backups of data), Platform Security (hardening, configuration management, secure software development, log generation), and Technology Infrastructure Resilience (network segmentation, capacity, resilience mechanisms).

The highest-leverage Protect investments for most organizations, in rough order: enforce MFA everywhere, centralize identity with SSO, patch on an SLA, harden and baseline configurations, encrypt everything by default, and run tested backups. Notice that several "Protect" purchases — EDR, for instance — actually deliver most of their value in Detect. Classifying spend by function reveals this.

Detect (DE)

Detect develops and operates the capability to find cybersecurity events and anomalies in time to matter. Industry breach reports consistently show attacker dwell times measured in weeks when detection is weak — every day of dwell time multiplies response and recovery cost.

CSF 2.0 consolidates Detect into Continuous Monitoring (networks, physical environment, personnel activity, and technology monitored for adverse events) and Adverse Event Analysis (analyzing anomalies to understand scope and declare incidents).

Practical implementation: centralize logs from endpoints, cloud infrastructure, identity providers, and SaaS admin consoles; deploy EDR with someone actually watching it (in-house or an MDR service); alert on high-signal events (impossible travel, privilege escalation, mass data egress, disabled logging); and tune relentlessly — an ignored alert queue is Detect theater, not detection.

Respond (RS)

Respond covers actions taken once an incident is detected, with the goal of containing impact. Its categories include Incident Management (executing the response plan, triaging and prioritizing), Incident Analysis (investigating scope and root cause, preserving evidence), Response Reporting and Communication (notifying internal stakeholders, customers, regulators, law enforcement as required), and Mitigation (containing and eradicating the threat).

The core artifact is a written, tested incident response plan: severity definitions, roles (who leads, who talks to customers, who talks to lawyers), escalation paths, communication templates, and regulatory notification triggers with their deadlines (for example, 72-hour windows under GDPR and various sector rules). The difference between organizations that handle incidents well and those that do not is almost always rehearsal — run at least one tabletop exercise per year, and after every real incident hold a blameless review.

Recover (RC)

Recover restores capabilities and services impaired by incidents and manages communication during restoration. Categories cover Incident Recovery Plan Execution (restoring systems, verifying backup integrity before restoring, confirming normal operations) and Incident Recovery Communication (keeping internal and external stakeholders informed, protecting the organization's reputation with honest updates).

Recovery is where untested assumptions die. Backups that were never restored, DR runbooks that reference decommissioned systems, and recovery time objectives nobody validated all surface here. Practical program: define RTO and RPO per critical system, keep at least one backup copy offline or immutable (ransomware targets backups first), test restores quarterly, and test failover at least annually.

Balancing the Functions

Most organizations dramatically over-invest in Protect and under-invest everywhere else — a pattern sometimes called the "crunchy shell, soft center" problem. A quick self-diagnosis: categorize your last twelve months of security spending and effort by function. Typical unbalanced profiles look like 70 percent Protect, 15 percent Detect, and scraps for the rest.

A balanced program accepts that prevention fails and budgets accordingly:

• If you have no reliable asset inventory, fix Identify before buying more Protect tools.
• If mean time to detect is unknown or measured in weeks, shift budget to Detect.
• If you have never run a tabletop, Respond is your cheapest big win — an exercise costs an afternoon.
• If you have never restored from backup, Recover is a live grenade.
• If no executive owns security risk, everything above is unstable — start with Govern.

Function-by-Function Baseline Checklist

Use this as a minimum-viable check across all six functions:

• Govern: Named security risk owner, approved policy set, risk register reviewed by leadership, vendor security review process
• Identify: Automated asset inventory, data inventory with sensitivity tags, annual risk assessment, recurring vulnerability scans
• Protect: MFA enforced organization-wide, SSO/least privilege with quarterly access reviews, patch SLAs, encryption at rest and in transit, security training at onboarding and annually
• Detect: Centralized logging with defined retention, EDR on all endpoints, alerting on high-risk events, someone accountable for triage
• Respond: Written IR plan with severity levels and comms templates, annual tabletop exercise, regulatory notification matrix
• Recover: Documented RTO/RPO for critical systems, immutable or offline backup copy, quarterly restore tests, post-incident review process

Frequently Asked Questions

Are there five functions or six?

Six, as of CSF 2.0 (February 2024): Govern, Identify, Protect, Detect, Respond, Recover. CSF 1.1 had five; Govern was created largely from governance and supply chain content previously scattered under Identify. If a questionnaire references "the five functions," it is using pre-2024 language.

Do the functions have to be implemented in order?

No. They are concurrent, continuous capabilities, not project phases. That said, there is a sensible dependency logic for new programs: establish minimal Govern and Identify first (you need ownership and an inventory), stand up core Protect controls, then build out Detect, Respond, and Recover in parallel.

How do the functions relate to categories and subcategories?

Functions decompose into 22 categories, which decompose into 106 subcategories — the specific outcome statements you assess against. When building profiles, most organizations assess at subcategory level for their critical areas and category level elsewhere.

Which function should a startup prioritize?

The highest-risk-reduction-per-dollar sequence for most startups: MFA and SSO (Protect), asset and data inventory (Identify), centralized logging plus EDR (Detect), a one-page IR plan and a tabletop (Respond), tested backups (Recover), and a lightweight policy set with a named owner (Govern). All six can reach baseline in a quarter of focused part-time work.

How do I map SOC 2 or ISO 27001 work onto the functions?

Use the CSF 2.0 Informative References — NIST publishes mappings between CSF subcategories and other frameworks, and most compliance automation platforms cross-map evidence automatically. Nearly every SOC 2 or ISO 27001 control lands cleanly in one or two CSF subcategories, so certification work directly advances your CSF profile.

What metrics show a function is healthy?

Examples per function — Govern: percentage of risks with documented treatment decisions. Identify: inventory coverage and scan cadence. Protect: MFA coverage, patch SLA adherence. Detect: mean time to detect, alert triage time. Respond: mean time to contain, exercises completed. Recover: restore test success rate, actual recovery time vs RTO.

In the next lesson, we will cover implementation tiers — how to characterize the maturity of the practices behind these functions.

Building capability across all six functions usually means comparing tooling and assessors. AuditXYZ helps you compare compliance automation platforms and find the right auditors for the certifications that sit alongside your CSF program.