We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

NIST CSF 2.0 · Function 3 of 6

Protect (PR): what it demands and how it is evidenced

The engineering function: identity and access, awareness, data security, platform security and infrastructure resilience. CSF 2.0 reorganised it — platform security (PR.PS) and infrastructure resilience (PR.IR) are the categories where 1.1-era profiles have the most unmapped ground.

Reviewed by Tanya Kumari, Director — compliance assessment & certification readiness · Part of the CSF 2.0 series · CSF is voluntary guidance — we build profiles, not certificates

The categories inside Protect

PR.AA
Identity management, authentication and access control

Identities managed lifecycle-wide, authenticated proportionally to risk (MFA), access granted least-privilege and reviewed.

PR.AT
Awareness and training

Personnel and privileged/specialised roles trained for their responsibilities — role-based, refreshed, measured.

PR.DS
Data security

Data-at-rest and in-transit protected, backups created, protected and tested — confidentiality, integrity and availability together.

PR.PS
Platform security

Configuration management, software maintenance/patching, logging enabled, software integrity — the hardening category (new arrangement in 2.0).

PR.IR
Technology infrastructure resilience

Networks and environments protected and built to resist and recover — segmentation, capacity, resilience mechanisms.

Category identifiers reference NIST CSF 2.0 (26 February 2024) — nist.gov/cyberframework.

Where profiles fall short

MFA coverage asserted, not enumerated

PR.AA holds up only when every access path is listed with its authentication strength — the same exercise PCI 8.4.2 forces, reusable here.

Backups that have never restored

PR.DS includes tested backups; an untested backup is the finding every framework writes the same way.

Hardening without drift detection

PR.PS expects configurations managed over time — baseline plus monitoring, not a golden image from two years ago.

Evidence that holds up

  • Identity lifecycle records, MFA coverage map, access reviews (PR.AA)
  • Role-based training records with completion tracking (PR.AT)
  • Encryption standards, backup configuration and restore tests (PR.DS)
  • Hardening baselines with compliance/drift reporting (PR.PS)
  • Segmentation design and resilience test evidence (PR.IR)

Protect FAQ

What is new in Protect under CSF 2.0?

The category structure: platform security (PR.PS) and technology infrastructure resilience (PR.IR) group hardening, patching, logging and resilience expectations that were scattered across 1.1.

Does CSF mandate MFA?

CSF states outcomes — authentication commensurate with risk (PR.AA) — rather than mandating controls; risk-appropriate implementation in practice means MFA for privileged and remote access at minimum.

How does Protect map to ISO 27001?

Closely: PR.AA↔A.5/A.8 access controls, PR.DS↔A.8 data controls, PR.PS↔A.8.9 configuration management — a CSF profile and an ISMS can share one evidence base.

Identify (ID)Detect (DE)

Your CSF 2.0 profile, built properly

Current and target profiles, gap analysis, and a prioritised roadmap that maps onto the ISO 27001, SOC 2 or SEBI CSCRF work you may already owe — kept current on SigmaTrust.