NIST CSF ransomware profile IR 8374 Rev. 1 guide

What the NIST CSF ransomware profile asks of your organization and who pays for the work

If a customer, contract or board asks for ransomware readiness mapped to NIST CSF 2.0, start by knowing that NIST's final IR 8374 Rev. 1, published June 11, 2026, is a CSF 2.0 Community Profile you can use to evaluate current defenses and build a ransomware countermeasure playbook. It does not produce a certificate, attestation or audit report, and no NIST program issues one. Your organization owns every control it describes. An implementation partner can prepare systems, configurations and evidence, but only an independent assessor can give a third-party opinion, and the buyer of that opinion should be clear about which one they need.

Cost and effort depend on scope, not on the profile itself. The main cost drivers are the number of identity systems, endpoints and servers in scope, how many backup sets exist and how often they are tested, whether logging already reaches a central store, and how much evidence already exists for each outcome. Most of the work is one-time: the baseline assessment, the gap list and the first playbook. Recurring costs include backup restore testing, access reviews, log retention, tabletop exercises and keeping the playbook current as systems change. Ask any partner for a quote that separates those one-time and recurring items, names the systems in scope and states who performs each test.

Ask internal owners and external parties for a short list of decisions before engaging anyone: which business services count as priority, who may execute the incident response plan, how many days of data loss the business can accept, and whether at least one backup copy can be kept offline and restored in a test. These answers set most of the effort. Where a restore test has never been run, plan for it as the largest unknown, because the profile's recovery outcomes are only proven by a restore you have actually performed. Confirm the current profile text and any appendices directly in NIST's publication before you write these decisions into a contract.

How to use the profile to assess defenses and build a playbook

The sequence moves from defining scope and objectives, to a Target Profile drawn from the ransomware Community Profile, to a prioritized gap list, and finally to a countermeasure playbook matched to the organization's resources and risk appetite. Each phase produces a written record that the next one depends on.

Confirm scope and objectives
Leadership, the security lead and the owners of business-critical systems agree which environments, business units and data the ransomware assessment covers, and what the organization wants to achieve, such as limiting the chance of encryption, protecting backups or shortening recovery. The security lead records the scope boundaries, named owners and the risk appetite that will guide later choices. This step is complete when the scope statement and objectives are signed off and every in-scope system has an owner. Questions to settle include which third parties and cloud services are in scope and whether any operational technology is included.
Adopt the profile as the Target Profile
The team reviews IR 8374 Rev. 1 and treats its ransomware outcomes as the starting point for the organization's Target Profile. Where the profile describes an outcome that does not fit the organization, the team records the change and the reason, such as a control that is not applicable to a given technology. The output is a draft Target Profile that lists each relevant CSF 2.0 Category and Subcategory with the intended outcome and a target tier. The step is done when reviewers have accepted each deviation in writing.
Document the current profile
Engineers and control owners describe how each relevant outcome is met today, using configuration records, backup logs, access reviews, incident response documents and evidence from recent exercises. The security lead compares actual practice against the evidence, not against policy statements alone. The output is a Current Profile that states, for each Subcategory in scope, what is in place, who operates it and where the evidence sits. The step is complete when every entry has a named evidence source or is marked as missing.
Compare current and target profiles
The team places the Current Profile beside the Target Profile and records each gap, grouping them by Function, with a short note on the likely effect of the gap during a ransomware event. Priority gaps are those where a missing outcome would let an attacker reach backups, spread across the environment or delay recovery. The output is a documented gap list with a priority rating and a named owner for each item. The step is done when the list has been reviewed by the people who run the affected systems and disputed items are resolved or accepted as risk.
Set priorities against resources
Leadership and the security lead rank the gaps by risk reduction, cost, dependency and the capacity of the teams that must act. Some gaps may need a procurement decision, a contract change or a shared effort with a managed service provider, so the ranking should show who must approve each item. The output is a prioritized action list with decision owners and the constraints that shaped the order. The step is done when the list has been approved and the organization knows which gaps it will close, which it will reduce and which it will accept.
Write countermeasure playbook entries
For each priority gap, the team writes a playbook entry that names the countermeasure, the trigger that starts it, the responsible role, the systems affected and the evidence that shows it worked. Entries for Respond and Recover should reference the incident response plan, who is authorized to execute it and how backup integrity is checked before restoration, as described in SP 1300. The output is a playbook with one entry per countermeasure, matched to the objectives, risk appetite and resources set in the earlier phases. The step is complete when each entry has been walked through with the teams that would execute it.
Test and record the playbook
The team tests selected playbook entries through tabletop exercises or controlled technical tests, then records what worked, what did not and what changed. Findings feed back into the gap list and the Target Profile so the next review starts from current facts. The output is an exercise record with dated findings, updated playbook entries and an updated gap list. The step is done when the organization can show that the playbook was tested and that open findings have owners. Any timing for repeating these tests should be set by the organization's own policy rather than by this profile.

