NIST CSF 2.0 for Developers: Where Your Work Lands in the Six Functions

By Sergey Nosov

16 October 2026

The NIST Cybersecurity Framework (CSF) does not name developers as its audience. Version 2.0, published on 26 February 2024, says its primary audience is “individuals responsible for developing and leading cybersecurity programs.” Of the other users it lists, the closest to a developer is “technology professionals.”

Yet developers deliver many of the outcomes it describes, including those for log records, backups, software inventories, data flows, authentication, data protection, and secure development practices. Each has an identifier you can cite in a design document or a pull request. Some sit where a developer might not look. Generating log records and making backups belong to Protect, one of the framework’s six functions, and Detect and Recover use what they produce.

The CSF describes outcomes and leaves the methods to each organization. That makes translation the useful skill for a developer: knowing which outcomes your work delivers, and turning an outcome on a security team’s list into an engineering decision. This article covers the six functions and the outcomes developer work delivers. It then connects the CSF to NIST’s SP 800-53 control catalog and Secure Software Development Framework (SSDF), explains what the Tiers measure, and suggests four habits for everyday work.

What the CSF Is, and What It Is Not

Executive Order 13636 of 12 February 2013 called for “a framework to reduce cyber risks to critical infrastructure” and a voluntary program to support its adoption. NIST published version 1.0 on 12 February 2014 as the Framework for Improving Critical Infrastructure Cybersecurity, and version 1.1 on 16 April 2018. Version 2.0 dropped that title and says it is designed for organizations of all sizes and sectors.

“Voluntary” is the default, but not the whole story. The CSF calls itself “a foundational resource that may be adopted voluntarily and through governmental policies and mandates.” NIST’s FAQ adds two cases. Executive Order 13800, issued in 2017, made the framework mandatory for federal agencies, and “some companies require the CSF for their customers or within their supply chain.” A Target Profile, a statement of desired outcomes, is another route: NIST says it can help express an organization’s requirements and expectations to suppliers.

The CSF names three uses: understanding and assessing a cybersecurity posture, prioritizing actions, and communicating in a common language inside and outside the organization. It “does not prescribe outcomes nor how they may be achieved,” and its outcomes “are not a checklist of actions to perform.” Nor does it come with a certification: the FAQ says NIST certifies and endorses no CSF-related products, implementations, or services, and plans no conformity assessment program. A product or a company described as CSF certified holds no certification from NIST.

The document has three parts. The Core is a hierarchy of outcomes. Organizational Profiles describe an organization’s current or target posture in terms of the Core. Tiers characterize how rigorously an organization governs and manages cybersecurity risk. Guidance on achieving the outcomes lives online: Informative References that relate outcomes to standards, guidelines, and regulations; Implementation Examples; Quick-Start Guides; and Community Profiles. These can change more often than the document itself.

The Core: Functions, Categories, and Subcategories

The Core has three levels: functions divide into categories, and categories into subcategories, the specific outcomes. Every subcategory has an identifier: PR.DS-01 is the first outcome in the Data Security category of the Protect function. Gaps in the numbering are deliberate; NIST says they mark version 1.1 subcategories that moved in 2.0. Version 2.0 has 6 functions, 22 categories, and 106 subcategories. Version 1.1 had 5, 23, and 108.

Version 1.1 defined each function as an activity; Protect, for example, read “Develop and implement appropriate safeguards to ensure delivery of critical services.” Version 2.0 states each function as an outcome:

Govern (GV): “The organization’s cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.”
Identify (ID): “The organization’s current cybersecurity risks are understood.”
Protect (PR): “Safeguards to manage the organization’s cybersecurity risks are used.”
Detect (DE): “Possible cybersecurity attacks and compromises are found and analyzed.”
Respond (RS): “Actions regarding a detected cybersecurity incident are taken.”
Recover (RC): “Assets and operations affected by a cybersecurity incident are restored.”

