Skip to content
CMMC 2.13
CMMC · Rev 2.133RA · Risk Assessment

RA.L3-3.11.4e

Security Solution Rationale

Requirement

Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.

Assessment objectives

Lettered references on this page, such as [a] or [b], point to this practice's assessment objectives in the official CMMC Level 3 Assessment Guide. This site does not carry that objective text yet. Open the CMMC Level 3 Assessment Guide (PDF)

Further discussion

The System Security Plan (SSP) is a fundamental component of an organization’s security posture. When solutions for implementing a requirement have differing levels of capabilities associated with their implementation, it is essential that the plan specifically document the rationale for the selected solution and what was acquired for the implementation. This information allows the organization to monitor the environment for threat changes and identify which solutions may no longer be applicable. While not required, it may also be useful to document alternative solutions reviewed and differing levels of risk associated with each alternative, as that information may facilitate future analyses when the threat changes. In addition to the implementations required for Level 2 certification, which may not be risk based, at Level 3, the SSP must carefully document the link between the assessed threat and the risk-based selection of a security solution for the enhanced security requirements (i.e., all CMMC L3 requirements derived from NIST SP 800-172). Example You are responsible for information security in your organization. Following CMMC requirement RA.L3-3.11.1e – Threat Informed Risk Assessment, your team uses threat intelligence to complete a risk assessment and make a risk determination for all elements of your enterprise. Based on that view of risk, your team decides that requirement RA.L3-3.11.2e – Threat Hunting is a requirement that is very important in protecting your organization’s use of CUI, and you have determined the solution selected could potentially add risk. You want to detect an adversary as soon as possible when they breach the network before any CUI can be exfiltrated. However, there are multiple threat hunting solutions, and each solution has a different set of features that will provide different success rates in identifying IOCs. As a result, some solutions increase the risk to the organization by being less capable in detecting and tracking an adversary in your networks. To reduce risk, you evaluate five threat hunting solutions and in each case determine the number of IOCs for which there is a monitoring mechanism. You pick the solution that is cost effective, easy to operate, and optimizes IOC detection for your enterprise; purchase, install, and train SOC personnel on its use; and document the risk-based analysis of alternatives in the SSP. In creating that documentation in the SSP, you follow the guidance found in NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems [a,b,c]. Potential Assessment Considerations • Has the organization completed a risk assessment and made a risk determinations for enterprise components that need to be protected [c]? • Can the organization identify what is being protected and explain why specific protection solutions were selected [a,b]? • Have all the decisions been documented in the SSP [a,b,c]?

How to implement

For each security solution you rely on, write down in the SSP (or a document it references) what you chose, why you chose it, and the risk determination behind it: which risks and threats it addresses and what residual risk you accepted. This is mostly documentation work rather than buying anything, and it turns the Level 2 SSP's 'how it is implemented' into 'why this solution, and what risk remains'.

  1. 1
    ProcessList the security solutions that implement your Level 2 and Level 3 requirements: identity and MFA, endpoint protection and EDR, SIEM and monitoring, firewalls and segmentation, encryption, backup, secure transfer, device management, and managed services.all
  2. 2
    ProcessFor each solution record the rationale: requirements it satisfies, threats and ATT&CK techniques it addresses (from the threat-informed risk assessment, RA.L3-3.11.1e), alternatives considered, and constraints such as FedRAMP authorization, FIPS-validated cryptography, cost and support.all
  3. 3
    ProcessRecord the risk determination: the risk before and after the solution, any residual risk, and who accepted it and when.all
  4. 4
    PolicyPut the information in the SSP or a referenced solution register, and require that any new or replaced security solution goes through the same rationale and risk determination as part of change management.all
  5. 5
    ProcessRevisit rationales when effectiveness assessments (RA.L3-3.11.5e), threat changes or incidents call a solution into question, and update the record.all

Evidence to collect

Artifacts that show the practice is implemented and operating. Tags show which assessment objectives each one supports.

SSP security solution rationale section or referenced registerall

policy · updated with each SSP revision and on solution change

Table or narrative per solution: name, requirements covered, threats addressed, alternatives, rationale, risk determination, residual risk acceptance.

Risk acceptance records for residual riskall

record · current for every solution

Signed or ticketed acceptances by the designated authority.

Change records for new or replaced solutionsall

record · within the last 12 months

Change tickets that include the rationale and risk determination before implementation.

How assessors check

Examine
SSP, solution register, risk assessment, change management records, risk acceptance records.
Interview
The SSP owner, security architects or administrators who selected solutions, and the official who accepts risk.
Test
Pick several security solutions in use and confirm each has a documented rationale and risk determination that matches the current threat assessment; pick a recently added tool and confirm the rationale was recorded through change management.

Tools and products

Named options a contractor can adopt, with an honest cost tier. The industry standard is listed even when it is expensive, alongside what is free and acceptable for a very small shop.

SSP and spreadsheet solution registerDocumentationFreeGood fit for a small shop

A structured table in or attached to the SSP is fully adequate.

MITRE D3FENDDefensive technique frameworkFreeGood fit for a small shop

Free knowledge graph linking defensive techniques to the ATT&CK techniques they counter; useful for writing rationales.

FedRAMP MarketplaceAuthorization status referenceFreeGood fit for a small shop

Look up and cite the authorization status of cloud security solutions in the rationale.

GRC platforms with risk registersGRC platformPaidWorkable for a small shop

Can link solutions, controls and risk acceptance records; worthwhile only if already used for the rest of the program.

Editorial mentions, not endorsements. Pricing and tiers change; confirm with the vendor and check FedRAMP or GCC High availability where CUI is involved.

Common pitfalls

  • Listing products in the SSP without saying why they were chosen or what risk remains.
  • Rationales that only say 'industry standard' with no link to your threats or requirements.
  • Solutions added or swapped by the MSP without updating the rationale.
  • No named person accepting residual risk.

Platform notes

Microsoft 365 (GCC / GCC High)

For Microsoft-provided solutions, reference the FedRAMP High authorization of the GCC High environment and the specific services relied on; record any GCC High feature gaps that changed your solution choice.

Google Workspace

Record the Workspace edition and Assured Controls configuration chosen and the reasoning, including any controls you implemented outside Workspace.

On-premises or MSP-managed

Ask the MSP for the reasoning behind tools it supplies (EDR, RMM, backup) and capture it in your register; you own the risk determination even when the MSP owns the tool.

Related practices: CA.L2-3.12.4, RA.L3-3.11.1e, RA.L3-3.11.5e, RA.L2-3.11.1, CM.L2-3.4.4

Editorial implementation guidance published November 2, 2026. It is not part of the official requirement and does not replace the assessment guide.

Track this in a workspace

The compliance workspace tracks each objective, its evidence and the tasks to close gaps. It is open to invited contractors while in pilot: request access below.

Source: DoD CIO · https://dodcio.defense.gov/CMMC/