Which backup and recovery outcomes matter most

Ransomware succeeds when attackers can lock data, spread unchecked and leave no clean copy to restore from. The cards below follow the PROTECT starting points in SP 1299 and the Respond and Recover actions in SP 1300, so each one maps to a decision your team can verify before an incident.

Unique accounts and least access

Ransomware operators move fast through shared and over-privileged accounts. Give each person and service its own identity, and grant only the access each role needs. Check whether administrative accounts are separate from daily-use accounts, and whether backup systems can be changed by the same credentials used on production servers. Those are the first paths an attacker tests.

Logging that survives the attack

Logs help you learn how far an intruder reached and when encryption began. Ransomware crews often try to clear or disable logs before they encrypt anything. Confirm that logs are generated on every critical system, forwarded to a store the production admins cannot edit, and retained long enough to cover the dwell time you would need to investigate.

Encrypted sensitive data

Encryption limits what an attacker can read or sell even when they copy data before locking it. Identify where sensitive data is stored and transmitted, then confirm that encryption covers those locations and that keys are managed apart from the systems they protect. Ask who can retrieve keys during an incident and how that access is logged.

Tested backups with an offline copy

SP 1299 calls for tested backups, with at least one frequently updated set kept offline against ransomware. A backup that has never been restored is an assumption, not a control. Verify that a copy is isolated from the network and from the identities that administer production, and record when each restore test last succeeded.

Incident response plan ownership

RS.MA-01 asks whether the response plan is executed and whether people know who can run it. During a ransomware event, decisions about isolating systems and engaging outside help cannot wait for a search through documents. Name the decision owner, the deputies and the contact path to leadership, and rehearse those roles with the people who would act.

Containment and eradication

RS.MI covers stopping the spread and removing the attacker's access. For ransomware, that means isolating affected hosts, disabling compromised accounts and clearing persistence before any restore begins. Restoring into a network that still holds the intruder usually leads to a second encryption. Define who can authorize network isolation and how quickly it can be carried out.

Backup integrity before restore

RC.RP-03 asks that backups and restored assets be verified before use. Ransomware groups sometimes encrypt or corrupt backups before triggering the attack, so restoring without checking can reintroduce the malware. Check that integrity verification steps exist, that you know which backup version predates the intrusion, and that restored systems are scanned before reconnection.

After-action reports

RC.RP-06 covers declaring recovery complete and documenting what happened. An after-action report records the entry point, the timeline, the gaps in controls and the changes you committed to make. Without it, the same weakness often returns. Plan who writes the report, who reviews it and how its findings feed back into your protect controls and playbook.

Who owns the controls, who prepares evidence and who assesses

Your organization owns the ransomware countermeasure playbook, the risk appetite behind it and every decision about which IR 8374 Rev. 1 outcomes to prioritize. NIST presents the profile as a tool for evaluating current defenses and choosing priority actions, and those choices depend on your objectives, resources and tolerance for downtime. No vendor or consultant can make those calls on your behalf, and NIST itself does not certify or endorse any implementation of the CSF.

