SA-15: Development Process, Standards, and Tools

SA-15 requires you to ensure any developer (internal teams and third parties) follows a documented, security-relevant development process, including defined standards and approved tools, and you can prove it with repeatable evidence. To operationalize it quickly, assign an owner, standardize your SDLC expectations, bind them into contracts and engineering workflows, and collect objective artifacts from every release. ¹

Key takeaways:

• SA-15 is an “engineering process control”: auditors want your documented SDLC standards and proof they’re followed release after release. ¹
• The fastest path is a single SDLC standard + toolchain baseline that applies to internal development and third-party development. ²
• Evidence quality matters more than policy prose: tickets, pipeline logs, code review records, and exception approvals win exams.

The sa-15: development process, standards, and tools requirement is where security governance meets engineering reality. A CCO or GRC lead usually inherits a mix of teams, repos, outsourced development, and cloud services, each with different “how we build” norms. SA-15 forces you to make that build process explicit, consistent, and defensible: documented processes, documented standards, and an approved set of tools that developers actually use. ¹

This control is often assessed indirectly. An assessor doesn’t just ask for an SDLC policy; they pull a sample of releases and trace them back to process steps: requirements, design review, code review, testing, security checks, approvals, and exceptions. If your process exists only in a PDF and not in Jira/Azure DevOps/GitHub/GitLab and CI/CD, you’ll struggle to show operating effectiveness.

Operationalizing SA-15 quickly means making a few decisions and codifying them: (1) what your “documented development process” is, (2) what standards are mandatory, (3) what tools are approved, and (4) what artifacts are required per change and per release. Then you enforce that baseline through contracts, engineering enablement, and audit-ready evidence collection.

Regulatory text

Excerpt (SA-15): “Require the developer of the system, system component, or system service to follow a documented development process that:” ¹

Operator interpretation (what you must do):

• Identify who “the developer” is for each system/component/service (internal engineering, a third party, or both).
• Put in place a documented development process with defined standards and tools.
• Require adherence, not just publication, and be able to show evidence that the process is followed. ²

SA-15 is written as an acquisition and development lifecycle control. Practically, treat it as an SDLC governance requirement that applies to software you build, software built for you, and system components you configure or customize in ways that affect security.

Plain-English requirement: what SA-15 really demands

You need a documented “how we build and change systems” playbook, and it must be the playbook your developers actually follow. That includes:

• Process: phases/steps and required gates (e.g., design review, code review, testing, security checks, approvals).
• Standards: coding standards, branching/merge rules, dependency rules, secure configuration standards, documentation standards.
• Tools: approved repositories, CI/CD, ticketing, scanners, artifact storage, and how those tools are configured to enforce your process.

Auditors commonly read SA-15 as: “Show me your SDLC standard and show me a release that followed it end-to-end.”

Who it applies to (entity + operational context)

Entity types commonly in scope:

• Federal information systems and programs implementing NIST SP 800-53 controls.
• Contractors handling federal data or operating systems on behalf of federal agencies, including third parties building system components/services. ¹

Operational contexts where SA-15 shows up:

• Product engineering teams shipping application code.
• Platform/SRE teams shipping infrastructure-as-code, CI/CD templates, container images, and hardened baselines.
• Data/analytics teams shipping pipelines and notebooks that run in production.
• Third parties delivering code, integrations, or managed services where configuration and change management materially affect security.

If a third party develops or significantly modifies a component in your system boundary, treat them as “the developer” for SA-15 purposes and flow requirements down contractually and operationally.

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

Use this as a fast implementation checklist for the sa-15: development process, standards, and tools requirement.

1) Assign ownership and define scope

• Control owner: typically the Head of Engineering, DevSecOps leader, or SDLC governance owner; GRC acts as policy steward and evidence coordinator.
• System coverage: list systems/services in scope and identify the dev model (internal, outsourced, mixed).
• Toolchain inventory: repos, CI/CD, ticketing, artifact registry, scanning tools, change approval tools.

Deliverable: SA-15 control narrative that maps scope → owners → evidence sources. ¹

