SA-11: Developer Testing and Evaluation

To meet the sa-11: developer testing and evaluation requirement, you must ensure the system’s developer performs and documents security-focused testing and evaluation activities across all post-design SDLC stages, and you must retain evidence that testing was planned, executed, defects were tracked, and fixes were verified. Your fastest path is to bind SA-11 to release gates and vendor/third-party acceptance criteria, then collect recurring artifacts per release. ¹

Key takeaways:

• SA-11 is about developer-performed testing throughout build, integration, and deployment, not just a one-time penetration test. ¹
• Operationalize SA-11 by making test evidence a release requirement for internal teams and third parties. ¹
• Auditors look for repeatable procedures + objective artifacts (plans, results, defect logs, retest proof), mapped to an owner and cadence. ¹

SA-11 sits in the System and Services Acquisition family and is a practical control: it forces you to prove that security testing happens as the developer builds and changes the system, and that results drive remediation before release. For a Compliance Officer, CCO, or GRC lead, the operational challenge is rarely “do we test?” It’s “can we show, for this specific system and each meaningful change, what was tested, by whom, using what methods, what failed, what was fixed, and what evidence ties it to a release decision?”

The regulatory excerpt you have is intentionally broad: it places the obligation on the developer and applies at all post-design stages of the SDLC. ¹ That breadth is useful because it covers internal development teams, system integrators, and third parties delivering components or services. Your job is to turn that into enforceable engineering requirements (entry/exit criteria), contractual expectations for third parties, and an evidence package that is repeatable release after release.

This page gives you requirement-level implementation guidance you can deploy quickly: scope, ownership, a step-by-step operating procedure, artifacts to retain, audit friction points, and a practical execution plan.

Regulatory text

Control excerpt (provided): “Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:” ¹

What that means for operators

• “Require the developer” means you must impose testing obligations on whoever builds or modifies the system: internal engineering, a system integrator, a cloud/SaaS provider delivering a system service, or another third party shipping components. Your enforcement mechanism is policy + SDLC gates + contract language + acceptance criteria. ¹
• “System, system component, or system service” expands scope beyond the “main application” to include libraries, containers, images, CI/CD pipelines, infrastructure-as-code modules, authentication services, and managed services that are part of your authorization boundary. ¹
• “All post-design stages” means testing and evaluation cannot be left until the end. You need a defined sequence of testing activities that align to build, integration, pre-production, and deployment, with evidence at each stage. ¹

Plain-English interpretation (what SA-11 requires)

SA-11 requires you to ensure developers perform security-relevant testing and evaluation after design, and to keep proof that testing happens consistently as changes ship. ¹ In practice, SA-11 becomes a set of mandatory checks tied to releases: code changes do not progress unless required tests ran, results were reviewed, defects were handled, and fixes were validated.

Who it applies to (entity and operational context)

SA-11 most directly applies in these contexts:

• Federal information systems and teams operating systems under NIST SP 800-53 control baselines. ²
• Contractor systems handling federal data, including controlled environments where a third party develops or operates components used to process government information. ¹

Operationally, expect SA-11 to touch:

• Product engineering and platform engineering (CI/CD, IaC, container builds)
• Security engineering / AppSec (test standards, tooling, triage rules)
• QA (functional testing that also supports security claims)
• Procurement / third-party risk (contractual testing obligations for third parties)
• GRC (control design, evidence, assessment readiness)

What you actually need to do (step-by-step)

Use this as a buildable procedure a control owner can run.

1) Set scope and name the control owner

1. Identify the systems/components/services in scope for your assessment boundary (include third-party services that are part of delivery).
2. Assign a single accountable owner (often AppSec, Engineering Enablement, or the system owner) and document backups.
3. Define which “post-design stages” exist in your SDLC (build, integration, staging, pre-prod, prod) and map required testing to each stage. ¹

Operator tip: If you cannot describe your stages, you cannot prove SA-11 is “at all post-design stages.”

2) Define the minimum developer testing baseline

Create a short “SA-11 testing baseline” that is unambiguous and testable at audit time:

• Secure coding checks (linting rules, banned functions, dependency rules)
• Static analysis expectations for new/changed code
• Dependency and container/image scanning expectations
• Secrets detection expectations
• Unit/integration tests that cover security-relevant logic (authz, input validation, crypto use)
• Pre-release validation in a staging-like environment
• Manual verification steps for high-risk changes

Write it as release gate criteria (pass/fail), not aspirational statements. ¹

3) Bind testing to SDLC gates (make it enforceable)

Implement enforceability in two places:

• CI/CD enforcement: required jobs must pass; exceptions require documented approval.
• Change management enforcement: releases require a test evidence packet attached to the change record.

Your goal is to make SA-11 evidence “fall out” of normal operations. ¹

4) Establish defect handling and retest rules

Developer testing is meaningless without closure rules. Set:

• Severity definitions and who can set severity
• Time-to-fix expectations (as internal guidance) and what triggers a release block
• A retest requirement: fixes must show new test results (or re-run outputs) tied to the original defect

Keep this lightweight but explicit, because auditors often ask how failures are handled, not just whether scans ran. ¹

5) Extend SA-11 to third parties (contracts + acceptance)

For third-party-developed components/services:

• Put testing requirements into the SOW/MSA and security addendum.
• Require delivery of test results summaries and evidence for each release you adopt.
• Add acceptance criteria: you do not deploy the component/service update without the required evidence (or documented exception).

This is where many programs fail: they treat SA-11 as internal-only while their highest-risk code paths are delivered by third parties. ¹

