ID.RA-01 vulnerabilities identified and recorded

What ID.RA-01 asks organizations to identify and record

A customer questionnaire or auditor asks how you find vulnerabilities in your systems and where those findings are tracked. ID.RA-01 is the CSF 2.0 Subcategory that expects an organization to have that answer. It sits in the Risk Assessment (ID.RA) Category of the IDENTIFY Function, and its outcome is that vulnerabilities in assets are found, validated and recorded. NIST published CSF 2.0 as CSWP 29 on February 26, 2024, and the CSF is a voluntary framework. NIST does not certify organizations or products against it, so no outside body can grant a CSF 2.0 certificate, and any claim of alignment has to be backed by your own records.

The risk behind this Subcategory is simple to state: a weakness nobody knows about stays open. An unpatched service, a misconfigured cloud resource or a vulnerable library in an internal application can be exploited long before anyone notices it. The practice is harder than the wording suggests. Asset inventories are often incomplete, so scanners never see systems that are running, and scanners produce large volumes of findings that include duplicates and false positives. Ownership is another common gap: a finding that nobody is assigned to is recorded but not fixed. Validation matters too, because a finding that has not been checked against the actual asset cannot be prioritized reliably.

Before answering an assessor, confirm three things in your own environment. First, which asset sources feed your vulnerability records, and whether cloud accounts, containers and endpoints are included. Second, who validates each finding and how a false positive is closed with a reason. Third, which system of record holds validated findings, and whether each one has an owner and a date. Those answers, not the framework text, are what an assessor will test. The sibling topics on threat intelligence and risk responses build on this record, so gaps here carry forward.

Which assets, teams and third parties fall under ID.RA-01

ID.RA-01 applies wherever vulnerabilities can exist, so the scope must be set deliberately rather than inherited from whatever a scanner happens to reach. The decisions below connect back to the organization's own CSF Current Profile and asset inventory under ID.AM, and each one changes the scanner count, the credentials required and the volume of evidence.

Hardware and operating systems

Start with endpoints, servers, hypervisors and mobile devices listed in the hardware inventory. Each operating system and build changes which vulnerability feed applies, so an inventory that records OS version and patch level is a precondition for finding unpatched software. Check whether unmanaged or byod devices that reach internal resources are in scope, because a scan that skips them leaves the most exposed assets unrecorded.

Applications and organization-developed software

Decide whether custom code, internal APIs and third-party applications are tested separately. ID.RA-01 explicitly covers testing organization-developed software, which usually needs source access, authenticated testing and separate tooling from infrastructure scans. Confirm which applications have an owner who receives findings, since unowned applications tend to produce findings that are never validated.

Network devices and cloud workloads

Routers, firewalls, switches and cloud instances often sit outside the teams that run servers. Cloud workloads also change state quickly, so the scope should define how new instances are discovered and enrolled. Confirm that scanners can reach segmented networks and that cloud accounts are included in the inventory before scan schedules are agreed, because unreachable assets produce gaps that look like clean results.

Physical facilities

The Implementation Examples for ID.RA-01 include assessing facilities for physical weaknesses, which is a different discipline from technical scanning. Decide which data centers, offices, server rooms and remote sites are walked through, and who records the findings. Physical findings such as unlocked racks or exposed network ports need the same validation and recording path as software vulnerabilities, or they will sit in a separate report nobody reconciles.

Teams that own the findings

A finding is only recorded when someone is accountable for validating it and fixing it. Map each asset class to an owning team, such as infrastructure, application, cloud platform or facilities, and name the person who triages findings for each. Without that mapping, duplicate findings appear across teams, and the evidence cannot show who validated what or when. Confirm this map against the roles defined under GV.RR.

Third parties and managed service providers

Managed service providers or outside scanning firms may run scans or operate systems on the organization's behalf. The contract should state which assets they scan, which credentials they hold, where results are stored and how findings reach the organization's register. Confirm that vulnerability data from a provider is imported into the organization's own system of record, since the organization remains responsible for recording findings it has been told about.

