Work through a security assessment

NIST CSF 2.0
assessment worksheet.

Start with a service you actually operate. What would show that a security outcome holds for that service, and what would leave the question open? The entries below give you questions, records to collect and checks to work through before making that decision.

106 starting points6 functions · 22 categoriesCognatory Editorial

The worksheet covers all 106 CSF 2.0 outcomes with example assessment prompts written by Cognatory. Adapt each prompt to the system and the work you are authorized to perform. A successful check on one sample does not establish that the outcome holds everywhere in the organization.

Download worksheet (CSV, 106 outcomes)

Choose the scope.Name the service, environment and owner. State the decision you need to make before deciding what to test.
Examine the evidence.Keep the relevant records with their dates and scope. Check what they demonstrate and what they cannot tell you.
Decide what follows.Assign an action and an owner to the unresolved problem. Specify what would show that the action worked.

Govern

Connect risk decisions to the organization’s purpose, dependencies and decision authority.

Organizational context GV.OC

GV.OC-01Security work should support what the organization is trying to accomplish.

Ask: If the organization lost its most important digital service, which part of its mission would stop?
Collect: A mission-to-service map showing the responsible owners and the cyber events that could interrupt each service.
Check: Pick a recent security investment or accepted risk and find the mission objective behind it. If the record only names a control or a score, ask what business result made that decision worthwhile.

Link to GV.OC-01

GV.OC-02Stakeholders may have different security needs, and those differences affect the work.

Ask: Whose security requirements could change the next service release?
Collect: A record of the internal and external groups affected, their stated needs, responsible contacts and unresolved disagreements.
Check: Compare the release decision with what those groups asked for. If their requirements conflict, find the decision that resolves the conflict and who accepted it. Leaving a requirement out of the release record does not resolve it.

Link to GV.OC-02

GV.OC-03Legal, regulatory and contractual requirements need an owner and an implementation.

Ask: Who decided that a selected security or privacy obligation applies, and where is it implemented?
Collect: An applicability register connecting each obligation to its interpretation, affected systems, owner and dated implementation records.
Check: Sample an obligation from each applicable source type and follow it into the system. Check who interpreted it and what would trigger another review. Refer an unresolved interpretation to qualified counsel instead of recording an unsupported compliance conclusion.

Link to GV.OC-03

GV.OC-04Customers and other external parties depend on specific functions continuing to work.

Ask: Which functions do external parties still need the organization to provide during a disruption?
Collect: A catalog of the services external parties rely on, with owners, dependency assumptions, impact thresholds and communicated commitments.
Check: Take one customer commitment and compare it with the recovery plan. If delivering it requires a dependency the plan cannot restore in time, the commitment and the operating plan need to be reconciled.

Link to GV.OC-04

GV.OC-05A critical operation can depend on more than the systems normally listed for it.

Ask: Which internal capability or outside service could stop this critical operation if it became unavailable?
Collect: A dependency map covering people, facilities, utilities, technology and providers, with an owner for each.
Check: Walk through the actual work and compare what it uses with the map. Include dependencies concentrated in one provider. Check that the owners know what the operation expects from them, rather than assuming a name on the diagram establishes that agreement.

Link to GV.OC-05

Risk management strategy GV.RM

GV.RM-01The risk program needs a result that its sponsors agree is worth pursuing.

Ask: What do the business and security sponsors expect the risk program to accomplish?
Collect: Approved objectives identifying the sponsors, business outcomes, measures and dates for decisions.
Check: Compare one stated objective with the work being funded. There should be an owner and a way to observe the intended result; otherwise, it will be difficult to tell whether completing the work achieved the objective.

Related guides
Governance and risk

Link to GV.RM-01

GV.RM-02Risk appetite and tolerance should make acceptance limits clear to the people using them.

Ask: When does a service owner’s exposure exceed the risk they are authorized to accept?
Collect: Current appetite and tolerance statements, delegated acceptance limits and records showing that the responsible people received them.
Check: Give the owners two plausible cases near an acceptance limit. If they reach different decisions, compare their interpretations of the statements. Resolve the ambiguity before depending on that limit in an actual approval.

Link to GV.RM-02

GV.RM-03Cyber risk needs to reach the people making financial and operational decisions.

Ask: How does a significant cyber scenario enter the organization’s wider risk-management process?
Collect: Linked cyber and enterprise risk records, including the escalation history and resulting management decisions.
Check: Follow a material scenario into a dated enterprise decision. Check that its business consequences and dependencies survived the handoff. A category or score may summarize the scenario while leaving out the information needed to decide what to do.

Related guides
Governance and risk

Link to GV.RM-03

GV.RM-04Owners need a strategy for deciding how to respond to risk.

Ask: What guidance supports reducing, avoiding, transferring or accepting the selected risk?
Collect: The communicated response strategy, its decision criteria and authority, and a recent record explaining the chosen response.
Check: Ask the owner why this response was selected and compare the explanation with the available alternatives. Where risk is transferred, check what responsibility remains with the organization.

Link to GV.RM-04

GV.RM-05A risk report has to reach someone who can act on it.

Ask: How would a supplier’s security concern reach the business owner authorized to make the decision?
Collect: A communication map with supplier and internal contacts, escalation triggers, decision authority and fallback routes.
Check: Walk through a hypothetical supplier alert without sending an emergency notice. Check each handoff and what happens when a contact is unavailable. Reaching a person is only useful if the information can continue to the required decision.

Link to GV.RM-05

GV.RM-06The assessment method should explain why one scenario receives a higher priority than another.

Ask: Would two reviewers using the documented method give the same scenario a comparable priority?
Collect: A rubric defining impact, likelihood, required evidence and uncertainty, with examples showing how those definitions are applied.
Check: Have the reviewers assess one scenario independently. Compare the assumptions behind their answers, not just the resulting scores. If the method permits different interpretations, revise it before treating the numbers as precise measurements.

Link to GV.RM-06

GV.RM-07A security change can make new work possible as well as reduce risk.

Ask: What useful business capability would the proposed security change make possible?
Collect: A proposal naming the capability, expected benefit, added exposure, assumptions and responsible sponsor.
Check: Compare the proposal with the current approach and an alternative. The sponsor needs to see both the opportunity and the risks of obtaining it before making the strategic decision.

