RA.L3-3.11.4e
Security Solution Rationale
Requirement
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
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'.
- 1ProcessList 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
- 2ProcessFor 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
- 3ProcessRecord the risk determination: the risk before and after the solution, any residual risk, and who accepted it and when.all
- 4PolicyPut 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
- 5ProcessRevisit 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.
A structured table in or attached to the SSP is fully adequate.
Free knowledge graph linking defensive techniques to the ATT&CK techniques they counter; useful for writing rationales.
Look up and cite the authorization status of cloud security solutions in the rationale.
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/