ID.RA-02 Threat intelligence: requirements and evidence

What ID.RA-02 asks for and why a feed subscription alone does not meet it

If your organization is being asked to show alignment with NIST CSF 2.0, you are likely looking at ID.RA-02, the Subcategory that asks whether cyber threat intelligence is received from information sharing forums and other sources. ID.RA-02 sits in the Risk Assessment (ID.RA) Category of the IDENTIFY Function. Its outcome is simple to state, but assessors look past the subscription list and ask how intelligence moves from a source into a decision. The identifier continues unchanged from CSF 1.1, where it was ID.RA-2, so an assessment built on the earlier version can be carried forward with its evidence largely intact.

Receiving intelligence is only the start. The outcome implies that the information reaches people and tools that act on it: a security analyst who triages an advisory, a detection engineer who turns an indicator into a rule, or a risk owner who decides whether a threat actor's techniques change the risk register. Organizations often struggle here because they can name their feeds but cannot show a repeatable path from receipt to use. A feed that nobody reviews, or an advisory that never leaves a mailbox, meets the wording of the outcome on paper but not in practice.

Before you commit budget to new feeds, confirm three things: which sources you rely on and why, who receives each one, and what records prove that intelligence changed a control, a detection or a decision. Illustratively, a team that subscribes to four feeds but cannot show one indicator that reached a detection rule in the last quarter has a subscription list, not a process. The NIST Implementation Examples for ID.RA-02 are a useful checklist for these questions, and the NIST CSF 2.0 Reference Tool export lists them alongside the informative references.

Which feeds, tools, teams and suppliers fall under ID.RA-02

ID.RA-02 covers how threat intelligence arrives, where it lands and who acts on it. Each decision below changes how many sources, tools, people and third parties your evidence must cover, so settle them in writing before estimating effort.

Intelligence sources in scope

Decide which sharing communities, commercial feeds, government alerts and vendor advisories count as sources the organization relies on. Each source you name becomes something an assessor can ask about: who subscribed, how often it is reviewed and what happened to the indicators it produced. Fewer, well-documented sources usually produce stronger evidence than a long list nobody reviews. Confirm the list with the owner of each subscription.

Sharing community agreements

Membership in an information sharing forum often carries rules on distribution, attribution and handling of shared material. Check whether those rules limit what your tools may ingest or redistribute, and whether they require your own feed to share back. Record the agreement version and the people authorized to act on shared content, since an assessor will ask who can see what.

Security tools that ingest feeds

Identify each tool that consumes intelligence: SIEM, EDR, firewalls, intrusion detection and vulnerability management. Each one needs a defined feed, a defined owner and a defined action when a match occurs. Tools that receive indicators but never alert or block make the outcome hard to show. Ask every platform owner which feed formats it accepts and whether ingestion is logged.

Teams that read threat actor advisories

Decide which team reads advisories on threat actors and their tactics, techniques and procedures, and how those readings reach detection engineering, incident response and risk owners. A shared inbox without an owner rarely satisfies this outcome. Name the role responsible for review, the cadence agreed for it and the record that shows the advisory was actioned or dismissed with a reason.

Platforms that correlate and share intelligence

If you run a platform such as MISP or OpenCTI, decide who administers it, which distribution levels apply and whether it synchronizes with other instances. Self-hosting moves patching, backup and access control onto your team. Confirm the hosting boundary, the admin accounts and how sharing groups are reviewed, because the platform itself becomes an asset that needs protecting.

Managed providers handling intelligence

Decide whether a managed security provider receives intelligence on your behalf, triages it or acts on it. Contract terms should state what the provider reviews, what it may do without approval and how it reports actions back to you. Accountability for the outcome stays with your organization, so confirm how the provider's records are shared with your evidence file before the engagement starts.

How an assessor tests ID.RA-02 threat intelligence intake

This table walks through the four steps an assessor is likely to take for ID.RA-02, with the evidence requested at each step and the findings that commonly appear. Read it as a preparation checklist: for each row, confirm you can produce the named record before an assessment starts.

