Risk Assessment Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the RA control family policy (POL-RA). It covers every control in the risk assessment family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the RA family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the high security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• GV.RM — Risk Management Strategy (Govern function)
• GV.OV — Oversight (Govern function)
• ID.AM — Asset Management (Identify function)
• ID.RA — Risk Assessment (Identify function)
• ID.IM — Improvements (Identify function)
• DE.CM — Continuous Monitoring (Detect function)

3. Controls Covered #

This procedure covers the following 14 controls in the RA family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the RA control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

NIST SP 800-30: Guide for Conducting Risk Assessments

• The organization must ensure risk assessments evaluate threats, vulnerabilities, impact to missions and business operations, and the likelihood of threat exploitation. Assessments must be conducted at all three tiers: organization, mission/business process, and information system. (NIST SP 800-30r1, §2)
• The organization must ensure risk assessments are updated periodically and whenever significant changes occur. The assessment must produce a risk report that identifies risk levels, prioritized risks, and recommended mitigations. Deadline: Periodically + on significant change. (NIST SP 800-30r1, §3)

NIST SP 800-39: Managing Information Security Risk

• The organization must manage information security risk at three tiers: Tier 1 (organization), Tier 2 (mission/business process), and Tier 3 (information system). Risk management must be integrated into all levels of the organization. (NIST SP 800-39, §2)

OMB M-19-03: Management of High Value Assets

• The organization must identify, inventory, and prioritize High Value Assets (HVAs) — systems that hold sensitive data or support critical missions. HVAs require enhanced security controls, more frequent assessments, and prioritized remediation. (OMB M-19-03, §1)
• The organization must identify, categorize, and prioritize High Value Assets (HVAs) using the OMB-defined categories (informational value, mission essential, federal civilian enterprise essential), and maintain the HVA inventory with annual review and submission to DHS/CISA. (OMB M-19-03, §A)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization should review the vulnerability reports from each FedRAMP authorized provider at intervals that match the system’s authorization, using automated processing of the provider’s machine-readable data. (FedRAMP Consolidated Rules for 2026, VER-AGM-RVR)
• The organization should use the provider’s vulnerability reports to keep the Organization’s own POA&M items when the Organization mitigates a provider vulnerability or accepts continued use with one. (FedRAMP Consolidated Rules for 2026, VER-AGM-MAP)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the RA controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Risk Assessment family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Risk Manager carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the RA policy (POL-RA) for the role definitions.

4.2 Control-Specific Procedures #

RA-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.RM (Risk Management Strategy), ID.RA (Risk Assessment)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] risk assessment policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the risk assessment policy and the associated risk assessment controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the risk assessment policy and procedures; and
3. Review and update the current risk assessment:

1. Policy at least annually and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO maintains POL-RA and PROC-RA on a standing review record in the policy library in the document management system. Every year, the CISO’s office collects input from the Authorizing Official (AO), System Owners, Information System Security Officers (ISSOs), and the assessment practitioners who use the procedures. The CISO’s office compares the documents with current mission, technology, and threat conditions. It then sends the revision to the CISO for approval.

The CISO’s office opens the same review out of cycle after a change in mission, business processes, information technologies, system architectures, or the threat environment. The CISO’s office distributes each approved version to the AO, System Owners, ISSOs, and key stakeholders. It records the distribution and withdraws the superseded version.

Evidence: the review records with the collected input, the approved revisions and their history, the CISO sign-offs, and the distribution records for each version.

RA-02 — Security Categorization #

Baselines: Low / Moderate / High CSF 2.0: GV.RM (Risk Management Strategy), ID.RA (Risk Assessment)

1. Categorize the system and information it processes, stores, and transmits;
2. Document the security categorization results, including supporting rationale, in the security plan for the system; and
3. Verify that the authorizing official or authorizing official designated representative reviews and approves the security categorization decision.

Procedure:

At system initiation, the System Owner and the ISSO identify the information types the system will process, store, and transmit, using the information types in NIST SP 800-60. They assign each type a Federal Information Processing Standards (FIPS) 199 impact level of low, moderate, or high for confidentiality, integrity, and availability. They then apply the high-water mark: the highest impact level across all types and all three objectives becomes the system category. The System Owner documents the information types, the impact levels, and any adjustments, with the rationale, in the System Security and Privacy Plan (SSPP).

The CISO’s staff reviews the categorization for consistency with organizational practice. The AO or designated representative then records approval of the categorization decision. The approved category sets the control baseline. Where the thresholds are met, it also feeds the Organization’s High Value Asset identification under Office of Management and Budget (OMB) M-19-03.

When the information types, mission use, or architecture change, the System Owner repeats the categorization and the approval path before the Organization treats the change as authorized.

Evidence: the SSPP categorization section with its information types and rationale, the recorded approvals, and the re-categorization records tied to system changes.

