RA-3(2): Use of All-source Intelligence

The ra-3(2): use of all-source intelligence requirement is easy to misunderstand as “buy a threat intel feed.” That interpretation fails audits because it does not prove the intelligence informed risk decisions. RA-3(2) is an execution requirement: you must incorporate relevant intelligence from multiple sources into how you analyze risk for systems, data, and mission/business processes. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a control-in-the-workflow problem. You need a documented set of intelligence inputs (internal and external), clear ownership for collection and triage, defined triggers for when intel must be reviewed (for example, significant changes or emerging threats), and a repeatable method to translate intel into updates to risk ratings, control selection, remediation priorities, or exception decisions.

This page gives you requirement-level implementation guidance you can hand to operators: what to do, how to prove it ran, and where teams get stuck during exams.

Regulatory text

Requirement (RA-3(2)): “Use all-source intelligence to assist in the analysis of risk.” ¹

Operator interpretation of the text

• “Use” means intelligence must be an input that changes (or confirms) your risk analysis outputs, not a passive reference library.
• “All-source” means you combine multiple categories of intelligence. In practice, that includes internal telemetry and external reporting, curated so it is relevant to your systems and third parties.
• “Assist in the analysis of risk” means intel informs likelihood/impact assumptions, control adequacy, prioritization, and acceptance decisions. ²

Plain-English interpretation (what this control is trying to prevent)

Your risk assessments become stale when they rely only on internal opinions, last year’s incidents, or generic checklists. RA-3(2) pushes you to ground risk analysis in current conditions: what attackers are doing, what vulnerabilities are active, what control failures are occurring, and what is changing in your environment and supply chain. ¹

Who it applies to (entity and operational context)

RA-3(2) applies where NIST SP 800-53 is the governing control baseline, especially for:

• Federal information systems and programs adopting NIST SP 800-53 controls. ²
• Contractor systems handling federal data, including environments supporting federal agencies and regulated federal workloads. ¹

Operationally, you should scope RA-3(2) to:

• Enterprise risk assessments and system-level risk assessments.
• Security authorization / continuous monitoring workflows.
• Change management for high-risk changes (new external exposure, new third party, new cloud service, major architecture shift).
• Third-party risk reviews where external intelligence about the third party meaningfully affects your risk decision (breach reports, exploit activity tied to their product class, systemic supplier compromise patterns).

What you actually need to do (step-by-step)

Use this as a runbook you can assign to an owner and audit.

Step 1: Define “all-source intelligence” for your program

Create a short standard that lists approved intelligence categories and what they’re used for. Example categories:

• Internal sources: security incident tickets, SIEM trends, EDR detections, vulnerability scanning results, pen test findings, abuse reports, help desk security issues.
• External sources: government advisories, vendor advisories, ISAC/ISAO bulletins (if applicable), reputable security research, vulnerability databases, and curated threat intel services.

Write down inclusion rules: relevance to your tech stack, timeliness expectations, and who can approve adding/removing a source.

Practical tip: auditors rarely care about the brand of intel. They care that you can show consistent intake, evaluation, and impact on risk decisions.

Step 2: Assign ownership and an operating cadence

Set named roles:

• Intel owner (often Security Operations / Threat Intel): curates sources, triages items, produces summaries.
• Risk analysis owner (GRC / system owner): consumes summaries and updates risk artifacts.
• Approver (authorizing official / risk committee): validates risk acceptance and major prioritization shifts.

Define when intel must be reviewed:

• Recurring review as part of continuous monitoring.
• Event-driven triggers: major incidents, significant vulnerabilities affecting your stack, major third-party changes, new internet-facing services, mergers/acquisitions, or material architecture changes.

Step 3: Embed intelligence into your risk assessment workflow (make it mandatory)

Update your risk assessment template and procedure so intel is a required input field, not optional narrative. Minimum fields:

• “Intel sources consulted” (list)
• “Items assessed” (advisories, campaigns, exploited vulnerabilities relevant to you)
• “Relevance rationale” (why it applies or not)
• “Resulting changes” (risk rating changes, control changes, remediation reprioritization, monitoring changes)
• “Decision record” (accept / mitigate / transfer / avoid, with approver)

If you use Daydream or another GRC system, configure the workflow so a risk assessment cannot move to “approved” without an intel attachment or link and a completed intel-impact section. This converts a policy requirement into a system-enforced control.

Step 4: Establish an “intel-to-risk translation” method

Teams fail RA-3(2) because they collect intel but do not translate it. Pick a simple, repeatable method:

• Map intel items to affected assets, systems, and third parties.
• Identify exposure conditions (is the vulnerable component deployed, is it internet-facing, is there compensating control coverage).
• Update risk likelihood/impact assumptions based on credible signals (active exploitation, prevalence in your environment, history of similar incidents).
• Create or update risk treatments: patch SLA exceptions, compensating controls, detection rules, segmentation, vendor escalation, or temporary access restrictions.

Keep the method lightweight. Consistency matters more than sophistication.

Step 5: Run control health checks and track remediation to closure

RA-3(2) is ongoing. Schedule periodic checks that confirm:

• Intel reviews occurred on schedule.
• Risk assessments reference intel and record outcomes.
• Remediation items tied to intel are tracked and closed or formally accepted.

Track exceptions. If intel could not be reviewed (staffing gap, tooling outage), log the lapse, assess impact, and record compensating actions.

Required evidence and artifacts to retain

Auditors need traceability from intel input to risk output. Keep an “evidence bundle” per cycle (or per triggered assessment):

1. Control card / runbook

• Objective, scope, owner, triggers, steps, and exception handling.
• Where evidence is stored and retention expectations.

2. Source inventory

• Approved intel sources list with owner and last review date.
• Rationale for each source category.

3. Intel review records

• Meeting notes or tickets documenting what was reviewed and relevance decisions.
• Weekly/monthly intel summaries distributed to risk stakeholders.

4. Risk assessment artifacts

• Completed risk assessments showing intel consulted and resulting changes.
• Risk register entries updated due to intel.

5. Decision and approval trail

• Risk acceptance memos, risk committee minutes, or approval workflows.
• Change tickets tying intel to remediation or monitoring changes.

6. Remediation tracking

• Tickets with due dates, closures, and verification notes.

Common exam/audit questions and hangups

Expect these questions and prepare answers with artifacts:

• “Show me the last risk assessment and where all-source intelligence was used.” Bring the assessment plus the intel summary/ticket referenced.
• “How do you decide which intel sources are credible and relevant?” Show your source inventory and inclusion rules.
• “How does intel change prioritization?” Show before/after risk ratings, reprioritized remediation tickets, or updated control selection.
• “Who owns this control and how do you know it is operating?” Provide the control card and evidence bundle list.

Hangup: teams present a threat intel subscription invoice. That does not show “use” in risk analysis.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “all-source” as “many external feeds.”
   Fix: include internal sources and document how they are considered in risk analysis.

2. Mistake: Intel stays in SOC chat and never reaches risk owners.
   Fix: formalize a distribution path (summary, ticket, or workflow task) and require acknowledgment in the risk process.

3. Mistake: No relevance filter, so intel becomes noise.
   Fix: define relevance criteria tied to your tech stack, deployed products, data types, and third-party dependencies.

4. Mistake: No audit trail from intel to decision.
   Fix: require explicit “impact” fields in risk assessments and keep the approval record with the assessment.

5. Mistake: One-time implementation.
   Fix: add recurring control health checks and remediation tracking so you can show sustained operation.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog. Treat RA-3(2) as a due diligence expectation that becomes visible during audits, customer assessments, and authorization reviews: if you cannot show how you incorporate credible intelligence, your risk analysis can be deemed incomplete, which can cascade into control selection gaps and weak risk acceptance decisions. ²

Practical 30/60/90-day execution plan

First 30 days (stand up the control mechanics)

• Publish a one-page RA-3(2) control card: owner, scope, triggers, steps, evidence, exceptions.
• Build your approved all-source intelligence inventory (internal + external) with credibility/relevance rules.
• Update the risk assessment template to include required intel fields and attachments.
• Pick a storage location for evidence bundles and standardize naming.

Days 31–60 (make it operational and test it)

• Run the first formal intel review cycle and produce an intel summary.
• Perform at least one risk assessment or risk register refresh that explicitly cites the intel reviewed.
• Create remediation or monitoring tickets driven by the intel; track them to closure or documented risk acceptance.
• Run a mini “tabletop audit”: can someone independent follow the trail from intel to risk decision?

Days 61–90 (scale and harden)

• Expand scope to cover key systems and high-risk third parties; confirm triggers are working.
• Add a recurring control health check and a backlog review for intel-driven risk items.
• Train system owners and risk approvers on what “good” looks like in the template.
• If you use Daydream, automate evidence collection prompts and approval gates so the workflow enforces the requirement rather than relying on memory.

Frequently Asked Questions

What counts as “all-source intelligence” for RA-3(2)?

Use a mix of internal security signals (incidents, detections, vulnerabilities) and external intelligence (advisories, vendor notices, reputable threat reporting). “All-source” should be defined in your program with an approved source list tied to your environment. ¹

Do we need a dedicated threat intelligence team to comply?

No. You need clear ownership and a repeatable intake-and-translation workflow. Many teams assign curation to SecOps and require GRC or system owners to document how the intel changed risk decisions.

How do we prove we “used” intelligence rather than just collecting it?

Your evidence must show a trail from intel review to a risk output: changed risk ratings, updated risk register entries, revised control decisions, reprioritized remediation, or documented acceptance with approvals.

How does RA-3(2) relate to third-party risk management?

If third-party products or services affect your threat exposure, external intelligence should feed third-party risk decisions (for example, reassessing a critical third party after widely exploited vulnerabilities in their product category). Record the intel reference in the third-party review artifact.

What if the intel is not applicable to our environment?

Record the relevance decision and rationale (for example, “component not deployed” or “compensating controls reduce exposure”). Auditors accept “not applicable” when you can show the review occurred and the rationale is consistent.

Can we satisfy RA-3(2) with a monthly memo?

A memo helps, but it must connect to risk analysis artifacts. Pair the memo with updated risk assessments, risk register changes, or tickets that show action or acceptance decisions.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5