ID.RA-03 Threats identified and recorded: NIST CSF 2.0

What ID.RA-03 threat identification requires in practice

Most organizations meet ID.RA-03 for the first time during a CSF 2.0 gap analysis, a customer security questionnaire or an audit request that asks, in effect, how you know which threats apply to you and where they are written down. The outcome NIST describes is that internal and external threats to the organization are identified and recorded. The risk it addresses is familiar: threats that are discovered late, or never written down at all, so that controls are chosen against a generic picture of attackers rather than the ones likely to target your sector, your technology and your people. NIST publishes ID.RA-03 as an outcome with three Implementation Examples, not as a certifiable control. No certification body tests it directly, and NIST states that it does not offer certifications or endorsements of CSF-related implementations. What an assessor or customer will look for is evidence that a threat list exists, is maintained and feeds decisions.

The difficulty lies in keeping the record current. Threat records go stale quickly because actor behavior, exposed services and sector alerts change faster than a register is reviewed. Insider threats are harder still, since a useful record must name the roles, access paths and conditions that make misuse plausible without turning the register into a list of suspects. The Implementation Examples point toward three working practices: using threat intelligence to decide which actors and techniques are likely, hunting for signs of those actors inside your own environment, and running a process that identifies internal threat actors. Each produces a dated, owned entry that someone reviews on a set schedule. Confirm with your own assessor which review cadence and owner they expect, because NIST does not set one.

For mapping work, the CSF 2.0 Reference Tool links ID.RA-03 to SP 800-53 Rev. 5.2.0 controls PM-12, PM-16, RA-3 and SI-5, to ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 and Annex A controls 5.7, 5.22 and 8.16, and to SP 800-171 Rev. 3 requirements 03.11.01 and 03.14.03. Treat these as informative references that help you find overlapping evidence, not as proof that any one control passes. An assessor will still test your threat records against your own scope and risk decisions. Before you map, check the current mappings in the NIST CSF 2.0 Reference Tool export, since the informative references are updated separately from the framework document.

Which systems, teams and third parties ID.RA-03 covers

ID.RA-03 asks whether internal and external threats are identified and recorded, so the first work is deciding what counts as a threat source, where threats are observed, who owns the intelligence and hunting, and where the threat register stops. Each decision below should be agreed in writing by the named owners before any tooling or hunting begins.

External threat actors in scope

Decide which external actor groups the organization tracks, such as financially motivated criminals, state-aligned groups or hacktivists, and which sectors and suppliers drive that choice. Record the decision because ID.RA-03 expects threat intelligence on which actors and techniques are likely, not a generic list. Confirm with the CISO and the business owners of the most exposed services, and state which actors are deliberately excluded and why.

Insider threats and privileged users

Decide which populations count as insider risk, such as employees, contractors with privileged access, administrators and departing staff, and which signals the organization will review. The HR, legal and works council functions must agree on what monitoring is permitted and how findings are escalated, because an insider process that cannot lawfully observe behavior will not produce records. Name the owner who can approve an insider investigation.

Third parties and their access paths

Decide which suppliers, managed service providers and integration partners are in scope as threat sources, based on their network connections, remote access and data handling. A supplier with a standing VPN tunnel is a threat path even when it is not a threat actor, so record each access route. Procurement and the owners of the affected systems should agree the list, and it should match the supplier inventory used for ID.RA-10 supplier assessment.

Endpoints, cloud accounts and identity systems

Decide which telemetry sources feed threat observation, including endpoints, cloud control planes and the identity provider. Identity logs are often the first place a threat shows up, so confirm that sign-in, token and administrative events are collected, not only server logs. Platform engineering and the cloud account owners must agree which accounts, regions and tenants are monitored, and which are out of scope because no logs reach the platform.

OT and industrial environments, if present

Decide whether operational technology, such as industrial controllers or building systems, is observed for threats at all. Passive monitoring may be the only safe option in these environments, and operations staff must approve any collection or scanning. If OT is excluded, record that boundary explicitly so the gap is visible to assessors rather than assumed to be covered.