Assessor step	What the assessor checks	Evidence requested	Common findings
1. Confirm sources	Which threat intelligence sources the organization subscribes to, joins or receives, and why each was chosen	Source register with owner, source type, access terms and review date; sharing community memberships	Feeds configured but unmonitored; sources with no documented owner
2. Sample feed configuration	That selected feeds are ingested into detection and response tools through a defined, secured path	Connector or TAXII configuration exports, feed import logs, sample indicators with timestamps, access control on feed credentials	Feeds enabled but silently failing; stale credentials; no alert when an ingestion job stops
3. Review advisory triage	How advisories on threat actors and their TTPs are read, categorized and assigned, and who acts on them	Triage tickets or threat intelligence records, assignment history, named reviewer for each advisory class, escalation criteria	Advisories read but not recorded; no evidence of who decided the action
4. Trace intelligence into work	That intelligence changes vulnerability priorities, detection content or hunts, not just a reading list	Detection rule change records, vulnerability tickets citing an advisory, hunt reports, sightings or matches linked to a source	Intelligence reviewed but never reflected in detection or vulnerability work; no link back to the source

Setting up threat intelligence intake in sequence

This sequence turns ID.RA-02 from a general intention into a working intake path, where named sources feed a chosen platform, indicators reach detection tools only after approval, and advisories on threat actors are reviewed on a schedule. Each step ends with an artifact an assessor can inspect.

Name an owner and list sources in scope
Assign one accountable owner, usually the head of security operations or the threat intelligence lead, and write down every intelligence source the organization will use. Sources typically include information sharing forums the organization belongs to, national computer security incident response teams, sector bodies, vendor advisories, and commercial or open feeds. For each source, record the owner, the data type (indicators, reports, advisories), the sensitivity and handling rules, and whether its terms allow sharing inside the organization. The step closes with a signed intake charter or a source register that names the owner and lists each approved source. Confirm the sharing terms of any forum with its operator before you rely on it.
Select and deploy the intelligence platform
Choose the platform that will store, correlate and distribute intelligence, and deploy it inside the organization's own infrastructure. Two open-source options fit this work. MISP (AGPL-3.0-only) correlates indicators by exact match and advanced patterns, synchronizes events between instances with sharing groups, records sightings and exports to STIX, CSV and Suricata, Snort and Zeek rule formats. OpenCTI (Apache-2.0) models intelligence as STIX-based entities and relationships and ingests data through connectors. Test both against the source register before choosing. The step closes with an architecture note, a hosting record and a platform decision approved by the owner. Confirm licensing obligations, such as AGPL source availability duties, with counsel before modification.
Configure feeds and connectors securely
Connect each approved source to the platform through its supported method, such as a connector, TAXII, RSS, CSV or JSON feed, or manual upload. Store API keys and credentials in a secrets manager, restrict outbound access to the feed endpoints, validate and sanitize incoming data, and limit each connector to the minimum permissions it needs. Enable logging of ingestion events so that each feed's activity can be traced. The step closes with a configuration baseline, a connector inventory showing source, method and owner, and test results showing that malformed or unexpected input is rejected or quarantined.
Route indicators to detection tools with approval
Define the rules that decide which indicators move from the platform into detection and response tools such as SIEM rules, intrusion detection signatures or endpoint blocklists. Require that an analyst review and approve indicators before they reach blocking controls, and separate low-confidence indicators, which may only feed monitoring, from high-confidence ones. Record the expiry or review date for each indicator so stale data does not persist. Where the platform exports to Suricata, Snort or Zeek formats, check each generated rule in a test environment first. The step closes with a written approval workflow, a routing matrix mapping indicator types to target tools, and a sample of approved and rejected indicators with reasons.
Set up recurring review of threat actor advisories
Schedule a recurring review of advisories on threat actors and their tactics, techniques and procedures. The reviewer compares each advisory against the asset inventory and existing detection coverage, notes which techniques the organization cannot currently detect, and opens a tracked item for each gap. NIST's Implementation Examples for ID.RA-02 describe this review of TTPs directly. Set the review cadence in the intake charter and assign a named backup reviewer. The step closes with a review calendar, a log of completed reviews and a backlog of detection gaps linked to tickets or risk items.
Record how intelligence affects risk decisions
Link each intelligence item that changes the organization's understanding of threats to the risk process. When an advisory names an actor targeting a sector or technology the organization uses, record it in the risk register as an input to likelihood, and reference it in ID.RA-03 threat identification and ID.RA-05 inherent risk prioritization. Document any resulting risk response, such as a control change, a compensating measure or an accepted risk, and note the decision owner. The step closes with register entries that cite the intelligence source, a sample of traced decisions from intelligence item to risk record to response, and a short report to the risk owner summarizing the period's changes.
Verify the intake path before assessment
Before an internal or independent assessment, test the full path end to end with a sample item: receipt from a source, ingestion, analyst approval, routing to a detection tool and recording in the risk register. Compare the evidence against the source register and the approval workflow, and close any gaps the test reveals. Keep the test record, because it shows whether the process operates as written. Independent auditors and certification bodies decide whether the evidence meets a given requirement; this check only prepares the organization for that review.

