ID.IM-01 Improvements from evaluations: evidence and audit

What ID.IM-01 improvements from evaluations asks for

A customer, regulator or leadership team that asks for proof of learning from assessments is really asking whether findings lead to changes. ID.IM-01 is the CSF 2.0 Subcategory that states this expectation. It sits in the Improvement (ID.IM) Category of the Identify Function, and its outcome is that improvements are identified from evaluations. NIST added it in CSF 2.0, so its topic was not clearly present in any Category or Subcategory of CSF 1.1. Organizations that already ran assessments under 1.1 will find that the evidence they hold was never framed as an improvement loop, which is the gap an assessor is likely to probe.

The risk this Subcategory addresses is familiar: findings are measured, written down and then never acted on. A penetration report, an internal audit, a self-assessment or a control check can all identify weaknesses, yet the program keeps running as before. Over time the organization holds a growing stack of reports that show it knew about problems, which is worse evidence than having none. The leadership team also loses the ability to judge whether its security spending is working, because the signals that should adjust direction never reach a decision.

This tends to happen for three reasons. No single owner holds the full list of evaluation findings, so each team tracks its own. Reports arrive in different formats with different severity scales, which makes them hard to compare or roll up. And findings often have no link to a tracked fix, with a named owner, a due date and a closure check. Before any evaluation is scheduled, confirm who owns the consolidated findings register, how each finding is linked to a remediation item, and how the program reports open items to leadership. Those answers form the core of the evidence an assessor will ask to see.

Which evaluations and systems fall under ID.IM-01 scope

ID.IM-01 is only as useful as the boundary drawn around it. The decisions below determine which services get self-assessed, which independent assessments count, which automated checks run, and which supplier evaluations feed the improvement cycle. Write each decision down before work starts, because NIST's Implementation Examples leave the choice of critical services, threats and requirements to the organization.

Critical services chosen for self-assessment

NIST's first Implementation Example asks organizations to self-assess critical services while considering current threats. The scope decision is which services qualify as critical and which threats the assessment must reflect. A narrow list keeps the cycle manageable but can leave customer-facing or revenue-generating paths untested. Record the service list, its owner, and the threat sources used, so an assessor can see why each service was included or left out.

Third-party assessments that count

The second Implementation Example covers investing in third-party assessments or independent audits of program effectiveness. Scope must state which external reviews feed improvement actions: a penetration test, an ISO 27001 surveillance audit, a SOC 2 report, or a readiness review. Findings from a review that is not written into scope are easy to lose. Confirm with each assessor which findings they issue, and that independent reports, not readiness work, are the evidence of an external view.

Automated checks and the systems they cover

The third Implementation Example describes continuous automated evaluation of compliance with selected requirements. Scope defines which requirements are checked automatically and on which endpoints, cloud accounts and clusters the checks run. A check that covers only servers misses laptops and cloud identities. List each check, its target population, and how failing results reach an owner. Tools such as Wazuh and Fleet can run such checks, but confirm their coverage against your own asset inventory.

Configuration baselines behind the checks

Automated checks are only as broad as the baseline they test. Wazuh's Security Configuration Assessment uses YAML policies, mostly based on CIS benchmarks and extendable with custom policies, to check files, directories, registry keys and running processes. Decide whether the organization uses vendor benchmarks, internal hardening standards, or both. Each custom policy adds maintenance, so the scope should name who approves changes to the baseline and how exceptions are recorded.

Device policies as yes or no questions

Fleet policies ask each device a yes or no question written as an osquery query, and the policies page shows which devices pass or fail. Scope decides which device groups receive each policy, such as encryption, disk state, or endpoint agent presence, and whether failing devices are reported, quarantined, or ticketed. Assign a named owner to each failing policy so that results lead to a documented improvement rather than a dashboard nobody reviews.

Supplier evaluations that feed the program

Evaluations of suppliers, such as their assessment reports, certificates or contractual test results, can reveal gaps in the organization's own program. Scope must decide which suppliers are reviewed, which documents they provide, and which findings are routed into ID.IM-01 rather than handled only in procurement. Consider suppliers that host critical services or hold regulated data first. Confirm contract rights to receive assessment results before the review cycle depends on them.

How an assessor tests ID.IM-01

This table compares the three evaluation sources behind ID.IM-01 (self-assessments, independent assessments and automated checks), showing how an assessor tests each one, what evidence they usually ask for and where programs commonly fall short. Read each row as a test question you should be able to answer before an assessment begins. Confirm the exact expectations with your own assessor, since assessors differ in how they sample and document their work.