Ownership of intelligence, hunting and the register

Decide which team owns threat intelligence collection, which owns threat hunting, and who maintains the threat register and approves entries. Name a single accountable owner for the register, because ID.RA-03 records threats that feed risk decisions in ID.RA-05 and ID.RA-06. Confirm the handoffs in writing, and confirm whether the register lives in the platform or a GRC tool, with the boundary of what each team may edit.

How an assessor tests ID.RA-03 and what they ask to see

This table compares how an assessor tests each part of ID.RA-03, the threat identification outcome, and the evidence they ask the organization to produce. Read each row as a test step paired with the artifact that passes it, then check your own threat register, intelligence records and hunt logs against the same questions. Assessors work from your own CSF-aligned evidence, since NIST does not certify CSF implementations.

Test area	What the assessor does	Evidence they ask to see
Threat identification	Interviews the named threat owner and asks how internal and external threats reach the register	Threat register with owner, scope and update history showing entries added over time
Register ownership	Checks that a named role is accountable for keeping the threat register current	Role assignment, review dates and a record of the last review decisions
Intelligence use	Samples one threat entry and traces it back to a source and a likely actor or TTP	Source citations, actor or TTP mapping and the date each item was received
Threat hunting	Reviews hunt plans, the hypotheses tested and the results recorded	Hunt plans, hypothesis write-ups, queries run, findings and follow-up tickets
Insider threat process	Reviews the criteria used to flag insider activity, the escalation path and any recorded cases	Documented criteria, escalation procedure, case log and outcomes with dates
Traceability to risk	Checks whether recorded threats feed vulnerability, likelihood and risk response work	Links from threat entries to risk register items and response records
Common finding: no owner	Flags a register that no named person maintains or reviews	Evidence of assignment and periodic review; absence usually leads to a finding
Common finding: unlinked intelligence	Flags intelligence collected but never tied to a recorded threat	Documented decisions showing why each intelligence item was or was not recorded
Common finding: undocumented hunts	Flags hunts described in plans or meetings but with no recorded results	Hunt records completed for every planned hunt, including negative results

How to implement ID.RA-03 step by step

This sequence turns ID.RA-03 from a statement of intent into a maintained threat register, with named owners, hunts that test stated hypotheses, and insider threat handling agreed with HR and legal before it is needed.