Link to GV.RM-07

Roles, responsibilities and authority GV.RR

GV.RR-01Leadership is responsible for risk decisions and for how the organization handles concerns.

Ask: Which leader owns an unresolved material risk, and what decision have they made about it?
Collect: Leadership review records with named owners, decisions and follow-up actions, plus the route available for raising concerns.
Check: Follow an overdue material issue to the accountable leader. Check what happened when staff raised it and whether they received a response. A reporting procedure provides little assurance if concerns are suppressed in practice.

Link to GV.RR-01

GV.RR-02People assigned security work also need the authority to do it.

Ask: Who can decide whether to revoke access when the business and technical owners disagree?
Collect: A responsibility matrix defining normal, exception and emergency authority for the teams involved.
Check: Work through that disagreement with the business, security and platform owners. Compare the actual handoffs with the matrix. Find who can resolve the dispute if the teams reach the edge of their delegated authority.

Link to GV.RR-02

GV.RR-03Assigned responsibilities have to fit the available staff, skills and funding.

Ask: Can the team perform the security work required by the strategy with the capacity it actually has?
Collect: A capacity plan connecting recurring duties and improvement work to staff time, skills, tools and approved funding.
Check: Compare the required work with a representative operating period. If a duty cannot be covered, find who accepted the resource tradeoff. Assigning work to a team does not, by itself, give that team the capacity to complete it.

Link to GV.RR-03

GV.RR-04Hiring, role changes and departures all change security responsibilities.

Ask: When a privileged employee or contractor moves or leaves, who resolves their access and remaining duties?
Collect: Employment and contractor procedures for relevant screening, training and access changes, with completed joiner, mover and leaver records.
Check: Check a recent role change and departure against their effective dates. Follow credentials, devices and duties through transfer or removal, including work that would otherwise be left without an owner.

Link to GV.RR-04

Policy GV.PO

GV.PO-01A useful policy explains what the organization requires and how people should act.

Ask: Which operating requirement follows from a security priority specific to this organization?
Collect: An approved policy connecting business context to requirements, responsible owners, implementation standards and exception decisions.
Check: Follow a requirement from its rationale to the control implementing it. Ask affected staff how they follow it and where they obtain a decision when they cannot. Both answers matter when deciding whether the policy works in practice.

Link to GV.PO-01

GV.PO-02Policy needs to keep up with changes in the business and its technology.

Ask: Which policies were reviewed after the last material business or technology change?
Collect: A revision history recording the review trigger, changed requirements, approvals and communication to affected people.
Check: Compare the change with the review that followed. Then check whether the revised instructions reached the people and systems expected to use them. Updating the document does not automatically update the work.

Link to GV.PO-02

Oversight GV.OV

GV.OV-01The results of security work should inform the next decision about the strategy.

Ask: What did leadership decide about the strategy after reviewing the latest security outcomes?
Collect: A strategy review comparing intended and observed results, the assumptions behind them and the resulting decisions.
Check: Follow a completed initiative into the review of its results. Check whether the intended risk changed, as well as whether the work finished, and how that difference informed the decision to keep or revise the strategy.

Link to GV.OV-01

GV.OV-02A new material risk or requirement may require a change in strategy.

Ask: Where does the current strategy address the newest significant risk or requirement?
Collect: A review mapping material risks and requirements to planned responses or explicit management decisions.
Check: Choose a new service, obligation or dependency and find it in the review. If the strategy does not address the resulting risk, identify who can decide whether that omission is acceptable or the strategy must change.

Link to GV.OV-02

GV.OV-03Performance measures should help explain whether risk management is working.

Ask: Which measure would expose a failing security process even if its activity totals increased?
Collect: A performance review with defined measures, denominators, source records, trends and corrective decisions.
Check: Recalculate one measure from its source records. Check missing observations and adverse trends before accepting the total as an improvement, then find the decision the review produced.

Link to GV.OV-03

Supply chain risk GV.SC

GV.SC-01Supply chain work needs an agreed scope across the teams responsible for it.

Ask: Which suppliers and product dependencies have the participating teams agreed to include?
Collect: An approved program charter setting out objectives, policy, lifecycle coverage and participating functions.
Check: Compare the program with procurement, engineering and operations workflows. Look for a dependency each team assumes another team covers, and identify the owner of any decision that falls between them.

Link to GV.SC-01

GV.SC-02Customers and providers need to agree on who performs each security task.

Ask: Who acts on each side when an incident crosses the customer–provider boundary?
Collect: An agreed responsibility matrix with customer and provider duties, escalation contacts and decision authority.
Check: Use a scenario such as a compromised customer-managed cloud credential to compare both parties’ expectations. If each expects the other to take an action, resolve that gap before relying on the arrangement during an incident.

Link to GV.SC-02

GV.SC-03Supplier findings can change the organization’s overall exposure.

Ask: What enterprise risk decision would change because of a material supplier finding?
Collect: A finding linked to the affected service, enterprise risk record and resulting improvement work.
Check: Follow the finding through escalation and remediation. Check whether other suppliers depend on the same service or component. Assessing them separately can hide a common source of failure.

Link to GV.SC-03

GV.SC-04A supplier’s importance depends on what the organization would lose if it failed.

Ask: Which provider failure would cause the most serious disruption to a critical service?
Collect: A supplier register connecting criticality to service dependencies, access, sensitive data and available substitutes.
Check: Compare the high-priority suppliers with dependency and procurement records. Investigate a missing critical provider even if its contract is small; contract value does not establish the impact of losing the service.

Link to GV.SC-04

GV.SC-05The supplier agreement should cover the security behavior the service relies on.

Ask: Does the critical supplier’s agreement require the actions needed to address the service’s material risks?
Collect: The executed agreement and a matrix of relevant duties, incident notifications, evidence access and exit arrangements.
Check: Follow one significant risk into the agreed requirement and how it will be verified. If the connection is missing, take the gap to procurement and the responsible legal reviewers rather than assuming general contract language covers it.

Link to GV.SC-05