Evidence that shows ID.RA-02 is working between audits

ID.RA-02 is met by a running process, not a one-time setup, so assessors look for records that accumulate over time. The cards below cover the artifacts that connect a threat source to a configured tool, a reviewed advisory and a decision the organization actually changed. Each one needs an owner and a refresh routine, because a dated export from last year proves little about today.

Threat intelligence source register

This is the list of every information sharing forum, commercial feed, government advisory channel and vendor bulletin the organization relies on for threat intelligence. For each source, record the owner, the purpose, the access method, the review frequency and the date the source was last confirmed as still in use. An assessor uses this register to ask why a source was chosen and who is accountable for it. Ask the owner to review the register on a fixed schedule and keep the dated versions, since a register that never changes suggests nobody is checking it.

Platform and connector configuration exports

Exports from the threat intelligence platform, such as the connector settings in OpenCTI or the feed and sharing configuration in MISP, show how sources are actually wired in. Capture the enabled connectors, feed URLs without credentials, distribution settings and sharing groups. Store each export with a date and the name of the person who approved the configuration change. Many platforms let administrators export settings, but confirm the exact export options for your version and check that secrets are removed before the file is retained.

Feed ingestion logs

Ingestion logs show that feeds arrived, when they arrived and whether they failed. An assessor can compare these logs against the source register to find sources that are listed but silent, or feeds that stopped working without anyone noticing. Keep logs for a retention period the organization sets in its own policy, and review failed ingestions as a recurring task with a ticket for each unresolved failure. Confirm where your chosen platform writes these logs and whether they can be forwarded to your central log store.

Triaged intelligence and sighting records

Triage records show what happened after an indicator or report entered the platform: whether it was discarded, correlated with existing data, linked to an asset or escalated. Sightings record that an indicator was observed in the environment, and they are the strongest evidence that intelligence was used rather than just stored. MISP records sightings natively, and OpenCTI can link observables and reports to other entities, but triage decisions usually require a documented analyst step. Sample a set of triaged items each review cycle and confirm the decision and reasoning are recorded.

Dated advisory review notes

Advisory review notes record which threat actor reports and their tactics, techniques and procedures were read, by whom and on what date, and what the reviewer concluded for the organization. NIST's Implementation Examples for ID.RA-02 include reviewing advisories on threat actors and their TTPs, so this is the record that matches that example. Tie each note to a named threat actor or campaign where possible, and note any follow-up action. A monthly or quarterly review log with entries signed by the reviewer is easier to defend than a collection of unconnected reading notes.

Tickets and risk register entries

The strongest evidence links intelligence to a decision. A ticket, change request or risk register entry that cites a specific threat report and shows a changed control, patch priority, detection rule or accepted risk demonstrates that intelligence informed the program. Link these records to the source and the triage entry so an assessor can follow the chain from feed to decision. Confirm that the register or ticketing system keeps the reference after closure, because a record that disappears when a ticket is archived breaks the chain.

What threat intelligence intake costs to run

This table breaks down the cost components of receiving and operating threat intelligence intake for ID.RA-02, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price figures are supplied for these components.