Define threat sources and actor types in scope
Start by listing the threat sources that could affect your organization, both external (criminal groups, hacktivists, nation-state actors, opportunistic attackers, and threats through suppliers and cloud providers) and internal (privileged staff, contractors, and people with access who may act carelessly or maliciously). Tie each source to the business services it could reach, so the scope reflects your own environment rather than a generic list. The output is a scoped threat source list signed off by the risk owner, with a note on any source you have deliberately excluded and why. You know this step is done when every critical service has at least one named threat source mapped to it.
Assign an owner and a review cadence
Name one accountable owner for the threat register, usually someone in the security or risk function with authority to request data from security operations, IT, and business units. Document the owner's responsibilities for intake, validation, and escalation, and agree who may add or retire entries. The output is a short ownership record that states the owner, the backups, and the decision rights. You know this step is done when the owner can name the people who feed them information and the people who act on it.
Select intelligence sources and a platform to receive them
Choose the threat intelligence inputs you will rely on, such as sector information sharing forums, government advisories, vendor reports, and commercial feeds, and record what each one covers and how often it is reviewed. Decide where indicators and reports will land. Open-source options include MISP for indicator correlation and sharing between instances with sharing groups, and OpenCTI for organizing intelligence as STIX-based entities and relationships. Confirm the feed formats, licensing terms, and sharing restrictions with each provider before ingestion. The output is an intelligence source register and a platform decision record. You know this step is done when each source has a named receiving tool and a documented handling rule.
Build the recorded threat register
Create a register where each entry records the threat source, the likely actor or actor type, the tactics, techniques, and procedures (TTPs) the actor is known to use, the affected assets and business services, the evidence and source reference, the date recorded, the confidence level, and the next review date. Link entries to your asset inventory and to the related vulnerabilities and risk responses so the register feeds the next Identify steps. An illustrative entry might name a phishing-led financially motivated group, the email gateway and finance systems it could reach, and a review date set by the owner. The output is a register template and a first set of populated entries. You know this step is done when every entry has an owner, a source, and a review date.
Set up threat hunting with written hypotheses
For the highest-priority entries, write a hunt hypothesis that states the actor behavior you expect to see, the data sources that would show it, and the query or detection logic to test it. NIST's Implementation Examples for ID.RA-03 describe threat hunting as a way to look for signs of actors already in the environment. Run hunts against collected logs in your SIEM or log platform, such as OpenSearch Security Analytics with Sigma rules or Wazuh with its ruleset mapped to MITRE ATT&CK, and record each result as confirmed, disproved, or inconclusive. The output is a hunt plan and a hunt log with findings linked back to the register. You know this step is done when every hunt has a written hypothesis and a documented outcome.
Define insider threat indicators and escalation
Agree the behavioral and technical indicators that should trigger an insider threat review, such as unusual access to sensitive data, use of privileged accounts outside normal hours, repeated failed attempts at restricted systems, or large data transfers ahead of departure. Document who can raise a concern, how it is triaged, and how it moves to HR and legal, including the privacy and employment rules that govern monitoring in your jurisdiction. Confirm these procedures with your legal and HR advisers before use, because the rules differ by location and contract. The output is an insider threat procedure with an escalation path and a record of the approvals obtained. You know this step is done when HR and legal have signed off on the monitoring scope and the escalation steps.
Schedule register reviews and keep the record
Set a recurring review of the threat register that retires stale entries, adds new intelligence, checks hunt outcomes, and confirms that each entry still maps to current business services. Record each review with its date, attendees, changes made, and decisions taken, and feed material changes into the risk assessment and risk response processes that cover ID.RA-04 through ID.RA-06. The output is a review record and an updated register version history that an assessor can trace. You know this step is done when the most recent review is documented and every change has a reason and an owner.

Evidence that passes an ID.RA-03 review

An ID.RA-03 review tests whether threats are identified, recorded and kept current, not whether a threat feed exists. The artifacts below connect into one trail: sources feed the register, the register drives hunts and insider criteria, and review minutes show someone acted on what changed. Keep each one dated and owned so an assessor can follow a threat from first record to outcome.

Threat register with dated entries

The threat register lists each internal and external threat the organization has identified, with a description, the affected business services, a named owner, the date first recorded and the date last reviewed. Assessors check whether entries exist for threats relevant to your environment and whether each one has an owner who can explain it. Keep a change log for every edit, including closed threats and the reason they closed. A register with no review dates reads as a one-time exercise. Schedule a recurring review cadence and record each pass as a dated revision so the history stays visible between audits.

Intelligence source records

Maintain a record for each threat intelligence source you use, covering the provider or forum, the feed or report, the date received and the systems or teams that consumed it. For each item, note how it changed the register, a detection rule or a hunt. An assessor tests whether intelligence leads to recorded threats rather than sitting in an inbox. If you ingest feeds into OpenCTI, export its ingestion history as part of this record. Confirm your retention period for raw feeds with your own policy owner.

Likely actors and TTPs with scope reasons

This list names the threat actors and techniques judged likely against your organization, each with the reason it is in scope, such as sector targeting, exposed services or a supplier relationship. Map techniques to the MITRE ATT&CK framework where you can, since Wazuh alerts map to it and detection coverage can be compared against the list. Assessors look for a stated rationale, not a long list. Review the list when the register changes and record which actors were added, removed or deprioritized, and why.

Hunt plans and results

A hunt plan states the hypothesis, the actor or technique under test, the data sources searched, the time window and the people responsible. Results record what was found, what was ruled out and what changed as a result, including new register entries or detection rules. Use OpenSearch Security Analytics findings or similar detector output as hunt inputs and keep the query or Sigma rule version used. Assessors often ask for a hunt that found nothing, so document negative results with the same care as positive ones.

