SA-11, Developer Testing and Evaluation, asks a developer to run an ongoing assessment plan, perform defined testing at defined depth, produce evidence of the results, implement a verifiable flaw remediation process and correct what testing finds. Keep the plan, the outputs and the fix records, all dated and linked.
What the control text requires
The Rev. 5 text asks the developer of a system, component or service, at all post-design stages of the life cycle, to:
- develop and implement a plan for ongoing security and privacy control assessments
- perform testing and evaluation of a defined type, at a defined depth and coverage
- produce evidence of the execution of the plan and the results
- implement a verifiable flaw remediation process
- correct flaws found during testing and evaluation
The type, depth and coverage are organization-defined, so the program tells you how much is enough. SA-11 is in the moderate and high baselines, not in low.
Enhancements to know
SA-11(1), static code analysis, asks for static analysis tools to find common flaws and document the results. The discussion notes it works best early, with each code change scanned, and that evidence can include aggregate defect density for critical defect types. In the baseline profiles used for this post, no baseline selects SA-11(1). A program may add it.
The evidence set
- Written test plan with scope and triggers. Why it matters: Shows the plan exists and is ongoing
- Pipeline configuration. Why it matters: Shows tests run on every change, not by memory
- Scan and test outputs with dates. Why it matters: Evidence of execution
- Triage records. Why it matters: Shows who judged findings and how
- Linked fix commits or pull requests. Why it matters: Shows flaws were corrected
- Re-test results. Why it matters: Shows the fix worked
- Exceptions with reasons and review dates. Why it matters: Shows the remediation process is verifiable
Make remediation verifiable
"Verifiable" is the key word. A person outside your team should be able to take one finding and trace it: detection, owner, change, test, closure. If any hop lives only in someone's memory, the process is not verifiable.
Use stable identifiers. A ticket number in the commit message and the pull request title does more for an assessor than a long policy document.
Common gaps
Testing happens, but outputs are not kept. Retain results for the period the program sets.
Tools run on the main branch only, so changes from feature branches are not covered.
Exceptions are accepted in chat and never recorded.
Try it yourself
Open the code scan demo and click a finding to see the location and the suggested fix. Think about which of the records above that click would create.
Click through it at your own pace, or open it full screen.
Quick check
Is static analysis mandatory under SA-11?
It is an enhancement, SA-11(1), and was not selected by the baselines checked. A program can still require it.
Who decides how deep the testing must be?
The organization or program, through the defined parameters in the control.
Safeguard's policies and gates can enforce checks on pull requests, and compliance and evidence automation stores the outputs. A free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-53 Rev. 5 catalog and baseline profiles, control SA-11 (OSCAL content)
- NIST SP 800-53 Rev. 5 page
Last reviewed: 19 October 2026.