RA-03 — Risk Assessment #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.RM (Risk Management Strategy), GV.OV (Oversight), ID.RA (Risk Assessment), ID.IM (Improvements)

1. Conduct a risk assessment, including:

1. Identifying threats to and vulnerabilities in the system;
2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and
3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;

2. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;
3. Document risk assessment results in security assessment report;
4. Review risk assessment results at least annually and whenever a significant change occurs;
5. Disseminate risk assessment results to [Assignment: organization-defined personnel or roles — to be defined]; and
6. Update the risk assessment annually or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.

Procedure:

The ISSO leads each system’s risk assessment with the System Owner. The team gathers the inputs first: the system’s categorization, its architecture and data flows, vulnerability scan results, assessment findings, incident history, and threat information. The team identifies threats and vulnerabilities and rates the likelihood and impact of each. The ISSO coordinates the privacy analysis of effects on individuals from personally identifiable information (PII) processing with the Senior Agency Official for Privacy (SAOP). The team writes the results into the Risk Assessment Report with prioritized risks and recommended responses. The team rates each risk with the scales in the Risk Management Strategy (PLAN-RMS-001). The ISSO records each risk rated Moderate or higher in the system’s risk register entries in the governance, risk, and compliance (GRC) system, using the Cybersecurity Risk Register Template.

The team distributes the report at a minimum to the AO, the System Owner, and the ISSO. The ISSO reconciles its conclusions with organization-level and mission-level risk decisions so the tiers agree.

The team reviews the assessment every year or when a significant change occurs, and updates it every year within continuous monitoring and ongoing authorization. An interim change that alters the risk picture requires an out-of-cycle update, which the ISSO tracks in the GRC system.

Evidence: the Risk Assessment Report versions, the input artifacts, the distribution records, and the review and update records in the GRC system.

RA-03(1) — Supply Chain Risk Assessment #

Baselines: Low / Moderate / High

1. Assess supply chain risks associated with [Assignment: organization-defined systems, system components, and system services — to be defined]; and
2. Update the supply chain risk assessment [Assignment: organization-defined frequency — to be defined], when there are significant changes to the relevant supply chain, or when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain.

Procedure:

For each in-scope system, whether it supports a mission essential function or is a High Value Asset, the CISO team assesses supply chain exposure. The team identifies the suppliers and service providers behind the system, the components whose compromise or disruption would matter most, and the events the Organization would need to withstand. The team records the results with the system’s risk documentation. The results feed the Risk Assessment Report and the Organization’s decisions about suppliers. The CISO team refreshes the assessment [RA-03(1) parameter 2 — to be defined] on the schedule in the GRC system, and sooner when the supply chain, the system, or its environment changes materially. Evidence: the recorded assessments, the refresh records in the GRC system, and the risk documentation they updated.

RA-05 — Vulnerability Monitoring and Scanning #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), ID.RA (Risk Assessment), DE.CM (Continuous Monitoring)

1. Monitor and scan for vulnerabilities in the system and hosted applications monthly operating system/infrastructure; monthly web applications (including APIs) and databases and when new vulnerabilities potentially affecting the system are identified and reported;
2. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:

1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;

3. Analyze vulnerability scan reports and results from vulnerability monitoring;
4. Remediate legitimate vulnerabilities high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery in accordance with an organizational assessment of risk;
5. Share information obtained from the vulnerability monitoring process and control assessments with [Assignment: organization-defined personnel or roles — to be defined] to help eliminate similar vulnerabilities in other systems; and
6. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.

Procedure:

Scanner agents on servers, workstations, and laptops report vulnerabilities continuously. Authenticated vulnerability scans cover assets without an agent on the cadence for each asset class: operating system and database scans every month, web application scans every month, and verification scans on request. The vulnerability management team updates the detection content within 24 hours of each vendor release. The team also confirms that results reach Cybersecurity and Infrastructure Security Agency (CISA)’s Continuous Diagnostics and Mitigation (CDM) Agency Dashboard within 72 hours.

Before a firewall rule or new service exposes a system to the internet, the team runs an authenticated scan of the target hosts, plus a web scan for web services. The team approves the exposure only when no critical finding and no past-due high finding remain, and records the result on the change ticket.

The ISSO analyzes new findings, documents false positives with evidence, and sends critical and high findings to the Security Operations Center on identification. Each finding’s due date is the earliest of the Binding Operational Directive (BOD) 26-04 Table 1 timeline, its severity timeframe, and any CISA directive deadline. The severity timeframes are 30 days for critical, 30 for high, and 60 for moderate. Remediation work orders become tickets in the ticketing system. A finding not fixed by its due date becomes a plan of action and milestones (POA&M) item in the GRC system. A rescan or agent report verifies each closure. The CISO tracks open findings and repeat weaknesses across systems.