2) Publish a documented development process (minimum viable SDLC)

Write one SDLC standard that is short enough to be used. Include:

• Required work intake (ticket required; emergency path defined).
• Requirements and design documentation expectations.
• Peer review requirements (who can approve, segregation of duties rules where feasible).
• Testing expectations (unit/integration; security test triggers).
• Release and rollback expectations.
• Exception handling (who can waive, for how long, and required compensating controls).

Make the SDLC standard referenceable from engineering workflows (templates, “definition of done,” pull request checklists).

3) Define mandatory standards (coding, dependencies, documentation, configuration)

Pick standards that are enforceable with automation and reviews:

• Secure coding expectations and prohibited patterns (e.g., hard-coded secrets, unsafe deserialization).
• Dependency and component rules (approved sources/registries, patching expectations, license constraints if applicable).
• Infrastructure-as-code and configuration standards (baseline modules, parameter constraints).
• Documentation standards for changes impacting security posture (threat modeling record where appropriate, architecture decision records).

Keep a single “standards index” page so assessors can find the authoritative list quickly.

4) Establish an approved tools baseline (and lock it in)

SA-15 is not “buy security tools.” It is “control which tools can be used to build and ship.”

• Approved repo platforms and required settings (branch protections, signed commits if you require them, required reviewers).
• Approved CI/CD systems and minimum pipeline checks (build, test, scan, artifact signing if used).
• Approved scanning and quality tools (SAST/SCA/secret scanning) and when they must run.
• Approved artifact repositories/registries and retention settings.
• Ticketing/change systems used to record approvals and traceability.

Key point: document tool configuration standards, not just tool names. A tool without enforced settings is weak evidence.

5) Integrate SA-15 into third-party onboarding and contracts

For third parties developing code/components:

• Add SDLC and secure development clauses: they must follow your documented process or demonstrate an equivalent documented process accepted by you.
• Require delivery of evidence artifacts with releases (test results, scan summaries, change records, exception approvals).
• Reserve audit/assessment rights for SDLC artifacts tied to your systems.

Practical approach: a one-page “Supplier Secure Development Addendum” that points to your SDLC standard and lists required deliverables.

6) Build an evidence program that runs automatically

Auditors sample. Your goal is to pass sampling without scrambling.

• For each release, ensure you can retrieve: ticket → PR → approvals → pipeline run logs → scan outputs → release record.
• Store evidence in durable systems: ticketing, repo logs, CI/CD logs, and an audit folder or GRC system with immutable exports when needed.
• Define an exception register for process deviations (emergency fixes, scan suppressions, skipped tests).

Daydream (or any GRC workflow system) fits naturally here as the place to map SA-15 to the control owner, implementation procedure, and recurring evidence artifacts so evidence collection is predictable instead of heroic. ¹

Required evidence and artifacts to retain

Retain artifacts that prove both design (the documented process exists) and operation (teams followed it):

Process / governance

• SDLC policy/standard and revision history
• Engineering standards index (coding, dependency, configuration)
• Approved tools list with required configurations
• Exception/waiver procedure and approvals matrix

Per change / per release (sample-ready)

• Work item/ticket with acceptance criteria and risk notes
• Design review record (meeting notes or ADR) for material changes
• Pull request with reviewer approvals and checks passing
• CI/CD pipeline run record (build, test, security checks)
• Scan outputs or summaries (SAST/SCA/secret scanning), including disposition of findings
• Release approval record and rollback plan (where used)
• Exception records for any skipped steps, with approvals and compensating controls

Third-party specific

• Contract clauses or addendum referencing your SDLC requirements
• Third-party deliverables: test reports, scan summaries, change logs
• Your acceptance record that the third party met required process steps

Common exam/audit questions and hangups

Expect these questions, and prepare crisp answers plus artifacts:

1. “Show me your documented development process.”
   Hangup: teams point to a wiki page with aspirational text and no linkage to actual workflows.

2. “How do you know developers follow it?”
   Hangup: no sampling package; no traceability from ticket to deployment.