GV.SC-06Due diligence should affect the decision before the supplier relationship begins.

Ask: Which security finding could change the decision to enter the proposed supplier relationship?
Collect: A pre-contract assessment recording intended use, access, data flows, alternatives, findings and approval conditions.
Check: Compare the assessment and approval dates with the contract and access start dates. Check how unresolved findings affected the decision. A finding recorded after commitment cannot demonstrate that it informed the earlier approval.

Link to GV.SC-06

GV.SC-07Supplier risk can change after the initial assessment.

Ask: What event after onboarding would trigger another review of this supplier?
Collect: A current supplier risk record with findings, response owners, review dates and change or incident triggers.
Check: Choose a supplier whose ownership, service or access changed. Find the resulting assessment and corrective work, then check who takes responsibility when an action becomes overdue.

Link to GV.SC-07

GV.SC-08A response plan depends on the provider being able to perform its part.

Ask: Can the critical provider carry out the containment and restoration actions assigned to it?
Collect: Agreed incident duties and contacts, together with a response or recovery exercise record involving the supplier.
Check: Review a scenario that depends on the provider. Separate contacts, evidence exchanges and restoration duties that worked in the exercise from those still assumed to work because they were not exercised.

Link to GV.SC-08

GV.SC-09Supply chain checks need to continue as products enter use, change and retire.

Ask: Which safeguard is reviewed when this product moves from acquisition into operation?
Collect: A lifecycle record covering acquisition, integration, updates, support changes and retirement, with the checks required at each relevant stage.
Check: Follow the product through two lifecycle changes and compare completed checks and open exceptions with the requirements. Check how the observed results reach the organization’s wider risk-management process.

Link to GV.SC-09

GV.SC-10Ending a supplier relationship does not automatically remove its access or data.

Ask: What happens to access, retained data and dependencies when this relationship ends?
Collect: An exit plan and completion records covering credential revocation, data export and disposal, retention exceptions and replacement dependencies.
Check: Compare a completed or rehearsed exit with active identities, integrations and stored data. A deletion clause establishes an obligation; use the completion records to determine whether the agreed deletion happened.

Link to GV.SC-10

Identify

Find out what is running, what it depends on and where the risks or improvement opportunities are.

Asset management ID.AM

ID.AM-01The hardware inventory should account for the devices actually observed.

Ask: Can you find an owned inventory entry for a device selected from network or management records?
Collect: Hardware records with stable identifiers, owners, location or environment, management status and the latest observation time.
Check: Compare a sample from endpoint, cloud and network discovery with the inventory. Resolve duplicate, stale and unmanaged entries. Record where those discovery sources have no visibility, since an empty result there does not establish that no device exists.

Link to ID.AM-01

ID.AM-02Software records should describe what is running now.

Ask: Who owns a selected running application, and which version is deployed?
Collect: A software, service and system inventory linked to deployment records, package lists and SaaS administration records.
Check: Start with an active workload or SaaS service and find its entry. Check the owner, environment, release and support status against the actual service, including whether an unregistered service could be missing from the records altogether.

Link to ID.AM-02

ID.AM-03The flow model should describe the communications that have been authorized.

Ask: Does a connection observed across a trust boundary match an approved data flow?
Collect: A maintained model of sources, destinations, protocols, data types and trust boundaries, with the owners who approved each flow.
Check: Compare selected flow logs and deployed rules with the model. If a path is unexplained, determine whether the connection is unauthorized or the diagram is out of date. The diagram cannot settle that question on its own.

Link to ID.AM-03

ID.AM-04External services need to be connected to the work, access and data they support.

Ask: Which outside services receive data or access during the selected workflow?
Collect: A supplier-service register with each service’s owner, purpose, integrations, data handling and governing agreement.
Check: Compare procurement records with active integrations and administration consoles. Find services missing from the register and services now used in ways their original entries do not describe.

Link to ID.AM-04

ID.AM-05Asset priority should explain which protection and recovery work comes first.

Ask: Why does one of the sampled assets have a higher priority than the other?
Collect: An asset priority record connecting sensitivity, mission impact and dependencies to protection and recovery resources.
Check: Compare the assets in the context of the workflows they support. Check whether the assigned priorities explain the resulting decisions. If everything is labeled critical, ask how the organization decides what to protect or restore first.

Link to ID.AM-05

ID.AM-07The data inventory should account for copies and the information needed to interpret them.

Ask: Where is a selected sensitive dataset stored, processed and retained?
Collect: A data register with ownership, classification, provenance, systems, sharing, retention and relevant metadata for the designated data types.
Check: Follow the dataset through collection, processing, export and backup. Compare the observed locations and metadata with the register, including derived copies and data retained under an exception.

Link to ID.AM-07

ID.AM-08Moving an asset through its lifecycle changes the work needed to secure it.

Ask: When a system is retired, how do you account for its remaining access and data?
Collect: A lifecycle record connecting introduction, ownership changes, maintenance, support and retirement to the actions completed.
Check: Pick an asset that changed lifecycle stage and reconcile its access, data, support and inventory records. Identify backups or dependencies that legitimately remain, so they are not confused with retirement work that was never completed.

Link to ID.AM-08

Risk assessment ID.RA

ID.RA-01A reported vulnerability needs to apply to the component actually deployed.

Ask: Does the reported weakness affect this artifact under its current configuration and exposure conditions?
Collect: A finding identifying the asset, version, exposure conditions, validation results, responsible owner and current disposition.
Check: Compare the scanner result or advisory with the deployed component using a safe, authorized check. Record confirmed applicability, false positives and untested assumptions separately; the presence of a product name alone does not answer the question.

Link to ID.RA-01

ID.RA-02Threat reports need to be assessed against the organization’s own systems.

Ask: Which recent threat report could change a decision about a service the organization runs?
Collect: A source register and intake log preserving provenance, report age, relevance and the team responsible for reviewing it.
Check: Follow a report from a sharing group or other source to the reviewing owner. Check why it was considered relevant and whether the retained source information would allow that decision to be reconsidered.

Link to ID.RA-02

ID.RA-03Threat scenarios should explain how an unwanted event could occur.