How ID.RA-01 differs from threat, likelihood and risk response subcategories

ID.RA-01 asks whether weaknesses in your assets are found, validated and recorded. It is a finding control. ID.RA-02 covers receiving cyber threat intelligence, ID.RA-03 covers identifying and recording threats, ID.RA-04 covers estimating likelihood and business impact, ID.RA-05 covers combining those inputs into inherent risk and priorities, and ID.RA-06 covers choosing and tracking risk responses. The practical split is simple: ID.RA-01 produces the inventory of confirmed vulnerabilities, with asset, source, status and owner for each entry. The later Subcategories decide what to do about that inventory. An assessor will test the findings record for ID.RA-01 on its own, looking for scan coverage, validation of results and evidence that entries were recorded, without requiring any prioritization logic to be present.

Organizations moving from CSF 1.1 should check where their older controls now sit. According to NIST's CSF 1.1 to 2.0 Core Transition Changes spreadsheet, ID.RA-01 continues CSF 1.1 ID.RA-1 at the same identifier and absorbs part or all of CSF 1.1 PR.IP-12 and DE.CM-8. Confirm this mapping against the spreadsheet itself, then trace each legacy vulnerability procedure to its new home. A vulnerability management procedure filed under a patching or monitoring heading in CSF 1.1 may now need to be cited under ID.RA-01, and your evidence index should reflect that move before an assessment begins.

The decision to make is where the line between finding and prioritizing falls in your own program. Write the boundary down. For example, a scanner export that lists unpatched hosts belongs to ID.RA-01, while the scoring that ranks those hosts against threat intelligence and business impact belongs to ID.RA-05. Ask whether your ticketing and risk register can show both records separately, with timestamps and an owner for each step. If one tool or spreadsheet blends them, an assessor may struggle to tell which evidence supports which Subcategory, and that is a reason to split the records now.

How an assessor tests ID.RA-01 vulnerability identification

This table maps each test area an assessor may use for ID.RA-01 to the approach, the evidence requested and the findings that commonly appear. Read it as a checklist of what to prepare before an assessment, and remember that the assessor draws the conclusions while the organization or its implementation partner assembles the evidence.

Test area	Assessor approach	Evidence requested	Common findings
Asset sampling and scanner coverage	Samples assets from the inventory (ID.AM) and compares them against scanner scope, agent deployment and scan history to see whether each sampled asset is covered	Asset inventory export, scan target lists, agent enrollment records and scan schedules	Assets in the inventory absent from scan scope, or scanners pointed at ranges that no longer match the network
Vulnerability management tools (unpatched and misconfigured software)	Reviews scan configurations and recent results, then checks whether findings for sampled hosts match what the host actually runs	Scanner configuration, authenticated scan settings, recent scan reports and feed update logs	Unauthenticated scans that miss installed software, stale vulnerability feeds, or scans that were never scheduled
Architecture assessments	Reads architecture documents and asks how weaknesses in design, segmentation and trust boundaries were identified and recorded	Architecture review reports, data flow diagrams and a register of design weaknesses with their status	No documented architecture review, or reviews that stop at diagrams without recording the weaknesses found
Testing of organization-developed software	Checks whether application or API testing covers code the organization builds, and whether results enter the findings register	Penetration test or code scan reports, test scope statements and tickets linked to each validated finding	Testing limited to vendor products, or findings reported verbally and never recorded
Facility assessments for physical weaknesses	Asks whether facilities such as server rooms and network closets are assessed, and whether physical weaknesses are logged like technical ones	Facility assessment records, walkthrough notes and physical findings in the same register as technical findings	No facility assessment on file, or physical weaknesses handled outside the vulnerability process
Threat intelligence monitoring for new vulnerabilities	Traces how new advisories reach the team, then checks whether relevant ones were matched to assets and recorded	Advisory subscriptions, triage logs, feed-to-asset matching records and the dates each advisory was reviewed	Advisories read but not matched to assets, or no record showing a new vulnerability was checked against the inventory
Process reviews for weaknesses	Walks through the vulnerability process from detection to recording and asks where weaknesses in the process itself were identified	Written procedure, meeting or review minutes and records of process changes made after reviews	A procedure that exists on paper but has no record of use, or no review of the process itself
Validation and recording of findings	Picks a sample of raw scanner results and follows each one to a validation decision and a record with an owner and status	Triage decisions, false positive justifications, deduplicated findings and linked remediation or risk tickets	Unvalidated scanner output treated as fact, duplicate records, or validated findings with no owner or disposition

