Development Process, Standards, and Tools

To meet the FedRAMP Moderate “Development Process, Standards, and Tools” requirement, you must require your system developers (internal teams and third parties) to follow a documented secure development process that covers security and privacy requirements, and you must inventory the standards and tools used, record tool configurations, and control changes to the process and toolchain with integrity safeguards ¹.

Key takeaways:

• You need a documented SDLC that explicitly maps security and privacy requirements into build, test, and release activities ¹.
• Auditors will expect a concrete toolchain inventory plus versioned, reviewable tool configuration baselines ¹.
• The hardest part operationally is change integrity: controlling and evidencing changes to your SDLC process and your tools, not just changes to code ¹.

SA-15 is a “show me” control. A policy that says “we do secure SDLC” will not pass if you cannot point to (1) a documented development process that explicitly addresses security and privacy requirements, (2) a defined set of development standards and tools, (3) the specific tool options and configurations you run in practice, and (4) a controlled, integrity-protected way of changing the process and toolchain over time ¹.

For a Compliance Officer, CCO, or GRC lead, the fast path is to treat SA-15 like a configuration management and governance problem for engineering. You are documenting how software gets built, what is allowed in the build pipeline, and how changes to that “factory” are approved and traceable. This applies equally to internal product engineering, platform engineering, DevOps teams, and third-party developers who deliver system components or services into your FedRAMP boundary.

If you run a modern CI/CD stack, SA-15 is achievable without slowing delivery. You standardize the process, baseline the toolchain, codify configuration, and make change control auditable. Tools like Daydream can help you keep evidence continuously current by mapping required artifacts to owners and automatically collecting change records from systems engineers already use.

Regulatory text

Requirement (verbatim excerpt): “Require the developer of the system, system component, or system service to follow a documented development process that explicitly addresses security and privacy requirements; identify the standards and tools used in the development process; document the specific tool options and tool configurations used in the development process; and document, manage, and ensure the integrity of changes to the process or tools used in development.” ¹

What this means for an operator: You must be able to demonstrate, with written procedures and evidence, that development follows a defined secure development lifecycle, that the toolchain and standards are known and controlled, and that changes to the SDLC and tools are managed with integrity controls (review, approvals, versioning, and traceability) ¹.

Plain-English interpretation

SA-15 asks: “Do you run a controlled software factory?”

Specifically:

1. Document the development process: not a slide deck, but a usable procedure engineers can follow. It must explicitly include security and privacy requirements as first-class inputs to design, implementation, testing, and release ¹.
2. Identify standards and tools: define what standards guide development (coding standards, branching, review rules) and what tools are used (source control, CI/CD, artifact repository, ticketing, SAST/DAST, dependency scanning, IaC tooling) ¹.
3. Document tool options and configurations: “We use GitHub” is insufficient. You need configuration detail that affects security, such as branch protection, required reviews, CI runner hardening, signing, secrets handling, and scan gating rules ¹.
4. Control changes to process/tools and protect integrity: you must treat SDLC procedures and pipeline tooling as controlled assets. Changes require approvals, are logged, and are protected from tampering ¹.

Who it applies to

In FedRAMP Moderate context, this applies to:

• Cloud Service Providers building and operating the system in the FedRAMP authorization boundary ¹.
• Federal Agencies when they are developing or significantly configuring systems/services, and when they must ensure developers (including integrators) follow required processes ¹.
• Third parties who develop system components or system services for you (including contractors, integrators, and managed service providers). SA-15 explicitly requires you to “require the developer” to follow your documented process ¹.

Operational contexts that trigger scrutiny:

• High-change SaaS environments with frequent releases.
• Use of multiple CI/CD systems across teams.
• Outsourced development or shared services with “standard corporate” pipelines not tailored to FedRAMP.
• Heavy Infrastructure-as-Code and containerized delivery where tool configuration equals production security.

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

1) Define and publish your secure development process (SDLC)

Create a concise SDLC procedure that answers:

• Phases: intake, design, build, test, release, operate.
• Security and privacy requirements integration: where requirements come from, how they are translated into engineering work, and what “done” looks like at each phase ¹.
• Mandatory activities: threat modeling or design review, code review, testing expectations, vulnerability handling, and release approvals (keep it practical; tie to existing workflows).