Ask: How could an internal or external actor or event adversely affect a critical workflow at a material trust boundary?
Collect: A scenario register covering relevant external actors, insiders, accidents and environmental or dependency events, with their supporting conditions and evidence.
Check: Walk through the workflow and identify a concrete unwanted action at each significant boundary. Explain the conditions that make it plausible. Naming an actor without describing how the system could be affected leaves the scenario incomplete.

Link to ID.RA-03

ID.RA-04Risk estimates depend on the events assumed to happen and the consequences that follow.

Ask: What would have to happen for this threat to exploit the weakness, and which business activity would be affected?
Collect: A scenario assessment separating prerequisites, likelihood reasoning, consequences, observations and uncertainty.
Check: Compare the proposed sequence with the architecture and operating conditions. Challenge prerequisites that have no supporting evidence, and keep a plausible consequence separate from one the assessment actually demonstrated.

Link to ID.RA-04

ID.RA-05Inherent-risk comparisons need the same baseline for each scenario.

Ask: Which of two scenarios takes priority before either proposed response is credited?
Collect: A ranked scenario register combining threats, weaknesses, likelihood and impact, with a stated inherent-risk baseline.
Check: Assess both scenarios using the same method and baseline. Check for business consequences or uncertainty hidden by a score, and for safeguards credited before the comparison allows them.

Link to ID.RA-05

ID.RA-06A completed work item does not automatically mean the risk response worked.

Ask: What result would justify closing the selected risk response?
Collect: A response plan with priority, owner, due date, dependencies, acceptance conditions and the parties informed of the decision.
Check: Follow the decision into implementation and compare the actual result with the acceptance condition. Record the exposure that remains. Closing the ticket should follow that assessment rather than substitute for it.

Link to ID.RA-06

ID.RA-07A change or exception can introduce exposure the earlier decision did not cover.

Ask: What additional exposure did the approver accept for this change or exception?
Collect: A dated record of scope, risk rationale, safeguards, authority, review date and rollback or exit conditions.
Check: Compare the approval with the current configuration. Check whether the exception expired, its scope expanded or implementation happened before the required risk decision. Resolve those differences with the person authorized to accept them.

Link to ID.RA-07

ID.RA-08An external vulnerability report needs a route to acknowledgment, validation and resolution.

Ask: Can a reporter reach the responsible team and receive a tracked acknowledgment?
Collect: The public reporting route, triage procedure, case records and coordination arrangements for affected maintainers or users.
Check: Use a clearly synthetic, benign report to walk through intake and assignment. Check acknowledgment, confidentiality, validation ownership and escalation when a report remains unresolved. Keep the exercise identified as a test, not a discovered vulnerability.

Link to ID.RA-08

ID.RA-09Authenticity and integrity checks belong before acquisition and before use.

Ask: Which checks informed both the purchase decision and approval to use this hardware or software?
Collect: An acquisition record with supplier and provenance evidence, receipt or deployment checks and decisions about failed verification.
Check: Separate what was known before acquisition from what was checked before use. Reperform an applicable check on the received component. A matching signature, hash or device identity also needs a source the organization has reason to trust.

Link to ID.RA-09

ID.RA-10A critical supplier assessment should address the proposed use before the purchase.

Ask: What evidence supported acquiring this critical supplier’s service for the intended purpose?
Collect: A supplier assessment connected to the proposed service, access, dependencies, material findings and acquisition decision.
Check: Compare the assessment with the actual use case and purchase date. Find how material gaps were resolved before commitment. A general assurance report may describe the supplier well without answering whether this use is appropriate.

Link to ID.RA-10

Improvement ID.IM

ID.IM-01An assessment finding should lead to work that changes the underlying problem.

Ask: Which material finding from the last assessment produced an assigned improvement and a way to verify it?
Collect: An evaluation report linked to the cause, corrective action, priority, owner and completion evidence.
Check: Follow the finding into its action and retest criteria. If it reappears after closure, determine what remained unchanged and why the earlier verification did not reveal that.

Link to ID.IM-01

ID.IM-02An exercise should change the workflow when it reveals a problem.

Ask: What changed after an exercise exposed a failure between teams or with a supplier?
Collect: An exercise record with scope, participants, expected and observed behavior, limitations and corrective work.
Check: Compare the failure observed with the action taken. Check the affected partner’s participation where relevant, and distinguish the part exercised from conditions still assumed to work.

Link to ID.IM-02

ID.IM-03Routine operational problems can reveal security improvements that assessments miss.

Ask: Which recurring operational problem led to a revised security procedure or control?
Collect: An operational review linking incidents, support patterns, near misses or process deviations to specific changes.
Check: Follow a recurring problem into the change it prompted, then compare observations before and after. Account for workload and missing records before attributing an apparent improvement to the change.

Link to ID.IM-03

ID.IM-04Plans need to remain usable when the normal collaboration system stops working.

Ask: Can the responsible team retrieve and follow its current plan without its usual collaboration tools?
Collect: Versioned incident and operational security plans with owners, distribution records, fallback access, review triggers and exercise-driven revisions.
Check: Walk through the documented fallback route with an agreed scope. Follow the roles, dependencies and escalation steps, and record which parts worked. Keep conditions the walkthrough did not examine marked as untested.

Link to ID.IM-04

Protect

Check whether safeguards protect access, data and the service behavior the organization requires.

Identity and access PR.AA

PR.AA-01Identity management includes the credentials and access issued over the identity’s lifetime.

Ask: Can a person, workload or device be retired without leaving credentials that still work?
Collect: An identity register with owners and expiry rules, plus redacted provisioning and retirement records for each relevant identity type.
Check: Follow the selected identities from approval to removal and reconcile their credentials with the register. Check downstream access as well as the central account. Deleting that account does not demonstrate that every dependent credential stopped working.

Link to PR.AA-01

PR.AA-02Enrollment and recovery must assign credentials to the right identity.

Ask: What prevents a recovery request from giving a replacement credential to the wrong person?
Collect: Enrollment and recovery procedures defining identity checks, with a redacted completed recovery record.
Check: Follow the claimed identity through verification, approval and credential replacement. Check which evidence was independent, who authorized any exception and what happened to the original credential.