Evidence: the scanner findings and coverage reports, pre-exposure scan results, remediation tickets with due dates, POA&M items for late findings, the Security Operations Center (SOC) notifications, and the CISO’s trend reports.

RA-05(2) — Update Vulnerabilities to Be Scanned #

Baselines: Low / Moderate / High

Update the system vulnerabilities to be scanned within 24 hours prior to running scans.

Procedure:

Before each scheduled scan, the System/Application Administrators update the scanner vulnerability content and verify the update. The administrators refresh the content and scan the affected assets without waiting for the schedule when someone identifies and reports a new vulnerability between cycles. The administrator records the content version and update time with each scan cycle’s results, so every report shows what the scanner knew when it ran. Evidence: the update and verification records for each scan cycle, and the off-cycle scan records for newly reported vulnerabilities.

RA-05(3) — Breadth and Depth of Coverage #

Baselines: Moderate / High

Define the breadth and depth of vulnerability scanning coverage.

Procedure:

The CISO defines coverage before anyone measures it. The CISO documents the breadth, meaning the asset population in scope by system and type, and the depth the scanning must reach. Each cycle, the ISSO reconciles what the vulnerability scanner actually scanned against the system inventory. The ISSO investigates gaps such as unreachable hosts, authentication failures, and missing assets. The ISSO opens a ticketing system ticket for each gap and keeps it open until scanning is restored or the exposure is formally accepted. The ISSO reports coverage results with each scan cycle so trends stay visible. Evidence: the documented coverage definition, the reconciliation records, the gap tickets, and the cycle coverage reports.

RA-05(4) — Discoverable Information #

Baselines: High

Determine information about the system that is discoverable and take notify appropriate service provider personnel and follow procedures for organization and service provider-defined corrective actions.

Procedure:

The Information System Security Officer (ISSO) reviews what each system shows to outside parties, using vulnerability scans results for service banners, version strings, and open ports. The ISSO also searches public sources, such as websites and published documents, for system details. Reports from outside researchers arrive through the vulnerability disclosure platform, where the Security Operations Center (SOC) triages them. For each finding, the ISSO records the exposed information and its risk in the GRC system. The System Owner then takes notify appropriate service provider personnel and follow procedures for organization and service provider-defined corrective actions. The ISSO confirms the change.

Evidence: scan results, public search notes, triage decisions in the vulnerability disclosure platform, and finding records with closure dates in the GRC system.

RA-05(5) — Privileged Access #

Baselines: Moderate / High

Implement privileged access authorization to all components that support authentication for all scans.

Procedure:

Each System Owner authorizes dedicated scanning accounts for the components in scope. The Organization provisions the accounts for scanner credentialed scanning and restricts them from any other use. Each cycle, the ISSO checks the scan authentication results. Where privileged scanning succeeded, the scan assesses the component for vulnerabilities and configuration benchmark deviations. Where authentication failed, the ISSO opens a ticketing system ticket and rescans the component once access is repaired. The Organization handles the scanning account credentials under its protections for privileged credentials. Evidence: the access authorizations, the per-cycle authentication reports, the remediation tickets for failures, and the credentialed scan results.

RA-05(8) — Review Historic Audit Logs #

Baselines: High

Review historic audit logs to determine if a vulnerability identified in a [Assignment: organization-defined system — to be defined] has been previously exploited within an [Assignment: organization-defined time period — to be defined].

Procedure:

When the vulnerability scanner reports a new vulnerability in [RA-05(8) parameter 1 — to be defined], the Information System Security Officer (ISSO) identifies the log sources that would show an attack on it. The ISSO searches those audit logs for the preceding [RA-05(8) parameter 2 — to be defined]. The search looks for signs tied to the vulnerability, such as unusual requests, unexpected accounts, or unexplained data transfers. If the ISSO finds signs of an attack, the ISSO opens an incident with the Security Operations Center (SOC) and notifies the System Owner and Chief Information Security Officer (CISO). The ISSO records the search scope, method, and result in the GRC system against the vulnerability finding.

Evidence: the log search record, the result entry in the GRC system, and any incident report the review produced.

RA-05(11) — Public Disclosure Program #

Baselines: Low / Moderate / High

Establish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.

Procedure:

The CISO team logs each report from the public channel in the ticketing system on receipt and triages it. The team validates the report, reproduces the issue where possible, and confirms the affected systems, with scanner verification where a scan can confirm the condition. Valid findings enter the standard remediation flow with due dates set by severity under the Organization Vulnerability and Posture Management Guide. The team engages the Security Operations Center for a finding that indicates active exposure. The team acknowledges the reporter and tells the reporter the remediation timing when a disclosure window applies. Evidence: the channel submissions, the triage and validation records, and the remediation tickets they opened.

RA-07 — Risk Response #

