SA-3 System development life cycle: requirements and evidence

What SA-3 system development life cycle requires

SA-3 requires you to acquire, develop and manage your system under a defined system development life cycle that incorporates security and privacy, with roles and responsibilities assigned to named individuals and risk management built into each life cycle activity. The control exists because security that is added late, after design decisions are locked and code is in production, is expensive to fix and often incomplete. SP 800-53B assigns SA-3 to the low, moderate and high security baselines and to the privacy baseline, and Appendix C of SP 800-53 Rev. 5 treats it as an organization-implemented, assurance-related control. An assessor will not accept a development process that only exists in the heads of the engineering leads. They will look for a written SDLC, evidence that it is followed, and proof that the people named in it actually hold those duties.

The most common obstacle is that the life cycle exists informally. Teams have a way they build software, a change board that meets when someone remembers, and a security reviewer who joins late, but none of it is documented as the organization's SDLC or tied to specific phases. Start by writing down the phases you actually use, then mark where security and privacy requirements are set, where threats are analyzed, where testing and acceptance happen, and where risk decisions are recorded. Confirm with your assessor which document they expect to see, since the SA-3 assessment procedure in SP 800-53A Rev. 5 examines SDLC documentation, the organizational risk management strategy and the enterprise architecture documentation. Those three artifacts should agree with each other.

Named roles are the part auditors test most directly. For each phase, record who owns security requirements, who approves privacy impacts, who signs off a release and who accepts residual risk, using individuals or current position titles that map to named people. Then sample a recent change and confirm that the person who approved it held the role the SDLC assigns. If the answers do not match, fix the document or the practice before the assessment, not during it. Also ask your assessor whether they expect FedRAMP-style evidence, since FedRAMP's Rev5 baselines require SA-3 at its Classes B, C and D.

Which systems and teams SA-3 reaches

SA-3 only works when the organization decides what the life cycle covers and who owns each phase. The cards below cover the scoping decisions assessors look for first, then the teams that hold roles. SA-3 applies in all three SP 800-53B security baselines and the privacy baseline, and the 2026 FedRAMP Rev5 baselines require it at Classes B, C and D.

Systems inside the life cycle

Start with a written inventory of every system the life cycle governs, including systems built in-house, systems configured from vendor products and systems that process the same data. Assessors compare that inventory against the system security and privacy plan. A system missing from the SDLC scope is a gap even when its code is well managed. Record the authorization boundary and confirm that each in-scope system has a named owner.

Custom code and configuration

Decide whether application source, build pipelines, container definitions, and security configuration files sit under the same life cycle controls. Many teams govern application code tightly but treat Terraform, Ansible or Helm files as ad hoc. The SDLC should cover those files too, with the same review, approval and change history. Confirm which repositories and branches are in scope before the first assessment.

Infrastructure as code

Infrastructure-as-code templates define what the production environment looks like, so changes to them are changes to the system. Bring them into the SDLC with the same phases, roles and risk reviews as application code. Ask who can merge infrastructure changes, whether plans are reviewed before apply, and where the approved baseline is kept. Gaps here often surface during configuration management and continuous monitoring testing.

Vendor-built and cloud services

Products and managed services the organization did not build still need a place in the life cycle. Define which decisions the organization makes during acquisition, integration, configuration and retirement, and which the provider makes. Record that split in the agreement and the system documentation. Where the provider owns development, SA-3 reliance usually runs through the external system services controls, so confirm the provider's responsibilities in writing.

Roles for development and operations

Assign named individuals to the phases of the life cycle, not just functions. Development leads own design and code changes, operations owns deployment, patching and monitoring, and both need defined handoffs. Auditors test whether these roles appear in the SDLC documentation and whether the people named still hold them. Keep the roster current when staff change, since stale names are a common finding.

Security, privacy and procurement roles

Security and privacy staff review risk at defined phase gates, and procurement confirms that contracts carry the requirements the SDLC sets. SA-3 expects risk management to be integrated into life cycle activities, so each gate should name the reviewer and the decision they record. The privacy baseline applies SA-3 regardless of impact level, so privacy reviewers must be included where personal information is processed. Confirm that each reviewer has the authority to stop a release.