How to implement ID.RA-01 in the order an assessor will check it

This sequence moves from a trusted asset inventory to scanning, validated findings and a tracked vulnerability record, then to periodic reviews of the process itself. Each step leaves an artifact an assessor can sample to confirm that ID.RA-01 operates, not just that a scanner was installed.

Confirm the asset inventory as the scan baseline
The organization's asset owner and IT operations lead reconcile the hardware, software and service inventory maintained under ID.AM against what the network and cloud accounts actually contain. Unknown or unmanaged assets are either onboarded or formally excluded with a recorded reason. The output is a signed-off scan scope list, mapped by asset class, that every later scan is measured against. The step is done when an assessor can pick any scanned host and find it in the inventory.
Select detection tools for each asset class
The security engineering team chooses one or more methods for each asset class, such as network vulnerability scanning for servers and network devices, endpoint software inventory matching for workstations, and code and dependency testing for organization-developed software. Tool selection is documented against the asset classes it covers, including any gaps that are accepted or handled manually. Open-source options such as Greenbone Community Edition, Wazuh and Fleet can be evaluated here, but the team should confirm each tool's coverage of its own operating systems and applications before relying on it. The output is a tool coverage matrix with an owner for each row.
Set scan schedules and credentialed coverage
The platform team configures scan tasks, frequencies and triggers, and sets up credentialed scans where the tool can authenticate to hosts, because unauthenticated scans often miss installed software and local misconfigurations. Scan jobs are scoped to the baseline, and failed or incomplete scans are logged and rerun. The output is a scan schedule document, the scan configuration exported from each tool, and a coverage report showing which in-scope assets were scanned, when, and with which credentials. Ask the tool vendor or documentation to confirm how credentialed scanning is configured before committing to it.
Validate findings and remove false positives
Security analysts review raw results, confirm each finding against the affected asset, and check whether the vulnerable version or configuration is actually present and reachable. Duplicates from overlapping tools are merged, and each false positive is closed with a written justification and a reviewer's name. Tools such as DefectDojo can import findings from many report formats and deduplicate them, which helps this step scale. The output is a validation procedure, a log of dispositions with reasons, and a set of confirmed findings. An assessor will sample closed false positives to test whether the justifications hold.
Record validated vulnerabilities in a tracking system
Each confirmed vulnerability is entered into a central tracking system with, at minimum, an owner, the affected asset, a severity or priority field, and a status such as open, in progress, mitigated or accepted. The record links back to the scan result that identified it, so the chain from detection to disposition can be traced. Acceptance of a risk is routed to the risk response process under ID.RA-06 rather than closed silently. The output is a populated tracking register and its access and change history. Confirm with the team which system of record will hold these entries and who may edit them.
Run periodic process and facility reviews
At intervals the organization sets and documents, the security lead reviews whether the scan scope still matches the inventory, whether tools still receive current vulnerability data, and whether processes such as architecture review, software testing and physical facility assessments are producing findings. Gaps found in these reviews become improvement items tracked under ID.IM. The output is a dated review record with attendees, decisions and follow-up actions. Assessors typically test this step by asking for the most recent review and tracing one of its actions to closure.