Link to PR.AA-02

PR.AA-03Authentication must work at every entry point that relies on an identity.

Ask: Will every entry point to this critical service reject an unknown, expired or revoked identity?
Collect: An authentication-flow diagram, human and workload authentication settings, and controlled successful and unsuccessful authentication results.
Check: Compare the actual human, service and device entry points with the diagram. Use approved test identities to check fallback and direct backend routes as well as the normal route. A successful check on one path says nothing about a path it did not exercise.

Link to PR.AA-03

PR.AA-04An identity assertion needs a protected path and checks at the application accepting it.

Ask: How does the application reject an assertion intended for a different recipient?
Collect: A redacted assertion, issuer trust settings and validation rules, with tests of audience, issuer, signature and expiration.
Check: Follow the assertion from issuer to application. Check recipient and signature validation, transmission protection and the protocol’s freshness or replay controls. Trusting the issuer does not remove those other requirements.

Link to PR.AA-04

PR.AA-05Permissions should enforce both least privilege and the required separation of duties.

Ask: Can the person initiating a consequential change approve it when the workflow requires someone else?
Collect: The permission matrix, assigned roles, latest access review and controlled authorization-test results for the workflow.
Check: Compare assigned permissions with the work they allow and the review supporting them. Check permitted and forbidden actions through the workflow and direct API paths, including attempts by an approved test identity to bypass the second approval.

Link to PR.AA-05

PR.AA-06Physical access should match the risks and ownership of the assets in the room.

Ask: Can a departed contractor’s badge or key still open the room containing a critical asset?
Collect: The room’s access policy, active badge and key register, departure record and a redacted sample of entry events.
Check: Compare approved occupants with active credentials and observed entries. Check revocation timing, visitor escorts and maintenance exceptions against the room’s risks, including who authorized each exception.

Link to PR.AA-06

Awareness and training PR.AT

PR.AT-01Awareness training should help people handle security risks in their everyday work.

Ask: Can an employee verify and report an unusual payment or access request and get a useful response?
Collect: The awareness material and reporting instructions available to staff, with an exercise record of reports and follow-up.
Check: Walk through an illustrative request with a willing participant. Observe whether they can use the verification route and what the receiving team does next. Training attendance alone does not show that this process works.

Link to PR.AT-01

PR.AT-02Specialized training should prepare people for the decisions their roles require.

Ask: Can the recovery operator restore a protected service when the normal key custodian is unavailable?
Collect: The role’s learning requirements, recovery runbook and supervised practice record covering the custodian’s absence.
Check: Compare the operator’s actions with their authority and the key-recovery requirements. If recovery stops, determine why. Missing skills may require training; missing approval, staff or a technical dependency requires action from the owner of that problem.

Link to PR.AT-02

Data security PR.DS

PR.DS-01Stored data needs protection against disclosure, alteration and loss of access.

Ask: What would protect this sensitive dataset if the storage administrator’s account were misused?
Collect: The data classification, storage and key permissions, integrity controls and an isolated recovery-test record.
Check: Identify the paths for reading, changing, deleting and recovering the data, and compare them with approved roles. Include key access and retention overrides. Check recovery separately; enabling encryption does not demonstrate that the data can be restored.

Link to PR.DS-01

PR.DS-02Data in transit needs protection across the complete delivery path.

Ask: What happens to a critical transfer when the destination cannot establish the expected identity?
Collect: A flow diagram, transport and trust settings, and a controlled test record of a transfer rejected after a failed trust check.
Check: Follow the transfer through its proxies and queues. Check destination authentication, confidentiality and integrity, then examine buffering and retries. The rejected connection still needs to be handled in a way that meets the required delivery behavior.

Link to PR.DS-02

PR.DS-10Data must remain protected while a workload is processing it.

Ask: Could one tenant’s job read or change another tenant’s working data?
Collect: A processing-boundary diagram, runtime permissions, temporary-file and diagnostic settings, and controlled isolation-test results.
Check: Follow working data through memory, temporary storage and diagnostics. Check cross-tenant access, cleanup after failure and resource limits. Isolating the data does not prevent one job from exhausting another job’s processing capacity.

Link to PR.DS-10

PR.DS-11Backups need protection and a recovery procedure that has actually been exercised.

Ask: Can the required data be restored when both the primary copy and normal backup credentials are unavailable?
Collect: Backup and retention schedules, normal and alternate access procedures, failure alerts and an isolated restore record identifying the credentials used.
Check: Compare required datasets with completed backups and their protection against change or deletion. In an approved isolated exercise, withhold normal backup credentials and use the documented alternative. Compare the restored age, usable contents and elapsed time with recovery needs; if credential loss was not exercised, record it as untested.

Link to PR.DS-11

Platform security PR.PS

PR.PS-01Configuration management should explain differences between approved and deployed settings.

Ask: Why does this production setting differ from its approved baseline?
Collect: A versioned baseline, deployed snapshot and drift report linked to the relevant change or exception.
Check: Compare the intended and actual values for a security-relevant setting. Determine whether the difference is authorized, temporarily excepted or unresolved. Check that the next deployment preserves the decision instead of silently reversing it.

Link to PR.PS-01

PR.PS-02Software maintenance needs a plan for the end of vendor support.

Ask: What will happen to this critical application when its vendor stops issuing security updates?
Collect: The inventory entry, support dates and patch history, with an approved replacement plan or time-limited exception.
Check: Confirm the deployed version and the service depending on it. Check exposure, interim restrictions, owner and decision date in the plan. Repeatedly reporting that the software is unsupported does not resolve the dependency.

Link to PR.PS-02

PR.PS-03Hardware maintenance needs to account for condition, support and eventual replacement.

Ask: Can this critical device be replaced before missing support or spare parts makes continued operation unsafe?
Collect: Inventory, condition, maintenance and support records, replacement dependencies and procedures for stored data at retirement.
Check: Compare the device’s condition and support with the work it performs. Check replacement lead time and who owns deferred work. For retired devices, follow credential removal and the required treatment of storage to completion.

Link to PR.PS-03

PR.PS-04Logging has to deliver usable events to the systems that need them.