Insider threat criteria and documented cases

Insider threat criteria define the observable indicators you monitor, such as unusual data access, bulk downloads, access outside role or resignation with elevated rights, and the thresholds that trigger review. Documented cases record how each review was handled, who approved it and what was decided. Because case files hold personal data, agree handling, retention and access with legal, HR and privacy reviewers before collecting them, and keep the criteria and aggregate case counts separate from individual files. Ask counsel which jurisdictions limit monitoring of staff.

Register review minutes

Minutes from each register review show who attended, which threats were added, changed or closed, which intelligence and hunt results were considered, and which actions were assigned with due dates. They show that the register is governed rather than maintained by one person. Assessors compare minutes against the change log to confirm that decisions were carried out. Set a recurring review cadence, invite the owners of affected services and file each set of minutes with the register revision it approved.

Which open-source tools can produce ID.RA-03 evidence

MISP is a threat intelligence platform that correlates indicators, records sightings and shares events with other organizations. For ID.RA-03, its most useful output is a dated record of which indicators were seen, where, and which sharing group received them. That record shows that threats were identified and recorded, and that intelligence on likely actors was kept in a form someone can review later.

Indicator correlation: MISP correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, so related threats can be linked in one event.
Sightings: Recorded sightings show when an indicator was observed in the environment, which supports threat hunting records.
Sharing groups: Granular distribution and sharing groups control which partners receive each event, and that scope can be documented.
Structured exports: The REST API exports to STIX 1 and 2, CSV and Suricata, Snort and Zeek rule formats, so records can move into other tools.
License caveat: MISP is licensed under AGPL-3.0-only. Review the obligations with counsel before modifying it or offering it as a network service.

Confirm which sharing groups and retention settings your register requires before you rely on exported events as evidence.

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

This table compares the cost components of identifying and recording threats under ID.RA-03, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No prices or durations are stated because none are supplied; use the table to structure a written scope and quote. The main takeaway is that open-source licenses remove the software fee, but people time and hosting usually carry most of the cost.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Tooling and hosting	Cloud or data center provider, implementation partner for setup	One-time setup, recurring hosting, storage and maintenance	Up: number of log sources and indicator volume. Down: reuse of existing SIEM data and narrow source scope
Intelligence sources	Paid feed vendors or sharing community operators, if used	Usually recurring, optional	Up: number of paid feeds and sharing groups. Down: start with free or community sources and confirm each provider's terms
Analyst time for triage and register upkeep	Internal security staff or outsourced analysts	Recurring	Up: volume of indicators and sightings. Down: tuned correlation rules and clear triage criteria
Threat hunting time	Internal threat hunters or external hunting providers	Recurring, scheduled or ad hoc	Up: hunting frequency and environment size. Down: hunts tied to threat intelligence on likely actors
Insider threat process design	Internal HR, legal and security staff, or outside counsel	One-time design, periodic review	Up: jurisdictional requirements and monitoring scope. Down: a written process reused across cases
External threat intelligence or hunting support	Specialist provider under written scope	Optional, one-time or recurring	Up: scope breadth and reporting depth. Down: limit to named actors or systems the organization cannot cover
Auditor sampling time	Independent auditor, if the organization is assessed	Recurring with each assessment cycle	Up: number of records and detection cases sampled. Down: consistent, dated, retrievable threat register entries

Who owns ID.RA-03 and what can be outsourced

Your organization owns ID.RA-03 in full. Nobody outside the organization can decide which threats matter to your mission, which actors are plausible for your sector and footprint, or who counts as an insider worth watching. Those decisions shape the threat register and must be traceable to your risk management process, so an auditor will expect to see named owners making them and recording the reasoning.

Threat register ownership: Keep one register of internal and external threats, with an owner, review date and a link to the business services each threat affects.
Likely actor approval: Review the threat actors and techniques that threat intelligence suggests, and record which ones you accept as likely for your environment and why.
Insider criteria: Define what triggers an insider threat review, such as privileged access changes, data movement or policy violations, and document who may approve those reviews, within your HR and legal limits.
Hunt result review: Read threat hunting outcomes, decide whether a finding changes the register, and assign follow-up.

