SA-4(3): Development Methods, Techniques, and Practices

SA-4(3) requires you to make developers (internal teams and third-party suppliers) prove they follow a defined system development life cycle (SDLC) with specified secure development methods, techniques, and practices, and to retain evidence that the SDLC is actually used. Operationalize it by setting SDLC “demonstration” criteria in contracts and gating releases on objective artifacts.

Key takeaways:

• Treat SA-4(3) as an evidence-backed SDLC requirement, not a policy statement. ¹
• Apply it to internal development and any third party building or delivering system components/services. ²
• Contract clauses, delivery gates, and an evidence bundle are what make the requirement auditable. ³

SA-4(3): Development Methods, Techniques, and Practices sits in the “System and Services Acquisition” family and targets a common failure mode: teams say they “do secure SDLC,” but cannot show consistent, repeatable proof across releases, suppliers, and components. The control’s phrasing is direct: you must require the developer of the system, system component, or system service to demonstrate the use of an SDLC process that includes specified elements. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to value is to translate “demonstrate” into concrete acceptance criteria: what artifacts must exist, who approves them, where they are stored, and what happens when evidence is missing. This page gives you a requirement-level implementation approach you can drop into procurement language, engineering delivery gates, and audit-ready evidence collection.

If you support federal information systems or contractor systems handling federal data, SA-4(3) also functions as a buyer’s requirement. You are not only assessing your own SDLC maturity; you are setting minimum development expectations for third parties that build, host, or operate parts of your system. ²

Regulatory text

Excerpt (control requirement): “Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:” ¹

Operator interpretation of the excerpt:

• “Require the developer” means this is a binding expectation, not a suggestion. You enforce it through internal SDLC policy, delivery governance, and third-party contracting. ²
• “Demonstrate the use” means you need observable, reviewable evidence that the SDLC is followed in practice, for real work, not just a process document. ³
• “System, component, or service” broadens scope beyond greenfield applications. It includes shared libraries, containers/images, infrastructure-as-code modules, SaaS configurations, and managed services. ²

Because the excerpt ends with “includes:” in the provided text, treat your implementation as: define the SDLC elements your organization requires, then force developers to prove they followed them for each release or delivery. ¹

Plain-English interpretation (what SA-4(3) demands)

You must be able to answer, with evidence:

1. What SDLC process is required?
2. Who must follow it (internal and third party)?
3. How do they prove they followed it for a given change/release?
4. What happens if they cannot prove it?

Auditors and customer assessors typically focus on whether you have repeatable gates (not ad hoc heroics) and whether evidence is traceable to a specific build/release.

Who it applies to

Entity scope (typical):

• Federal information systems. ²
• Contractor systems handling federal data (including systems operated by third parties on your behalf). ²

Operational scope (where it shows up):

• Internal software engineering (product teams, platform teams, data engineering).
• DevOps/SRE where infrastructure code or deployment pipelines change system behavior.
• Procurement and third-party risk management for suppliers delivering code, components, or operated services.
• Security engineering (secure coding standards, testing, and release approvals).
• Program management where acceptance criteria and delivery milestones are set.

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

1) Create a “requirement control card” for SA-4(3)

Document a one-page runbook that an operator can execute repeatedly:

• Objective: Developers demonstrate use of the required SDLC for each delivery.
• Owner: Typically Head of Engineering (process) plus Security (control checks) plus Procurement/TPRM (third-party enforcement).
• Trigger events: New system onboarding, major release, new third-party engagement, material change to component/service.
• Execution steps: Your gates and evidence checks (below).
• Exceptions: Who can approve, for how long, and what compensating controls apply.

This aligns with the practical control pattern: “Create a requirement control card with objective, owner, trigger events, execution steps, and exception rules.” ¹

2) Define what “SDLC demonstration” means in your environment

Turn “demonstrate” into acceptance criteria that can be checked quickly. A practical minimum set is:

SDLC demonstration area	What you check	Pass/fail evidence signal
Requirements & design	Security-relevant requirements captured; design reviewed	Ticket/PR links to requirements; design review record
Code change control	Changes tracked, reviewed, and approved	PR approvals; branch protection; change record
Testing	Evidence of required tests executed	CI logs; test reports; SAST/DAST results if required
Vulnerability/defect handling	Findings triaged and addressed	Issue tracker items with status and remediation notes
Release approval	Release gate or sign-off performed	Release checklist; approval record; pipeline gate status

Keep it short enough that teams can comply, strict enough that “we talked about it” does not pass.

3) Bake SA-4(3) into third-party contracting and onboarding

For third parties building or operating components/services:

• Add contract language requiring the third party to provide SDLC documentation and per-release evidence upon request.
• Require the third party to map their SDLC artifacts to your required demonstration criteria (a simple crosswalk table works).
• Add a right-to-audit or evidence access clause scoped to security and SDLC artifacts relevant to your environment.

Your goal: when a third party is the “developer,” you can still meet “require the developer…to demonstrate.” ¹

4) Implement delivery gates (do not rely on after-the-fact collection)

Add lightweight controls that stop nonconforming releases:

• Pipeline gate: block promotion if required artifacts are missing (links, approvals, test runs).
• CAB/change gate (if used): require the evidence bundle as entry criteria.
• Security approval gate for high-risk changes: require explicit sign-off when thresholds are met (define thresholds internally).

5) Define the minimum evidence bundle and retention location

Standardize what gets retained per execution cycle. The practical control pattern is explicit: “Define the minimum evidence bundle for each execution cycle (inputs, approvals, output artifacts, and retention location).” ¹

A workable evidence bundle (store links or exports):

