SA-11(5): Penetration Testing

SA-11(5) requires you to contractually require the system’s developer (including third-party developers of components or services) to perform penetration testing and to deliver results you can act on before acceptance and during controlled change. Operationalize it by embedding pen test obligations into SDLC gates, defining scope/rules of engagement, and tracking remediation to closure with retained evidence. ¹

Key takeaways:

• Put the requirement in the developer’s contract/SOW, not just in your policy. ¹
• Define “what counts” as penetration testing: scope, timing, independence, and deliverables. ²
• Treat findings like release blockers: assign owners, deadlines, retest, and keep artifacts for assessors. ²

The sa-11(5): penetration testing requirement is easy to misunderstand because it sits in the System and Services Acquisition (SA) family. That placement is the clue. SA-11(5) is not primarily about your internal security team running annual tests; it is about ensuring the developer of the system, component, or service performs penetration testing as part of building and delivering capability into your environment. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat SA-11(5) as a supply-chain control and an SDLC control at the same time. You must be able to show that (1) you required pen testing from the developer, (2) you defined what “penetration testing” means for your risk profile, and (3) you reviewed results and enforced remediation before you accepted the deliverable or promoted it to production. ²

This page gives requirement-level guidance you can copy into procedures, third-party contracting checklists, and assessment evidence folders. It focuses on execution: who owns what, what artifacts to collect, what auditors ask, and how to avoid the common “we did a scan” failure mode.

Regulatory text

Requirement (excerpt): “Require the developer of the system, system component, or system service to perform penetration testing:” ¹

What the operator must do

You must impose a requirement on the developer (internal dev team or external third party) to perform penetration testing on the system, component, or service being delivered. Then you must be able to demonstrate the requirement was executed through planned testing, documented results, and tracked remediation that informs go/no-go decisions. ²

A practical interpretation: if you acquire a SaaS platform, integrate a hosted API, buy a COTS component, or accept code from a contractor, you need a defined mechanism to (a) require penetration testing by that developer and (b) receive and evaluate outputs as part of acceptance and ongoing change. ²

Plain-English interpretation

SA-11(5) means: “Don’t accept software or services on trust. Make the builder prove exploit resistance through a controlled, documented penetration test, and fix what matters before production.” ²

This is different from:

• Vulnerability scanning (automated detection)
• SAST/DAST (application testing techniques)
• Bug bounty (crowdsourced reporting)

Those can support your program, but SA-11(5) expects an explicit penetration test requirement on the developer as part of acquisition and development assurance. ²

Who it applies to

Entities

• Federal information systems and programs using NIST SP 800-53 as a control baseline. ²
• Contractor systems handling federal data where contracts, authorizations, or customer requirements flow down NIST controls. ¹

Operational contexts that trigger SA-11(5) work

• New system development or major releases.
• Procurement of a system component (library, appliance, identity provider, payment module).
• Third-party services that process, store, or transmit sensitive data.
• Material architecture changes (new auth pattern, new network exposure, new privileged paths). ²

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

1) Assign ownership and define the control boundary

• Control owner: usually AppSec, Security Engineering, or Product Security; GRC owns policy mapping and evidence readiness.
• Define what “system, component, or service” means in your environment (apps, APIs, infrastructure-as-code modules, critical vendors). ²

Output: SA-11(5) control implementation statement and RACI.

2) Put penetration testing requirements into acquisition and SDLC gates

For external developers/third parties, add to contract/SOW:

• Frequency/trigger: before initial acceptance, and after material changes.
• Scope: in-scope environments, endpoints, roles, and data paths.
• Deliverables: report, severity ratings, proof-of-concept details, and remediation verification.
• Confidential handling and sharing rules for reports. ¹

For internal development:

• Add a release gate: pen test required for defined risk tiers (internet-facing, privileged workflows, regulated data). ²

Output: Standard contract clause + SDLC control gate language.

3) Define rules of engagement (RoE) that auditors can follow

Document:

• Objective (what you are trying to prove).
• Test type (black/gray/white box) and allowed techniques.
• Production safety constraints (rate limits, test windows).
• Success criteria (what constitutes “passed” vs “conditional go”). ²

Tip from audits: If the RoE is missing, teams end up defending ad hoc testing as “penetration testing,” and assessors push back.

4) Verify tester competence and independence expectations

SA-11(5) says “developer performs,” which often leads to developer-selected testers. Your job is to define minimum expectations:

• Tester qualifications (experience, methodology transparency).
• Independence guardrails (no self-attestation without challenge, defined conflict handling).
• Right to review raw evidence for high-severity findings. ²

Output: Tester qualification checklist and approval workflow.

5) Review results and turn findings into tracked remediation

Operationalize this as a repeatable workflow:

• Intake report into your GRC/ticketing system.
• Triage: map findings to system risk (internet-exposed auth bypass beats low-risk content issues).
• Assign owners and remediation plan.
• Require retest or validation evidence for significant issues.
• Make acceptance contingent on closure or documented risk acceptance. ²