Before assessment, confirm that each register entry has a named owner and that the approvals are dated and retained.

Where organizations fall short on ID.RA-03 and how to close each gap

Most organizations have some threat activity under review, but the records rarely show who owns the threat list, how intelligence turns into a recorded threat, or how that threat feeds later risk work. The cards below cover the gaps assessors most often find under ID.RA-03 and one practical fix for each.

Threat register without an owner

A threat register that nobody owns goes stale within a few review cycles. ID.RA-03 expects internal and external threats to be identified and recorded, so each entry needs a named owner, a last-reviewed date and a next review date. Check that the register lists the owner and review date on every row, and that a reviewer can show the entries changed since the previous cycle. Illustrative example: a ransomware entry last reviewed two years ago with no owner should trigger reassignment.

Intelligence never linked to threats

Teams often collect threat reports, feeds and advisories but never record the link between an actor or technique and a threat entry in the register. The result is intelligence that exists but cannot be traced to a recorded threat. Set up a workflow in which each relevant indicator or actor note is attached to a register entry, with the source and date. A platform such as OpenCTI can hold these relationships as STIX-based entities, and you should confirm which connector and feed formats your environment needs before you commit.

Hunting without a written hypothesis

Threat hunting that starts with a general sweep of logs rarely produces records an assessor can follow. NIST's Implementation Examples for ID.RA-03 describe hunting for signs of threat actors in the environment, so each hunt should begin with a written hypothesis, such as a named technique likely to target your identity provider. Record the hypothesis, data sources, queries, outcome and any new threat entry raised. Without that record, the hunt cannot show that threats were actually identified.

Insider threats handled ad hoc

Insider threat work often depends on a manager's judgment in the moment, with no agreed process for HR, legal or privacy involvement. ID.RA-03 includes processes for identifying internal threat actors, so the process must be written and approved before a case arises. Define which signals trigger review, who may access activity data, how employees are informed where local law requires it, and how cases are recorded. Confirm the agreement with HR and legal counsel for each jurisdiction where you operate.

Threats not carried into risk analysis

A recorded threat that never reaches likelihood and impact estimates is only half of the work. ID.RA-04 and ID.RA-05 depend on threat entries as inputs, so a threat list that stays separate from the risk register breaks the chain from identification to prioritization. Add a field in each threat entry that points to the related risk record, and review open threats during each risk assessment cycle. An assessor will typically trace one threat forward to a risk decision to test this link.

Evidence that lives in chat and email

Threat decisions made in chat threads or email rarely survive staff turnover or an assessor's sampling. Evidence for ID.RA-03 should sit in a system of record with timestamps, owners and version history, such as a ticket queue, a GRC tool or the threat platform itself. Set a rule that any threat identified in chat is logged in the register within a set time you define, and that the log entry links to the conversation rather than replacing it. Ask your auditor which evidence formats they accept before you standardize.

Questions buyers ask about ID.RA-03 cost, effort and outside help

How much effort does ID.RA-03 take for a mid-sized team?

The effort depends mostly on how many internal and external threat sources the organization must cover, how many log sources and intelligence feeds already exist, and whether threat records are kept in a usable form today. ID.RA-03 asks for threats to be identified and recorded, so the first cycle is usually spent building the threat inventory and agreeing how it is reviewed. Drivers that raise effort include many business units, cloud and SaaS sources without central logging, and no owner for threat records. Ask any partner to size the work from a written list of systems, feeds and review cadences, and to state which parts are one-time and which recur.

Can ID.RA-03 be done in-house with open-source tools?

Yes, many teams do the work in-house, and the open-source options cover the main functions. MISP and OpenCTI can organize threat intelligence and share indicators, Wazuh and OpenSearch Security Analytics can match logs against detection rules, and both record findings for review. Your team still owns the decisions: which actors matter, what the threat register contains, and how threat hunting results feed back into it. Confirm each tool's current capabilities and licensing directly with its project before you commit to a design, since this page only describes what the supplied documentation states.