Ask: Does the monitoring platform receive enough information to explain a selected administrative change?
Collect: An audit-event specification, source and collection settings, and matching source and destination records for a harmless test change.
Check: Compare actor, object, action, result and time in the two records. Measure delivery delay and check how collection failure becomes visible. A logging setting can be enabled while the event still fails to arrive.

Link to PR.PS-04

PR.PS-05Software controls should enforce what may be installed and run.

Ask: Will a managed endpoint stop a standard user from running a benign executable the policy does not approve?
Collect: The application-control policy, deployment coverage, approved exceptions and an authorized benign-sample test record.
Check: On a representative test device, compare permitted, denied and exception behavior with enforcement active. Include relevant scripts and user-writable paths, and check whether the resulting decision produces an event someone can review.

Link to PR.PS-05

PR.PS-06Secure development work should continue through release, maintenance and retirement.

Ask: Can you trace a selected release decision back to its security requirements and forward into maintenance?
Collect: The release’s threat review, acceptance criteria, review and test results, dependency findings and exceptions, with applicable maintenance or retirement decisions.
Check: Follow a material risk from design through release and the later stages available in the sample. Check how failures and exceptions were resolved and whether recurring findings changed the development process. State which lifecycle stages the sample did not cover.

Link to PR.PS-06

Infrastructure resilience PR.IR

PR.IR-01Network and environment boundaries should enforce the permitted communication paths.

Ask: Can a lower-trust workload reach a production administration interface it should not access?
Collect: The approved flow matrix, deployed routes and network policies, administrative entry points and controlled connectivity results.
Check: Compare the approved path with deployed routes and policies, then test a permitted and an explicitly denied source within the authorized scope. Include relevant return traffic and alternate paths. Record any path left untested before drawing a wider conclusion.

Link to PR.IR-01

PR.IR-02Environmental safeguards protect the equipment that services depend on.

Ask: If cooling fails, what prevents damage to the equipment running the critical service?
Collect: An environmental dependency assessment, sensor thresholds, shutdown procedure, maintenance records and the latest safe exercise report.
Check: Connect the cooling dependency to affected assets and check detection, response time and shutdown authority. If a provider operates the facility, assess the evidence it supplies. The dependency remains even though the organization does not run the cooling equipment.

Link to PR.IR-02

PR.IR-03Resilience should preserve the service behavior the organization needs.

Ask: Can the critical service meet its agreed minimum operating requirements after a dependency fails?
Collect: The dependency map, resilience requirements, failover or degraded-operation design and a controlled dependency-failure exercise.
Check: Compare observed business transactions with the minimum requirements. Follow failover, degraded operation and the return to normal. Check for shared dependencies that could cause separate replicas to fail together.

Link to PR.IR-03

PR.IR-04Service capacity is limited by its dependencies as well as the application itself.

Ask: When demand rises beyond the expected peak, which resource limits the service first?
Collect: A capacity model with quotas, queue limits and scaling rules, supported by a controlled load-test record.
Check: Compare tested demand with the planning assumption and inspect downstream limits, including the database and identity provider. Determine whether overload causes controlled rejection, growing delays or failure. Application capacity alone does not answer that question.

Link to PR.IR-04

Detect

Use the observations to decide what needs investigation, keeping gaps in monitoring visible.

Continuous monitoring DE.CM

DE.CM-01Network monitoring should make activity worth investigating visible to the team.

Ask: Would the monitoring team see an unexpected connection from a restricted segment?
Collect: A coverage map, flow or DNS collection settings, detection logic and the record of an authorized synthetic event.
Check: Generate an approved connection or replay suitable test telemetry and follow it to the analyst’s view. Record encrypted, uninstrumented or dropped traffic the test cannot show. Successful delivery of one event does not establish coverage of those missing areas.

Link to DE.CM-01

DE.CM-02Physical monitoring needs a working path from the sensor to the responder.

Ask: Would an after-hours entry into a restricted room reach someone responsible for assessing it?
Collect: The monitoring rule, sensor-health records, notification route and a supervised alarm-test report for the room.
Check: Check the received alert’s time, room and authorized-entry context. Examine what happens when a sensor fails or the responder is unavailable, and compare documented coverage with the critical areas actually monitored.

Link to DE.CM-02

DE.CM-03Personnel monitoring should collect what the approved investigation purpose requires.

Ask: Can an investigator assess unusual bulk access without collecting unrelated employee activity?
Collect: The monitoring purpose and scope, access-event fields, detection rule, retention settings and analyst permissions.
Check: Use synthetic activity to inspect what is recorded and what the investigator receives. Compare collection, analyst access and retention with the approved purpose. Check how legitimate bulk work is distinguished from activity still needing an explanation.

Link to DE.CM-03

DE.CM-06Provider activity needs enough context to distinguish authorized work from unexpected access.

Ask: Can an unexpected privileged provider action be distinguished from an approved support session?
Collect: The provider-access agreement, administrative audit feed, approved session records and a representative alert or test event.
Check: Connect the action to its account, resource and approval window. Check feed delay and coverage, then identify activity visible only to the provider or requiring a separate evidence request.

Link to DE.CM-06

DE.CM-09Monitoring should cover the workloads and data actually deployed.

Ask: Would an unexpected change to a deployed executable or sensitive dataset be detected?
Collect: A workload monitoring inventory, integrity or runtime rules, sensor-health records and controlled-change results.
Check: Follow an approved change through host or runtime telemetry to an alert. Compare sensor coverage with deployed workloads, including short-lived instances. Record data changes the selected sensor cannot observe instead of treating the inventory as proof of complete coverage.

Link to DE.CM-09

Adverse event analysis DE.AE

DE.AE-02Event analysis needs to explain the observation in context.

Ask: What would distinguish this suspicious administrative login from legitimate maintenance?
Collect: A redacted investigation record connecting the alert to user and device context, the change schedule and the analyst’s reasoning.
Check: Follow the conclusion back to its observations and consider the other explanation. Check contradictory evidence and missing telemetry. An event cannot be ruled out merely because the records needed to observe it are absent.

Link to DE.AE-02

DE.AE-03Records should be correlated using evidence that they belong to the same activity.