Govern is the new function. It gathered categories that version 1.1 kept under Identify, among them governance, risk management strategy, and supply chain risk management. The supply chain category grew from five subcategories to ten, GV.SC-01 through GV.SC-10. The CSF draws the six functions as a wheel, with Govern in the center, because it informs how an organization carries out the other five.

The six functions are not a lifecycle in which you identify first and recover last. The CSF says the functions “should be addressed concurrently” and that their order in the Core implies neither sequence nor importance. Work under Govern, Identify, Protect, and Detect should be continuous; Respond and Recover should stand ready and come into play when incidents occur.

Where Developer Work Lands

The subcategories below are the ones a development team delivers most directly. The Implementation Examples cited with them are NIST’s, from its CSF 2.0 Reference Tool; the framework calls them “notional examples” and says they are not a baseline of required actions. The practices I add after them are my recommendations, not NIST’s.

Govern: The Suppliers You Choose

A payment API, a hosted identity provider, or a SaaS monitoring service is a supplier, whoever picks it. GV.SC-04 asks that “Suppliers are known and prioritized by criticality,” and GV.SC-06 calls for planning and due diligence before a formal supplier relationship begins. Treat a new external service as a decision with an owner and a review, not as a key pasted into configuration.

The arrow also points the other way: if you sell software, you are the supplier. One example for GV.SC-05 has customers require, by contract, that suppliers “provide and maintain a current component inventory (e.g., software or hardware bill of materials) for critical products.” Govern is also where the rules you work under are set, from policy (GV.PO) to risk tolerance (GV.RM-02).

Identify: Inventories, Data Flows, and Risks

ID.AM-02: “Inventories of software, services, and systems managed by the organization are maintained.” Its first example includes open-source software and API services. For the open-source components inside an application you build, a software bill of materials, like the one in the GV.SC-05 example, can serve as the inventory. Generate it in the build from what you release, and keep it with that release.
ID.AM-03: “Representations of the organization’s authorized network communication and internal and external network data flows are maintained.” One example asks for documentation of the ports, protocols, and services that systems are expected to use. A threat model’s data-flow diagram can serve as that representation if it also shows ports and protocols; Threat Modeling with STRIDE shows how to draw one. Keep the diagram next to the code, and update it in the pull request that changes a flow.
ID.AM-04: “Inventories of services provided by suppliers are maintained.” Its examples name SaaS offerings and APIs, and one is to update the inventory “when a new external service is going to be utilized.” For a service your code calls, the pull request that adds the call is that moment.
ID.AM-07: inventories of data, and corresponding metadata, for designated data types, with an example of labeling those data types with their classification. Put the classification in the schema, where it changes with the code, and track exports and other copies outside the database.
ID.RA-01, ID.RA-03, and ID.RA-04: vulnerabilities, threats, and their potential impacts and likelihoods are identified and recorded. One example for ID.RA-01 is to “Review, analyze, or test organization-developed software to identify design, coding, and default configuration vulnerabilities.” Code review, static analysis, and threat modeling all feed these records.
ID.RA-07: “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked.” One of its examples reads like a good pull request description: “Document the possible risks of making or not making each proposed change, and provide guidance on rolling back changes.”
ID.RA-08: “Processes for receiving, analyzing, and responding to vulnerability disclosures are established.” Publish a way to report a vulnerability in your product.
ID.RA-09: “The authenticity and integrity of hardware and software are assessed prior to acquisition and use.” Check what you install against a signature from a trusted key or a hash from a trusted source.

Protect: Most of the Code