Evaluation source	How the assessor tests it	Evidence requested	Common findings
Self-assessment of critical services	Reviews whether the scope names the critical services and whether the assessment considers current threats, not only the control list from last cycle.	Scope statement, list of critical services, assessment method, threat inputs used, dated results and sign-off by an accountable owner.	Critical services are missing from scope, or threat sources are not recorded, so the assessment cannot show it looked at current risk.
Independent assessments or audits	Confirms that the assessment was commissioned by the organization, reviews the terms and scope, then traces each finding to an action in the improvement register.	Engagement letter or scope, the final report from the independent assessor, remediation plan, owner assignments and closure records.	Findings have no named owner, or the plan is accepted but nothing shows the work or its verification was completed.
Automated compliance checks	Samples check results across endpoints or systems, then compares failing results with tickets and confirms that the rule set still matches the selected requirements.	Policy or rule definitions, pass and fail results with dates, sampled remediation tickets and records of rule changes or exceptions.	Failing checks are closed without a documented fix, or the rules have not been reviewed since the requirements they test changed.
Coverage of evaluations	Compares the list of critical services and systems against what evaluations actually covered during the period under review.	Asset or service inventory, evaluation calendar, coverage map linking each critical service to at least one evaluation.	Evaluations never reach the critical services, often because they cover only systems that are easy to test.
Closure and verification	Selects closed improvement items and asks how the organization confirmed the change worked before marking it complete.	Closure records with verifying evidence such as retest results, configuration exports or a re-run of the check.	Items are closed on a promise to fix, with no retest, so the same gap reappears at the next evaluation.
Ownership and tracking	Checks that each improvement from any evaluation source has an owner, a status and a link back to the evaluation that raised it.	Improvement register or ticket export showing source, owner, status history and due dates set by the organization.	Findings exist only in reports or email threads, with no register that management reviews.

Evidence that satisfies ID.IM-01 and how to keep it current

ID.IM-01 is met when an organization can show that findings from evaluations led to recorded improvements. The cards below describe the artifacts an assessor will ask for, how often each one should be refreshed between audits, and who in the organization signs it off. The organization owns all of this evidence, and only an independent auditor or assessor issues a report.

Dated self-assessment record per critical service

For each critical service, keep a dated self-assessment that considers current threats, lists the gaps found, and names an owner for each gap. NIST's Implementation Examples for ID.IM-01 point to self-assessments of critical services that account for current threats, so the record should show which threat sources were reviewed and when. Check that every critical service has a current record, that the threat inputs are named, and that the service owner and the security lead have both signed. Refresh cadence is set by the organization's own policy, so confirm the interval with your risk owner and record it in the policy.

Independent audit report and tracked findings

An independent audit or third-party assessment tests whether the program is effective, and ID.IM-01 expects the organization to act on what it finds. Keep the issued report from the independent assessor, then log each finding with a severity, an owner, a target date and a closure decision. DeployOpen can help prepare systems and documentation for an assessment, but the report itself comes only from the independent auditor. Confirm the report's scope, date and period covered before using it as evidence.

Automated compliance check outputs with exception approvals

Continuous automated checks, such as configuration assessments or endpoint policy queries, produce recurring output that shows whether selected requirements still hold. Export the results on a schedule and keep them with the policy version used. Every failing check that is accepted rather than fixed needs a signed exception with an expiry date and a named approver. Wazuh's Security Configuration Assessment and Fleet's policies page are examples of tools that produce pass and fail results that can be exported, but confirm the export format and retention in your own environment.

Improvement tickets linked to closure records

Each finding from an evaluation should become a tracked improvement with a unique identifier that links the source, the corrective action and the closure record. Assessors look for the chain from finding to fix to verification, so a ticket closed without a verification step is weak evidence. Review open tickets at a set governance meeting, and record who approved closure and the evidence used to verify it. Retention periods should follow the organization's records policy and any contractual or regulatory rules that apply.

Management review minutes on improvement status

Leadership reviews of improvement status show that the results of evaluations reach people who can fund and prioritize fixes. Minutes should list the open findings by age, the exceptions approved, and any decisions to accept residual risk. Attendance and the named decision makers matter, because an assessor will check that the reviewer had authority over the risk. Confirm the review frequency in your governance charter and keep the signed minutes with the improvement register.

Implementing ID.IM-01 step by step

This sequence turns the ID.IM-01 outcome, identifying improvements from evaluations, into a repeatable loop: sources feed one register, each finding gets an owner, and closed items are verified and reported to leadership.