Cost component	Who is paid and for what	One-time or recurring	Main cost drivers
Commercial or community feed subscriptions	Feed providers, for access to indicators, reports or advisories	Recurring	Number of feeds, data volume, sharing or redistribution rights, and whether the license covers your partners
Platform licensing for self-hosted open source	Usually none for MISP (AGPL-3.0-only) or OpenCTI (Apache-2.0) software; labor is still required	Mostly one-time setup, with recurring support if bought	Choice of commercial support contract, managed hosting, or paid add-ons from third parties
Hosting and maintenance of the intelligence platform	Your cloud or data center team, or an implementation partner under a written scope	Recurring	Instance count, storage for indicators and sightings, high availability needs, patching and upgrade frequency
Engineering for connectors and detection integration	Your engineers or an implementation partner, to configure TAXII, RSS, CSV and JSON feeds and export rules to detection tools	One-time, with recurring changes as sources change	Number of sources, number of detection tools receiving rules, format conversions, and testing needed before rules go live
Analyst time for triage and advisory review	Your security analysts, reviewing advisories on threat actors and their TTPs and deciding what to act on	Recurring	Volume of alerts and advisories, depth of sector relevance filtering, and the number of threat actors you track
Sharing governance and sharing group administration	Your security or legal staff, setting distribution levels and sharing group membership	One-time setup, with recurring reviews	Number of information sharing partners, sharing agreements, and how often membership changes
Evidence upkeep for ID.RA-02	Your compliance or security staff, keeping feed lists, configurations, review records and sample outputs current	Recurring	Frequency of assessment, number of teams involved, and whether evidence is collected automatically from the platform
External review or sampling by an assessor	Independent auditor or assessor, who tests samples; NIST does not certify CSF implementations	Recurring per assessment cycle	Scope of the assessment, number of samples requested, and how well records are organized before the review starts

How MISP and OpenCTI can produce intake evidence

ID.RA-02 asks an organization to show that cyber threat intelligence actually arrives and is used. MISP and OpenCTI are two self-hosted open-source platforms that can record that intake as data, from feed ingestion through sharing and sighting history. The cards below cover what each platform records, where it fits, and what to confirm before relying on it as evidence.

MISP for indicator correlation and sharing

MISP correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, so an assessor can see which received indicators matched assets or prior events. Its synchronization between instances uses granular distribution levels and sharing groups, which records who received what and under which rules. Check that your deployment's distribution settings and sync partners are documented, because those settings are what an assessor will ask to see.

MISP sightings and rule exports

MISP records sightings, which log when an indicator was observed in your environment, creating a dated trace from intelligence to detection. Its REST API exports events to STIX 1 and 2 and CSV, and to Suricata, Snort and Zeek rule formats. Confirm which export formats and API endpoints your MISP version supports, and keep a sample export and sighting log as evidence that intelligence reached detection tooling.

OpenCTI for structured threat knowledge

OpenCTI organizes intelligence as STIX-based entities, relationships and containers, such as threat actors, campaigns and reports linked to observables. This structure lets reviewers trace how an advisory on a threat actor's TTPs connects to the indicators your team received. Confirm that your analysts use the relationship model consistently, because inconsistent linking weakens the evidence even when feeds are flowing.

OpenCTI connectors and ingestion paths

OpenCTI ingests data through connectors and TAXII, RSS, CSV and JSON feeds, or manual file upload, so each intake path can be logged separately. Record which feed or connector delivered which data, when it last ran and who approved it. Connector availability depends on the version you deploy, so confirm the connector list and any native feed options with the OpenCTI project before you commit to a source list in your evidence.

Licensing and version checks

MISP is licensed AGPL-3.0-only and OpenCTI is licensed Apache-2.0, and the two licenses carry different obligations when you modify and distribute code or run it as a network service. Have counsel review the terms that apply to your deployment, including any customization. Confirm with each vendor which connectors, sharing features and export formats your exact version supports, and record that version in your intake evidence.

Who owns intelligence intake and what a partner can take on