PR.AA-01, PR.AA-03, and PR.AA-05: identities and credentials “for authorized users, services, and hardware” are managed, and “Users, services, and hardware are authenticated.” Access permissions are reviewed and follow “the principles of least privilege and separation of duties.” The word services matters: service accounts and workload identities are identities, and API keys and certificates are credentials. Give each an owner, a scope, and a review date, and prefer short-lived credentials.
PR.DS-01, PR.DS-02, and PR.DS-10: the confidentiality, integrity, and availability of data at rest, in transit, and in use are protected. One example for data in transit speaks to developers directly: “Prevent reuse of sensitive data from production environments (e.g., customer records) in development, testing, and other non-production environments.” The Core never names input validation, but NIST’s mapping of CSF 2.0 to SP 800-53 lists SI-10, Information Input Validation, under PR.DS-10. The Boundary Defense Principle covers the practice.
PR.PS-01 and PR.PS-02: configuration management practices are applied, and “Software is maintained, replaced, and removed commensurate with risk.” The examples include reviewing default configuration settings when software is installed or upgraded, and deploying new container instances instead of updating running ones. Dependency updates and upgrades away from end-of-life versions are PR.PS-02 work.
PR.PS-06: “Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle.” This is the developer’s own subcategory, and two later sections return to it.

Logs, Backups, and Resilience Belong to Protect

It is natural to file logging under Detect, graceful degradation under Respond, and backups under Recover. The CSF files all three under Protect, as version 1.1 did under PR.PT-1, PR.IP-4, and PR.PT-5.

Logs: PR.PS-04. “Log records are generated and made available for continuous monitoring.” Producing and sharing the records is a Protect outcome; finding something in them is the work of Detect. In practice, what each record contains is decided in code, and other monitoring may not see an event the application never logged.
Backups: PR.DS-11. “Backups of data are created, protected, maintained, and tested.” One example is to “Test backups and restores for all types of data sources at least annually.”
Graceful degradation: PR.IR-03. “Mechanisms are implemented to achieve resilience requirements in normal and adverse situations.” The first example is to “Avoid single points of failure in systems and infrastructure.” Timeouts, fallbacks, redundancy, and load shedding belong here too, and PR.IR-04 covers adequate capacity. Respond, in the CSF, is about managing, analyzing, mitigating, reporting, and communicating incidents.

For the content of a security log record, SP 800-53’s AU-3, Content of Audit Records, gives a usable minimum. It asks that each record establish the event’s type, time, location, source, and outcome, and the identity of anyone or anything involved. Its enhancement AU-3(3) limits the personally identifiable information in audit records. Secrets do not belong there at all. My Software Development Principles series has an entry on the audit trail principle, which separates audit trails from operational logs, with the signs that it is applied well or badly.

Detect, Respond, and Recover: The Records You Leave Behind

Detection and incident response may belong to another team, but for events inside an application, they work from what the code recorded. DE.CM-09 reads “Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events.” One example is to watch authentication attempts for attacks on credentials and their unauthorized reuse. An application with its own sign-in supports that monitoring by recording each attempt and its outcome, never the password. DE.AE-03, “Information is correlated from multiple sources,” is far easier when every service logs each request’s correlation identifier and takes timestamps from a synchronized clock.

Respond needs evidence it can trust. RS.AN-03 calls for analysis “to establish what has taken place during an incident and the root cause of the incident.” Its first example is to determine the sequence of events and the assets and resources involved in each. RS.AN-07 adds that “Incident data and metadata are collected, and their integrity and provenance are preserved.” For developers, that means logs an intruder cannot quietly edit, with enough context to rebuild the sequence and to show which system wrote each entry.

Build for containment before you need it. RS.MI-01 reads “Incidents are contained,” which is easier with a way to revoke sessions, rotate a key, or switch off a feature without a deployment.

Recover restores, and it checks first. RC.RP-03 reads “The integrity of backups and other restoration assets is verified before using them for restoration.” An example for RC.RP-05 is to confirm, before production use, that restored assets show no indicators of compromise and that the incident’s root causes are fixed. A system rebuilt from version control and infrastructure code, with its data restored from a verified backup, is easier to trust than one patched in place. Availability by the Numbers makes the related point that bringing a compromised system back quickly, with the attacker still inside, is not recovery.

The CSF and SP 800-53: What and How