Ask: Can the identity event be reliably connected to the network and application actions that followed?
Collect: The correlation rule or query, source-field mappings, clock settings and a timeline retaining the contributing records.
Check: Reconstruct the sequence using stable identifiers and account for aliases. Check reused addresses and clock offsets before connecting events. Similar timestamps can suggest a relationship without establishing that the records describe the same activity.

Link to DE.AE-03

DE.AE-04Impact estimates need to distinguish observed effects from possibilities and unknowns.

Ask: Which services and data could be affected, and which have not been examined?
Collect: An initial impact assessment with affected assets, dependency records, supporting queries and stated information gaps.
Check: Compare each impact statement with its supporting evidence, including downstream dependencies and data sensitivity. Keep demonstrated effects, plausible effects and insufficient visibility separate so the next decision does not depend on an unstated assumption.

Link to DE.AE-04

DE.AE-06A detection needs to reach an available responder with access to the relevant evidence.

Ask: Does a high-priority detection reach someone who can open the evidence needed for the first decision?
Collect: Notification rules, on-call assignments, evidence permissions and a test delivery with acknowledgment times.
Check: Follow a synthetic event through the integrations and paging route. Check authorized and unauthorized access to its evidence, then exercise the fallback for an unacknowledged notification.

Link to DE.AE-06

DE.AE-07Threat intelligence is useful when its assumptions fit the service being investigated.

Ask: How would a relevant new threat report change the investigation of this exposed service?
Collect: The dated report and confidence assessment, service inventory entry and resulting investigation hypothesis or query.
Check: Compare the report’s technology and exposure assumptions with the actual service. Consider its age, reliability and local observations together. An indicator match warrants investigation; it does not, on its own, establish an incident.

Link to DE.AE-07

DE.AE-08Incident declaration should apply agreed criteria to the information available.

Ask: What would move a suspected account takeover from an alert to a declared incident?
Collect: Declaration criteria, assigned decision authority and a redacted case or tabletop record explaining the decision.
Check: Apply the criteria to what was known when the decision was made. Check who had authority, how uncertainty affected the choice and what new information would justify reconsidering it.

Link to DE.AE-08

Respond

Coordinate the people and actions needed to assess, contain and resolve an incident.

Incident management RS.MA

RS.MA-01A declared incident requires coordinated action inside the organization and across provider boundaries.

Ask: Who coordinates the first containment decision when both the organization and its hosting provider are involved?
Collect: The activated response plan, assigned roles, provider contacts and a case or joint-exercise timeline.
Check: Follow declaration into role assignment and the first coordinated action. Compare duties and access limits on both sides, and check that the internal lead retains the decisions made across the provider boundary.

Link to RS.MA-01

RS.MA-02Triage should establish what a report supports before deciding how to handle it.

Ask: How would the team assess a data-exposure report supported only by a screenshot?
Collect: The intake record, triage and preservation procedures, and analyst notes identifying corroboration and unresolved questions.
Check: Follow acknowledgment, preservation and validation to escalation or closure. The disposition should be explained. Keep an unverified report trackable without presenting its contents as an event the team has confirmed.

Link to RS.MA-02

RS.MA-03Incident priority should reflect business, safety and data consequences.

Ask: Would a small outage in a safety-critical process receive a different priority from a larger noncritical outage?
Collect: The classification matrix, service-criticality definitions and two case or exercise records explaining the assigned priorities.
Check: Compare the decisions with the consequences and operating context of each event. Check whether the matrix supports that distinction and whether new evidence can change the priority without losing the earlier decision history.

Link to RS.MA-03

RS.MA-04Escalation should provide the authority and resources the first responder lacks.

Ask: Who can authorize an on-call responder to suspend a critical service if the primary decision-maker is unavailable?
Collect: An escalation matrix with delegated limits and backup contacts, plus a timed exercise of the decision route.
Check: Follow the request to someone with sufficient authority and compare elapsed time and fallback behavior with the plan. Record the decision and its operational consequences. Reaching a contact does not establish that the required decision was made.

Related guides
Incident response Governance and risk

Link to RS.MA-04

RS.MA-05Recovery can begin only within the scope authorized for the unresolved incident conditions.

Ask: What evidence would allow restoration to begin while the investigation remains open?
Collect: Recovery-entry criteria, containment status, unresolved questions and the recorded authority to start restoration.
Check: Compare the authorization with the service’s entry criteria. Check how remaining access, unsafe dependencies and evidence preservation limit the permitted work, and identify who accepts the risk that remains.

Link to RS.MA-05

Incident analysis RS.AN

RS.AN-03An incident explanation should connect what happened with the conditions that allowed it.

Ask: Can another analyst reconstruct the sequence from initial access to the observed consequences?
Collect: A timeline with source references, alternative explanations and a causal analysis recording confidence and unresolved questions.
Check: Reconstruct part of the sequence from the cited records. Separate the entry mechanism from the control or process conditions that allowed it. Identify any proposed cause still relying on an assumption the records do not support.

Link to RS.AN-03

RS.AN-06Investigation records should show who acted, what changed and why.

Ask: Can a reviewer identify the investigator who changed the system and the authority for that action?
Collect: An action log, case-access history, common time reference, approvals and protection against unrecorded changes to the records.
Check: Follow one action from approval through execution to its observed result. Check actor, time, target and rationale, including whether corrections and exports preserve the original entry and revision history.

Link to RS.AN-06

RS.AN-07Evidence needs a traceable origin and handling history as well as intact contents.

Ask: Can a collected file be traced to its source and collection method without relying on the collector’s memory?
Collect: An evidence manifest with collection notes, source and time metadata, transfers and integrity-check results.
Check: Follow an artifact through collection, storage and transfer, recomputing its recorded hash where appropriate. Assess the source separately. Matching bytes do not establish that the system they came from was trustworthy.

Link to RS.AN-07

RS.AN-08The estimated size of an incident should change when the evidence changes.

Ask: How was the current count of affected accounts, records or operations calculated?
Collect: The impact estimate, calculation method, source queries, deduplication rules, coverage gaps and revision history.
Check: Reproduce a defined part of the calculation and check time limits and double counting. Separate possible exposure from confirmed access, then examine how new evidence changes the estimate or the range being reported.