Define critical services and evaluation sources
Start by naming the services whose failure would matter most, using the organization's own business impact view. Then list every evaluation source that can produce findings for those services: self-assessments, third-party assessments or independent audits, automated compliance checks, and the tests and operational reviews covered by the sibling subcategories. The output is a scoped inventory that states, for each service, which sources apply and who owns that source. Confirm the list with the business owners before moving on, because later steps depend on it.
Set self-assessment cadence and scope
Agree how often self-assessments run for each critical service and what each one covers. NIST's Implementation Examples for ID.IM-01 expect self-assessments of critical services that consider current threats, so the scope should reflect the threat picture the organization is tracking today, not last year's. Record the cadence, the scope and the assessor for each service in a written schedule approved by the accountable executive. The output is an approved assessment calendar that the next steps can be measured against.
Connect automated checks to a findings register
Route output from automated compliance checks into one findings register instead of separate dashboards. For example, a configuration assessment tool can report failing checks on monitored endpoints, and a device policy engine can report which devices fail each yes or no policy. Each finding should carry the service, the source, the control reference and the date first seen. Test the feed by confirming that a deliberately failing check appears in the register. The output is a register that receives every evaluation source defined in step one.
Record and triage manual evaluation findings
Enter findings from self-assessments, third-party assessments and independent audits into the same register, using the same fields as automated findings. Triage each one by its effect on the critical service and by the risk the organization has accepted or rejected in its risk management strategy. Mark duplicates and findings that another source already covers. The output is a triaged register in which every entry has a severity decision and a status, so no finding is left without a disposition.
Assign owners and target dates for improvements
For each accepted finding, name one accountable owner who can change the system, process or policy involved, and set a target date agreed with that owner. Where a finding is accepted as residual risk, record the approver and the review date instead. Improvements that need funding or a supplier change should link to the decision record that authorizes them. The output is a register in which each open improvement has an owner, a due date or documented risk acceptance, and a link to its work item.
Verify closure with evidence
Close a finding only when someone other than the owner has checked the change. Re-run the automated check that raised it, repeat the relevant self-assessment question, or review the audit or assessor evidence. Keep the before and after results attached to the register entry. Reopen any item whose check still fails. The output is a closure record for each finding that cites the verification evidence, which is what an assessor will ask to see when testing ID.IM-01.
Report trends to leadership
Summarize the register for leadership on a regular schedule agreed with governance: open and closed findings by critical service, overdue items, recurring findings and accepted risks. Trends show whether the evaluation program is finding problems early or only after incidents. Use the same figures in board and risk committee material so that the governance record matches the register. The output is a dated leadership report, with decisions and changes to scope or cadence recorded, that feeds back into step two.

Which open-source tools produce ID.IM-01 evidence

ID.IM-01 is satisfied by a record of how evaluation findings became improvements, not by the scan or assessment alone. The three tools below each produce a different layer of that record: assessment findings, configuration check results and device compliance states. Confirm current capabilities and license terms with each project before you design around them.

CISO Assistant for assessment records

CISO Assistant (AGPL-3.0-only) ships NIST CSF among more than 200 frameworks and runs audits and compliance assessments against them, with automatic mapping between frameworks. It can hold the assessment record for ID.IM-01: the evaluation scope, the findings, and the improvement actions raised from them. An assessor will ask whether each finding links to an owner and a dated action, so check that the tool captures those fields. The AGPL-3.0-only license matters if you modify the software and make it available to users over a network, so have counsel review the obligations before you customize it.

Wazuh configuration assessment results

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints for misconfigurations using YAML policies. Most policies are based on CIS benchmarks, and you can extend them with custom policies that check files, directories, registry keys and running processes. Each failed check comes with a remediation recommendation, which gives you a dated list of findings to route into an improvement action. Confirm which policies ship for your operating systems and whether scan history is retained long enough for your review cycle. The GPL-2.0-only license governs distribution of modified code, so record which changes you make to policies and the software.

Fleet policy pass and fail records

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries. The policies page shows which devices on each fleet pass or fail each policy, which gives a current compliance state per device. For ID.IM-01, the useful evidence is the trend: a failing policy that is later passing, with a recorded change that caused it. Check whether you can export pass and fail history over time, since a single snapshot shows the current state but not how the failure was found and fixed. The MIT license carries few distribution obligations, but confirm the license of any custom queries or extensions you add.

What meeting ID.IM-01 costs in money and effort