Your organization owns the intelligence program itself. Source selection, the decision about which intelligence changes risk ratings or triggers action, and any obligations to share indicators with peers or authorities stay with your leadership and security team. The analyst who reviews advisories on threat actors and their tactics, techniques and procedures also remains an internal responsibility, because that review shapes your risk register and detection priorities.

Source selection: Decide which information sharing forums, commercial feeds and government advisories you trust, and record why each one is in scope.
Risk decisions: Decide how intelligence affects likelihoods, priorities and risk responses, and document those decisions.
Sharing obligations: Confirm what you may receive, what you may redistribute, and under which contractual or regulatory terms.
Advisory review: Assign a named analyst to read advisories on threat actors and record what changed in your environment.
Ownership of the outcome: Accept that the control is yours even when a partner builds the pipeline.

Before engaging anyone, confirm internally who signs off on source selection and sharing rules.",

Where threat intelligence programs usually fall short

Most threat intelligence programs fail ID.RA-02 not for lack of feeds but because intelligence arrives without an owner, a destination or a record. The gaps below are the ones assessors most often find when they ask how received intelligence changed what the organization did.

Feeds subscribed but never ingested

Subscriptions to sharing forums, vendor advisories and commercial feeds often sit in inboxes or portals while the SIEM, EDR and vulnerability tools never receive the data. An assessor testing ID.RA-02 will ask to see an indicator from a named feed inside a detection tool. Check each subscribed source against a documented ingestion path, and confirm that the tool configuration, not a person's memory, carries the feed. Where a feed is not ingested, record why and whether that is accepted.

No named owner per source

When no one is accountable for a given source, its advisories are read by whoever notices them, and volume drops off without anyone deciding to stop. ID.RA-02 expects intelligence to be received deliberately, so each source needs an owner who decides whether it stays subscribed, how often it is reviewed and who acts on it. Keep a short register listing source, owner, review cadence and the backup owner for absences.

Intelligence not linked to vulnerability or detection work

An advisory about a threat actor exploiting a specific product has little value if it never reaches the patching queue or a detection rule. Assessors look for a traceable path from a received item to a resulting action, such as a ticket, a new rule or a vulnerability priority change. Pick a recent advisory and follow it end to end. If the trail stops at the reader, the process is not yet operating as the subcategory describes.

Sharing terms not checked in use

Information sharing communities often attach distribution limits, such as sharing groups or handling restrictions, to the intelligence they provide. Once that material is ingested and exported, those limits can be broken without anyone noticing, for example when an internal platform pushes indicators to a partner. Map each agreement to the tool settings that enforce it, and test that restricted events are not synchronized beyond their permitted audience. MISP, for example, exposes distribution and sharing group settings that the team must configure and verify.

No dated record of advisory review

Assessors cannot credit a review that cannot be shown. Many teams read advisories daily but keep no dated log of what was received, who reviewed it, what was decided and what happened next. Create a simple record for each relevant advisory with the date received, reviewer, relevance decision and linked action or reason for no action. Retain it under the organization's records policy and sample it before an assessment to confirm it is complete.

What buyers ask about ID.RA-02 threat intelligence

How much does it cost to meet ID.RA-02 threat intelligence?

The cost depends mostly on how many feeds you ingest, how many people review advisories, and whether you pay for commercial intelligence. NIST does not publish a price for ID.RA-02, so no figure can be quoted from a source. The main cost components are staff time to triage and act on intelligence, the platform (hosting and administration), any paid feeds or memberships in sharing communities, and outside help to set things up. Ask any provider for a written scope that lists the feeds, tools, integrations and deliverables included, then compare quotes on that basis. Recurring costs usually include feed subscriptions, hosting, and staff time, while setup work is typically one-time.

How long does setting up threat intelligence ingestion take?

Setup length depends on the number of sources, the state of your existing security tools, and how much your team must define before work starts. A narrow scope, such as one sharing community and one detection platform, moves faster than a program that spans many feeds and business units. No duration is supplied for this work, so ask any provider to state the timeline in the written scope and to list the dependencies it assumes, such as access to your SIEM or EDR. Confirm which milestones are fixed and which depend on your team's decisions.