How an assessor tests SA-3

This table groups the SP 800-53A assessment activities for SA-3 by what the assessor examines, interviews or tests, the evidence requested and the findings seen most often. Read each row as a question the assessor will ask about your system development life cycle. The main takeaway is that a written SDLC alone does not pass; assessors look for named roles, recorded risk decisions at each phase and proof that the process actually ran.

Assessment focus	Test methods	Evidence an assessor requests	Common findings
SDLC documentation	Examine	Approved SDLC document with security and privacy activities in each phase, version history and approval date	SDLC is undocumented or exists only as informal team practice
Roles and responsibilities	Examine and interview	Role descriptions or RACI matrix naming the individuals who perform each SDLC responsibility	Roles are assigned to job titles or teams with no named individuals
Risk checkpoints per phase	Examine and interview	Phase gate checklists or tickets showing risk decisions recorded before work moves forward	No risk checkpoints per phase; risk is reviewed only at go-live
Organizational risk management strategy	Examine	Organization-wide risk management strategy and a mapping showing how the SDLC applies it	SDLC cannot be traced back to the organization's risk management strategy
Information security and privacy risk management strategy documentation	Examine	Privacy and security risk documentation, plus triggers that route new or changed systems to privacy reviews	Privacy steps are absent from the SDLC or only applied after deployment
Enterprise architecture documentation	Examine	Architecture diagrams showing where the system fits and where security requirements are allocated	Architecture documents are out of date with the deployed system
Enforcement in the build pipeline	Test	Pipeline configuration and a sample of recent builds showing security checks ran and approvals were recorded	Security gates are configured but skipped, overridden or not required for merges
Staff practice	Interview	Interview notes from developers, system owners and security staff confirming they follow the SDLC version in force	Staff are unaware of the current SDLC version or follow an older process

Implementing SA-3 step by step

The sequence below takes an organization from no written lifecycle to a documented SDLC with named owners, phase gates and records that an assessor can test against SA-3. The organization makes the decisions at each step, and a partner can draft the artifacts and prepare the evidence.

Confirm scope and system boundaries
Start by listing the systems, applications and services the SDLC must cover, including in-house development, vendor-supplied products and cloud services. Record the system impact level and the SP 800-53B baseline that applies, since SA-3 is selected in the low, moderate and high baselines and in the privacy baseline. The organization owns this decision. A partner can draft the scope statement for review. The step is done when the scope is approved by the system owner and the security and privacy leads, and the approval is dated and filed.
Choose or adapt an SDLC model
Select a lifecycle model that fits how the teams actually build and release software, such as a waterfall, iterative or DevSecOps variant, then adapt it so security and privacy activities appear in every phase. SA-3 does not prescribe a specific model, so the justification for the choice matters more than the name. The output is a written SDLC standard that names the phases, the activities in each phase and the decision points. Confirm the model with the engineering leads and the risk owner before it is published.
Define security and privacy gates per phase
For each phase (requirements, design, build, test, release, operation and retirement), define a gate with entry and exit criteria covering security and privacy. Examples include a threat model before design approval, a privacy impact check before a new data flow goes live, and a sign-off that known high-severity findings are resolved or formally accepted. Gate checklists are the main artifact an assessor will sample, so each item should name the evidence it produces, such as a ticket, a review record or a test report.
Assign roles to named individuals
Build a role matrix that maps each lifecycle activity to an accountable person, not only a team. Cover the system owner, the security and privacy officers, the development lead, the release approver, the risk executive and any third-party developer contacts. SA-3 requires defined roles and responsibilities with named individuals, so the matrix should carry names, backups and the date each assignment was confirmed. The organization owns these assignments. A partner can prepare the template and help reconcile it with existing org charts.
Integrate risk management into each phase
Connect the lifecycle to the organization's risk management process so that each phase produces risk inputs and receives risk decisions. Requirements feed the risk register, design reviews record accepted risks, and test results update the plan of action and milestones where findings remain open. SA-3 expects risk management to be part of life cycle activities, not a separate report written after release. The output is a risk workflow diagram plus example entries showing how a finding moves from detection to decision, labeled as illustrative if used in training.
Map phases to the SP 800-53 controls they support
Create a phase-to-control mapping that shows which gate, artifact and owner satisfies SA-3 and the related controls the catalog links to it, such as SA-4, SA-8, SA-11 and SA-15. This mapping lets assessors trace a control to a process and then to records. Use only the control relationships published in the NIST catalog and confirm them against the current release before relying on them. The mapping is complete when each phase lists at least one control and one evidence source.
Extend the SDLC to preproduction and technology refresh
Document how the lifecycle covers preproduction environments, the controls that apply to them and the criteria for moving data or configurations into production. Add a technology refresh step that tracks component end-of-life dates and triggers a review before support lapses. Where the organization relies on tools such as GitLab protected branches or Semgrep scans in CI/CD, record their configuration as evidence, and confirm current tool capabilities with each vendor before stating them in policy. The step closes when the refresh review schedule and preproduction rules are approved.
Record outputs and prepare for assessment
Store the SDLC standard, role matrix, gate records, risk decisions and mapping in a version-controlled location so changes are traceable. Retain completed gate checklists and sign-offs for each system in scope. Before an independent assessor tests SA-3, run an internal review that samples a release from each phase and confirms the records exist and match the standard. Only the assessor can issue a finding or report. Preparing the evidence set is where an implementation partner adds the most practical value, and the organization should ask for a written list of deliverables before work begins.