Risk appetite and priorities: Leadership accepts or rejects residual ransomware risk and decides which Target Profile outcomes come first.
Control ownership: Named owners are accountable for backup policy, access rules, logging standards and the incident response plan, including who can execute it (RS.MA-01).
Playbook approval: Your security and business leaders approve the countermeasure playbook and its recovery priorities.
Exercises and lessons learned: Your staff run tabletop and recovery exercises and write the after-action reports (RC.RP-06).
Operational decisions: Your people decide when to isolate systems, when to restore and when to declare recovery complete.

Confirm that each control in your playbook has a named owner who can explain it without outside help.

What makes the ransomware assessment larger or smaller

The effort to run IR 8374 Rev. 1 against an environment depends less on the profile itself than on what the assessment has to cover. The cards below cover the factors that expand or shrink that work and the controls an organization can put in place to keep it bounded.

Number and type of systems in scope

A profile assessment grows with every system that holds data, runs business processes or can reach a backup. Start with a count of production, development and administrative systems, then group them by function so the team can assess representative configurations rather than each machine. Ask whether the asset inventory under ID.AM is current, because an assessment built on an outdated list will miss the systems ransomware actually reaches. Assessing by group also limits how far the scope drifts during the work.

Backup platforms and their coverage

Each backup platform, copy and storage target is a separate line of evidence for the recovery outcomes. Count the backup products, the storage tiers (on-premises, cloud, offline or immutable media) and the systems each one protects. Confirm which copy is offline, since SP 1299 calls for at least one frequently updated set kept offline. Restore tests against each platform show whether backup integrity is verified before recovery, which is the check the recovery outcomes call for.

Identity sources and privileged access paths

Ransomware operators commonly move through directories, single sign-on and privileged accounts, so each identity source widens the assessment. Map every directory, federation provider and local administrator store, and record which ones can change backup or logging settings. The PROTECT starting point of unique accounts and least access is easier to assess when the number of trust relationships is known. Ask who can disable backup jobs and whether that action requires separate approval.

Locations, networks and air-gapped segments

Sites, cloud regions, data centers and isolated networks each need their own defenses and their own recovery path. Air-gapped or operational technology segments often run older software and have limited logging, so they usually need separate test steps and sometimes manual evidence collection. Document how each segment connects to the corporate network, which transfers cross the boundary, and how a restored segment is validated before it returns to service. Ask whether isolation was tested, not only designed.

Third-party and managed service dependencies

When an MSP, cloud provider or software vendor administers part of the environment, the assessment must cover their controls as well as the organization's own. Identify which functions the provider performs, such as backup administration, remote access or patching, and which evidence the contract lets you obtain. Clarify who executes the incident response plan and who can authorize a restore, because those decisions can sit outside the organization. Confirm these responsibilities in writing before the assessment starts.

Maturity of existing evidence

An organization with centralized logs, dated backup reports and tested runbooks will assess faster than one whose evidence lives in individual administrators' notes. Check whether logs are retained long enough to reconstruct an incident, whether backup restore results are recorded, and whether after-action reports are written and kept. Where evidence is missing, the work shifts from checking controls to building them, which is the largest driver of effort. Ask for a short evidence inventory before scoping.

What a ransomware profile assessment costs in money and staff time

The NIST CSF ransomware profile (IR 8374 Rev. 1) is free to download, so the cost of using it sits almost entirely in people's time, any outside help you buy, and the tools you run. Your internal staff carry the largest share: the security, infrastructure, backup and incident response owners who answer the profile's questions about your current defenses, pull evidence, and agree on priority actions. Tooling usually adds little new spend, because the profile's PROTECT and RECOVER outcomes are mostly met with configuration, logging, backup and identity capabilities you may already license or can run from open-source components. Check that before you assume new purchases. Independent assessment fees apply only if you engage an outside assessor to test the results, and that is a separate decision from the profile itself.

