NIST CSF 2.0Implementation GuideJune 13, 2026· 14 min read
How to Implement the NIST CSF 2.0 Protect Function: A Practitioner's Guide
The Protect function is where most security controls live. It covers identity and access management, security awareness training, data security, platform hardening, and infrastructure resilience. This guide breaks down all five PR categories with practical implementation steps - what to configure, what to document, and where organizations consistently fall short. (Spoiler: it is usually MFA, backups, and documentation. It is always MFA, backups, and documentation.)
What the Protect Function Covers
In CSF 2.0, the Protect function has five categories: PR.AA (Identity Management, Authentication, and Access Control), PR.AT (Awareness and Training), PR.DS (Data Security), PR.PS (Platform Security), and PR.IR (Technology Infrastructure Resilience). CSF 2.0 significantly reorganized Protect from CSF 1.1 - the five categories are substantially different in scope and naming, even though the count stayed the same.
The Protect function implements the safeguards that limit the impact of a cybersecurity event. Where Identify tells you what you have and what risks exist, Protect is the operational response - the controls, configurations, and processes that reduce the likelihood and impact of those risks materializing.
Implementation principle: Protect controls need both a technical implementation and a policy backing. A screen lock configured in Group Policy with no corresponding policy document creates a documentation gap. A policy requiring MFA that isn't enforced technically creates an implementation gap. Both matter.
PR.AA - Identity Management, Authentication, and Access Control
PR.AA is the largest category in the Protect function and covers the full identity lifecycle: how identities are managed, how users authenticate, and what they can access once authenticated. This is where most organizations have the most existing controls - and the most gaps.
PR.AA-01 through PR.AA-06
Control who can access your systems and what they can do
PR.AA covers: managing identities and credentials (PR.AA-01), managing permissions and access authorizations (PR.AA-02), requiring strong authentication (PR.AA-03), managing network access (PR.AA-05), and managing remote access (PR.AA-06). It also includes physical access to assets (PR.AA-04).
How to implement:
Implement a centralized identity provider (Microsoft Entra ID, Okta, or equivalent) - no local accounts on individual systems for users who access sensitive resources
Enforce multi-factor authentication for all user accounts - at minimum for remote access and privileged accounts, ideally for all accounts. Phishing-resistant MFA (hardware tokens, passkeys) for privileged access
Implement role-based access control: define roles, assign minimum permissions to each role, assign users to roles based on job function. Audit quarterly
Implement privileged access management: separate privileged accounts from standard accounts, enforce just-in-time access for administrative tasks, and log all privileged activity
Configure session management: idle session timeouts, automatic lock on inactivity, re-authentication requirements for sensitive operations
For remote access (PR.AA-06): require VPN with MFA, or zero-trust network access solutions. No direct RDP or SSH exposure to the internet
For physical access (PR.AA-04): badge access to server rooms and areas with sensitive systems, visitor logs, and security camera coverage of physical infrastructure
Common mistake: Organizations enable MFA for remote access but leave direct application logins (email, cloud SaaS) protected only by password. A phished password with no MFA fallback is a complete authentication bypass. MFA must cover all authentication paths, not just VPN.
PR.AT - Awareness and Training
The function everyone checks off with an annual click-through video nobody remembers by February.
PR.AT requires that personnel are aware of their cybersecurity responsibilities and trained to fulfill them. This is the human layer of the Protect function - technical controls fail when users don't know what they're supposed to do or why.
PR.AT-01 through PR.AT-02
All users need security training; privileged users need more
PR.AT-01 requires that all personnel are provided cybersecurity awareness and training. PR.AT-02 specifically requires that individuals with privileged access have the training needed to understand and fulfill their heightened responsibilities.
How to implement:
Conduct annual security awareness training for all employees covering: phishing recognition, password security, acceptable use, incident reporting, and data handling. Track completion rates - 100% completion with documented records is the target
Run quarterly phishing simulations. When someone clicks a simulated phishing link, deliver immediate just-in-time training rather than just a notification. Track click rates over time as a program effectiveness metric
For privileged users (IT admins, security team, anyone with elevated access): provide role-specific training covering the specific risks of their elevated access - credential hygiene, admin account discipline, secure configuration practices
Include security training in onboarding for new hires - before they get access to systems, not after
Document your training program: what topics are covered, what the delivery method is, how you track completion, and how you handle employees who don't complete training
Update training content annually to reflect the current threat landscape - a 2021 training module about USB-dropped malware is less relevant than one covering AI-generated phishing
Common mistake: Annual training is completed on paper but not actually absorbed. Clicking through a 40-slide presentation at 2x speed and clicking "I completed this" isn't training. Effective programs use scenario-based learning, simulations, and role-specific content - not passive reading exercises.
PR.DS - Data Security
Backups: the thing everyone agrees is important right up until someone asks when they were last tested.
PR.DS requires the organization to manage data throughout its lifecycle - protecting it at rest and in transit, ensuring backups exist and work, preventing unauthorized exfiltration, and verifying integrity. Data is the target in most attacks; PR.DS is what protects it.
PR.DS-01 through PR.DS-11
Protect data at rest, in transit, in backups, and at disposal
PR.DS covers encryption at rest (PR.DS-01), encryption in transit (PR.DS-02), data integrity (PR.DS-04), data backups (PR.DS-11), data leak prevention (PR.DS-05), access controls on data (PR.DS-03), and data disposal (PR.DS-08), among others. It's the most technically specific category in the Protect function.
How to implement:
Encrypt sensitive data at rest: enable BitLocker on Windows endpoints, FileVault on macOS, and use platform-native encryption for servers and cloud storage. For databases containing sensitive data, use transparent data encryption (TDE)
Enforce TLS 1.2+ for all data in transit - audit web applications, APIs, and internal service-to-service communications. Disable TLS 1.0 and 1.1, and all versions of SSL
Implement and test backups: 3-2-1 rule at minimum (3 copies, 2 media types, 1 offsite). Include at least one offline or immutable copy that ransomware cannot encrypt or delete. Test restores quarterly - an untested backup is an unknown-value backup
Implement data loss prevention (DLP) policies to detect and block unauthorized transmission of sensitive data - Microsoft Purview, Defender for Cloud Apps, or equivalent
Establish secure data disposal procedures: certified wiping or physical destruction for decommissioned hardware, documented procedures for cloud data deletion including verification
Verify data integrity for critical systems: use file integrity monitoring (FIM) on critical servers, and verify backup integrity as part of your restore testing process
Common mistake: Backups exist but have never been tested. A backup that hasn't been restored in over a year is an assumption, not a recovery capability. When a ransomware event forces you to rely on that backup under time pressure, discovering it's corrupted or incomplete is catastrophic. Quarterly restore tests are non-negotiable.
PR.PS - Platform Security
PR.PS covers the security of the hardware and software platforms your organization uses. This is configuration management, patch management, secure development practices, and everything that goes into keeping the platforms themselves from becoming the attack surface.
PR.PS-01 through PR.PS-06
Harden, patch, and maintain your technology platforms
PR.PS covers configuration management and security baselines (PR.PS-01), software maintenance and patch management (PR.PS-02), configuration change control (PR.PS-03), log generation from platforms (PR.PS-04), technologies designed for trustworthiness (PR.PS-05), and secure coding practices (PR.PS-06).
How to implement:
Establish security baselines for all platform types: CIS Benchmarks are the industry standard starting point for Windows, macOS, Linux, cloud services, and network devices. Document your baselines and the deviations you've accepted and why
Implement a patch management process: critical and high-severity patches applied within 14–30 days of release, OS and application patches on a defined monthly cycle. Track patch compliance by system and escalate exceptions
Use a configuration management tool (Group Policy, Intune, Ansible, Puppet, Chef) to enforce and audit baseline configurations - manual configuration doesn't scale and drifts
Implement a change management process: all changes to production systems require documentation, approval, and a rollback plan. Changes without change records create audit gaps
Enable comprehensive logging on all platforms (PR.PS-04) - this feeds your Detect function. Windows Event Logs, Azure Activity Logs, cloud audit logs, and application logs should all be captured and retained
For development environments (PR.PS-06): establish secure coding practices, conduct code reviews, use static application security testing (SAST) tools, and manage third-party library dependencies
Common mistake: Patch management is done reactively - patches are applied when IT gets around to it, not on a defined cadence. The CISA Known Exploited Vulnerabilities catalog makes clear that unpatched vulnerabilities are the primary mechanism for most significant breaches. A defined patch SLA with documented exceptions is a baseline expectation.
PR.IR - Technology Infrastructure Resilience
PR.IR requires that the organization's technology infrastructure is designed and maintained to be resilient - able to withstand disruptions and recover quickly when they occur. This is not incident response planning (that's in RS); it's the architectural and operational decisions that make recovery possible.
PR.IR-01 through PR.IR-04
Build resilience into your infrastructure, not just your response plan
PR.IR covers: protecting networks and environments from unauthorized access (PR.IR-01), ensuring systems can operate under adverse conditions (PR.IR-02), protecting data adequately for recovery (PR.IR-03), and adequate capacity and performance to meet organizational demands (PR.IR-04).
How to implement:
Network segmentation (PR.IR-01): separate high-risk systems (production servers, OT/ICS, PCI environments) from general user networks using VLANs or physical segmentation. Limit lateral movement pathways
Implement redundancy for critical systems: redundant internet connections, failover servers, and load balancing for critical applications. Define RTO and RPO for each critical system and validate that your architecture can meet them
PR.IR-03 aligns with PR.DS backup requirements - resilience for recovery means backups are available, tested, and can actually restore systems to operation within your RTO targets
Capacity planning (PR.IR-04): monitor resource utilization trends and plan infrastructure capacity before limits become crises. This includes both normal operations and potential surge scenarios (incident response, business growth)
Document your resilience architecture: network diagrams showing segmentation, redundancy documentation, and DR/BCP documentation that maps to your PR.IR implementation
Common mistake: Organizations have DR documentation that describes a target state rather than their actual architecture. The DR plan says "failover to the secondary datacenter" but the secondary datacenter was decommissioned two years ago and no one updated the plan. PR.IR requires that resilience exists in practice, not just in documentation.
Evidence tip: For PR.AA, evidence includes MFA enrollment reports, access review records, and privileged access management logs. For PR.DS, it's encryption configuration documentation and backup test records. For PR.PS, it's patch compliance reports and configuration baseline documentation. Collect these on a defined schedule so you're not assembling evidence under pressure when a review arrives.
Policy Documentation for Your CSF 2.0 Protect Program
Every Protect control needs written policy backing. Our NIST CSF 2.0 Full Policy Bundle includes policy language for all five PR categories - identity and access management, security training, data security, platform security, and resilience - alongside the other five CSF 2.0 functions. Professionally written and ready to adapt.
CSF 2.0 significantly reorganized the Protect function. The old Access Control (PR.AC) and Identity Management categories were merged into PR.AA. The old Information Protection Processes category was broken into PR.PS (Platform Security) and PR.IR (Technology Infrastructure Resilience). Data Security (PR.DS) and Awareness and Training (PR.AT) remain but were substantially updated. Overall, the category count stayed at five but the content and scope changed considerably.
CSF 2.0 is outcome-based and doesn't mandate MFA by name. However, PR.AA-03 requires that users, services, and hardware are authenticated using strong mechanisms, and MFA is widely recognized as the baseline for strong authentication in enterprise environments. For any organization with meaningful cyber risk exposure, MFA for all user accounts - especially privileged accounts and remote access - is the minimum defensible implementation of PR.AA-03.
PR.DS covers data-at-rest protection (encryption), data-in-transit protection (TLS), data backups, data disposal, data leak prevention, and data integrity verification. In practice: encrypt sensitive data at rest using AES-256 or platform-native encryption. Use TLS 1.2 or higher for all data in transit. Maintain tested backups with offline or immutable copies. Implement DLP policies. Document your data handling procedures in a data classification and handling policy.
PR.AT only has two subcategories - general personnel awareness training and privileged user training. You don't need an expensive LMS. At minimum: conduct annual security awareness training for all staff (CISA provides free training resources), run quarterly phishing simulations, document completion rates, and provide specific training for staff with privileged access covering the unique risks of elevated permissions. Tracking and documentation matter as much as the training content itself.
PR.PS (Platform Security) is about maintaining the security of your technology platforms - hardening, patching, and configuring to security baselines. It's about preventing vulnerabilities from existing in the first place. PR.IR (Technology Infrastructure Resilience) is about ensuring your infrastructure can withstand or recover from disruptions - redundancy, failover, backup capability, and capacity. PR.PS minimizes attack surface; PR.IR ensures you can absorb a hit and keep operating.