Deliverable: “Secure Development Process” document + an engineer-facing checklist per phase.

2) Create a standards register (what engineers must follow)

Create a single register that lists:

• Coding standards and secure coding expectations.
• Branching and pull request requirements.
• Logging/telemetry requirements (as applicable).
• Secrets management rules.
• Privacy engineering expectations (data minimization, access controls for sensitive data) as required by your program ¹.

This should be written as “must/shall” statements where possible, with links to implementation guides.

3) Inventory the development toolchain (and define the approved baseline)

Build a tool inventory that includes:

• Source control systems and org/repo structure.
• CI/CD platform(s) and runner model (hosted/self-hosted).
• Artifact and container registries.
• Dependency/package registries and proxies.
• Security tools (SAST, SCA, container scanning, IaC scanning, secrets scanning).
• Ticketing/change tracking systems.
• Release orchestration and feature flag tools.

For each tool, document the owner, purpose, where used, and system boundary relevance ¹.

4) Baseline “tool options and tool configurations” that matter

Create configuration baselines for the toolchain components that impact security and privacy, such as:

• Source control: SSO requirements, MFA, branch protection, required reviewers, signed commits (if used), restrictions on force-push.
• CI/CD: who can modify pipelines, secret injection method, approval gates, separation of duties for production deploys.
• Artifact integrity: immutability settings, retention, access controls.
• Scanning gates: what triggers scans, what severity blocks a release, documented exceptions process.
• IaC tooling: module sources, state backend controls, review requirements.

Capture this as:

• Configuration-as-code where possible (preferred).
• Screenshots/exports where configuration-as-code is not available, with a cadence to refresh evidence.

Requirement mapping: this is the “document the specific tool options and tool configurations” portion ¹.

5) Put change control around the SDLC process and the toolchain

You need two change-control tracks:

1. Process changes: edits to SDLC procedures, standards, and required steps.
2. Toolchain changes: new tools, removed tools, major config changes, privilege model changes, scan gate changes.

Minimum mechanics:

• Version control for SDLC documents and configuration baselines.
• A formal approval workflow (security and compliance review for relevant changes).
• Traceability: ticket/change record that explains why, what changed, who approved, and when ¹.

6) Ensure integrity of changes (protect against tampering)

Integrity here means you can trust the record and the current state:

• Restrict who can change SDLC documents and tool configurations.
• Log changes and preserve history.
• Keep evidence that approvals happened before changes took effect where the process says they must ¹.

If engineering resists “paperwork,” meet them where they already work: pull requests, protected branches, required reviews, and ticket links. That is often the cleanest integrity story.

7) Flow requirements to third-party developers

If a third party develops components/services:

• Bake SDLC requirements into contracts/SOWs.
• Require the third party to provide toolchain/configuration evidence that matches your baselines, or to adopt your pipeline controls for work in-scope ¹.
• Define acceptance criteria: you do not accept deliverables without required evidence (review records, scan results, release notes, etc.).

8) Operationalize continuous evidence (so audits stop being fire drills)

Assign owners and set a refresh rhythm for evidence:

• Tool inventory maintained by platform/security engineering.
• Configuration baselines owned by tool owners.
• SDLC document owned by AppSec/GRC with engineering sign-off.

Daydream can help centralize the SA-15 evidence list, map it to system owners, and keep a live record of changes and approvals so you are not reconstructing tool configuration and process history during an assessment.

Required evidence and artifacts to retain

Keep artifacts that prove both definition and execution:

Governance

• Secure Development Process (SDLC) document ¹.
• Development standards register ¹.
• RACI for tool ownership and SDLC approvals.

Toolchain inventory and baselines

• Tool inventory with owners and scope ¹.
• Configuration baselines (configuration-as-code, exports, or admin setting snapshots) ¹.
• “Approved tools” list and exceptions procedure.

Change integrity

• Change records/tickets for process updates and tool changes ¹.
• Version history (git history for docs/configs).
• Approval evidence (PR reviews, change approvals, CAB notes if used).

Execution samples (pick representative releases)

• PRs showing required reviews and linked work items.
• CI logs showing scans executed.
• Exception approvals where gates were bypassed, with rationale and compensating controls.