Baselines: Low / Moderate / High / Privacy CSF 2.0: GV.RM (Risk Management Strategy), GV.OV (Oversight), ID.RA (Risk Assessment), ID.IM (Improvements)

Respond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.

Procedure:

Findings from every source, including control assessments, scanner monitoring, audits, and reviews, go into the GRC system, each tied to its system. The System Owner, with the ISSO, proposes the response and records the rationale: immediate mitigation, mitigation on a timeline, acceptance, transfer, or avoidance.

The ISSO tracks immediate mitigations on the finding record and verifies closure. Deferred mitigations become POA&M items with milestones, owners, and dates; the ISSO maintains them and reports slippage. The System Owner sends a proposed acceptance to the official the Risk Management Strategy names for that risk level, with the justification and the exposure stated. The AO records the decision in the GRC system, and a declined acceptance returns to the System Owner for a new response. The ISSO updates the system’s risk register entry, using the Cybersecurity Risk Register Template (TMPL-RISKREG-001).

The CISO reviews response performance across systems, including aging POA&M items, repeat findings, and acceptance patterns, and raises systemic issues to the AO and System Owners.

Evidence: the finding records with their recorded responses, the closure verifications, the POA&M items and their history, the AO acceptance decisions, and the CISO’s cross-system reviews.

RA-08 — Privacy Impact Assessments #

Baselines: Privacy CSF 2.0: ID.RA (Risk Assessment)

Conduct privacy impact assessments for systems, programs, or other activities before: a. Developing or procuring information technology that processes personally identifiable information; and b. Initiating a new collection of personally identifiable information that: 1. Will be processed using information technology; and 2. Includes personally identifiable information permitting the physical or virtual (online) contacting of a specific individual, if identical questions have been posed to, or identical reporting requirements imposed on, ten or more individuals, other than agencies, instrumentalities, or employees of the federal government.

Procedure:

The System Owner starts a privacy threshold analysis in the GRC system when a project to build, buy, or change a system is approved, and before a new form or survey goes out. The Privacy Officer reviews the analysis and decides whether the project requires a privacy impact assessment (PIA). The Privacy Officer records that decision in the GRC system.

If the project requires a PIA, the System Owner drafts it with the ISSO, the Information Owner, and the Privacy Officer. The draft describes the PII the system collects, why the Organization needs it, who receives it, how long staff keep it, and the safeguards that protect it. The Privacy Officer reviews the draft and sends it to the SAOP for approval. The ISSO attaches the approved PIA to the authorization package in the GRC system, and the Privacy Officer posts the public version on the Organization’s privacy web page.

When the System Owner submits a significant change, the Privacy Officer checks whether the change affects privacy risk. If it does, the System Owner updates the PIA, and the SAOP approves the new version before the change goes live.

Evidence: the privacy threshold analysis and the Privacy Officer’s decision in the GRC system, the SAOP-approved PIA, the posted public PIA, and the change records that show PIA updates.

RA-09 — Criticality Analysis #

Baselines: Moderate / High CSF 2.0: GV.RM (Risk Management Strategy), ID.RA (Risk Assessment)

Identify critical system components and functions by performing a criticality analysis for [Assignment: organization-defined systems, system components, or system services — to be defined] at [Assignment: organization-defined decision points in the system development life cycle — to be defined].

Procedure:

Criticality analysis takes place during design. When the Organization develops, modifies, or upgrades an architecture or design for a system, the System Owner convenes the analysis. The team lists the missions the system serves, breaks them into functions, and traces each function to the hardware, software, and firmware that implements it. The team lists as critical the components that underpin critical functions and the components with direct paths into them, and notes their dependencies and interconnections.

The ISSO records the analysis in the ticketing system with the design change record. The results feed protection decisions for the affected components, supply chain risk assessment for their sources, and the High Value Asset inventory that the Organization maintains and reviews every year under OMB M-19-03.

The CISO’s staff reviews analyses across systems for consistency. The CISO’s staff returns an architecture change that arrives without its criticality analysis before design approval.

Evidence: the recorded analyses, the design records showing the review, the HVA inventory updates, and the returns for missing analyses.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Risk assessment report
• Vulnerability scan reports (authenticated and unauthenticated)
• Risk register / POA&M
• Risk treatment decisions
• Evidence for IG FISMA metric RAM.01
• Evidence for IG FISMA metric RAM.02
• Evidence for IG FISMA metric RAM.03
• Evidence for IG FISMA metric RAM.04

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-20-32: Improving Vulnerability Identification, Management, and Remediation, October 28, 2020.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• FIPS 199: Standards for Security Categorization, February 2004.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments, September 2012.
• NIST SP 800-39: Managing Information Security Risk: Organization, Mission, and Information System View, March 2011.
• NIST SP 800-60 Rev. 1: Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008.