3. “What are your standards, and how do you enforce them?”
   Hangup: standards exist but enforcement is manual and inconsistent across repos.

4. “Which tools are approved, and who can change tool configurations?”
   Hangup: tool sprawl and admin rights without governance.

5. “How do third parties comply?”
   Hangup: contracts lack SDLC obligations; no evidence delivered with releases.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing a long SDLC policy nobody uses.
  Fix: keep the SDLC standard short; enforce it through templates, required repo settings, and CI checks.

• Mistake: Treating SA-15 as “security scanning” only.
  Fix: include process steps (reviews, approvals, exception handling) plus standards and tools.

• Mistake: No exception mechanism, so teams bypass quietly.
  Fix: create a lightweight waiver path and log every deviation in an exception register.

• Mistake: Ignoring infrastructure-as-code and configuration changes.
  Fix: apply the same SDLC gates to IaC repos and pipeline templates.

• Mistake: Third-party development left out of scope.
  Fix: flow down SDLC requirements into third-party contracts and onboarding, and require deliverable artifacts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-15, so this page avoids case-specific claims. The operational risk is still concrete: weak or inconsistently followed development processes increase the chance of introducing vulnerabilities, misconfigurations, and undocumented changes that are hard to detect and harder to remediate. SA-15 reduces that risk by making development repeatable, reviewable, and auditable. ²

Practical 30/60/90-day execution plan

Use this plan to operationalize quickly without inventing timelines for engineering work.

First 30 days (stabilize expectations + ownership)

• Assign SA-15 control owner and backups.
• Define scope: in-scope systems and who develops each.
• Publish a minimum SDLC standard and standards index.
• Create an approved tools baseline (tool list + required settings).
• Identify required evidence artifacts per release and where each artifact lives.

Days 31–60 (enforce through workflow + contracts)

• Implement repo protections and PR templates that reflect the SDLC gates.
• Add CI/CD minimum checks and standard pipeline templates.
• Stand up an exception register and waiver workflow.
• Update third-party development language in MSAs/SOWs; add a secure development addendum.
• Run one internal “audit rehearsal” by sampling recent releases and assembling evidence.

Days 61–90 (prove operating effectiveness + scale)

• Expand enforcement to all repos in scope (including IaC and platform components).
• Standardize evidence exports and retention (what you store centrally vs. what stays in system logs).
• Build dashboards for coverage: repos with required protections, pipelines running required checks, open exceptions.
• Formalize recurring evidence collection in Daydream so audits pull from a known evidence set instead of ad hoc requests. ¹

Frequently Asked Questions

Does SA-15 apply to low-code/no-code and configuration-only changes?

Yes if those changes affect the system’s behavior or security posture. Treat configuration and IaC as “development” and route changes through the documented process with review, testing, and approval artifacts. ²

Can we accept a third party’s SDLC instead of forcing ours?

Yes if it is documented and you formally accept it as equivalent for your risk needs. Put that acceptance in writing, map it to your SA-15 expectations, and require evidence artifacts with each delivery. ¹

What’s the minimum evidence set an auditor will accept?

Provide the documented SDLC standard plus a release sample showing ticket-to-deploy traceability, code review approvals, pipeline results, and exception approvals where applicable. If you can’t reconstruct a release package quickly, expect follow-up questions. ²

Our teams use different tools. Do we have to standardize everything?

You can allow multiple tools, but each must be on an approved list with minimum required configurations and a consistent evidence trail. Tool diversity is manageable if evidence collection is consistent and sampling works. ²

How do we handle emergency fixes that bypass normal gates?

Define an emergency change path with explicit criteria, required approver, and mandatory after-action steps (e.g., retroactive PR review and documented justification). Track each occurrence in an exception register and review trends. ²

What should the GRC team ask engineering for without creating busywork?

Ask for workflow-native artifacts: repo settings exports, PR records, CI/CD logs, ticket links, and the exception register. Avoid manual screenshots as the primary evidence source unless there is no better system-of-record.

Footnotes

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

2. NIST SP 800-53 Rev. 5