What does ID.RA-03 need from our own staff?

The work needs people who understand the threat landscape for your sector and people who understand your systems. Security analysts should judge which threat actors and techniques are likely to target you, drawing on sector sharing groups and vendor advisories. System owners should confirm which assets, cloud accounts and suppliers are in scope. HR and legal input is needed for the insider threat process, because it must respect employment law and privacy rules in each jurisdiction. Plan time for these people in the project schedule, not as an afterthought.

How long does ID.RA-03 take to implement?

The duration is set by the agreed scope and by your environment, not by a fixed period. Timing depends on how many log sources need onboarding, whether threat intelligence feeds are already ingested, how quickly approvals move through change management, and how many teams must agree on the insider threat process. A written scope should list the systems, feeds, review cadence and acceptance criteria, and the schedule should follow from those items. Ask any partner to show the dependencies behind each milestone rather than a single overall estimate.

Can an auditor certify ID.RA-03?

No auditor certifies ID.RA-03 as a control on its own, because NIST does not offer certifications or endorsements of CSF implementations and has no conformity assessment program for the framework. An independent assessor reviews your organization's own records, such as the threat register, intelligence sources, review minutes and evidence of threat hunting and insider threat handling, and forms a view on whether they meet the outcome. An implementation partner can prepare the systems and evidence, but only the independent assessor issues any report. For background, read NIST's CSF FAQs.

What should we ask an implementation partner for in a written scope?

A written scope should name the threat sources in scope, the systems and feeds to be onboarded, the tools to be deployed and who operates them, and the records that will be produced. Ask for deliverables such as a threat register template, an intelligence source inventory, detection rules mapped to the threats recorded, a threat hunting procedure, and an insider threat process reviewed by your HR and legal teams. Also ask what the partner will not do, who signs off each deliverable, and what support follows handover. Fixed-scope engagements are agreed in writing before work starts, so every item should appear there.

How do we keep the threat register current after the first audit?

Keeping the register current is recurring work that the organization owns. Set a review cadence, assign an owner, and feed new intelligence, hunting results and sightings into the register as they arrive. MISP and OpenCTI can record sightings and relationships, which helps show when a threat was identified and how it was reviewed. Use change and exception management to record any threat that is accepted without action. Ongoing support, upgrades and continuous testing are available as retainers, but the ownership of the register stays with your team.

How DeployOpen prepares ID.RA-03 threat records and evidence

DeployOpen plans, builds and documents the threat identification and recording capability that ID.RA-03 asks for, inside your own infrastructure. We prepare systems and evidence for your assessment, while your organization owns its controls and an independent assessor makes any formal determination.

How we scope

Engagements are fixed-scope, with the threat sources, platforms and business units covered agreed in writing before work starts.
The written scope names which internal and external threat sources are recorded, and which threat intelligence feeds and hunting activities are in or out.
Scope also records the owners who review threat entries and the evidence the assessor will expect to see for ID.RA-03.

How we build

We deploy self-hosted threat intelligence platforms such as OpenCTI and MISP in your environment, configured to store threat entries with source and date.
We configure detection content in OpenSearch Security Analytics or Wazuh so that threat indicators and actor behavior are matched against your logs.
We set up threat hunting queries and insider threat detection rules, then test them against sample data to confirm they produce recorded findings.

How we hand over

Handover includes configuration documentation, a register of recorded threats, and a mapping from each record to the ID.RA-03 implementation examples.
We provide runbooks describing how analysts add, review, retire and escalate threat records, including how insider threat cases are handled.
Evidence packs list exported records, rule definitions and review logs, so your team and assessor can trace each threat to its source.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering feed changes and platform updates.
Periodic review of threat records and hunting results helps your team keep the register current as likely actors and techniques change.
Your organization decides which threats are accepted, and independent auditors or assessors, not DeployOpen, issue any report or determination.