Which evidence proves vulnerabilities were identified and recorded

An assessor testing ID.RA-01 wants to see that scanning and review actually ran, covered the right assets, and produced recorded findings that someone validated and owned. The artifacts below connect in one chain: the asset baseline defines scope, the scan configuration and reports show coverage over time, and the findings register shows what happened next.

Scan configuration and schedules

Export the scan tasks, targets, credentials and schedules from each vulnerability management tool, along with the feed or data update settings. This shows the identification activity was planned and repeatable, not ad hoc. Check that the configuration matches what you say you scan, because a schedule that targets an outdated address range proves nothing. Keep dated exports of configuration changes, and confirm with your auditor how long they must be retained.

Scan reports with date and scope

Each report should state when the scan ran, which assets were in scope, which checks were applied and what was found. An undated report or one that does not list its targets cannot show coverage. Export reports on a fixed cadence, such as monthly, and store them in a location that cannot be silently overwritten. Compare the target list in each report with the inventory to show gaps were noticed and addressed.

Asset inventory used as scan baseline

The inventory is the reference that tells an assessor whether scanning reached everything it should. Retain dated snapshots of the asset list used to set scan targets, and record how new hosts, containers and cloud resources enter it. Wazuh and Fleet build their own software inventories from enrolled agents or hosts, so those inventories can serve as evidence that the baseline is current. Confirm with your auditor whether they accept tool-generated inventories or require a separate reconciliation.

Findings register with validation notes and owners

A findings register shows that identified vulnerabilities were recorded, checked and assigned. Each entry should carry the source scan, an asset reference, a validation note showing whether a false positive was ruled out, and a named owner. DefectDojo can import findings from many tool formats and deduplicate them, which keeps one record per issue. Export the register at fixed intervals so the history of open and closed findings survives tool upgrades.

Architecture and software testing records

Architecture reviews and tests of software your organization builds show vulnerabilities found outside automated scanning. Keep the review scope, the reviewer, the date, the findings and the disposition for each one. Store test reports for in-house applications alongside the scanning evidence, and link any finding to the ticket that tracks its fix. Confirm with your assessor which architecture and code review artifacts they expect, since the required depth varies by organization.

Facility assessments and process review minutes

Physical weaknesses at sites and gaps in operational processes are part of ID.RA-01 and are often missing from technical evidence. Keep dated facility assessment reports with the observations, the person who performed the walkthrough and the actions raised. Process review minutes should show what weaknesses were discussed, who attended and which items were logged in the findings register. Ask your auditor how often these reviews must recur and how far back the records need to go.

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

Endpoint tools answer the question most assessors ask first: which software is actually installed on the systems in scope, and which known vulnerabilities apply to it. Wazuh and Fleet both build a software inventory from each host and then compare it against vulnerability data. The output is a per-host list of findings that can be exported and retained as dated evidence.

Wazuh vulnerability detection (GPL-2.0-only): Each Wazuh agent reports its software inventory, which is correlated with the Wazuh CTI vulnerability repository. Where hosts cannot reach the internet, a locally hosted offline copy of the data can be used instead, which matters for air-gapped environments.
Fleet vulnerability processing (MIT): Fleet matches installed software on enrolled hosts against the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Each source covers a different operating system or ecosystem, so coverage depends on the platforms in your estate.
Operating system and application scope: Both tools focus on the operating system and installed applications. They do not replace scanning of network services, firmware or web applications, which ID.RA-01 also expects to be assessed.
Retention of results: Findings are only useful as evidence if the organization keeps dated exports or database snapshots. Plan where these records are stored and for how long.

Before relying on either tool, confirm with your assessor which vulnerability sources they accept and whether an inventory gap on any host class will be treated as a finding in its own right. Confirm the license terms with your legal team, since GPL-2.0-only and MIT carry different obligations if you modify the code.

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