Evidence that passes an SA-3 review

An SA-3 assessor looks for a life cycle that is written down, owned by named people, and visibly used on real projects. The cards below cover the artifacts that prove this and the habits that keep them current between assessments.

The approved SDLC document

This is the written life cycle the system follows, from initiation through disposal, with security and privacy activities placed in each phase. Assessors compare it against what teams actually did, so the document should name the phases, the required outputs of each, and the approval record. Check that the approving authority, approval date and version number appear on the document itself. A life cycle that exists only in a wiki draft without an approval record is hard to defend.

Role assignments with named individuals

SA-3 requires defined roles and responsibilities, and assessors expect those roles to map to people, not only to job titles. A responsibility matrix should name the individual who owns each life cycle phase, the security reviewer, the privacy reviewer and the person who signs off on production release. Confirm that the names are current, that acting or backup owners are recorded, and that departures trigger an update within a set internal process.

Phase gate records

Gate records prove that the SDLC was followed on specific systems. Each gate, such as requirements approval, design review, pre-production testing and release, should carry a dated decision, the reviewers who signed it, and any security or privacy conditions attached. Pull a sample of recent releases and confirm each one has a gate record for every required phase. Missing gate records for emergency changes are a common finding, so document how exceptions were approved and closed.

Risk assessments tied to life cycle activities

SA-3 expects risk management to run through the life cycle, not sit beside it. Keep risk assessments linked to specific phases, for example a design-stage risk assessment before architecture approval and a pre-release assessment before go-live. Each assessment should record identified risks, the owner of each risk, the decision taken and any residual risk accepted. Assessors often pick one system and trace its risks from the assessment through to the gate decision.

The risk management strategy it references

The SDLC document usually points to an organization-level risk management strategy, and assessors examine that strategy alongside the life cycle. Confirm the referenced strategy exists, has an owner and a review date, and describes how risk tolerance is set and applied to development decisions. A life cycle that cites a strategy the organization never adopted will fail on consistency, even when the development teams work well.

Change history and review dates

Between assessments, keep the SDLC document, role matrix and risk strategy under version control with a recorded review date and a reason for every revision. A wiki with per-version history, or a document repository with check-in records, lets you show what changed, when and by whom. Set a review cadence in the document itself and keep the review minutes. An assessor who sees a current review date and a clear revision trail is far more likely to accept the artifacts without further sampling.

Preproduction environments and technology refresh in SA-3