Link to RS.AN-08

Response communication RS.CO

RS.CO-02Incident notifications depend on the facts, the affected parties and the authority to communicate.

Ask: Who needs the first incident notification, and who can authorize it?
Collect: A stakeholder and notification matrix, approved contact routes, the relevant decision record and a case or exercise delivery log.
Check: Compare known facts with the notification triggers and involve the responsible legal or contractual owner where needed. Check approval, recipients, timing and delivery. A message template cannot decide which obligations apply.

Link to RS.CO-02

RS.CO-03Shared evidence should give authorized recipients what they need for the agreed action.

Ask: Can a provider receive the evidence needed for containment without unrelated customer information?
Collect: The sharing procedure, approved recipients, redacted evidence package and secure-transfer record.
Check: Compare the package with the recipient’s role and authority. Check minimization and handling restrictions without removing the integrity or context needed to use the evidence. Redaction that makes the package unusable also needs to be addressed.

Link to RS.CO-03

Incident mitigation RS.MI

RS.MI-01Containment should stop the access paths that can keep the incident active.

Ask: After a compromised account is disabled, do its active sessions and unattended jobs stop as intended?
Collect: The containment decision, account and token inventory, action times and subsequent access-test results.
Check: Compare the intended containment with observed behavior within the authorized response scope. Include sessions, delegated credentials and queued work. Record service disruption and any access intentionally left available.

Link to RS.MI-01

RS.MI-02Eradication should remove the identified means of continued malicious access or activity.

Ask: How would the team detect an identified persistence mechanism that survived the rebuild?
Collect: An eradication plan linked to persistence findings, rebuild provenance, credential replacement and scoped validation results.
Check: Connect each identified foothold to its removal or replacement and a check of the result. Revisit the entry condition and dependent credentials, not just the rebuilt host, and retain the parts of the investigation still unresolved.

Link to RS.MI-02

Recover

Verify that restored services work under the conditions agreed for their return.

Recovery execution RC.RP

RC.RP-01Recovery work should stay within the authority and scope established during response.

Ask: Does the handoff explicitly tell the recovery team what work it may begin?
Collect: The activation decision, response-to-recovery handoff, assigned runbook and completed-step records.
Check: Compare the first actions with the authorization, service priorities and containment restrictions. Check that the recovery lead understands unresolved incident conditions that could limit those actions.

Link to RC.RP-01

RC.RP-02Recovery order should follow service priorities and the dependencies needed to restore them.

Ask: Why should the selected service be restored before another affected service?
Collect: A recovery action plan with business priorities, dependencies, owners, estimated effort and completion records.
Check: Connect the restoration order to the transactions that must resume. Check that identity, network, key and supplier dependencies are available before dependent steps, and retain the reasoning when changing conditions alter the order.

Link to RC.RP-02

RC.RP-03A backup needs to be suitable for restoration, as well as intact.

Ask: What supports the decision that this backup predates the compromise and can be used for restoration?
Collect: The backup manifest, integrity checks, incident timeline, image or package provenance and an isolated inspection of restored contents.
Check: Compare the capture time and origin with the known incident window. Inspect the isolated restore for the concerns identified in the investigation. A matching checksum does not establish that the system was uncompromised when it was backed up.

Link to RC.RP-03

RC.RP-04Resuming a service before every issue is resolved may require temporary restrictions.

Ask: Which restrictions would apply if the service resumed with incident issues still open?
Collect: An approved interim operating plan with residual-risk decisions, minimum service requirements and review or expiry dates.
Check: Compare the proposed service level with critical needs and remaining risks. Check authority, compensating measures and the conditions for changing or ending the arrangement. A temporary decision needs a route out of it.

Link to RC.RP-04

RC.RP-05Restoration should produce a usable service with the intended controls working.

Ask: Can a representative user complete the required transaction on the restored service with its security controls active?
Collect: A validation plan, restored configuration and integrity results, end-to-end transaction records and the service owner’s acceptance.
Check: Compare configuration and data with the approved recovery state, then exercise the agreed transaction across its dependencies. Include access and monitoring checks. A running host or healthy process does not demonstrate that the business service works.

Link to RC.RP-05

RC.RP-06Closing recovery requires completion criteria and a decision about unfinished work.

Ask: What conditions must be met before the recovery lead declares the phase complete?
Collect: Exit criteria, service acceptance records, remaining actions and an approved closure record linked to the incident documentation.
Check: Connect each criterion to evidence and assign an owner and disposition to unfinished work. Account for temporary access and changes, and record accepted limitations explicitly in the closure decision.

Link to RC.RP-06

Recovery communication RC.CO

RC.CO-03Recovery updates should explain what is usable now and what is still being restored.

Ask: Can a customer or business owner tell which functions work and which remain unavailable?
Collect: The communication plan, recipients, service-status definitions and timestamped updates linked to recovery milestones.
Check: Compare updates with the execution log and service tests. Check stated capabilities, restrictions and the next update time. Keep estimated restoration separate from recovery already confirmed by the tests.

Link to RC.CO-03

RC.CO-04Public updates need an approval process and a publishing route that works during the incident.

Ask: How would the organization publish an accurate update if its normal website or identity service were unavailable?
Collect: The approval workflow, alternate publishing procedure, reviewed message and rehearsal record.
Check: Follow a draft through fact checking, approval and publication to the designated channel. Check fallback access, consistency with internal status and how the organization would correct a public statement when new evidence changes it.

Link to RC.CO-04

Source and use

The 106 outcome identifiers come from Appendix A of The NIST Cybersecurity Framework (CSF) 2.0, published February 26, 2024. Cognatory provides the summaries, assessment prompts and guide links. Read the publication for the complete outcome wording and the wider framework context.

Use the worksheet to investigate a particular question. It does not calculate a maturity score, establish compliance or confer certification. Linking a guide to an outcome does not demonstrate its implementation or imply NIST endorsement.

Record what you observed, what you assumed and what remains unknown. Include the scope, date and owner. Another reviewer should be able to follow the result and determine what further check would resolve the remaining question.

Browse all 35 security guides · Discuss an assessment