This table compares the main cost components of identifying and recording vulnerabilities, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since the largest recurring costs are often staffing and triage rather than scanner licenses.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Scanner tooling or licenses	Commercial vendor subscription, or no license fee for open-source tools such as Greenbone Community Edition, Wazuh or Fleet	Recurring for commercial subscriptions; none for open-source licenses	Asset count and scanner capacity; open-source tools move this cost into infrastructure and staff time
Deployment and tuning engineering	Internal platform team or implementation partner, fixed-scope or hourly	One-time, with periodic retuning	Number of tools, integrations with asset inventory and ticketing, and how many environments are in scope
Credentialed scan setup	Internal staff or implementation partner, plus credential vault or service account administration	One-time setup, recurring credential rotation	Operating system and application diversity, and whether scanners reach cloud, OT or segmented networks
Findings triage and validation	Internal security operations or vulnerability management staff	Recurring, usually the largest ongoing cost	Scan frequency, false positive rate, deduplication quality and how many findings need manual validation
Evidence upkeep	Internal compliance or security engineering staff	Recurring, tied to each assessment cycle	Number of scan reports, retention rules and how well scan outputs are linked to tickets and asset records
External penetration or vulnerability testing	Independent testing firm, if used to supplement internal scanning	Recurring per test cycle	Application and network scope, test depth and whether retesting is included in the agreed scope
Auditor sampling time	Organization staff who respond to auditor requests, plus the independent auditor's fees	Recurring per audit cycle	Number of sampled scan cycles, quality of exports and whether the evidence trail is consistent
Infrastructure and maintenance for self-hosted platforms	Organization cloud or data center costs, and staff who patch and back up the platform	Recurring	Database size, scan volume, high availability needs and how often feeds and platform components are updated

What your team, a partner and the auditor each do for ID.RA-01

Your organization owns the vulnerability identification process and every decision that comes out of it. ID.RA-01 expects vulnerabilities in assets to be found, validated and recorded, and only your staff can say which assets matter, which owners answer for each finding and which risks are accepted. A partner can configure a scanner, but it cannot decide that a system is out of scope or that a critical finding may wait.

Asset inventory: Maintain the list of hardware, software and services that scanning must cover. Gaps in this list become gaps in the evidence.
Scan scope and cadence: Approve which networks, cloud accounts, endpoints and applications are scanned, how often, and which exclusions apply and why.
Finding owners: Name an accountable owner for each system or application so that validated findings reach someone who can fix them.
Risk decisions: Decide whether each finding is remediated, mitigated, accepted or transferred, and record the reasoning. Risk response belongs to ID.RA-06, but the vulnerability record feeds it.
Policy and resourcing: Set the timeframes for triage and remediation, and fund the people who review results.

Confirm with your customer or regulator which vulnerability records and scan reports they expect to receive, since NIST does not certify CSF alignment.

Common questions about meeting ID.RA-01

How much effort does ID.RA-01 take for a small team?

The effort depends mainly on how many assets you run and how many of them you can scan with the access you already have. ID.RA-01 asks you to find, validate and record vulnerabilities in your assets, so a small team needs a current asset list, a scanning tool that can reach each system, and a place to log findings and track fixes. NIST's Small Business Quick-Start Guide, SP 1300, cites ID.RA-01 when it suggests that small businesses assess their IT and physical assets for vulnerabilities, which shows the outcome is meant to scale down. Ask any provider for a written scope that lists the assets, scan frequency and who reviews results before you commit to a timeline.

Can we meet ID.RA-01 in-house without outside help?

Yes, many organizations do this in-house, because the outcome is operational work rather than a certification. Your team owns the controls and decides how vulnerabilities are found, validated and recorded. The main questions are whether you have people who can run scans, interpret results, separate false positives from real exposure, and keep records current. If those skills or hours are missing, an implementation partner can help set up the tooling and evidence, but the organization still owns the process and the decisions about risk.