What does the internal team need to provide?

The organization owns its controls, so the internal team must decide what intelligence matters and what action each source triggers. In practice this means:

A named owner for threat intelligence who accepts or rejects sources
Access to the security tools that will consume indicators, such as detection and response platforms
Staff time to review advisories on threat actors and their TTPs, and to act on them
A documented process for sharing indicators and recording sightings

An implementation partner can prepare the platforms and integrations, but it cannot decide your risk priorities for you.

Can a small security team run threat intelligence without outside help?

Yes, a small team can run threat intelligence internally if it has a clear scope and enough time to review what arrives. NIST describes the outcome as receiving intelligence from information sharing forums and other sources, which a small team can meet with a few curated sources and a clear review routine. The harder part is sustained triage, so a small team should limit ingestion to sources it can actually review. Outside help is most useful for initial configuration, secure feed ingestion and documentation. Ask any provider which parts it would hand over to your staff and which it would keep.

Do self-hosted tools remove license costs for threat intelligence?

Self-hosted open-source platforms remove per-seat or platform license fees, but they do not remove all costs. MISP is published under AGPL-3.0-only and OpenCTI under Apache-2.0, so the software itself carries no license fee for the use described here. You still pay for infrastructure, administration, updates, integrations, and any commercial feeds you subscribe to. Confirm the license terms with the project before deployment, especially if you plan to modify the code or offer it to third parties.

What will an assessor ask to see for ID.RA-02?

An assessor will typically ask how your organization identifies intelligence sources, who reviews them, and how the output reaches decisions. Expect requests for a list of intelligence sources and the reasons for selecting them, configuration records showing how feeds are ingested into tools, records of advisories reviewed and actions taken, and evidence of sharing or sightings where you participate in information sharing. Assessors also check that the process runs in practice, not only on paper. The assessment is performed by an independent auditor or assessor, and NIST does not offer certifications for the CSF, so confirm the evidence expectations with your assessor before you start.

How do MISP and OpenCTI differ for ingesting threat intelligence?

Both are self-hosted open-source platforms, but they emphasize different workflows. MISP correlates indicators by exact match and advanced patterns, synchronizes events between instances with sharing groups, records sightings, and exports rules in Suricata, Snort and Zeek formats through its REST API. OpenCTI organizes intelligence as STIX-based entities and relationships and ingests data through connectors and TAXII, RSS, CSV and JSON feeds. Many teams evaluate both against their sharing community and detection stack. Confirm the connectors and export formats you need with each project's current documentation before selecting one.

How DeployOpen scopes and implements ID.RA-02 intake

DeployOpen treats ID.RA-02 as an intake problem: which sources you receive threat intelligence from, how feeds reach your detection and response tools, and who reviews advisories on threat actors. We set up self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and we prepare the records an assessor would ask to see. Your organization keeps ownership of its controls and decisions throughout.

How we scope

We agree in writing which threat intelligence sources, information sharing forums and feed types are in scope for ID.RA-02.
We record which internal tools will consume intelligence, such as SIEM, EDR or detection rules, and who owns each one.
We confirm with you whether an independent assessor will test ID.RA-02 and what evidence that assessor expects to see.

How we build

We deploy a self-hosted threat intelligence platform, such as MISP or OpenCTI, within your infrastructure and configure access controls.
We configure feed ingestion and sharing groups so intelligence reaches approved tools through documented, reviewable paths.
We test that indicators correlate and export to your detection formats, and we document the tests and their results.

How we hand over

We deliver configuration records, feed inventories, data flow notes and procedures for reviewing advisories on threat actors and their TTPs.
We document who receives, triages and acts on intelligence, with the review cadence you approve.
We walk your team through the evidence set so your staff can maintain and explain it to an assessor.

How we support

Engagements are fixed-scope, so changes to sources, platforms or tooling are handled through a written change to the agreed scope.
Ongoing support, upgrades and continuous testing of the intake pipeline are available as a retainer.
Your auditor or certification body issues any report or attestation. DeployOpen prepares the systems and evidence for that review.