This table breaks down the cost components of meeting ID.IM-01 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price or duration is supplied for this outcome and figures must come from your own scope and vendors.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling and licenses	Tool vendors or your own staff if self-hosted	Recurring if subscription; one-time if perpetual	Self-hosted open-source tools such as CISO Assistant (AGPL-3.0-only), Wazuh (GPL-2.0-only) and Fleet (MIT) can remove license spend, but hosting and administration remain
Engineering time to connect automated checks	Your engineers or an implementation partner	One-time build, then recurring upkeep	Number of critical services, endpoints and policies to cover; quality of existing asset inventory
Findings register and workflow setup	Your GRC or security team, possibly a partner	One-time setup, recurring updates	Whether a GRC tool already tracks findings; number of sources feeding the register
Self-assessments of critical services	Your staff and reviewers who challenge the results	Recurring, typically each review cycle	Number of critical services; how current the threat picture must be; depth of reviewer sign-off
Independent assessments or audits	External assessors or audit firms	Recurring, tied to audit frequency	Scope boundaries, audit frequency, number of sites and systems, and whether reports are required by a customer or regulator
Auditor sampling and evidence requests	Your staff who gather evidence; auditor time billed to you	Recurring with each audit	Quality of retained evidence, automated exports, and how many samples the auditor selects
Remediation of findings	Your system owners and any partner doing the fixes	Variable, often recurring	Volume and severity of findings; backlog from prior cycles; whether fixes need change approvals
Automated compliance checks maintenance	Your platform team or a retained support provider	Recurring	Frequency of platform changes, policy updates and false-positive tuning

Who owns ID.IM-01 work, and what to outsource

The organization owns ID.IM-01 in full. Its leaders decide which critical services are assessed, which current threats the self-assessment must consider, what counts as a finding, how risk is accepted or treated, and who is accountable for each improvement. Those decisions cannot be delegated to a vendor or consultant without losing the basis of the self-assessment itself. Outside parties can supply inputs, but the organization must reach and document the conclusions.

Self-assessment decisions: Choosing the critical services in scope, the threat scenarios considered and the criteria for judging a control effective.
Risk acceptance: Deciding which gaps are fixed, which are accepted, and who signs off on each acceptance.
Improvement ownership: Assigning named owners, due dates and priorities for every improvement item.
Independent input selection: Deciding whether and when to commission third-party assessments or independent audits.
Automated check scope: Approving which requirements are evaluated continuously and what a failing result triggers.

Before you start, confirm that a named executive owns the self-assessment conclusions and that your internal team can explain every automated result without the partner present.

Common gaps that fail ID.IM-01 reviews

Assessors reviewing ID.IM-01 rarely fail an organization for running evaluations. They fail it when findings never turn into tracked, verified and repeatable improvements. The gaps below are the ones that most often separate an evaluation program that looks busy from one that visibly improves the program.

Self-assessments that ignore current threats

A self-assessment of critical services is only useful if it is tested against the threats the organization faces now, not the ones in the last review template. ID.IM-01 expects self-assessments that consider current threats, so a checklist copied forward each year will look complete while missing new attack patterns. Check that each assessment records which threat information was used, who reviewed it, and which critical services were in scope. Illustrative example: a ransomware scenario added after a sector advisory would appear as a dated change in the assessment record.

Audit findings with no tracked remediation

Independent audits and third-party assessments produce findings, but a finding that lives only in the auditor's report is not an improvement. Reviewers look for a register that links each finding to an owner, a remediation decision, a due date and a closure record. Ask the program owner to show the open findings list and the reason each item is still open. Findings accepted as risk should carry a documented risk decision by someone with authority to make it.

Automated checks whose exceptions go unapproved

Continuous automated evaluation of compliance with selected requirements is a strong source of evidence, but only when failures are handled. A scanner or policy engine that reports failing devices every day, with no owner or approval for exceptions, shows monitoring without improvement. Confirm which checks feed the improvement process, how exceptions are approved and how long they last. Open-source tools such as Wazuh Security Configuration Assessment and Fleet policies show pass and fail results per device, so the exception workflow must be defined separately.

Improvements closed without verification

Marking a finding as fixed is not the same as showing that the fix works. Assessors expect evidence that a remediated control was re-tested, re-scanned or re-reviewed after the change. Build a verification step into the closure workflow and require a named reviewer who did not make the change. Keep the retest result, not just the ticket status, in the evidence set.

No link between evaluation and the next cycle

An evaluation that does not feed the next planning cycle has no lasting effect on the program. Reviewers look for a documented path from each evaluation to the updated priorities, policies or control baselines that follow it. Check that the minutes of the governance meeting that reviews the program reference specific findings and their status. Without that link, the same gaps reappear in each new assessment.

Questions buyers ask about ID.IM-01 cost, effort and scope

Does ID.IM-01 require a third-party audit?