Do we need an implementation partner for this?

You do not need a partner to meet ID.RA-01, but a partner can shorten the setup work if your environment is complex or your team is stretched. A partner such as DeployOpen can plan, deploy, integrate and document self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and can prepare the scanning and evidence workflow. A partner does not issue audit reports or certificates, and NIST does not offer conformity assessments. Decide whether you need help based on your internal capacity, and get the division of responsibilities in writing.

What does ID.RA-01 need from our organization to start?

ID.RA-01 needs three inputs before any scan runs. First, an asset inventory that lists hardware, software and the systems you want to assess, which connects to the ID.AM asset management outcomes. Second, a named owner for each asset or system group who can approve scanning windows and fix findings. Third, scan access, including network paths, credentials for authenticated scans where your tools support them, and agreement from change management so scans do not disrupt production. Missing any of these usually adds more delay than the scanning itself.

How long does it take to produce ID.RA-01 evidence?

The time to produce usable evidence depends on the number of assets, how many scope areas you include, how quickly owners respond, and how many findings need validation. No duration is set by NIST for ID.RA-01, so treat any single figure with caution. Ask your provider for a written scope and timeline that states the asset count, the scanning schedule, the validation process and the points at which evidence is delivered. Ask how the plan changes if your asset count grows during the work.

Does NIST certify that we align with ID.RA-01?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The Cybersecurity Framework is voluntary, so alignment is shown through your own documented evidence, and in some cases a customer or contract may ask for an independent assessment. Be cautious with any provider that claims NIST certification or partner status for ID.RA-01. Ask for the independent assessor's name and scope if an outside review is required.

How does ID.RA-01 relate to ID.RA-05 prioritization?

ID.RA-01 produces the raw input, a validated and recorded list of vulnerabilities in your assets. ID.RA-05 uses that list, together with threats, likelihoods and impacts, to understand inherent risk and decide which responses come first. In practice, a scanner can flag hundreds of findings, but ID.RA-05 asks you to rank them by how exposed the asset is and how much harm an exploit would cause. Keep the vulnerability records in a form that carries asset criticality and owner, so the prioritization step can be done without rebuilding the data.

What should we ask a partner to include in a quote?

Ask for a fixed written scope that names the assets, environments and tools in scope, the deliverables, the timeline and the responsibilities split between your team and the partner. The quote should list one-time work, such as setup, integration and documentation, separately from recurring work, such as scan operations, upgrades and retainers. Ask which tools are included, how findings will be recorded and deduplicated, what handover training covers, and what your team must provide. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen works on this

DeployOpen works on ID.RA-01 as an implementation partner. We help your team set up scanning, software inventory and vulnerability tracking inside your own infrastructure, and we prepare the records that show vulnerabilities are found, validated and recorded. Your organization owns the control and its conclusions, and only an independent assessor can issue a report on it.

How we scope

The written scope lists which asset groups, networks, cloud accounts and applications feed vulnerability identification.
We confirm which of the six NIST Implementation Examples for ID.RA-01 your environment needs, and which are handled by other teams.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.

How we build

We deploy self-hosted scanning and detection tools, such as Greenbone Community Edition, Wazuh or Fleet, in your infrastructure.
We configure scan schedules, asset inventories and credentialed scanning scope so results cover the agreed assets.
We test that findings are validated, deduplicated and assigned to owners, then document the workflow your staff will run.

How we hand over

You receive configuration records, scan schedules, a list of covered assets and a runbook for triage and recording.
Sample vulnerability records show how each finding was identified, validated, owned and linked to a remediation or risk entry.
We walk your team through the evidence an independent assessor is likely to request, so your staff can produce it unaided.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
We can keep scanners current, review coverage gaps as assets change, and update records for each review cycle.
Ask us to confirm in writing which tasks sit under the retainer and which would need a new scope and quote.

ID.RA-01 Vulnerabilities identified and recorded