• SDLC process document (versioned) and secure coding/testing standards (versioned)
• Release/change record with unique ID and scope
• Requirements/design review evidence (where applicable)
• Peer review approvals (PR metadata)
• Test execution output (CI job links, reports)
• Security scan outputs required by your standard (or documented exception)
• Approval to release (release checklist/sign-off)
• Exception records (if any), with approver and expiry

Retention: central GRC repository or controlled folder with immutable logs/links. Avoid scattering evidence across personal drives or ephemeral chat threads.

6) Run recurring control health checks and close gaps

Operationalize “sustained compliance” with a cadence:

• Sample recent releases from each team and each critical third party.
• Check for completeness of the evidence bundle and whether it maps to your criteria.
• Track remediation items to closure with owners and due dates.

This matches the recommended control pattern: “Run recurring control health checks and track remediation items to validated closure with due dates.” ¹

7) Use Daydream to make “demonstration” auditable without slowing delivery

Daydream fits naturally where SA-4(3) programs fail: evidence sprawl, unclear ownership, inconsistent gates, and third-party artifact collection. Use it to:

• Maintain the SA-4(3) control card as the single source of truth for owners, triggers, steps, and exceptions.
• Define the evidence bundle template and required fields.
• Track health checks, findings, and validated closure for both internal teams and third parties.

Required evidence and artifacts to retain (audit-ready list)

Keep evidence tied to specific releases/deliveries and to the governing SDLC version:

• SDLC policy/process documentation and change history
• Secure development standards (coding, dependency management, testing)
• Third-party contractual clauses or addenda requiring SDLC demonstration
• Onboarding due diligence results for third-party development practices
• Release-level evidence bundles (as defined above)
• Exception register for SDLC deviations, including approvals and expirations
• Control health check records, sampling approach, findings, and closure proof

Common exam/audit questions and hangups

1. “Show me proof the SDLC is used, not just documented.”
   Hangup: teams provide a process PDF but no release artifacts.
2. “How do you enforce this on third parties?”
   Hangup: contracts lack evidence rights; procurement cannot compel artifacts.
3. “Is evidence complete for a sample of releases across teams?”
   Hangup: evidence exists but is inconsistent and not centrally retrievable.
4. “What happens when gates are bypassed?”
   Hangup: no exception process or expired exceptions stay open indefinitely.
5. “Which systems/components/services are in scope?”
   Hangup: scope excludes “platform” components, images, libraries, or IaC.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating SA-4(3) as an engineering policy-only item.
  Fix: require per-release evidence bundles and make them a release gate.
• Mistake: Applying it only to internal dev teams.
  Fix: extend to third parties through contracting, onboarding checks, and evidence requests.
• Mistake: Overbuilding the SDLC checklist.
  Fix: start with a minimum viable demonstration standard; expand after you can pass audits with consistent evidence.
• Mistake: Evidence stored in tools auditors cannot access or that change over time.
  Fix: store immutable exports or stable links with access controls and retention rules.
• Mistake: No owner, no cadence.
  Fix: assign an accountable owner and run control health checks with tracked remediation. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-4(3). ¹

Risk still concentrates in predictable places:

• Supply chain risk: a third party ships insecure code/components; you cannot show you required or verified their SDLC practices.
• Authorization and customer diligence failures: inability to produce consistent SDLC evidence delays ATOs, renewals, and enterprise security reviews.
• Operational risk: teams bypass gates under delivery pressure; defects and vulnerabilities reach production with no paper trail.

Practical 30/60/90-day execution plan

First 30 days (establish enforceable definitions)

• Assign SA-4(3) owners across Engineering, Security, and Procurement/TPRM.
• Draft the SA-4(3) control card: triggers, steps, exceptions, and escalation.
• Define “SDLC demonstration” acceptance criteria and the minimum evidence bundle.
• Identify in-scope systems/components/services and top third parties.

Days 31–60 (put gates and contracts in place)

• Implement release gates in CI/CD or change management that require the evidence bundle.
• Update third-party templates: MSA/SOW clauses for SDLC demonstration and evidence access.
• Pilot evidence collection with one internal team and one third party; fix friction fast.

Days 61–90 (prove it works, then scale)

• Run control health checks across multiple teams and critical suppliers.
• Build a remediation backlog with due dates; validate closure with objective proof.
• Move evidence storage to a single system of record (Daydream or your GRC repository) and standardize naming, access, and retention.

Frequently Asked Questions

What counts as “demonstrate the use of an SDLC” for SA-4(3)?

“Demonstrate” should mean objective artifacts tied to real releases, such as PR approvals, test results, security checks, and release sign-offs mapped to your SDLC criteria. A process document alone rarely satisfies the expectation. ¹

Does SA-4(3) apply to SaaS and managed service providers?

Yes if the provider is effectively the “developer of the system service” or delivers components that affect your system’s security posture. Treat their SDLC evidence as a contractual and due diligence requirement. ²

How do we handle agile teams that don’t have formal phase gates?

Keep agile workflows, but enforce evidence-based gates (definition of done, CI checks, approvals) that prove SDLC activities occurred. Document the mapping from agile ceremonies and tooling outputs to your SDLC demonstration criteria.

What if a third party refuses to share detailed SDLC artifacts?

Escalate through procurement: require at least a defined evidence bundle or independent assurance that maps to your criteria, or treat it as a risk acceptance with compensating controls and explicit approval. Your contracts should set this expectation up front. ¹

How should we store evidence so it survives audits and staff turnover?

Store it centrally with stable links or exported records, tied to release IDs and SDLC version, and with controlled access. Daydream can act as the system of record for the control card, evidence bundle requirements, and closure tracking. ³

What’s the fastest way to fail SA-4(3) in an assessment?

Having an SDLC policy but no consistent, retrievable proof for a sampled set of releases, especially for third-party-developed components. Fix it by standardizing the evidence bundle and making it a release gate. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI