3.11 RA
635 paragraphs across nine sections. Here is the structure and the decisions that carry the most operational weight in this family.
Document structure
The RA family's three controls form a deliberate chain, and the document is organised to make that chain explicit. The chain is: assess risk (3.11.1) → identify technical vulnerabilities through scanning (3.11.2) → remediate vulnerabilities in order of risk priority (3.11.3). The phrase "in accordance with risk assessments" in 3.11.3 is the link that connects the vulnerability scanning programme to the broader risk management process. An organisation that patches in CVSS score order without reference to a risk assessment of its specific systems and CUI categories cannot fully evidence 3.11.3 — the risk context must inform the remediation prioritisation.
Section 2 covers all three control implementations. The 3.11.1 section embeds the 5×5 likelihood × impact matrix as a full colour-coded table — five likelihood levels, five impact levels, 25 cells each coloured by risk tier (Very High in red, High and Moderate in amber, Low and Very Low in green). Below the matrix are two supporting tables: one defining the five likelihood levels with operational examples, one defining the five impact levels in terms of CUI consequences. These three tables together constitute the documented methodology that assessors expect to see.
Section 3 is the nine-phase annual risk assessment procedure, structured as a specTable with phase, activities, output, and timing columns. The nine phases run from initiation through threat intelligence gathering, asset valuation, risk identification workshop, risk treatment, report production, management review, risk register update, and POA&M integration. Each phase is timed relative to the annual cycle — phase 1 (initiation) starts four weeks before the assessment workshop; phase 2 (threat intelligence) two weeks before; the workshop itself; then the subsequent phases over two to four weeks after the workshop. This gives the CISO a calendar-ready implementation schedule.
Section 4 is the risk register field structure — 17 fields, each with a mandatory/optional designation. The most commonly incomplete fields in assessments are the 'inherent risk rating' (risk before controls are applied) and 'control effectiveness' — organisations jump directly to residual risk without documenting the baseline. The residual risk entry without a corresponding inherent risk and control effectiveness assessment cannot be independently verified by an assessor.
Section 5 is the scanner configuration requirements table, covering 10 configuration items from authentication through to cloud CSPM integration. The authentication item is flagged as the most consequential — unauthenticated scans miss locally installed software versions, Windows patch levels accessible only via registry, and many of the configuration vulnerabilities that drive High and Critical findings. Section 5 exists to prevent the single most common 3.11.2 finding.
The SLA clock — the operationally most consequential technical point
The 3.11.3 implementation contains an explicit, highlighted warning: the patch SLA clock starts at vendor release date, not detection date. This is documented as its own para block in the implementation section, not buried as a bullet, because this single misunderstanding consistently causes organisations to believe they are compliant when they are not.
The scenario is predictable: Microsoft releases a Critical CVE on Patch Tuesday (second Tuesday of the month). The organisation's monthly scan runs in the first week of the following month — 10 to 20 days after the patch was released. The scan detects the vulnerability. The SLA from detection is 7 days, so the organisation has until the end of the second week to patch. They patch in time. The patch tracking register shows "Compliant."
But the SLA from vendor release was 7 days. The vulnerability was detected 10 days after release. The organisation was already 3 days over SLA before the scanner found it. The patch tracking register computed from detection date conceals this.
The practical remediation is a two-column change to the patch tracking register: add a "vendor release date" field populated from NVD (nvd.nist.gov) for each CVE, and configure the SLA deadline column to compute from that date. For currently open vulnerabilities, retroactively populate the vendor release date. Items that were previously shown as compliant may now show as overdue — those become exception register entries with the retrospective documentation of what compensating controls were in place during the gap.
The CISA KEV integration — why it overrides CVSS scoring
The vulnerability scanning schedule table and the remediation SLA table both give CISA KEV entries a special row: 7-day SLA regardless of CVSS score, with an immediate triggered scan. This is because the KEV catalogue represents a different type of evidence than CVSS scoring.
CVSS is a theoretical severity score based on the vulnerability's characteristics in isolation. A KEV entry is empirical evidence — CISA has confirmed that this specific CVE is being actively exploited in the wild. A CVE with a CVSS score of 6.5 (Medium) that appears in the KEV catalogue is more dangerous in practice than a CVSS 9.0 vulnerability with no known exploit. The 7-day KEV SLA, regardless of base CVSS score, reflects this.
The KEV integration also solves an operational problem with monthly scanning: if a Critical vulnerability is released and begins being exploited mid-month, the monthly scan cycle means up to 30 days could pass before detection. KEV integration + triggered scanning within 24 hours closes this detection gap for the highest-risk vulnerabilities.
Shared evidence with AT-SI
The call-out box at the end of the 3.11.2 implementation section makes explicit that EV-D06 (vulnerability scan reports) and EV-D07 (patch tracking register) serve two NIST 800-171 families simultaneously: AT-RA 3.11.2 (scan for vulnerabilities) and AT-SI 3.14.1 (identify, report, and correct flaws). These are technically distinct obligations — RA scans to understand risk; SI identifies flaws for operational security — but they share the same technical implementation and the same evidence items.
An assessor reviewing AT-RA will look at the same scan reports and patch register that an assessor reviewing AT-SI will look at. This is a compliance efficiency worth making explicit in both pages: a gap in the scanning programme creates a dual failure against two separate control families, and a strong scanning programme with well-maintained patch records satisfies both families in a single operational programme.
The risk assessment as the upstream control for the entire ISMS
Section 1 makes the framing point that is often missed in compliance programmes: the risk assessment (3.11.1) is not just one of 110 NIST 800-171 controls — it is the upstream governance mechanism that informs the prioritisation of every other control. The risk register drives the POA&M. The POA&M drives the corrective action register (EV-A04). The corrective action register drives the improvement programme that an ISO 27001 auditor and a CMMC C3PAO will evaluate as evidence that the organisation's ISMS is improving over time rather than being static.
An organisation that implements all 110 NIST controls but has no functioning risk assessment process is, in ISO 27001 terms, missing the engine that drives continuous improvement. The management review cannot be meaningful without a risk assessment input. The POA&M cannot be risk-prioritised without a risk register. The treatment decisions for AT-SC, AT-SI, AT-IA, and every other family should trace back to a risk register entry that explains why those controls were prioritised.
Cross-linking in Confluence
The AT-RA page connects to six other pages with direct operational dependencies. Link to AT-CA (Security Assessment) because the SSP's POA&M is fed by risk treatment action items from EV-C04, and AT-CA documents the POA&M management process. Link to AT-SI (3.14.1 shares EV-D06 and EV-D07 — the vulnerability scanning evidence satisfies both families). Link to AT-CM (vulnerability findings often manifest as configuration deviations — the patch tracking register feeds into the change management process for remediation, and the quarterly config audit in AT-CM catches configuration vulnerabilities that the scanner surfaces). Link to AT-IR (risk assessment threat scenarios inform the incident response playbooks in AT-IR — the top-ranked threat scenarios become the exercise scenarios for the IR exercise programme). Link to AT-AU (SIEM correlation rules in AT-AU are calibrated to the threat scenarios identified in the risk assessment — the risk assessment informs which threat techniques to instrument). And link to 05 · Risk Register (the Confluence section that is the live home of the risk register referenced throughout this page).
Complete NIST 800-171 family library — all 14 families now drafted
With AT-RA complete, all 14 NIST 800-171 family pages are now drafted:
| Page | Controls | CMMC L1 | Status |
|---|---|---|---|
| AT-AC · Access Control | 22 | 4 | Complete |
| AT-AT · Awareness and Training | 3 | 0 | Complete |
| AT-AU · Audit and Accountability | 9 | 0 | Complete |
| AT-CA · Security Assessment | 4 | 0 | Remaining |
| AT-CM · Configuration Management | 9 | 0 | Complete |
| AT-IA · Identification and Authentication | 11 | 2 | Complete |
| AT-IR · Incident Response | 3 | 0 | Complete |
| AT-MA · Maintenance | 6 | 0 | Complete |
| AT-MP · Media Protection | 9 | 1 | Complete |
| AT-PE · Physical Protection | 6 | 4 | Complete |
| AT-PS · Personnel Security | 2 | 0 | Complete |
| AT-RA · Risk Assessment | 3 | 0 | Complete |
| AT-SC · System and Comms Protection | 16 | 2 | Complete |
| AT-SI · System and Info Integrity | 7 | 4 | Complete |
AT-CA (Security Assessment, 4 controls — 3.12.1 through 3.12.4) is the final and keystone document: the SSP master structure, the POA&M management process, the internal security assessment programme, and the continuous monitoring plan that ties all 13 other family pages together into a coherent, assessable compliance programme. It is the document that an assessor reads first before looking at anything else.