Costs fall into two patterns. The first assessment is the heaviest, since it establishes your baseline and builds the countermeasure playbook. Afterward, recurring costs come from testing and backup verification, such as restore exercises that check whether backups can be recovered and whether the recovery steps in SP 1300-style guidance actually work, plus periodic review as systems and staffing change. Drivers that raise cost include the number of business units and systems in scope, how much evidence is missing or scattered, and how many restore tests you need to prove recovery times. Drivers that lower cost include a current asset inventory, documented incident response roles, and backups already tested on a schedule.

If you bring in an implementation partner, ask for a written quote that states the scope in plain terms: which systems, sites and Functions are covered, and which parts of the profile are excluded. Require named deliverables, such as a gap assessment, a countermeasure playbook, and the backup and restore test records, each with an acceptance step. Confirm who on your side owns each decision and each evidence item, and what the partner will not do, such as issuing an attestation, which only an independent auditor or assessor can provide. Ask whether testing and backup verification are priced separately as recurring work, and confirm any travel, licensing or third-party costs before signing.

Questions buyers ask about the NIST ransomware profile

Is NIST IR 8374 Rev. 1 a certification for ransomware protection?

No. IR 8374 Rev. 1 is a Community Profile, a set of CSF 2.0 outcomes tailored to ransomware risk that an organization can use as a baseline. NIST does not certify products, implementations or services, and it has no plans for a conformity assessment program, so no body can issue a NIST ransomware certificate. Customers may still ask you to show alignment with the profile. That means a documented assessment, a countermeasure playbook and evidence behind each claim. Before you commit, confirm with the customer what "meets the profile" means, whether a self-assessment is acceptable, and whether they expect a letter from an independent assessor. The NIST CSF FAQs explain NIST's position on voluntary use and endorsements.

Can our own team use the ransomware profile without outside help?

Yes. NIST describes the profile as applicable to organizations of any size and in any sector, and it is designed to help you evaluate current ransomware defenses and identify priority actions. A team that owns security, backup and incident response can map its existing controls to the profile outcomes, record gaps and draft a playbook. Teams commonly miss three things internally: independent challenge of their own gap ratings, restore tests that prove backups work under pressure, and evidence that people outside the security team can execute the playbook. Ask whether your backup, identity and incident response owners have the time to run the work, and whether anyone can review their ratings without a stake in the outcome. The SP 1299 starting points for PROTECT, including unique accounts, least access and tested backups with an offline copy, give a practical first pass.

How long does a ransomware profile assessment take and what does it need from us?

The duration depends on scope, and no standard figure applies across organizations. The main drivers are the number of business units and systems in scope, how many identity sources and privileged accounts you run, the design of your backups (including whether any copy is offline or immutable), how mature your incident response plan already is, and whether restore tests have been recorded. On your side, expect to provide an asset inventory, an access model, backup logs and restore test records, the current incident response plan, an up-to-date contact list, and named owners for each outcome. Interviews and walkthroughs also draw on staff time. Ask any provider for a written timeline that is tied to a written scope, and confirm which of your staff must be available and for how many sessions.

Does a CSF 2.0 assessment satisfy a customer's security requirement?

It depends on the wording of the requirement. NIST states that most organizations use the CSF voluntarily, although some companies require it of their customers or suppliers. A CSF 2.0 assessment shows how your outcomes compare with a target, which can be useful evidence. It does not, on its own, satisfy a contract that names a particular certification, a SOC 2 report, an independent penetration test or a regulator's form. Ask the customer to name the document they expect, the systems and locations in scope, who must sign it, whether a self-assessment is acceptable, and how often it must be refreshed. Get those answers in writing before you scope any work, because they determine whether you need an assessment, an attestation or an independent review.

Do we need an outside consultant for the ransomware profile?

