SA-11: Developer Testing and Evaluation

Quick-reference card

What this control requires

SA-11 requires developers to build security and privacy testing into every post-design phase of the software development life cycle (SDLC). That means creating structured assessment plans, executing defined test types at specified depth and coverage levels, producing documented evidence of those tests, and correcting every flaw that testing uncovers.

The scope goes beyond running a scan before deployment. Developers must carry out unit, integration, system, and regression testing alongside security-specific evaluations such as manual code review, security architecture review, penetration testing, and static, dynamic, or binary analysis. Each testing method targets a different class of defect, and the NIST SP 800-53 framework requires that the plan spell out which analyses apply, how rigorous they need to be, how often they run, and what artifacts they produce.

Equally important is what happens after testing finds problems. SA-11 mandates a verifiable flaw remediation process, which means flaws can’t disappear into an untracked backlog. Every identified defect must be documented, prioritized, corrected, and re-verified. Contracts and service-level agreements (SLAs) should specify acceptance criteria for both the assessment plan itself and the remediation workflow, creating enforceable accountability between the acquiring organization and the developer.

Why it matters

Most organizations treat developer testing as a quality assurance checkpoint rather than a security control. That distinction matters because untested or under-tested code is one of the most common root causes of exploitable vulnerabilities in production systems. When SA-11 is absent or weak, security flaws survive the development process and reach environments where they become far more expensive to fix and far more dangerous to ignore.

The compliance risk is direct. Federal agencies selecting the MODERATE or HIGH baselines must demonstrate that developers follow a documented, verifiable testing regimen. Auditors don’t just ask whether testing occurred; they ask for the assessment plan, the test results, and the flaw remediation records. A gap in any of those artifacts can trigger a finding that delays or blocks a system’s authorization to operate (ATO).

Beyond authorization timelines, weak developer testing erodes trust in the entire System and Services Acquisition family of controls. SA-11 is the mechanism that confirms whether the security requirements defined in SA-04 (Acquisition Process) and the architecture principles from SA-08 actually survived implementation. Without it, you’re accepting vendor claims at face value.

Interconnections and changes compound the risk. Upgrading an application, swapping an operating system, or updating firmware can silently break controls that previously worked. SA-11’s requirement for regression testing exists specifically to catch those regressions before they reach production.

What attackers exploit

• Untested code paths where input validation, access controls, or encryption were specified in design documents but never verified through unit or integration testing
• Stale security architecture reviews that don’t reflect recent changes to interfaces, dependencies, or data flows
• Missing regression testing after upgrades or patches, leaving previously remediated vulnerabilities re-exposed
• Opaque flaw remediation pipelines where identified defects are logged but never tracked to closure, allowing known weaknesses to persist across releases
• Gaps in static and dynamic analysis coverage that let injection flaws, memory corruption, or insecure deserialization pass through to production binaries

How to implement

For your vendors

The most common failure mode with SA-11 is accepting a vendor’s statement that they “follow secure development practices” without asking for the artifacts that prove it. Self-attestation alone doesn’t satisfy the control. You need to verify that the vendor has a documented assessment plan, executes the testing it describes, produces traceable results, and closes the flaws that testing surfaces.

What to ask in security questionnaires

Start with the assessment plan itself. Ask the vendor to describe which security testing methods they perform at each SDLC phase, including code review (manual or automated), static application security testing (SAST), dynamic application security testing (DAST), binary analysis, penetration testing, and security architecture review. Ask how they determine testing depth, coverage targets, and frequency. Request the names or categories of tools used for each method.

Then move to flaw remediation. Ask how defects identified during testing are logged, prioritized, assigned, and tracked to resolution. Ask whether the vendor maintains a flaw tracking system and whether remediation timelines are defined by severity. Ask how they verify that a fix actually resolves the defect without introducing new issues.

Evidence to request

Ask for a copy of the security and privacy assessment plan covering the system or component you’re acquiring. Request recent test results, including SAST and DAST scan reports, penetration test summaries, and code review findings. Ask for flaw tracking records that show the lifecycle of identified defects from discovery through verification of the fix. If the contract or SLA specifies acceptance criteria for testing, request documentation showing how those criteria were met.

Red flags