NIST SP 800-53 is a catalog of security and privacy controls. Revision 5 was published in September 2020 and updated on 10 December 2020; its latest release as of October 2026, 5.2.0, came out on 27 August 2025. FIPS 200 sets minimum security requirements for federal information and information systems, and agencies must meet them with SP 800-53 controls.

The catalog has twenty families, from Access Control (AC) to Supply Chain Risk Management (SR). By my count of NIST’s machine-readable catalog for release 5.2.0, it holds 300 controls and 714 control enhancements, not counting withdrawn ones. The common figure of more than a thousand controls holds only if the enhancements count.

The CSF and SP 800-53 connect through Informative References. NIST’s mapping of CSF 2.0 to SP 800-53 release 5.2.0, posted on 17 November 2025, lists the controls related to each subcategory. For data at rest, it lists fourteen under PR.DS-01, among them SC-28, Protection of Information at Rest. The CSF itself notes that a single SP 800-53 control may be only one of many references needed to achieve one subcategory’s outcome.

SC-28 shows how much the catalog still leaves to you. Its entire control statement is: “Protect the [Selection (one or more): confidentiality; integrity] of the following information at rest: [Assignment: organization-defined information at rest].” The organization fills in the brackets. The enhancement SC-28(1) calls for cryptographic mechanisms, and its discussion lets the organization encrypt whole components or media, or individual files, records, or fields. Which records, which fields, which keys, and which library are still engineering decisions. The CSF names the outcome, SP 800-53 names a more specific safeguard with parameters, and the design is still yours.

The family that deals with developers most directly is System and Services Acquisition (SA). Several of its controls, among them SA-11, Developer Testing and Evaluation, begin “Require the developer of the system, system component, or system service.” SP 800-53’s glossary counts in-house teams as developers, not only vendors. SA-11’s enhancements include static code analysis, SA-11(1), and threat modeling and vulnerability analyses, SA-11(2).

The mapping for PR.PS-06 lists only SA controls: SA-3, SA-8, SA-10, SA-11, SA-15, SA-15(13), SA-17, and SA-24. Two of them arrived in release 5.2.0: SA-15(13), Logging Syntax, which NIST added to make logging requirements clearer, and SA-24, Design for Cyber Resiliency. Release 5.2.0 also added SI-2(7), Root Cause Analysis. NIST’s change summary says an analysis of the SSDF identified it as a gap, and the mapping lists it under RS.AN-03.

Secure Development Has Its Own Framework

PR.PS-06 leaves open which secure development practices to use. NIST covers them in a separate publication, SP 800-218, the Secure Software Development Framework (SSDF). Version 1.1, from February 2022, organizes its practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Two of the examples under PR.PS-06 echo the PS and PW groups. For PS, the SSDF says organizations “should protect all components of their software from tampering and unauthorized access.” PR.PS-06’s first example reads “Protect all components of organization-developed software from tampering and unauthorized access.”

But the two frameworks do not line up one to one. A footnote in the SSDF explains why: its practices “may help support the NIST Cybersecurity Framework Functions, Categories, and Subcategories, but the SSDF practices do not map to them and are typically the responsibility of different parties. Developers can adopt SSDF practices, and the outcomes of their work could help organizations with their operational security in support of the Cybersecurity Framework.” That is the division of labor in two sentences. The SSDF describes what developers do, and the CSF describes what the organization achieves with it.

The CSF 2.0 Reference Tool does relate some SSDF tasks to CSF outcomes. As of October 2026, it lists them as Informative References for 26 of the 106 subcategories, though none for PR.PS-06.

Version 1.2 of the SSDF, SP 800-218 Revision 1, is in draft; NIST published the initial public draft on 17 December 2025. It adds two practices: PO.6, on improvement over time, and PS.4, on robust and reliable updates. The comment period closed on 30 January 2026, and as of October 2026, version 1.1 is still the final version.

Profiles Measure Progress; Tiers Describe Rigor