SA-3 gained its enhancements in the SP 800-53 Rev. 5 catalog, and the 5.2.0 release lists three in total, all active. The enhancements address two concerns the base control touches only in general terms: how preproduction environments are kept separate and governed, and how technology is refreshed before components become unsupported. None of the three is assigned to an SP 800-53B baseline, so a low, moderate or high system does not inherit them automatically. Before you scope them in or out, open the SA-3 entry in the OSCAL catalog and read the exact enhancement wording yourself. The enhancement titles, parameters and assessment objectives are the authoritative text, and the wording in any summary, including this one, should be checked against it.

For preproduction environments, the question an assessor will ask is whether development, test and staging systems are controlled as part of the same lifecycle as production. Evidence usually includes network and account boundaries between environments, separate credentials and access lists, documented rules for copying production data into test systems, and change records showing how code moves from one environment to the next. If you run self-hosted tooling, confirm which of these your environment can produce from logs and configuration. For example, a Git server can show protected branch settings and merge history, but it cannot by itself prove that a staging database holds no live personal data. That proof has to come from your data handling procedures and their records.

For technology refresh, the evidence is a current inventory of the components in each system, their vendor support end dates, and a dated plan for replacement or alternative support. Connect this plan to SA-22 and to your change control records so the refresh decisions are traceable. Ask your assessor early which evidence they expect for the enhancements in your baseline and how they want the refresh plan dated and approved, and confirm this with the authorizing official or the compliance owner for your system. Any implementation partner can prepare the inventory and the plan, but the organization owns the decisions and the assessor, not the partner, determines whether the evidence is sufficient.

What meeting SA-3 costs

This table breaks the cost of meeting SA-3 into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since NIST does not publish cost or effort figures for SA-3 and no fixed prices are supplied here.

Cost component	One-time or recurring	Who is paid or who does the work	What drives the cost
Process design and SDLC documentation	One-time, with periodic revision	Internal security and engineering leads, often supported by an outside consultant	Number of development methods in use, and how many lifecycle phases need written security and privacy steps
Role assignment and named individuals	Recurring as staff change	Internal management time to name owners and record them in the plan	Staff turnover and the number of teams that build or change systems
Phase gate reviews and risk sign-off	Recurring, per release or per phase	Internal reviewers, with risk decisions recorded by the organization	Release frequency, number of systems, and how much review each change needs
Protected branches and code scanning setup	One-time setup, then recurring tuning	Internal platform or DevOps engineers, or an implementation partner under a fixed-scope agreement	Number of repositories, languages in use, and how many pipelines must enforce the rules
Open-source tooling licenses	Often no license fee for community editions	Hosting and staff time are the main costs, not the software license	Whether self-hosting needs new servers or can use existing infrastructure; confirm each tool's license terms before use
Evidence upkeep and assessor sampling	Recurring, per assessment cycle	Internal evidence owners, and the independent assessor who samples records	Number of systems in scope and how consistently evidence is kept during development

Who owns SA-3 and who can help

Your organization owns SA-3. The control asks that the system be acquired, developed and managed under a defined system development life cycle that addresses security and privacy, with roles and responsibilities assigned to named individuals and risk management built into the life cycle. Those decisions cannot be delegated to a vendor or consultant, because they describe how your organization accepts risk on its own systems.

Naming the SDLC owner: A named individual, usually in engineering or product leadership, approves the life cycle and answers for it at assessment time.
Assigning phase roles: Security, privacy, architecture and operations each need documented responsibilities at requirements, design, build, test, release and retirement.
Making risk decisions: Accepting, mitigating or transferring life cycle risk is a management act that must be recorded with a date and an owner.
Approving the SDLC document: Leadership sign-off and a review schedule show that the process is governed rather than informal.
Operating the process: Teams must follow the life cycle in real releases, since assessors test practice as well as the written procedure.

Before any outside party starts work, confirm that these named roles exist and that someone internal can explain each risk decision.

Common SA-3 gaps and how to close them

Most SA-3 findings come from a life cycle that is followed informally rather than written down, assigned and recorded. The cards below cover the gaps assessors meet most often, each with a closing action the organization can verify before its assessment begins.

An SDLC that exists only in practice