Watch for vendors who can describe their testing process verbally but can’t produce written assessment plans or test artifacts. A vendor that has no flaw tracking records, or whose records show long remediation timelines with no re-verification step, is a concern. Be cautious if the vendor performs only one type of analysis, such as automated scanning alone, with no manual code review or architecture-level assessment. Another warning sign is a vendor whose testing plan hasn’t been updated to reflect recent changes like new integrations, upgraded components, or shifted deployment environments.

Verification beyond self-attestation

Where possible, review the vendor’s third-party software security practices directly. Request access to summarized test reports rather than accepting a checklist response. For high-risk acquisitions, consider requiring independent third-party penetration testing or code audit results. Contract language should tie acceptance milestones to delivery of assessment plan artifacts, test evidence, and closed flaw remediation records, giving you leverage if the vendor can’t demonstrate compliance with SA-11.

Evidence examples

Cross-framework mapping

Related controls

• CA-02 — Control Assessments: Provides the broader assessment framework that SA-11’s developer-level testing feeds into, ensuring development-phase findings integrate with system-wide control evaluations.
• CA-07 — Continuous Monitoring: Extends testing beyond the development phase by monitoring deployed controls on an ongoing basis, catching regressions that post-deployment changes introduce.
• CM-04 — Impact Analyses: Requires analysis of changes before implementation, complementing SA-11’s regression testing by identifying which controls a proposed change could affect.
• SA-03 — System Development Life Cycle: Defines the SDLC phases where SA-11 testing must occur, establishing the lifecycle context for when and how developer evaluations are performed.
• SA-04 — Acquisition Process: Specifies the security requirements that SA-11 testing verifies, including contract clauses for assessment plan delivery and flaw remediation expectations.
• SA-05 — System Documentation: Ensures that the system documentation developers test against is accurate and complete, providing the baseline for meaningful security architecture reviews.
• SA-08 — Security and Privacy Engineering Principles: Defines the design principles that SA-11 testing validates, confirming that engineering decisions translate into correctly implemented controls.
• SA-15 — Development Process, Standards, and Tools: Governs the development environment and tooling standards that shape how SA-11 testing is conducted, including approved analysis tools and coding standards.
• SA-17 — Developer Security and Privacy Architecture and Design: Provides the architectural specifications that SA-11’s security architecture reviews evaluate, linking design intent to implementation verification.
• SI-02 — Flaw Remediation: Addresses flaw remediation at the operational level, extending SA-11’s development-phase defect correction into the deployed system’s patch management process.

Frequently asked questions

What is NIST SP 800-53 SA-11

SA-11 is the NIST SP 800-53 control that requires developers to create security and privacy assessment plans, execute defined testing at each post-design SDLC phase, and correct every flaw that testing identifies. The control covers unit, integration, system, and regression testing alongside specialized evaluations such as static analysis, dynamic analysis, penetration testing, and security architecture review. It applies to the MODERATE, HIGH, and PRIVACY baselines and is particularly relevant when organizations acquire software or systems from third-party developers.

What happens if SA-11 is not implemented

Without SA-11, your organization has no verified evidence that developer-delivered code meets its stated security and privacy requirements. Auditors evaluating control assessments will flag the absence of developer assessment plans, test result artifacts, and flaw remediation tracking records as material findings. These findings can delay or block authorization to operate decisions, increase the cost of late-stage defect correction, and leave exploitable vulnerabilities in production systems that passed through the development pipeline untested.

How do you audit SA-11

Auditing SA-11 starts with requesting the developer’s security and privacy assessment plans and confirming they specify test types, depth, coverage, frequency, and required artifacts for each SDLC phase. From there, verify that test execution evidence exists, including SAST and DAST reports, penetration test results, code review findings, and binary analysis outputs. Examine flaw tracking records to confirm that every identified defect has a documented remediation action and a re-verification entry. Check that contracts and SLAs include acceptance criteria for both the assessment plan and the remediation process.

What types of testing does SA-11 require

SA-11 requires a combination of testing methods applied across post-design SDLC phases, including unit testing, integration testing, system testing, and regression testing. Beyond functional testing, the control calls for security-specific evaluations such as manual code review, security architecture review, static application security testing, dynamic application security testing, binary analysis, and penetration testing. The assessment plan must define which methods apply, how rigorous each test needs to be, what coverage targets are set, and how frequently the tests run.