What RA-9 criticality analysis asks for and why assessors check it
RA-9 requires the organization to perform a criticality analysis that identifies the critical system components and functions for defined systems, components or services, carried out at defined decision points in the system development life cycle. If someone has told you RA-9 applies to your system, the practical question is which decision points you have defined and whether the analysis they feed actually changes how you buy, build and protect the system. The control is assigned to the moderate and high SP 800-53B baselines, and the organization owns the work. An implementation partner can help prepare the analysis and its supporting records, but the criticality decisions belong to your organization.
Criticality matters because effort is finite. Once you know which components and functions would cause the most damage if they failed or were compromised, you can direct supply chain scrutiny, secure engineering review, testing depth and monitoring toward them first. Rev. 5 folded the withdrawn SA-14 into RA-9, so the analysis now also carries the critical-component focus that previously sat under the acquisition family. Assessors typically look for a finalized criticality result for each component or subcomponent in scope, linked to the mission or business function it supports, and for evidence that the analysis was revisited at the defined decision points. The SP 800-53A procedure lists assessment reports, event logs and analysis reports among the objects they examine.
Two things usually make this control hard. The first is that no shared definition of critical exists inside most organizations, so engineering, operations and business owners rank the same component differently. Agree on the criteria in writing before ranking anything, such as impact on safety, financial loss, data sensitivity or dependency for other services. The second is the missing inventory. You cannot rank components you have not listed, so confirm that your asset and software records cover the scope before the analysis starts. Ask any partner to state in its written scope which decision points, systems and inventory sources the analysis will cover.
Which systems, components and teams RA-9 reaches in practice
RA-9 applies only where the system's baseline or authorization level calls for it, so scope starts with categorization and baseline selection. Once RA-9 applies, the organization must set its parameters, choose what gets analyzed and decide when in the lifecycle the analysis happens, then route the results to the teams that act on them.
Moderate and high baseline systems
SP 800-53B assigns RA-9 to the moderate and high baselines, so a low-impact system carries no RA-9 obligation under that baseline. Confirm the impact level recorded in the RA-2 security categorization, since that decision selects the baseline for RA-9 and every other control. Check whether any system is tailored in or out of the baseline, and record that decision in the system security plan.
FedRAMP Rev5 Class C and D
FedRAMP's Rev5 baselines require RA-9 at Classes C and D, so cloud services seeking authorization at those classes inherit the analysis requirement regardless of how their own categorization reads. Ask the authorizing body which class applies and whether any service boundary component falls outside the authorized scope. Treat the Class C and D requirement as the floor for the analysis, not a reason to skip components inside the boundary.
FedRAMP 20x and KSI-PIY-RSD
FedRAMP 20x lists RA-9 among the related SP 800-53 controls for Key Security Indicator KSI-PIY-RSD, which concerns reviewing security in the software development lifecycle. Teams running 20x evidence should map their criticality analysis outputs to this indicator, so that the review of security in the SDLC draws on the same component list. Confirm the current indicator wording in the FedRAMP rules before building evidence against it.
The two organization-defined parameters
RA-9 leaves two parameters for the organization to set: the systems, components or services to be analyzed, and the decision points in the development life cycle at which the analysis runs. Document both in the control implementation statement, with a named owner for each. Vague values such as all systems weaken the assessment, because an assessor cannot test coverage against an undefined scope.
Components and SDLC decision points
Define the components in scope, such as authentication services, data stores, payment paths, third-party libraries and critical integrations, and the SDLC decision points where the analysis is repeated, such as design review, major release and significant change. Keep the component list tied to the asset inventory so that every analyzed component can be traced to an owner. Record which decision points produced a changed criticality rating.
Teams whose decisions the analysis feeds
Engineering uses the analysis to set design and testing depth, supply chain teams use it to prioritize supplier reviews, and security uses it to focus monitoring and vulnerability response. System owners decide on protection investment and accept residual risk for their systems. Confirm which team signs off the final criticality list, because an analysis that no decision-maker reads does not change how the work is prioritized.
How an assessor tests RA-9 and what they ask to see
This table maps each SP 800-53A assessment method for RA-9 to what the assessor requests and where the control commonly fails. Read it as a preparation checklist: the single determination statement is satisfied only when the examine, interview and test evidence agrees with the documented criticality analysis.
| Assessment element | What the assessor requests | Common finding |
|---|---|---|
| Determination statement | Evidence that the organization performs a criticality analysis for defined systems, components or services at defined decision points in the life cycle | Decision points or scope never defined, so the analysis cannot be tested against them |
| Examine: assessment reports | Prior assessment reports and the scope they cover, showing whether criticality results were reviewed | Criticality results exist but no report shows they were reviewed or acted on |
| Examine: criticality analysis | A finalized criticality analysis for each component and subcomponent in scope, with the method used to rank them | Analysis is a draft, covers only top-level systems, or omits subcomponents such as third-party libraries |
| Examine: audit records or event logs | Records showing when the analysis ran, who approved it and when it was last updated | No dated approval or change history, so the assessor cannot confirm the analysis is current |
| Examine: analysis reports | Reports tying critical components to supply chain, engineering and protection priorities | Criticality is recorded but no downstream plan (monitoring, hardening, sourcing) references it |
| Interview: system owners | How they identify critical functions, who they consult and what changed since the last analysis | Owners cannot name the critical functions of their own system or describe the trigger for review |
| Interview: engineers | How criticality shapes design reviews, testing depth and change approvals | Engineers apply the same controls to all components and cannot point to a criticality-based decision |
| Test: sampled components | Walkthrough of a sample of critical and non-critical components to confirm the recorded rating matches the system | Ratings in the register differ from actual dependencies discovered during the walkthrough |
How to implement a criticality analysis step by step
This sequence turns RA-9 from a policy statement into a ranked, recorded list of critical components and functions that supply chain, engineering and protection teams can act on at each SDLC decision point.
Define the two organization parameters
Decide which systems, components or services fall in scope for the analysis, and which decision points in the system development life cycle trigger it. RA-9 leaves both to the organization, so the security lead, system owner and engineering manager should agree on them in writing. Typical decision points include design review, major architecture change, acquisition of a new component and pre-release review. The output is a short parameter record that names the scope and the decision points, approved by the owner of the risk assessment program. The step is closed when every later step can point back to this record.
Build or confirm the component and function inventory
Assemble the inventory of hardware, software, services and the functions they perform within the scoped system. If the platform already has an asset register, confirm it against what is actually running rather than trusting the register alone. Open-source asset management tools such as GLPI can hold the register, and endpoint inventory collectors such as Wazuh Syscollector can help confirm installed software and services on managed endpoints. Each entry should name the owner and the function it supports. The output is a reconciled inventory with a stated date of confirmation and known gaps listed.
Rank components by mission impact and dependency
For each function in the inventory, determine what happens to the mission or service if the component fails, is compromised or is unavailable, and which other components it depends on. Score or group components by impact and by how many functions depend on them, using a scale the organization defines and documents. Dependencies matter because a low-profile component can be critical if many critical functions rely on it. The output is a ranked list with the rationale for each rank, reviewed by the business or mission owner as well as the technical owner.
Record the finalized criticality for each component and subcomponent
Write the final criticality determination for every component and, where the analysis requires it, every subcomponent, and record who approved it and when. Assessors look for a finalized criticality result per component, not a draft spreadsheet or a verbal agreement, so the record should be versioned and stored with the risk documentation. Note any components excluded from the analysis and why. The output is an approved criticality register that an assessor can trace to the parameters from the first step. The step is closed when the register has no unassessed items within scope.
Link the results to supply chain decisions
Use the critical list to set supply chain priorities: which suppliers and components need deeper provenance checks, which acquisitions need additional due diligence, and which dependencies need an alternate source. Supply chain risk management controls in the SR family can draw on this register directly. Confirm with procurement and the supply chain owner which items trigger a review before purchase. The output is a documented mapping from each critical component to its supply chain treatment, held alongside the criticality register.
Link the results to engineering and protection decisions
Carry the critical list into engineering and security work. Critical components should receive priority for secure design review, testing, vulnerability remediation, monitoring coverage and backup or recovery planning. Confirm with the engineering lead how the list changes sprint or change-board priorities and which protection controls are applied first to critical items. The output is a traceable link from each critical component to at least one engineering or protection action, such as a design review record, a monitoring rule or a test plan, so that the analysis changes what the team does.
Set a review trigger tied to SDLC decision points
Define when the analysis must be repeated. Tie the trigger to the decision points recorded in step one, such as a major architecture change, a new critical dependency, a change of supplier, or a significant change in mission. Record who monitors the trigger and how changes are logged into the register. Confirm with the program owner how often a routine review occurs, because RA-9 does not set a fixed cycle in the supplied facts and the organization's own policy or the assessment baseline may. The output is a documented review procedure and a change log that shows the analysis has been revisited when a trigger occurred.
Which evidence passes RA-9 and how to keep it current
An assessor testing RA-9 looks for a finalized criticality analysis that the organization can trace from components to decisions and forward to each SDLC decision point. The cards below cover the artifacts SP 800-53A names as examine objects, how to keep each one current between assessments, and what dates and ownership an assessor will check.
Signed criticality analysis
This is the core artifact: a document that identifies the critical system components and functions for the defined systems, components or services. Record who reviewed it, the version, and the approval date, and check that the approving owner is named in the system security plan. Assessors commonly ask whether the version on file is the one in force. Confirm your own approval workflow in your environment, since the control does not prescribe one.
Component and subcomponent register
SP 800-53A expects a finalized criticality designation for each component and subcomponent in scope, not only for top-level systems. Keep the register tied to your asset inventory so that a new host, container image or third-party service appears with a criticality value. Check that every entry has a designation date and an owner, and that retired components are marked rather than deleted so the history stays auditable.
Organization-defined parameter definitions
RA-9 has two organization-defined parameters that set which systems, components or services are covered and which decision points in the development life cycle trigger analysis. Document both values, the rationale for each, and the date they were last approved. An assessor will compare the parameter values against the scope in the system boundary, so any gap between them is a finding waiting to happen.
Criticality analysis report
The analysis report explains how criticality was determined: the functions considered, the dependencies traced, and the method used to rank components. Keep it dated and versioned, and reissue it when architecture changes alter a dependency chain. Assessors check that the report's conclusions match the register. Where the method relies on judgment, record who made the call and the inputs they used.
Decision records linking criticality to controls
Criticality matters only if it changes what the organization does. Keep records showing which critical components received additional supply chain review, stronger protection, or priority in engineering and vulnerability work. RA-9 sits alongside RA-2, RA-3, SA-8, SA-15 and SR-5 in the related controls, so link each decision to the control it affects. Date each record and name the accountable owner.
Review history tied to SDLC decision points
Because RA-9 runs at defined points in the system development life cycle, keep a log of each review: the trigger, the date, the reviewer and whether the criticality changed. Include reviews prompted by major design changes, new third-party dependencies and decommissioning. Assessors look for an unbroken record between the last assessment and today, so schedule reviews against your release process and retain the log with the audit records.
What meeting RA-9 costs in money and effort
This table breaks down the cost components of meeting RA-9 criticality analysis, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope a written quote, since no price or duration for this control is published in the supplied material and every figure depends on your environment.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling and licenses | Software vendor, or your own team if self-hosted open source | Recurring if commercial; no license fee for GPL or AGPL tools | Number of components tracked, deployment model and support terms |
| Inventory build and analysis time | Your engineers and analysts, or an implementation partner under a fixed-scope agreement | One-time for the first criticality analysis, then recurring updates | Number of systems, component count, depth of dependency mapping |
| Mapping to SDLC decision points | Architects and engineering leads inside your organization | Recurring at each defined decision point | Number of decision points defined in your SDLC and how often they occur |
| Inventory data upkeep | Operations and asset owners | Recurring | Inventory maturity, whether discovery is automated or manual, and change frequency |
| Evidence upkeep | Control owner and compliance staff | Recurring at each assessment cycle | Number of analysis reports, audit records and finalized criticality records kept |
| External review | Independent reviewer or implementation partner, if engaged | Typically one-time per scope change, plus periodic | Scope of the written engagement and number of systems reviewed |
| Auditor sampling | Your organization pays the independent assessor | Recurring with each assessment | Number of components and decision points the assessor samples and the evidence quality |
| Quote request checklist | Procurement and control owner | One-time at sourcing | Ask for scope, deliverables, component count assumptions, exclusions and who maintains evidence after handover |
Which open-source tools can support RA-9 evidence
RA-9 is evidenced by a recorded criticality analysis, which needs an accurate picture of what the system contains and how the assessment was tracked. The three tools below can hold that inventory, that asset data and the assessment record, but none of them decides which components are critical.
GLPI Assets for components
The GLPI Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks, entered manually or pushed by the GLPI Agent. Use it as the register of components that a criticality analysis ranks, so each entry has an owner, location and relationship to the services it supports. Check that the fields you need, such as business function and dependency links, are configured before you rely on the register as evidence. Licensed under GPL-3.0-or-later.
GLPI native inventory since version 10
Native inventory built into GLPI from version 10 onward lets the GLPI Agent report hardware and software automatically instead of relying on spreadsheets. For RA-9, this keeps the component list that the analysis starts from current between review cycles. Confirm which agent deployment method and inventory tasks your environment uses, and keep the export or report that shows the inventory date as part of the analysis record.
Wazuh Syscollector endpoint inventory
The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint, then stores them in the Wazuh indexer. These records show what actually runs on a critical component, which helps test whether the analysis matches reality. Licensed under GPL-2.0-only. Confirm agent coverage for every component class in scope before treating the inventory as complete.
CISO Assistant for assessment records
CISO Assistant, licensed under AGPL-3.0-only, ships more than 200 frameworks, including NIST CSF, and runs audits and compliance assessments against them with automatic mapping between frameworks. For RA-9, use it to track the criticality analysis as an assessment item, link it to the related controls, record the reviewer, and keep the finalized determination with its date. Confirm which NIST SP 800-53 content is loaded in your instance before you rely on the mapping.
Determination stays with the organization
None of these tools produces the criticality determination itself. Each can supply inventory, dependency data or assessment tracking, but the organization must decide which components and functions are mission critical, at which decision points in the life cycle, and record that decision with its rationale and approval. An assessor will look for that human-made record first, so treat the tools as inputs to it rather than as the analysis.
Who owns the criticality analysis, who can help, and who assesses it
The organization owns RA-9. Its leaders decide which components, functions and services are mission critical, set the two organization-defined parameters for the control, and choose the decision points in the system development life cycle at which criticality is reassessed. Those choices are accountable decisions, so they need named owners, documented rationale and sign-off from the people who carry the risk. The control text also ties criticality to supply chain, engineering and protection effort, so the output must be usable by the teams who act on it.
- Criticality decisions: Named owners determine which components and functions are critical and record why.
- Parameter definitions: The organization fills in the two RA-9 parameters, including the systems, components or services in scope and the decision points.
- Decision points: The organization sets when criticality is revisited, such as before major architecture changes or new supplier onboarding.
- Downstream use: Engineering, supply chain and protection teams must act on the results, so they should review them.
- Accountability: Leaders accept the residual risk of components they do not treat as critical.
Before engaging anyone else, confirm who signs the criticality register and how it links to your risk assessment and plan of action and milestones.
An implementation partner can prepare the material that supports RA-9 but cannot make the determination. DeployOpen, for example, works inside the client's own infrastructure to build asset inventories, criticality analysis templates, dependency mapping and the evidence files an assessor will request. Much of this work is labor-intensive and well suited to outside help, especially where the inventory spans several clouds, data centers or legacy systems. The partner's output is an input to the organization's decisions, not a replacement for them.
- Inventory build-out: Partners can populate and reconcile component and service inventories from existing tools.
- Analysis templates: Partners can design templates that capture criticality rationale, dependencies and decision dates.
- Evidence preparation: Partners can organize analysis reports, finalized criticality records and event logs for review.
- Tooling setup: Partners can configure self-hosted inventory tools so that records stay current.
- Limits: A partner cannot choose the critical components, set the parameters or certify the outcome.
Ask any partner for a written scope that names the deliverables, who approves them and which decisions remain with your staff.
An independent assessor tests whether RA-9 is implemented and produces findings. Under SP 800-53A, the assessor examines the assessment reports, the finalized criticality records for each component and subcomponent, audit records and analysis reports, and interviews the people who run the process. The assessor is independent of both the organization and the partner that helped prepare the evidence. Only an independent auditor, assessor or certification body issues reports or certificates, so the assessor's conclusions are the ones that count for an authorization or contract.
- Examination: The assessor reviews criticality records and the reports behind them.
- Interviews: The assessor confirms that owners understand the process and the decision points.
- Testing: The assessor may sample components and check whether they appear in the criticality analysis.
- Findings: Gaps become findings that the organization must remediate or record in its plan of action and milestones.
- Independence: The partner that built the evidence cannot also serve as the assessor for the same scope.
Confirm with your assessor which evidence they expect, the sampling approach they will use and whether your authorizing or contracting body accepts their report.
Splitting the work clearly avoids the most common RA-9 problem: a criticality list that exists on paper but is not owned, maintained or tested. The organization decides, the partner prepares, and the assessor verifies. Each step should leave a record that another party can check. Costs follow the same split. Internal time goes to decisions and approvals, partner fees cover the build-out and evidence preparation, and assessment fees cover the independent testing.
- One-time work: Initial inventory, template design and first criticality analysis.
- Recurring work: Reassessment at decision points, inventory updates and evidence refresh.
- Cost drivers: Number of systems in scope, quality of existing inventories and how many suppliers feed the analysis.
- Quote request: Ask for a written scope listing who prepares, who approves and who is paid for each deliverable.
- Reduction: Clean asset data and fewer systems in scope usually reduce effort for each role.
Before signing any scope, confirm in writing which decisions stay with your organization and which evidence the assessor has said it will accept.
Where RA-9 programs usually fall short and how to close each gap
RA-9 looks simple on paper, but most programs fail in the same few places: parameters left blank, no inventory to analyze, and results that go stale. The cards below cover the gaps assessors most often find and the practical fix for each, so the criticality analysis can be produced, dated and traced to decisions.
Organization-defined parameters left blank
RA-9 carries two organization-defined parameters, which means the organization must decide the systems, components or services in scope and the decision points in the system development life cycle where the analysis runs. Many programs never fill these in, so there is nothing to test against. Write both values into the system security plan, name the owner of each, and confirm that the assessor reads the same values you do before fieldwork starts.
No component inventory to analyze
A criticality analysis can only rank components that someone has listed. Programs often rely on architecture diagrams that omit hosted services, shared libraries and third-party integrations. Build the inventory from a source that is refreshed automatically, such as an asset register that agents populate or an endpoint inventory, and reconcile the two each cycle. Ask whether every component in scope has an identifier that appears in both the inventory and the analysis.
Criticality set once and never revisited
The control asks for analysis at defined decision points in the life cycle, not a one-time ranking. Criticality changes when a service gains a new data flow, a dependency is added or a function moves to a different provider. Tie the analysis to design review, major change approval and acquisition decisions, and record the date and reviewer each time the ranking is confirmed or changed. A list last reviewed before the most recent architecture change is a common finding.
Criticality disconnected from supply chain and protection
The analysis is only useful when its results drive decisions. The related controls for RA-9 include supply chain risk management, system acquisition, contingency planning and risk assessment, so the ranking should inform which suppliers get deeper review, which components receive stronger monitoring, and which recovery targets come first. Trace at least one high-criticality component to a supplier assessment, a protection requirement and a contingency test, and show that link in the evidence package.
Evidence without dates or owners
Assessors test RA-9 by examining the criticality analysis, the finalized criticality for each component or subcomponent, and related analysis reports. A spreadsheet without version history, approval records or named owners rarely satisfies that examination. Store each version with its date, the people who approved it, the decision point that triggered it, and the systems it covers. Confirm with your assessor which format they accept before you build the record.
What buyers and engineers ask before doing RA-9 work
How much effort does RA-9 criticality analysis take?
The effort depends on how many systems, components and services fall inside the defined scope, and how many decision points in the system development life cycle the organization has defined for the analysis. RA-9 has two organization-defined parameters and no enhancements, so the control itself is narrow, but the work behind it is not. Someone must inventory components and functions, decide which ones are critical to the mission, record the reasoning, and then keep the result current as the system changes. Effort rises with the number of components, the depth of dependency mapping and the number of teams that must confirm the results. Ask any partner for a written scope that lists the systems, components and decision points covered before accepting a quote.
Can a small team do RA-9 in-house?
A small team can usually do RA-9 in-house if it has an accurate asset inventory, clear mission ownership and someone who understands how each component supports the mission. The control asks for a documented criticality analysis, not a specialist tool or certification, so the main constraint is staff time and knowledge of dependencies. Open-source asset management such as GLPI can hold the component records, and Wazuh's Syscollector can supply inventory data from endpoints, which reduces manual collection. Teams that lack a current inventory or have unclear system boundaries often find that the inventory work takes longer than the analysis itself, and that is the point where outside help is most useful.
How long does RA-9 work take?
NIST does not set a duration for RA-9, and the schedule depends on scope. NIST's risk management guidance also does not set federal implementation timelines, leaving that to OMB Circular A-130. The schedule is shaped by the number of systems in scope, the state of the existing inventory, how many business and engineering owners must review the results, and whether the analysis must be repeated at defined decision points. A narrow scope with a current inventory moves much faster than a broad scope that starts from no records. Any timeline a partner offers should appear in the written scope, along with the dependencies on client staff who must confirm the findings.
What does the client need to provide for RA-9 work?
The client must provide the knowledge the analysis depends on, because only the organization can say which functions matter to its mission. That includes access to asset and configuration records, system architecture and data flow documentation, owners who can confirm dependencies, and the mission or business impact statements that already exist for the system. The client also owns the decisions and the sign-off, and the results become part of its own risk documentation. Ask a partner to list these inputs in the written scope, with named owners and the review steps, so that gaps are visible before the work starts.
Can a partner issue the RA-9 assessment?
No. A partner such as DeployOpen can plan the criticality analysis, prepare the systems and records, and organize the evidence, but only an independent assessor issues an assessment result. The organization owns its controls and its criticality decisions. Under the FISMA framework, Inspectors General independently assess agency systems, and FedRAMP uses its own assessment process. Organizations should confirm with the authorizing body or customer which assessor they accept before engaging any partner, because the assessor's independence is what gives the result weight.
How does RA-9 relate to SA-14 and FedRAMP?
SA-14 was a separate control in earlier revisions covering criticality analysis for the system development life cycle. In Rev. 5, its content was incorporated into RA-9, so the same work now sits under RA-9 and teams should cite RA-9 in their documentation. FedRAMP's Rev5 baselines require RA-9 at Classes C and D, and FedRAMP 20x lists RA-9 among the related SP 800-53 controls of the KSI-PIY-RSD indicator on reviewing security in the SDLC. Teams working toward FedRAMP should map their criticality records to those requirements and confirm the current FedRAMP rules directly, since the rules change over time. The RA-9 analysis feeds supply chain and engineering priorities, which is why it is cross-referenced with SA-8, SA-15 and SR-5.
How DeployOpen scopes and prepares RA-9 evidence
DeployOpen works on RA-9 Criticality analysis as a written, fixed-scope piece of work: we help you identify which components and functions are critical, then prepare the systems and records that show the analysis was done and kept current. The organization owns the analysis and its decisions, and an independent assessor determines whether the control is met.
How we scope
- Confirm which systems, components or services fall inside the defined scope of the criticality analysis.
- Agree the decision points in the system development life cycle where the analysis must be performed.
- Record the two organization-defined parameters for RA-9 in writing before any work starts.
How we build
- Configure self-hosted inventory tools such as GLPI so each in-scope component has an owner, function and dependency record.
- Use Wazuh system inventory data to check that deployed software and services match the documented component list.
- Draft the criticality analysis method and results so that each finalized criticality rating traces back to recorded inputs.
How we hand over
- Deliver the criticality analysis report, component inventory and rating rationale in formats your assessors can examine.
- Map each deliverable to the RA-9 determination statement and the examine objects listed in SP 800-53A.
- Document who approved each rating and when, so an assessor can interview the responsible owners and confirm the records.
How we support
- Offer ongoing support as a retainer to review the analysis when systems, components or decision points change.
- Agree in the written scope how updates to criticality ratings will be reviewed and recorded over time.
- Confirm with your assessor and authorizing body which evidence formats and review cycles they expect before work begins.
