SA-3, System Development Life Cycle, asks the organization to do four things. Acquire, develop and manage the system using an organization defined life cycle that includes security and privacy considerations. Define and document security and privacy roles and responsibilities throughout that life cycle. Identify the individuals who hold those roles. And integrate the organization's security and privacy risk management process into life cycle activities.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and a common ask in customer security reviews: show us your secure development process.
What it means in practice
The guidance calls the life cycle the foundation for developing, implementing and operating systems, and says considering security early is a founding principle of systems security engineering. It points to SA-8 for the engineering principles that help people design, code and test. It also says qualified people, such as security architects and engineers, should take part in the life cycle so that requirements are actually met.
Because the life cycle spans several organizations, including suppliers, developers, integrators and service providers, acquisition and supply chain functions matter too.
You do not need a heavy methodology. You need a defined process that your team follows, with security activities attached to stages and named people responsible.
The enhancements add three specifics: SA-3.1 Manage Preproduction Environment, SA-3.2 Use of Live or Operational Data and SA-3.3 Technology Refresh. The second one is the one that trips teams, because it concerns putting real data in test environments.
Evidence to collect
- A written life cycle document with stages and the security activity at each.
- A roles table naming who owns security tasks, with actual names or role titles.
- Tickets or pull requests that show the activities happening, such as threat model reviews and security sign off.
- Risk register entries linked to development work.
- Environment separation records between development, test and production.
Common gaps
A process on paper that the team does not follow. Auditors sample real changes and compare.
Roles defined at company level but no named owner for a specific system.
Production data copied into staging without masking. That runs against SA-3.2 if you set it as a requirement.
Security joining at the end as a release gate rather than from design.
How to implement it
- Write the life cycle in one or two pages: plan, design, build, test, release, operate, retire.
- Add a security activity to each stage, such as requirements review, threat modeling, code review, testing and release approval.
- Name the role holders and publish the table.
- Link your risk register to project intake so new systems get assessed.
- Separate environments and write a rule on live data in tests.
- Sample five recent changes every quarter and confirm each followed the process.
What an auditor may ask
- Show me the life cycle document and the last five changes that followed it.
- Who owns security tasks for this system by name?
- How do you keep live data out of test environments?
Sample your own changes first, so you know the answers.
Quick check
What does SA-3.2 address?
Use of live or operational data in preproduction environments.