Daydream fit (earned mention): Daydream works well here when you need a single place to map SA-11(5) to a control owner, store recurring evidence artifacts, and show an assessor the exact pen test requirement, report, and remediation trail without email archaeology. ¹

6) Tie outcomes to your authorization/acceptance decision

Pen testing with no decision impact is where programs fail. Define:

• Release blockers (categories that must be fixed).
• Conditional approvals (allowed only with compensating controls and a dated plan).
• Risk acceptance authority (who can accept residual risk). ²

Required evidence and artifacts to retain

Keep artifacts in an assessor-ready folder per system/component/service:

1. Contract/SOW clauses requiring penetration testing by the developer (or internal SDLC gate evidence). ¹
2. Rules of Engagement (scope, constraints, approvals).
3. Penetration test report (dated, versioned, identifies target and environment).
4. Management response (triage notes, severity mapping, risk decision).
5. Remediation tickets (owner, dates, fix references, links to code/changes).
6. Retest/validation evidence (attestation, screenshots, logs, or updated report).
7. Exception record for accepted risks, with approver and compensating controls. ²

Common exam/audit questions and hangups

Questions you should be ready for

• “Show me where the developer is required to perform penetration testing.” ¹
• “What systems/components/services are in scope, and why?”
• “How do you decide timing: pre-prod, post-change, annually, by risk tier?”
• “Who reviewed the report, and what did they do about the findings?”
• “How do you validate remediation? Do you require retesting?” ²

Hangups that slow audits

• Report exists but no evidence of review or action.
• Testing occurred, but scope did not match the component actually deployed.
• Findings were “fixed,” but no validation is documented.
• Pen test is treated as optional because the vendor “won’t share reports.” You still need a documented alternative that meets your risk needs and contractual posture. ²

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Confusing vulnerability scans with penetration tests.
   Fix: define penetration testing deliverables (attack narrative, exploitability proof, and chained attack paths where relevant). ²

2. Mistake: No contractual teeth with third parties.
   Fix: add explicit pen test obligation, delivery timelines, and rights to receive an executive summary at minimum, plus deeper detail under NDA when needed. ¹

3. Mistake: Pen tests happen after production.
   Fix: make pre-acceptance testing a gate for high-risk systems; allow post-prod only with documented constraints and compensating controls. ²

4. Mistake: “One-and-done” testing that ignores major changes.
   Fix: define change triggers (auth redesign, new exposure, new privileged roles, major dependency shifts) that require retesting. ²

Risk implications (practical)

SA-11(5) gaps usually show up as:

• Preventable externally exploitable flaws discovered by attackers or customers instead of your program.
• Contract disputes with third parties after a security incident because testing obligations were vague.
• Authorization delays because assessors cannot trace test results to remediation and acceptance decisions. ²

Practical 30/60/90-day execution plan

Days 0–30: Establish the requirement and the paper trail

• Name the SA-11(5) control owner and backups.
• Publish a one-page pen test standard: scope, RoE template, minimum deliverables, and acceptance criteria.
• Update third-party templates (MSA/SOW/security addendum) to require developer-performed penetration testing and report delivery terms. ¹
• Create an evidence folder structure per system/component/service.

Days 31–60: Apply it to your highest-risk targets

• Inventory in-scope systems/components/services by risk tier (internet-facing, sensitive data, privileged access).
• Schedule penetration tests for top-tier items and align to release timelines.
• Stand up a remediation workflow: ticket intake, SLA guidance, retest requirement, and risk acceptance path. ²

Days 61–90: Make it repeatable and auditable

• Add SDLC gates (definition of done) so releases cannot bypass pen test requirements for defined tiers.
• Run one tabletop audit: pick a system and demonstrate end-to-end evidence from requirement → test → remediation → approval.
• If you use Daydream, map SA-11(5) to the control owner, attach recurring evidence artifacts, and set review reminders to keep the evidence fresh. ¹

Frequently Asked Questions

Does SA-11(5) require an external penetration test firm?

The text focuses on requiring the developer to perform penetration testing, not on a specific sourcing model. Define independence and competence expectations that fit your risk and document why the approach is credible. ¹

Our SaaS provider refuses to share the full pen test report. Are we noncompliant?

Not automatically, but you need evidence that you required penetration testing and that you received enough results to make a risk decision. Negotiate at least an executive summary plus deeper access under NDA or controlled viewing for critical services. ²

Is a bug bounty program enough to satisfy SA-11(5)?

Bug bounty can complement penetration testing, but it rarely substitutes for a scoped, time-bound engagement with documented RoE and deliverables. Keep the pen test requirement explicit and treat bug bounty as additional assurance. ²

What should trigger retesting?

Tie retesting to material changes that affect exploitability, like major authentication changes, new external exposure, or new privileged workflows. Document triggers in your RoE or SDLC gate criteria. ²

How do we prove we acted on findings?

Retain triage notes, remediation tickets, and retest evidence, then link them to the acceptance decision. Assessors look for traceability, not just the report. ²

Who should approve risk acceptance if findings remain open?

Assign a named risk acceptance authority aligned to your governance model (system owner, CISO delegate, or authorizing official function). Document the decision, compensating controls, and planned closure path. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5