The CSF tracks progress outcome by outcome, in the Organizational Profile. A Current Profile “specifies the Core outcomes that an organization is currently achieving (or attempting to achieve) and characterizes how or to what extent each outcome is being achieved.” A Target Profile lists the outcomes that the organization has selected and prioritized, and an action plan addresses the gaps between the two.

A Profile can cover less than the whole organization; one of NIST’s examples of a narrower scope is an organization’s financial systems. A product team can keep a Current Profile scoped to its own system. A published Community Profile, such as SP 800-61 Revision 3 for incident response, can serve as the basis for a Target Profile.

The Tiers are Partial, Risk Informed, Repeatable, and Adaptive, and they “characterize the rigor of an organization’s cybersecurity risk governance and management practices.” It is tempting to read them as maturity levels. Version 1.1 said plainly that “Tiers do not represent maturity levels.” Version 2.0 drops that sentence and describes the Tiers as “a progression from informal, ad hoc responses to approaches that are agile, risk-informed, and continuously improving.”

Version 2.0 also says that Tiers should complement an organization’s own risk management methodology, not replace it. It encourages moving to a higher Tier “when risks or mandates are greater or when a cost-benefit analysis indicates a feasible and cost-effective reduction of negative cybersecurity risks.” So Tier 4 is not every organization’s goal, and a Tier describes how an organization manages risk, not the state of a codebase.

Using the CSF in a Development Team

None of this requires a compliance program to begin. Four habits bring the framework into everyday development work.

Check requirements against all six functions. When you design a feature, ask a question or two per function:

Govern: Which policy, contract, or supplier is involved?
Identify: Which data, flows, dependencies, and external services change?
Protect: Who can access what, and how is the data protected?
Detect: What misuse should someone be able to spot, and in which records?
Respond: What will an investigator need, and how would you switch the feature off?
Recover: How would you restore the feature and confirm that it is clean?

Put outcome identifiers in reviews. A short section in a pull request template turns the framework into questions a reviewer can answer:

### Security (CSF 2.0)
- Data flow changed? ID.AM-03
- New dependency? ID.AM-02
- Authentic and intact? ID.RA-09
- New external service? ID.AM-04
- New identity or key? PR.AA-01
- Permissions widened? PR.AA-05
- Stored data protected? PR.DS-01
- Sent data protected? PR.DS-02
- Security events logged? PR.PS-04
- Rollback described? ID.RA-07

Use the identifiers in design documents and tickets. A security reviewer can then trace each outcome to the changes that support it. The CSF also stresses “practitioners sharing their updates, insights, and concerns with managers and executives,” and a design document that names the outcomes it addresses can be one such update.

Reach for SP 800-53 when you need detail. For an authentication change, read the Identification and Authentication (IA) and Access Control (AC) families; for logging, Audit and Accountability (AU); for data protection, System and Communications Protection (SC). The CSF 2.0 Reference Tool shows each subcategory’s mappings and exports the Core, with its examples and references, in human-readable and machine-readable formats. For an application built on a large language model, look beyond SP 800-53. Since April 2026, NIST’s Online Informative References catalog has included a mapping of the OWASP Top 10 for LLM Applications to CSF 2.0.

Checklist

Read the CSF as outcomes, not as a checklist. It describes what should be true and leaves the methods to you.
Learn the six functions in the 2.0 wording, with Govern at the center, and treat them as concurrent, not as a sequence.
Know the subcategories your work delivers, most of them in ID.AM, ID.RA, and Protect, and those that use your logs and backups: DE.CM-09, RS.AN-07, and RC.RP-03.
Look for log generation, backups, and resilience under Protect: PR.PS-04, PR.DS-11, and PR.IR-03.
Use SP 800-53 for detail, and learn how your organization fills in its parameters. The SA family names the developer.
Adopt the SSDF for secure development practices, and do not expect a one-to-one mapping to the CSF.
Measure progress with Current and Target Profiles, and read a Tier as the rigor of the organization’s risk practices, not as a maturity score.