Not always, but outside help is useful in three areas: independent review of your gap ratings, technical testing of backups and recovery, and playbook content that an operations team will actually use. The organization owns its controls and its risk decisions. An implementation partner such as DeployOpen can prepare systems, configure logging and backup, and assemble evidence inside your own environment under a fixed scope agreed in writing before work starts. DeployOpen also runs security testing, including red teaming, which can check whether recovery holds under attack. Only an independent auditor or assessor issues reports or certificates, and NIST issues none. Choose help based on the gaps you have found, and ask every provider which deliverables you receive, who signs off on them, and what evidence you keep.

How does IR 8374 Rev. 1 relate to SP 800-61 Rev. 3?

The two documents cover different depths of the same problem. IR 8374 Rev. 1 sets CSF 2.0 outcomes that run across the whole program for ransomware risk, from protecting accounts and backups to recovering systems. SP 800-61 Rev. 3 is NIST's incident response guidance, rebuilt as a CSF 2.0 Community Profile, and it focuses on how the incident life cycle runs. A practical sequence is to use the ransomware profile to decide which outcomes matter most for your organization, then use the incident response guidance to shape how your team detects, contains, analyzes and reports incidents. The Respond and Recover actions in SP 1300, such as understanding who can execute the response plan (RS.MA-01), checking backup integrity before restoring (RC.RP-03) and writing an after-action report (RC.RP-06), connect the two. Confirm with your incident response lead how much of your current plan already follows that guidance.

Which NIST sources to read before scoping

Before you scope a ransomware program against this profile, read the source documents yourself. The NIST CSRC news release for IR 8374 Rev. 1, published June 11, 2026, is the natural starting point because it states what the final profile covers and how NIST expects it to be used. Read the profile itself next, not a summary of it, since scope decisions depend on which Subcategories and examples the document actually lists. Confirm the current revision and any errata on NIST's site before you cite it in a plan or a contract.

Two Special Publications explain the Functions the profile leans on most. SP 1299, the CSF 2.0 Resource and Overview Guide, is the document to read for the PROTECT starting points, including unique accounts, least access, tested backups and an offline backup copy. SP 1300, the Small Business Quick-Start Guide, is shorter and useful for the Respond and Recover actions, such as confirming who can execute the incident response plan and checking backup integrity before restoration. Use both to test whether your current owners, tools and documents match what the profile assumes.

The NIST Cybersecurity Framework FAQs answer questions about voluntary use, the absence of certification and how Community Profiles relate to the Core. Read them before you describe the profile to an auditor, customer or board as a compliance requirement, because NIST does not present it as one. Ask your advisors to confirm which of these documents your regulator or customer will accept as a reference.

How DeployOpen scopes, implements and prepares ransomware evidence

DeployOpen helps organizations use the ransomware Community Profile as a working baseline: scoping the profile against their own environment, preparing the systems and evidence behind each outcome, and documenting the result. The organization owns its controls and its risk decisions, and only an independent auditor or assessor issues any report on them.

How we scope

We agree the systems, business units and backup platforms in scope before any work starts.
The written scope lists which profile outcomes are assessed, which are configured, and which the client owns.
Engagements are fixed-scope, with scope, deliverables and timelines confirmed in writing before work begins.
Quotes follow from the written scope, so the reader should expect pricing to depend on system count and backup complexity.

How we build

We deploy and harden self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks.
We configure unique accounts, least access, centralized logging and at least one offline backup copy, matched to the agreed scope.
We test backup restoration and verify integrity checks, so recovery claims in the playbook rest on tested steps rather than assumptions.

How we hand over

We document the ransomware countermeasure playbook against the client's objectives, risk appetite and resources.
Handover includes configuration records, backup test results and incident response roles, mapped to the profile outcomes in scope.
The client receives evidence packages organized for their own auditors, who decide what they accept and issue.

How we support

Ongoing support, upgrades, backup testing and continuous security testing are available as retainers after handover.
Retainers let the client rerun backup restoration tests and update the playbook as the environment and threats change.
Before engaging, confirm with DeployOpen which tasks sit in the fixed scope and which move to a retainer.

NIST CSF ransomware profile (IR 8374 Rev. 1)