What the NIST CSF Protect function requires and who does the work
NIST does not certify organizations, products or service providers against the Cybersecurity Framework, so a Protect claim is a statement you make and must be able to support. Your organization owns its safeguards. An implementation partner can prepare systems, configurations and evidence, but only an independent assessor can report on them. Before anyone is hired, a board, customer or regulator asking for Protect alignment should be told exactly which safeguards are in scope and who will check them. Protect has five Categories in CSF 2.0: 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). The NIST CSF 2.0 Reference Tool export lists 22 Subcategories and 77 Implementation Examples under these Categories. Those counts describe the framework, not your program. How much of each Subcategory you must address depends on your scope, the systems and data involved, your risk decisions and your maturity, so the first task is to agree the boundary of the systems being assessed.
Start by listing who approves what. Leadership sets the risk decisions that justify each safeguard, system owners configure and operate the controls, and staff in the security or platform team produce the evidence. An implementation partner usually carries the build and documentation work, such as hardening baselines, identity configuration, backup testing and logging pipelines, under a written scope. Ask any partner which evidence each safeguard will produce, who keeps it, and how long it is retained. The independent assessor then tests whether the safeguards work as described. Ask the assessor, before fieldwork, which evidence it will request and how it will sample it, because that determines how much preparation is needed. Costs usually rise with the number of systems in scope, the number of exceptions to document and the amount of manual evidence collection, so ask for those drivers to be itemized in any quote.
Which five Protect Categories a program must cover
The Protect Function in CSF 2.0 is organized into five Categories, each addressing a different kind of safeguard. Together they cover who can access what, how people are prepared, how data is kept safe, how systems are configured and maintained, and how the infrastructure keeps running under stress.
Identity management, authentication and access control
This Category (PR.AA) covers identities and credentials, identity proofing, authentication, identity assertions, access permissions and physical access. Its core question is whether each account belongs to a known person or service and holds only the access it needs. Check that every account is unique, that default manufacturer passwords are changed, and that multifactor authentication is enabled on every account that supports it. Review access permissions on a regular schedule, not only when someone joins or leaves.
Awareness and training
This Category (PR.AT) has two outcome areas: general awareness for all personnel and role-based training for people in specialized roles. General awareness helps every employee recognize phishing, handle sensitive data and report suspicious activity. Role-based training targets administrators, developers and others whose decisions directly change system security. Confirm that training is delivered on a recurring basis, that completion is recorded, and that the content matches the roles people actually hold.
Data security
This Category (PR.DS) covers protecting data at rest, in transit and in use, along with backups. Its outcomes are the most direct link to ransomware recovery and data loss. Check that sensitive data is encrypted where it is stored and moved, that full-disk encryption is applied to laptops and tablets, and that backups are tested by restoring them. Keep at least one frequently updated backup set offline so an attacker with network access cannot reach it.
Platform security
This Category (PR.PS) covers configuration management, software and hardware maintenance, log generation, preventing unauthorized software and secure software development. It asks whether systems run in known, approved configurations and whether they stay patched. Check that standard build images are used, that patches and updates are applied on a defined cycle, that end-of-life software is replaced, and that logs are generated and retained in a form that supports later investigation.
Technology infrastructure resilience
This Category (PR.IR) covers network protection and segmentation, protection against environmental threats, resilience mechanisms and capacity. It asks whether a failure or attack in one part of the environment can spread to the rest, and whether the infrastructure can keep operating under pressure. Confirm that networks are segmented by function and sensitivity, that critical services have redundancy, and that capacity is planned for peak and failover loads rather than average use.
How Protect was reorganized from CSF 1.1 to CSF 2.0
The most important change for anyone holding CSF 1.1 evidence is that the old Protect Categories no longer map one to one. CSF 1.1 PR.AC, Identity Management, Authentication and Access Control, became PR.AA in CSF 2.0, and its content is now organized around identities, credentials, authentication, access permissions and physical access. The older PR.IP (Information Protection Processes and Procedures), PR.MA (Maintenance) and PR.PT (Protective Technology) Categories were not carried forward as they were. Their Subcategories were split across PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience) and, for some items, ID.IM (Improvement) in the Identify Function.
The split is easiest to see at the Subcategory level. In NIST's transition spreadsheet, CSF 1.1 PR.AC-1, which covers identities and credentials issued for authorized devices, users and processes, maps to both PR.AA-01 and PR.AA-05 in CSF 2.0. PR.AA-01 covers management of identities and credentials, while PR.AA-05 covers access permissions and authorizations. An illustrative example: a single evidence item, such as an export of the identity provider's user and service account list, may now support a CSF 2.0 claim under PR.AA-01 and a different claim about role-based permissions under PR.AA-05. The same artifact can satisfy more than one outcome, so a single old row in your spreadsheet can become several rows in the new one.
Do not assume a one-to-one match. Open NIST's CSF 1.1 to CSF 2.0 Core transition changes spreadsheet, filter by each CSF 1.1 Subcategory you currently claim, and record every CSF 2.0 Subcategory it now maps to. Then check whether your existing evidence actually shows the new outcome, not only the old one. Ask your assessor or internal audit team to confirm the mapping for your environment, because the transition document shows how NIST relates the two versions, not whether your controls meet each new outcome. Any gap you find becomes a line item in your Current Profile for the Protect Categories.
Where NIST suggests small and large organizations start with Protect
NIST's small business quick-start guide, SP 1300, names a short set of Protect actions that a small team can finish without a dedicated security staff. They map to specific CSF 2.0 Subcategories, so you can trace each action back to the outcome it serves. The list is deliberately narrow, and it assumes the organization already knows which accounts, laptops and data sets it has.
- Multifactor authentication (PR.AA-03): Turn on multifactor authentication for every account that supports it, starting with email, cloud administration and financial systems.
- Default passwords (PR.AA-01): Change default passwords on routers, cameras, printers and other devices supplied by manufacturers before they go into service.
- Automatic patching (PR.PS-02): Enable automatic updates where the vendor offers them, and replace software that the vendor no longer supports.
- Tested backups (PR.DS-11): Back up important data, test that restores work, and keep at least one copy disconnected from the network.
- Full-disk encryption (PR.DS-01): Encrypt laptops and tablets so that a lost or stolen device does not expose stored data.
Before you act, confirm which accounts, devices and data sets are in use, since a list built from memory often misses a shared mailbox or an old backup target.
The resource and overview guide, SP 1299, gives larger organizations a wider set of starting points. These cover identity design, training, device standards, logging, data protection and the retirement of unsupported systems. Each one needs an owner, a documented standard and evidence that the standard operates, which is where most of the work sits.
- Unique accounts and least access: Give each person a unique account and grant only the permissions their role needs, reviewing them on a set schedule.
- Regular training: Run user training on a recurring basis, with separate role-based content for administrators and developers.
- Uniform device configuration and logging: Apply one approved build to each device class and collect logs centrally so that changes and failed logins can be reviewed.
- Encryption of sensitive data: Define which data counts as sensitive and encrypt it at rest and in transit, with key management assigned to a named team.
- End-of-life replacement and offline backups: Schedule the replacement of unsupported software and keep at least one frequently updated backup set offline against ransomware.
These items are starting points, not a complete control set, so check each one against the Protect Subcategories and your own risk assessment.
The two audiences share the same outcomes, but the depth differs. A small organization can often finish its starting list with a single administrator, while a larger one needs owners, schedules and records for each item. Treat the lists as a first pass that shows where to begin, then extend them to cover the Protect Categories for identity, training, data, platform security and infrastructure resilience.
- Start with inventory: You cannot protect accounts, devices or backups you have not listed, so confirm the inventory before changing settings.
- Record the decision: Note who approved each setting, the date and the evidence, such as a screenshot, configuration export or restore test log.
- Repeat the test: A backup that restored once may fail later, so schedule restore tests and keep the results.
- Plan for exceptions: Some legacy systems cannot take multifactor authentication or patches, so document the compensating controls and the review date.
- Ask for scope in writing: If an outside provider helps, agree in writing which systems, accounts and evidence are in scope.
Before you rely on either list, check that every starting point maps to a Subcategory in your own Protect review.
What must be in place before evidence can support Protect
Protect outcomes are only as credible as the inventory, access model, training record, data classification, configuration baseline and restore tests behind them. A reviewer will trace each safeguard back to these six foundations before accepting a screenshot or a policy as proof.
Current asset inventory
Every account, device and workload that Protect safeguards has to appear in an inventory first. Without it, an MFA report or patch report covers only the systems someone remembered to list. Check that the inventory is reconciled against identity provider exports, endpoint management records and cloud account lists, and that each entry has an owner. Reviewers commonly ask for the inventory date, the reconciliation method and the list of exceptions.
Documented access model
A written access model states who may hold which accounts, how least access is granted, and who approves privileged roles. PR.AA outcomes depend on it. Check that the model names roles, not individuals, and that it covers service accounts and physical access. Reviewers typically request the role definitions, the approval records for privileged access and a sample of joiner, mover and leaver tickets.
Training record
Awareness and role-based training under PR.AT only counts when the organization can show who completed what and when. Check that the training catalog separates general awareness for all personnel from specialized training for administrators and developers. Reviewers usually ask for completion records tied to the current roster, the content used each year and follow-up actions for people who did not finish.
Data classification scheme
Encryption and backup rules under PR.DS need a classification scheme that says which data is sensitive. Without labels, teams cannot prove that sensitive stores were encrypted. Check that the scheme names categories, owners and handling rules for data at rest, in transit and in use, and that systems holding each category are mapped. Reviewers commonly request the scheme, the data store inventory mapped to it and encryption settings for the top categories.
Configuration baseline
A configuration baseline defines the secure settings that PR.PS expects every device, server and platform to share. Check that it exists as versioned code or documented standards, that deviations are approved, and that drift is detected. Reviewers usually ask for the baseline document, the configuration scan results for a sample of systems and the change records that explain any exceptions.
Tested backup restore record
Backups count as protection only after a restore has been tested. Check that restore exercises cover representative systems, that at least one copy is kept offline as the SP 1299 suggestion describes, and that the results record recovery time and any failures. Reviewers commonly ask for the restore test plan, dated test results, the offline copy location and the remediation tickets for failed restores.
Who is paid for what when Protect is assessed
This table compares the cost components behind a Protect assessment, showing who is paid, whether each cost is one-time or recurring, and what drives it. NIST does not charge a fee because it does not certify, and no price figures are supplied here, so request written quotes that separate each row.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| Internal staff time | Your own staff (no external invoice) | Recurring. Drivers include how many identity, training, backup and patching owners you name and how often they review evidence. |
| Implementation partner for systems and evidence | A firm such as DeployOpen, under a written scope | Mostly one-time for configuration, MFA rollout and backup testing, with retainers possible later. Drivers include the number of systems and identity sources in scope. |
| Tooling, one-time | Software vendors, hosting providers or open-source setup work | One-time. Drivers include licenses for identity, endpoint management, backup and logging, and whether you self-host. |
| Tooling, recurring | Software vendors, hosting or cloud providers, and support contracts | Recurring. Drivers include user counts, log volume, storage for offline backup copies and support tier. |
| Independent assessor or auditor | A third-party assessor you select, if you commission one | Recurring when repeated. Only independent assessors issue assessment reports; ask for the scope, sampling approach and deliverable format in writing. |
| Self-assessment | Your own staff or a consultant you engage for it | Recurring. Drivers include the number of Protect Subcategories you test and whether results are checked by someone independent. |
Questions buyers ask about the Protect function
Does NIST certify an organization's Protect function?
No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it has no plans to create a conformity assessment program. NIST's FAQs state that it does not offer certifications or endorsements of CSF-related products, implementations or services. A claim of Protect alignment is a self-assessment that the organization makes and can support with evidence. If a customer wants independent assurance, the organization can ask for an assessment by a qualified third party, but that party reports on its own findings and does not issue a NIST certificate. Ask any firm that offers a NIST CSF certificate to explain which body issued it and what it tested.
Is the NIST CSF Protect function mandatory?
Protect is mandatory only where a rule or contract makes the framework mandatory. NIST is not a regulator, and most organizations use the CSF voluntarily. A 2017 executive order made the framework mandatory for U.S. federal agencies. Other organizations meet it because a customer, supplier or sector body requires it in a contract or questionnaire. Read the clause that names the framework and check whether it asks for the Core, a Profile, a Tier or a specific set of outcomes. Protect is one of six Functions, so a contract that asks for "CSF alignment" may still leave some outcomes to your judgment.
How long does Protect work take to complete?
No reliable duration can be given without a defined scope, because the time depends on the size of the estate, the number of accounts and systems, how much configuration is already standardized, and how much evidence exists. Ask for a written scope that lists the systems, identity sources, data stores, backup targets and sites in scope, then ask for a timeline built from that scope and a list of dependencies, such as change windows or vendor actions. For engagements with DeployOpen, scope, deliverables and timelines are agreed in writing before work starts, so the timeline follows from that document rather than from a standard estimate.
What does Protect work need from internal staff?
Protect work depends on decisions and access that only the organization can provide. Expect to name owners for identity sources, backup systems, endpoint standards and data classes. Staff must approve changes that affect users, such as enforcing multifactor authentication or changing configuration baselines, and must review access rights for accuracy. Security and IT operations teams need to supply current inventories, existing policies and logs. Plan time for the people who run change management, because updates to production systems usually pass through that process. An implementation partner can prepare systems and evidence, but the organization still owns the controls and their operation.
Can a small internal team implement the Protect function alone?
A small team can work through Protect alone if it has the skills and time, and NIST's Small Business Quick-Start Guide (SP 1300) is written for that case. Its Protect actions include multifactor authentication on accounts that support it, changing default passwords, regular patching with automatic updates, tested backups and full-disk encryption on laptops and tablets. Teams that lack configuration, identity or backup experience usually find the hardest parts are testing restores and standardizing settings across devices. Consider outside help for specific gaps, such as a fixed-scope engagement to build hardened platform configurations, while the internal team keeps ownership of the outcomes.
How does Protect map to CIS Controls and SP 800-53?
NIST publishes informative references that link each CSF 2.0 Subcategory to controls in other catalogs, including SP 800-53 Rev. 5 and CIS Controls v8.1. The NIST CSF 2.0 Reference Tool export lists these references along with Implementation Examples. Use them as a starting point, but do not treat a mapping as proof that one control satisfies another. A mapping shows where two catalogs address a similar topic, and the depth of each match can differ. For example, a Protect Subcategory on backups may link to several controls that each test a different aspect of recovery. Confirm each mapping against the source text and your own evidence before you report it to an assessor or customer.
What evidence shows that Protect safeguards work?
Evidence should show that a safeguard exists, is configured as intended and is operating over time. Useful artifacts include identity provider settings and access review records, multifactor authentication enrollment reports, configuration baselines with compliance scans, patch reports, encryption status for endpoints and databases, and restore test records for backups. Keep one offline or immutable backup set and record when it was last tested. Store evidence in a way that shows the date and the source system. Ask any assessor which artifacts they expect for each Subcategory before you collect them, so the evidence matches the test.
What usually delays Protect work and how to avoid it
Most Protect delays come from work that looks finished but has not been checked against the full scope. The five pitfalls below share one pattern: a control is assumed to cover everything it was meant to cover, and nobody confirms it against the real inventory, the restored data or the current framework version.
Treating MFA as finished
Multifactor authentication often covers the main identity provider and misses legacy applications, service accounts, administrative consoles and remote access paths. PR.AA-03 asks for MFA on all accounts that offer it, so a partial rollout is still an open gap. Check every account type against the directory and the application list, and record the exceptions with an owner and a review date.
Leaving backups untested
A backup job that reports success does not show that data can be restored within the time the business needs. PR.DS-11 expects backups that are tested, and SP 1299 suggests keeping at least one frequently updated set offline against ransomware. Schedule a restore test for a sample of systems and record how long it took and what was missing.
Scoping without an asset inventory
Teams that define Protect scope from memory or from the production diagram usually miss shadow systems, cloud accounts and laptops that receive different configurations. Without an inventory, uniform device configuration and encryption on laptops and tablets (PR.DS-01) cannot be verified. Build the inventory from discovery data and reconcile it with the asset register before setting any control targets.
Using CSF 1.1 IDs in new evidence
Evidence written against CSF 1.1 identifiers, such as PR.AC, does not map cleanly to CSF 2.0, where PR.AC became PR.AA and one 1.1 Subcategory can split across several 2.0 Subcategories. Assessors then have to rebuild the crosswalk themselves. Tag every new policy, ticket and test result with CSF 2.0 Subcategory IDs and keep the NIST transition spreadsheet as the reference for older records.
Assuming a vendor badge equals alignment
A product that supports MFA, encryption or logging does not make the organization aligned with Protect outcomes, because alignment depends on how the product is configured and operated. NIST does not certify products or services for CSF use. Ask each vendor for the configuration evidence that supports the specific Subcategory you are claiming, and test it yourself before reporting alignment.
How a Protect readiness project moves from scope to evidence
The sequence turns a general wish to protect systems into a scoped baseline, a gap list against the Protect Subcategories, remediated controls with dated proof, and an independent view of whether that proof holds up. Each phase has a named output so the organization can see progress without relying on a vendor's word.
Define scope and build the asset baseline
The organization decides which business units, systems, identities and data stores fall inside the Protect review, and records who owns each one. Its own IT and security staff own this decision, with an implementation partner helping collect inventories from directories, cloud accounts, endpoint tools and network records. The step closes when the team holds an agreed scope statement and an asset list that names an owner for every system in it. Gaps in the inventory are logged as open items rather than silently dropped.
Run a gap analysis against Protect Subcategories
For each in-scope system, the team compares current safeguards with the Protect Subcategories in the CSF 2.0 Core, covering identity and access, awareness and training, data security, platform security and infrastructure resilience. The organization owns the findings, and the partner records what it observed and how. The output is a Current Profile and a gap register that lists each missing or partial outcome, its affected systems and a proposed owner. Ask whether the gap register distinguishes between evidence that is missing and controls that are actually absent.
Prioritize gaps and set the target profile
Leadership and system owners rank the gaps by the risk they carry to the organization's mission, customers and legal obligations. The result is a Target Profile that states the intended Protect outcomes for each scoped system, along with the decisions made on accepted risk. Risk acceptance is signed by an accountable manager, not by the implementation partner. The step closes when the prioritized list has an owner and a planned change for every item that is not accepted.
Remediate controls and configure logging
Engineers change configurations, enforce multifactor authentication where supported, standardize device builds, enable encryption, schedule patching and set up logs that will later prove the controls work. The organization's teams perform or approve each change, and the partner documents the configuration and the reason for it. This step closes when each remediated control can be demonstrated on a live system, with a configuration record, a change ticket and a log source. Changes that cannot be evidenced yet stay on the gap register.
Test backups and training records
The team restores sample data from backups to confirm recovery works, verifies that at least one set is kept offline as the Protect guidance suggests, and checks that role-based and general awareness training has been delivered and recorded. Results are written down, including failed restores and missed training, with a remediation owner for each. The step is complete when the restore tests and training logs exist for the period under review and the organization has signed off on the results.
Assemble the evidence package
The team organizes configuration exports, access reviews, change records, log samples, restore test reports and training attendance into a package mapped to each in-scope Protect Subcategory. Each artifact is dated, attributed to its owner and stored where the organization controls retention. The output is an evidence index that a reviewer can follow from a Subcategory to the proof behind it. Confirm the retention and access rules for this package before the review starts.
Obtain independent review of the evidence
An independent assessor or auditor, chosen and engaged by the organization, examines the evidence and tests a sample of controls against it. The implementation partner answers questions and fixes documentation gaps but does not issue findings, reports or certificates. NIST does not offer a conformity assessment program for CSF 2.0, so the scope, method and output of any outside review should be agreed in writing with the reviewer. The step closes when the reviewer's written findings are received and the organization has a dated list of open issues to resolve.
How DeployOpen prepares Protect systems and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the Protect safeguards for identity, training, data, platform and resilience are configured where they run. We prepare systems and evidence for your assessment, while your organization owns its controls and an independent assessor makes any determination.
How we scope
- Agree a written scope listing which Protect Categories and Subcategories the engagement covers, before work starts
- Map each in-scope safeguard to the systems, accounts and data stores it touches in your environment
- Confirm which outcomes stay with your own staff, such as policy approval and access reviews
- Define deliverables, timelines and acceptance criteria in writing, since most engagements are fixed-scope
How we build
- Configure identity and access controls, including unique accounts, least access and multifactor authentication where platforms support it
- Set uniform device and platform configurations, with logging, encryption and patching routines documented as built
- Implement tested backup and restore procedures, including an offline copy, inside your own cloud accounts or data centers
- Test each safeguard against its stated outcome and record results for review
How we hand over
- Deliver configuration records, runbooks and architecture documentation that show how each safeguard operates
- Provide evidence packs such as configuration exports, access lists, training records and backup test logs, organized by Subcategory
- Walk your staff through operation so they can run and explain the controls to an assessor
- Document open items and the owner responsible for each one
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Refresh evidence and configurations when platforms are upgraded or new systems join the scope
- Coordinate with your independent auditor or assessor on evidence requests, while they alone issue any report
- Confirm retainer terms, response expectations and service levels in writing before engagement