Teams may follow a sound life cycle, but SA-3 expects it to be defined and managed as the organization's documented method for acquiring, developing and maintaining systems. Assessors look for a written life cycle that names its phases, the security and privacy activities in each phase and the gates that must pass before a release. Close the gap by documenting the life cycle as it is actually run, then checking that recent projects followed it. Where they did not, record why and decide whether the document or the practice should change.

No privacy steps in the life cycle

SA-3 requires the life cycle to incorporate privacy as well as security, and the privacy baseline applies this control regardless of impact level. Many SDLCs cover threat modeling but never ask what personal data a feature collects, why it is needed or how long it is kept. Add a privacy checkpoint at requirements and design, with a named reviewer who can stop a release. Confirm the checkpoint produces a record for each system that processes personal information.

Roles without named people

SA-3 expects defined roles and responsibilities, and assessors test whether those roles are assigned to named individuals. A role such as product security owner or release approver that exists only as a job title in a diagram leaves no one accountable when a gate fails. Name a person and an alternate for each life cycle role, record the assignments in the system documentation, and confirm each person has the access and authority the role needs. Update the list when staff change.

Risk management disconnected from delivery

The control expects risk management to be integrated into life cycle activities, not run as a separate exercise once a system is built. When the risk register is updated quarterly but backlog items move weekly, risk decisions are made without the people who understand the change. Tie each significant risk to a delivery item, require a risk review before design sign-off and before production, and record accepted risks with an owner. Ask whether a change that alters the threat picture can reach production without that review.

No evidence trail for life cycle decisions

An SDLC can be sound and still fail assessment if the organization cannot show it ran. Assessors ask for documentation of decisions, approvals and risk reviews for specific systems, not only the policy. Keep these records in version-controlled tools so each change shows what changed, when and by whom. Use protected branches so that approvals are enforced in the repository, and store gate decisions in a wiki or documentation system with history kept. Check that you can produce the record for one release within a day.

SA-3 questions buyers ask

What does it cost to meet SA-3 system development life cycle requirements?

Cost depends on how much of the life cycle already exists in writing and in tooling, and on how many systems fall under the requirement. The main cost components are internal staff time for defining roles and phase gates, tooling and hosting for the repositories and tracking systems that hold evidence, and any outside help for documentation and assessment preparation. NIST does not publish certification or compliance cost estimates, so no figure can be quoted from a standard. Ask any partner for a fixed-scope quote that lists the systems in scope, the life cycle phases to document, the tools to configure and the evidence to produce. Separate one-time setup from recurring costs such as tool licenses, hosting, and periodic review of the SDLC.

How long does it take to put an SDLC that satisfies SA-3 in place?

The duration depends on the number of systems, how mature current development practices are, and how many teams must agree on roles and gates. Organizations with a documented development process usually need less time to map it to SA-3 than organizations starting from informal practice. NIST does not set implementation timelines for SP 800-53; those are set by the authorizing body or contract, such as OMB Circular A-130 for federal agencies. Confirm the schedule with your assessor and authorizing official before work starts, and ask any implementation partner to tie milestones to agreed deliverables in a written scope.

What does the client organization have to provide?

The organization owns the control, so it must supply the decisions and people that an SDLC depends on. That means named individuals for each life cycle role, executive approval of the security and privacy roles, access to current development, testing and release records, and the existing risk management strategy that SA-3 expects to be integrated into each phase. Engineering leads must confirm how work actually flows today, because a documented process that nobody follows will fail assessment. An implementation partner can draft the process and configure tooling, but it cannot assign accountability or approve risk on the organization's behalf.

Can our in-house team implement SA-3 without outside help?

Yes, many internal teams can implement SA-3 themselves, particularly where security, engineering and risk staff already collaborate. The work is mostly governance and documentation: defining the life cycle, naming roles, placing security and privacy checkpoints into phases, and keeping records. The harder parts are usually consistent adoption across teams and producing evidence that an assessor can trace from policy to practice. Internal teams should check whether they have capacity to maintain the process after launch, since SA-3 expects the life cycle to be managed, not written once.

What does an implementation partner add to SA-3 work?