No. ID.IM-01 asks that improvements be identified from evaluations, and one of the examples NIST publishes is investing in third-party assessments or independent audits of program effectiveness. Other examples are self-assessments of critical services that consider current threats, and continuous automated evaluation of compliance with selected requirements. The organization chooses which evaluation approaches fit its risk, size and obligations. A customer or regulator may ask for an independent report, but that requirement comes from the contract or rule, not from the Subcategory itself. Confirm the expected evidence with whoever is asking for it before you buy an audit.

How much effort does ID.IM-01 take to meet?

The effort depends on how many evaluation methods you run and how mature your evidence trail already is. Effort usually falls into three parts: defining which critical services get self-assessed, running the evaluations on a set schedule, and recording findings and the improvements that follow from them. Self-assessments require people who understand the services. Automated checks require tooling that is configured and monitored. Third-party reviews require scoping, access and time to answer assessor questions. Ask your team to estimate effort for each method in your written scope rather than relying on a general figure.

Can we meet ID.IM-01 in-house without an implementation partner?

Often yes, if you already run periodic risk reviews and have staff who can judge whether a finding leads to a change. Organizations with a small team or no recent independent review may choose outside help for the first cycle, either to set up automated checks or to structure self-assessments. An implementation partner can prepare systems, configure tooling and organize evidence, but the organization still owns the controls and the decisions about improvements. Only an independent auditor or assessor can issue an audit report or attestation. Compare internal capacity against the methods you select before deciding.

How long does preparation for ID.IM-01 take?

Set the timeline from your written scope, not from a general rule. Preparation depends on which evaluation methods you adopt, how many critical services are in scope, whether tooling must be deployed first, and how quickly your team can complete reviews. A fixed-scope engagement with DeployOpen starts with written scope, deliverables and timelines agreed before work begins, so the schedule follows from those agreed items. If you plan to use an independent audit, add the auditor's scheduling and fieldwork time to your plan and confirm it with them directly.

Does NIST certify that we comply with ID.IM-01?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations. Any statement that you meet ID.IM-01 should be based on your own documented evaluations, and if a customer or regulator asks for independent confirmation, that comes from an independent auditor or assessor who issues the report. Ask any vendor or consultant who claims NIST certification to show you the basis for that claim.

What does ID.IM-01 need from our staff day to day?

It needs people who own the critical services, people who run evaluations, and people who approve the resulting changes. In practice, service owners describe current threats and dependencies, security staff run automated checks and review results, and leaders decide which improvements get funded and when. Staff also need time to record what they found and what changed, because that record is the evidence an assessor will ask for. Confirm who holds each role in your organization before you start, since unclear ownership is a common reason evaluations produce findings that never close.

What drives the cost of meeting ID.IM-01?

The main drivers are the number of critical services in scope, the evaluation methods you choose, and the state of your existing tooling and documentation. Recurring costs include staff time for reviews, tool licenses or hosting if you use commercial products, and any independent assessments you commission on a cycle. One-time costs include setting up automated checks, writing evaluation procedures and any initial gap review. When requesting a quote, ask the provider to itemize one-time setup, recurring support, tooling and what is excluded from the scope. Open-source tools can reduce license costs but still require configuration and upkeep.

How DeployOpen scopes and prepares ID.IM-01 evidence

DeployOpen works on ID.IM-01 by preparing the systems, evaluation records and evidence that show how your organization identifies improvements from self-assessments, third-party assessments and automated compliance checks. The organization keeps ownership of its controls, and independent auditors or assessors provide any report or certificate.

How we scope

Agree a written, fixed scope naming the critical services, evaluation types and compliance checks covered by ID.IM-01.
Confirm which evaluation sources feed improvement tracking, such as self-assessments, audit findings and policy compliance results.
Define deliverables, responsibilities and timelines in writing before work starts, with a quote that follows directly from that scope.

How we build

Configure self-hosted platforms to run automated compliance checks against the policies your organization selects.
Set up a register that records each evaluation finding, its owner, its improvement action and its closure status.
Test that check results, findings and remediation records export cleanly for review by your internal team or external assessors.

How we hand over

Document the configured checks, evaluation workflow and finding register so your staff can operate them without us.
Provide a walkthrough of how a single finding moves from evaluation to documented improvement and verified closure.
Deliver an evidence index mapping each artifact to ID.IM-01 so your assessor can trace it to the relevant outcome.

How we support

Review evaluation results and automated check outputs on a schedule agreed in your scope.
Maintain platform upgrades, check policies and finding records through an ongoing retainer if your organization chooses one.
Prepare updated evidence for each new independent assessment or audit cycle, while the auditor remains responsible for its conclusions.