6) Create an “SA-11 evidence pack” per release (repeatable)

Standardize a per-release folder or ticket template with required artifacts (see next section). Require it for every production release and for emergency changes (with an exception path). ¹

7) Map SA-11 to a control procedure and recurring evidence

Make SA-11 auditable: document the control statement, the operating procedure, roles, tools, and the recurring evidence you will produce and retain. This mapping is a practical control on its own and is explicitly recommended in your guidance pack. ¹

Where Daydream fits: Daydream is useful when you need SA-11 to be “always audit-ready” across many teams and third parties. Map SA-11 to an owner, a procedure, and recurring artifacts, then track collection by system and release so evidence is complete at assessment time. ¹

Required evidence and artifacts to retain

Store artifacts in a way you can retrieve by system + release + date:

Core artifacts (typical minimum set)

• SA-11 control procedure (who, what, when, tools, gates) ¹
• SDLC stage definitions and where tests occur ¹
• Test plans or testing standards for security-relevant testing ¹
• CI/CD logs showing required jobs ran and passed (build pipelines, job outputs)
• Tool reports (SAST, dependency scanning, container scanning, secrets detection), including configuration/settings where feasible
• Defect/issue tracker exports: findings, severity, assignment, remediation status
• Retest evidence: re-run reports or PR links proving closure
• Release approvals showing test evidence reviewed and accepted
• Exception records for waived tests with compensating controls and approvals ¹

Third-party artifacts (if applicable)

• Contract clauses / SOW language requiring developer testing evidence ¹
• Third-party release notes + testing attestation or summaries
• Your internal acceptance record tying third-party evidence to deployment approval

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me evidence for multiple releases. How do you know this is continuous and not a one-off?” ¹
• “What do you mean by post-design stages in your SDLC, and which tests occur at each stage?” ¹
• “Who reviews failures, and what blocks a release?”
• “How do you handle third-party components? Do you require developer testing evidence from them?” ¹
• “Where is the written procedure, and who owns it?” ¹

Hangups that stall audits:

• Tool screenshots without context (no system/release linkage)
• Passing scan outputs without proof anyone triaged high-risk findings
• No exception process, which leads to undocumented workarounds

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-11 as “security testing near launch.”
   Fix: Define required tests by SDLC stage and make them entry/exit criteria for each stage. ¹

2. Mistake: “We ran scans” but no defect lifecycle.
   Fix: Require ticket creation, ownership, remediation, and retest evidence as part of the release packet. ¹

3. Mistake: Ignoring third parties.
   Fix: Add contract requirements and acceptance gates for third-party releases; retain their testing summaries and your internal approval record. ¹

4. Mistake: Evidence sprawl across tools with no index.
   Fix: Create a standard evidence pack template, indexed by system and release, and make it a mandatory artifact of change management. Daydream can track this mapping and recurring evidence collection across systems and teams. ¹

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for SA-11, so this page does not cite enforcement outcomes. The practical risk is straightforward: if developer testing is inconsistent or undocumented, vulnerabilities ship to production, and you lose audit defensibility because you cannot prove the control operates “at all post-design stages.” ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize control ownership and minimum gates)

• Assign SA-11 owner(s) per system and document the operating procedure. ¹
• Define SDLC stages and the minimum test baseline per stage. ¹
• Implement a release evidence pack template and require it for new releases.
• Identify third parties delivering components/services and draft contract addenda language for testing evidence.

Next 60 days (enforce and standardize evidence)

• Wire required tests into CI/CD as mandatory checks with an exception workflow.
• Standardize defect handling rules and retest expectations; train engineering leads and release managers.
• Start collecting evidence packs for releases and run an internal “mini-audit” to verify retrieval works.
• For priority third parties, update SOW/MSA language and add acceptance criteria to deployment runbooks.

By 90 days (prove repeatability and audit readiness)

• Demonstrate multiple consecutive releases with complete evidence packs.
• Review exceptions taken and close gaps (missing artifacts, inconsistent severity triage).
• Operationalize reporting: per-system view of SA-11 evidence completeness, owners, and open items. Daydream is a natural place to centralize control-to-evidence mapping and retrieval for assessments. ¹

Frequently Asked Questions

Does SA-11 require a penetration test?

SA-11 requires developer testing and evaluation across post-design SDLC stages, but your excerpt does not prescribe specific test types like penetration testing. Treat pen testing as optional unless your program, authorization package, or risk decisions require it. ¹

We buy SaaS. How can we “require the developer” to test?

You operationalize SA-11 through procurement and acceptance: contract clauses, security addenda, and release acceptance criteria that require test evidence or attestations from the provider. Keep proof of what you required and what you received. ¹

What counts as “post-design stages” in practice?

Define your organization’s SDLC stages (for example build, integration, staging, production) and map required tests to each stage. Auditors will accept your definitions if they are documented and used consistently. ¹

How do we handle emergency changes without breaking SA-11?

Use an exception process with documented approvals, compensating controls, and follow-up testing evidence after stabilization. The key is that exceptions are tracked and recover back to the baseline quickly, with artifacts. ¹

What evidence is most persuasive in an assessment?

A repeatable release packet: CI/CD run logs, scan outputs tied to the specific commit/build, defect tickets showing remediation, and retest proof. Pair this with a written SA-11 procedure and ownership assignment. ¹

How should a GRC team avoid becoming the bottleneck for SA-11?

Set the control requirements and evidence schema, then make engineering and release management produce artifacts automatically through pipelines and change management. Use a central register (often via tools like Daydream) to track completeness without manually collecting screenshots. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5