A partner adds technical preparation and evidence production under a written scope. In practice, DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside the client's own infrastructure, so the life cycle records, review gates and change history can live in systems the client controls. The partner does not decide the organization's risk acceptance, does not write the authorization decision, and does not issue an audit report or certificate. Independent assessors and certification bodies perform that testing.

How does an assessor test SA-3, and what evidence passes?

SP 800-53A Rev. 5 gives SA-3 eight determination statements that an assessor tests using examine, interview and test methods. Assessors typically examine the system development life cycle documentation, the organization's risk management strategy, the information security and privacy risk management strategy documentation, and the enterprise architecture documentation. They interview process owners to confirm that roles are understood and followed. Evidence that usually passes includes a approved life cycle document, a role assignment matrix with named individuals, records showing security and privacy reviews at defined phases, and traceable links between risks and development work. Confirm the exact assessment objects and sampling expectations with your assessor, since the assessment approach follows your authorization scope.

Which open-source tools can produce SA-3 evidence?

Several self-hosted tools can generate records an assessor can examine. GitLab Community Edition (MIT) protected branches restrict which roles can push or merge and keep force pushes disabled unless explicitly allowed, which supports a controlled development workflow. Semgrep Community Edition (LGPL-2.1-only) can run in CI/CD pipelines to scan repositories continuously with community or custom rules, producing security checkpoint results per change. XWiki (LGPL-2.1-or-later) keeps version history of each page showing what changed, when and by whom, which suits life cycle documents. BookStack (MIT) assigns abilities through roles and per-page permissions, useful for documenting role assignments. Confirm each tool's fit with your own assessor and environment, since none of these tools alone satisfies SA-3.

How DeployOpen approaches SA-3

SA-3 asks the organization to run its systems under a defined development life cycle with named roles and risk management in each phase. DeployOpen works on the implementation side of that: it scopes the work in writing, prepares the life cycle documents, configures self-hosted tooling that generates evidence, and packages that evidence for assessment. The organization owns the life cycle, and independent assessors decide whether it is met.

Written scope and role split

Every engagement starts with a written scope that names which systems, teams and life cycle phases are covered and who owns each deliverable. For SA-3, the organization remains accountable for its SDLC and for naming the individuals who hold each role. DeployOpen documents what it prepares and what the client must approve, so an assessor can see who decided what. Ask for the scope document to list the assignment of roles before work begins.

SDLC documentation package

The life cycle documentation covers the phases the organization uses, the security and privacy activities expected in each phase, and the roles assigned to them. Assessors examine this documentation against the SA-3 determination statements, so it must describe how the process is actually run. DeployOpen drafts the package from interviews and existing practice, then the organization approves and maintains it. Confirm who signs off each revision.

Risk management in each phase

SA-3 expects risk management to be integrated into life cycle activities, not added at release. In practice this means a documented checkpoint at requirements, design, build, test and deployment where security risks are reviewed and recorded. DeployOpen configures the records and templates for those checkpoints inside the client's environment. Check that each checkpoint produces a decision, an owner and a date that can be shown later.

Self-hosted repository controls

Source control is one of the main sources of SDLC evidence. GitLab Community Edition can be deployed in the client's infrastructure with protected branches that restrict who can push or merge, block direct pushes, and keep force pushes disabled unless explicitly allowed. These settings show that changes pass through the defined roles. Confirm the branch protection rules match the approval roles written in the SDLC documents.

Automated code scanning evidence

Static analysis in the pipeline shows that security checks happen during development rather than only before audit. Semgrep Community Edition can scan languages including Go, Java, Python, TypeScript and Terraform, using community or custom rules, and run in CI/CD on each change. Results should be retained and linked to the risk checkpoints. Confirm the languages in your codebase are covered and decide who triages findings.

Versioned life cycle records

The SDLC documents themselves need a change history, because an assessor will ask which version was in force at a given time. XWiki keeps every page change under version control, recording what changed, when and by whom, and allows comparison and rollback. BookStack assigns abilities through roles that can be overridden per shelf, book, chapter or page. Choose one wiki for policy and records, and confirm that approval roles match the permissions set in the tool.