Common exam/audit questions and hangups

• “Show me your documented development process and where security and privacy requirements are addressed.” Expect follow-ups on where those requirements originate and how they become engineering tasks ¹.
• “List all standards and tools used in development.” Gaps appear when teams use “shadow” tools (personal CI, unmanaged registries) ¹.
• “Show current tool configurations for repo controls, CI/CD permissions, and scan gating.” Auditors often test whether documented settings match real admin settings ¹.
• “How do you control changes to the process and to the tools?” A common hangup is strong code change control but weak pipeline/tool change control ¹.
• “How do you ensure your third-party developers follow this process?” “They said they do” will not work without contractual requirements and deliverable evidence ¹.

Frequent implementation mistakes and how to avoid them

1. Mistake: SDLC document is generic and not used.
   Fix: tie every step to an engineering artifact (ticket, PR, pipeline run, release record) and sample-test it quarterly with real releases.

2. Mistake: Tool inventory exists, but configurations are tribal knowledge.
   Fix: baseline the specific options that affect access, integrity, and release gating; store baselines in version control ¹.

3. Mistake: No integrity story for changes to the toolchain.
   Fix: treat CI/CD and repo admin changes like production changes: ticket, approval, logging, and limited admin roles ¹.

4. Mistake: Third-party developers are out of scope “because they’re external.”
   Fix: SA-15 explicitly requires you to require the developer to follow the documented process; enforce via SOW language and acceptance criteria ¹.

5. Mistake: Evidence collected only at audit time.
   Fix: define evidence owners and automate collection where possible; Daydream-style evidence workflows reduce last-minute exports and screenshots.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, SA-15 failures tend to surface as assessment findings because uncontrolled toolchains and undocumented configurations create auditability gaps and increase the chance of unauthorized changes to build/release systems ¹.

A practical 30/60/90-day execution plan

First 30 days (stabilize and document the minimum)

• Identify in-scope development teams and third parties.
• Publish a draft SDLC that includes explicit security and privacy requirement touchpoints ¹.
• Build the initial tool inventory with owners.
• Pick the “top risk” tools (source control and CI/CD) and capture current configuration baselines.

Days 31–60 (control and evidence)

• Put SDLC docs and configuration baselines into version control with restricted write access.
• Implement a standard change workflow for SDLC and toolchain changes (ticket + approval + traceability) ¹.
• Define the approved tools list and exception path.
• Update third-party SOW templates to require conformance and evidence delivery ¹.

Days 61–90 (prove operation and close gaps)

• Run an internal mini-audit: select representative releases and trace from requirements to PR to CI to release record.
• Close mismatches between documented configuration and actual settings.
• Formalize a recurring review cadence for tool inventory and baselines.
• Stand up an evidence workspace (for example, in Daydream) that maps SA-15 required artifacts to owners and keeps change records current.

Frequently Asked Questions

Do we need one SDLC for every engineering team?

You need a documented development process that developers follow, and it must address security and privacy requirements ¹. A common approach is one standard SDLC with team-specific appendices for tool differences.

What counts as “tools” under SA-15?

Any tool used in the development process is in scope, especially source control, CI/CD, artifact repositories, scanning tools, and change tracking ¹. If a tool can change code, builds, dependencies, or releases, document it and baseline its relevant settings.

How detailed do tool configurations need to be?

Detailed enough to show the specific options and configurations that affect security, privacy, access, and release integrity ¹. Capture what an auditor would verify in admin settings or configuration-as-code.

We outsource development. Can we inherit the contractor’s SDLC?

You can accept a third party’s SDLC only if you explicitly require it to address your security and privacy requirements and you can obtain evidence that they follow it for your system work ¹. Contract language and acceptance criteria are your enforcement mechanism.

Is change control only for code changes?

No. SA-15 explicitly requires you to document, manage, and ensure integrity of changes to the development process and tools ¹. Pipeline and tooling changes often carry higher systemic risk than a single code change.

How do we keep SA-15 evidence current without constant manual work?

Assign owners for each artifact type and standardize where evidence lives (version control, ticketing, CI logs). A GRC evidence platform like Daydream can track required artifacts, owners, and change records so your assessment package stays current between audits.

Footnotes

1. NIST Special Publication 800-53 Revision 5