Secure Development Life Cycle in SOC 2: Controls, Evidence, and Templates

The secure development life cycle in SOC 2 is a software development life cycle in which security requirements, approvals, testing, and evidence are built into every phase, so the artifacts an auditor needs are produced by normal engineering work instead of reconstructed before the audit. SOC 2 does not prescribe a methodology or a toolchain. It asks you to define how you build software, follow that definition consistently, and prove both across an observation period that typically runs three to twelve months.

That distinction is where most engineering teams lose time. The controls usually exist — code gets reviewed, tests run, releases get approved — but the record of them expires, lives in an archived chat thread, or was never tied to the deployment it belongs to. This guide is written for CTOs, CISOs, founders, and compliance leads at midmarket and startup companies, particularly fintechs with license obligations, healthcare companies handling protected health information (PHI), and vendors selling into enterprise accounts. It draws on Konfirmity's experience across more than 6,000 security audits to show what auditors sample, what they accept, and what causes an exception in the report.

Key Takeaways: The Secure Development Life Cycle in SOC 2

• CC8.1 is the criterion at the center. It requires changes to infrastructure, data, software, and procedures to be authorized, designed, developed, configured, documented, tested, approved, and implemented — and it is tested by sampling real production deployments.
• Security is the only mandatory Trust Services Category. Availability, processing integrity, confidentiality, and privacy are optional, but enterprise and regulated buyers increasingly expect at least one beyond security.
• Exceptions come from missing records, not missing controls. Pipeline logs that expire before the observation period ends, self-approved merges, and approvals given verbally are the three most common causes.
• Separation of duties is non-negotiable. A developer approving their own change to production is a finding regardless of how good the change was.
• Emergency changes are allowed if your policy defines them. What fails is the undocumented hotfix, or a policy that pretends emergencies never happen.
• The artifacts are the same ones ISO 27001 Annex A 8.25–8.32 asks for, so a single secure SDLC can serve both frameworks if the controls are mapped rather than duplicated.

What the Secure Development Life Cycle Means in SOC 2

SOC 2 is an attestation report, issued by an independent CPA firm, on whether a service organization's controls meet the AICPA's Trust Services Criteria. It is not a certification against a control checklist — it is an opinion on controls you define yourself. That design choice is why the secure development life cycle in SOC 2 looks different at every company and still passes: the auditor tests your stated process against your evidence, not against a reference implementation.

What this means practically is that a small team shipping through a single pipeline with branch protection and automated tests can produce cleaner evidence than a large organization with a change advisory board that meets fortnightly and records its decisions in meeting minutes nobody indexes. The control that is enforced technically beats the control that is enforced by good intentions.

Which Trust Services Criteria Govern Development

Security — the Common Criteria — is mandatory in every SOC 2 report. Within it, development activity maps mainly to:

• CC8.1 — change management, the primary criterion for anything shipped to production.
• CC6.1, CC6.2, CC6.3 — logical access: who can read the repository, merge to the default branch, and deploy.
• CC6.8 — preventing and detecting unauthorized software, which covers dependency and artifact integrity.
• CC7.1, CC7.2 — detecting configuration drift, vulnerabilities, and anomalies in what you have deployed.
• CC7.3, CC7.4, CC7.5 — responding to the incidents your monitoring surfaces.
• CC3.2, CC3.4 — identifying and assessing risk, including risk arising from a significant change.
• CC9.2 — third-party risk, which now includes the dependencies and subprocessors in your build.

The optional categories add requirements where they apply: availability brings recovery and capacity commitments into release planning, processing integrity asks whether your system processes data completely and accurately, and confidentiality and privacy constrain what test data engineers may use. A full walkthrough of the criteria sits in our SOC 2 controls list.

CC8.1: The Change Management Criterion at the Center

CC8.1 reads, in substance, that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. Every verb in that list is a place an auditor can ask for proof.

The useful way to read it is as four questions asked of each sampled change:

1. Was it authorized? Something — a ticket, an approved roadmap item, an incident — justified the change before it was written.
2. Was it tested? Tests, scans, or a staging exercise ran against the code that actually shipped.
3. Was it approved by someone other than the author? This is the separation-of-duties point, and the single most frequent failure.
4. Does the record still exist? Retention is a control requirement, not an IT housekeeping detail.

A change that satisfies the first three and fails the fourth is, from the auditor's chair, indistinguishable from one that satisfied none of them.

Type I Versus Type II, and Why It Changes Your SDLC

A Type I report assesses whether controls are suitably designed at a point in time. A Type II report tests whether they operated effectively across an observation period, commonly three to twelve months. For the SDLC this difference is decisive. A Type I can be satisfied by a written policy, a configured pipeline, and a walkthrough. A Type II is satisfied only by the trail those controls left behind, every week, for months — which is why retention windows and consistency matter more than any individual control's sophistication. Our SOC 2 audit timeline guide breaks down how the observation period fits into the wider schedule.

Why Enterprise, Fintech, and Healthcare Buyers Scrutinize Your SDLC

Enterprise procurement treats security as a qualifier rather than a differentiator, and the SDLC is one of the few control areas where a buyer's own engineers can evaluate your answers. Security questionnaires routinely ask how changes are approved, whether code is scanned before release, who can deploy to production, and how quickly a disclosed vulnerability in a dependency gets patched. These are questions a reviewer can sanity-check against your public behaviour, which is why vague answers cost deals.

The stakes behind that scrutiny keep rising. IBM's 2026 Cost of a Data Breach Report puts the global average cost of a breach at a record $4.99 million, and a large share of incidents still trace back to known weaknesses in software and its dependencies rather than to novel attacks.

For fintechs, a sponsor bank or regulator reviewing a license application expects to see an operating change management process, not a policy binder. For healthcare vendors handling electronic protected health information, the HIPAA Security Rule's requirements for evaluation and access management overlap heavily with what SOC 2 asks of the SDLC, and a reviewer will notice if your answers to the two differ. For anyone selling into a large enterprise, the security review is a gate that a vendor with documentation clears in weeks and a vendor with promises does not clear at all.

Core SOC 2 Requirements That Affect the Software Development Lifecycle

Seven requirement areas shape day-to-day engineering work:

Policies and documentation. Auditors establish what your process claims to be before testing whether it operated. That means a secure development or change management policy, an access control policy, and an incident response plan, each reviewed at least annually with a record of the review and of engineering acknowledging it.

Risk management. CC3.2 asks you to identify and assess risks to your objectives, and a significant architectural change is one of those risks. A new third-party API, a new data flow, or a change to how authentication works should produce a recorded assessment, not just a design document.

Change management. Every production change authorized, tested, approved by someone else, and documented. This is CC8.1, and it is where most of the audit's development-related work happens.

Access controls. Least privilege applied to repositories, pipelines, artifact registries, and cloud consoles, enforced through single sign-on with multi-factor authentication and reviewed quarterly. Administrator accounts able to bypass branch protection are a specific thing auditors look for; if they exist, their use must be logged and reviewed. See our glossary entry on access control for how the principle applies more broadly.

Security testing and vulnerability management. Static analysis, dependency scanning, infrastructure scanning, and periodic penetration testing, with defined severity thresholds, remediation timelines, and a register that tracks findings to closure. Our SOC 2 vulnerability management guide and SOC 2 penetration testing guide cover both in depth.

Incident response. A tested plan with defined severities, escalation paths, and communication responsibilities, connected to the monitoring your deployed systems emit. Post-incident reviews feed back into the SDLC as new tests or new controls.

Evidence generation. The requirement that ties the rest together: each of the above must leave a durable, retrievable record for the whole observation period.

Mapping SOC 2 Controls to SDLC Phases

Mapping controls to phases is how you find out whether a phase is producing evidence or merely producing software. The table below maps 7 SDLC phases to the Common Criteria each satisfies, the control to write, and the artifact that evidences it. It is a working map, not an exhaustive one — your auditor may map a control to an adjacent criterion, which is normal and not a finding.

Secure SDLC Steps for SOC 2 Compliance

Planning and Requirements

Record security and regulatory requirements next to functional ones, in the same ticket. Identify which Trust Services Categories apply to the change: security always, plus availability where the change affects uptime commitments, processing integrity where it affects the correctness of processing, and confidentiality or privacy where it touches customer or personal data. Flag changes handling PHI, cardholder data, or personal data at this point — retrofitting a data map after release is how privacy findings happen.

The artifact to preserve is the ticket itself. An auditor reading it nine months later should be able to see why the change was made and what security considerations were raised.

Design and Threat Modeling

Threat model the changes that deserve it rather than all of them. The trigger list is short and defensible, and 5 items long: anything altering authentication, authorization, encryption, the trust boundary, or the flow of regulated data. STRIDE and its 6 threat categories give a reasonable structure, but the framework matters less than recording the abuse cases you considered and the controls you chose in response. Keep diagrams in version control so their history is auditable alongside the code.

Build and Secure Coding

Enforce the controls in configuration, not in documentation. Branch protection requiring a review from someone other than the author, a signed-commit or verified-identity requirement, secrets held in a managed store rather than environment files, and infrastructure defined as code and reviewed on the same path as application code. A secure coding standard covering input validation, parameterized queries, server-side authorization, safe error handling, and approved cryptographic libraries gives reviewers something concrete to review against.

Attach a checklist to the pull request template so that peer review demonstrably considered security rather than only correctness. The completed template is the evidence.

Testing and Security Validation

Run unit, integration, and acceptance tests plus static analysis, dependency scanning, and infrastructure-as-code scanning on every change, and set thresholds that block rather than warn. A pipeline configured to warn produces a log showing the check ran and the change shipped anyway, which is worse evidence than no check at all. Supplement automation with manual penetration testing at least annually, for the logic flaws scanners miss. Link each finding to its remediation or its formal acceptance, with an owner and a date — a common and defensible structure blocks anything at CVSS 7.0 and above while tracking the rest against a stated SLA.

Deployment and Release Approval

Deployments go through the pipeline, and the pipeline records who approved them. Require multi-factor authentication on deployment tooling, keep production credentials out of developer hands, harden container images and scan them before they ship, and document a rollback plan that someone has actually executed at least once. The deployment record should tie the released artifact to the commit, the approval, and the pipeline run — those four references are what turn a deployment into auditable evidence.

Operations and Monitoring

Operations and monitoring is where CC7.1 and CC7.2 are tested: centralize logs, alert on the behaviour each change introduced, patch on a defined schedule, and review repository and pipeline access at least quarterly. Configuration drift detection matters here as much as vulnerability scanning, because CC7.1 is concerned with unauthorized change reaching production by any route, including one that bypassed the pipeline entirely. Our SOC 2 continuous monitoring guide covers how to run this without generating alert noise nobody reads.

Evidence Collection and Retention Windows

Evidence collected as you go is cheap; evidence reconstructed in month nine is expensive and often impossible. Before the observation period starts, check the retention window on every system that holds evidence — pipeline logs, deployment history, ticket exports, alert history — against the length of the period. A 30-day pipeline log retention against a twelve-month observation period guarantees a gap you cannot close retroactively. Our SOC 2 evidence requirements guide lists what to capture and how long to keep it.

SOC 2 Change Management: What Auditors Actually Sample

SOC 2 change management is tested by sampling. The auditor takes the population of production changes across the observation period, selects a subset, and asks you to produce the record for each one. Sample sizes are set from population and risk rather than by a fixed rule, and a sample of 15 to 40 changes over twelve months is common.

For each sampled change, expect to produce:

• The ticket or issue establishing why the change was made.
• The pull request, showing a reviewer who is not the author and the review actually recorded before merge.
• The pipeline run for the released commit, showing which tests and scans executed and their results.
• The deployment record, tying the artifact to the approval and to a named approver.
• Where relevant, the threat model, the risk assessment, or the finding acceptance that the change depended on.

Three patterns cause the bulk of exceptions in this area. Self-approval: branch protection allows administrators to bypass review, and a founder or lead uses it, usually during an incident. Evidence expiry: a control operated correctly, but the log proving it aged out before the auditor asked. Undocumented emergency changes: a hotfix went out at 3 a.m. and was never retrospectively reviewed, so the change population and the deployment log disagree — which invites a wider sample.

The defence against all three is a quarterly self-sample. Pick ten production changes at random, try to assemble the five records above using only what your tooling retains, and count the ones you cannot complete. That number is what the auditor will find, and finding it yourself three months early is the difference between a fix and an exception in the report.

The Secure Development Policy and the Evidence Auditors Expect

The policy's job is to state what your process is, precisely enough that an auditor can test it and narrowly enough that you will actually pass. A policy promising security review of every change will fail if you review only the risky ones; a policy that says you threat model changes affecting the trust boundary will pass if that is what you do. Overclaiming is the most common self-inflicted wound in SOC 2 documentation.

At minimum the policy should cover scope and system boundary, roles and responsibilities including who may approve a release, the phase gates and the artifact each produces, secure coding standards and training expectations, the emergency change path and its retrospective approval window, the exception process with owner and expiry, and the review cadence for the policy itself.

Around it sit the supporting documents an auditor will ask for in the same breath: the change management policy if it is separate, the access control policy governing repository and pipeline permissions, the incident response plan, and the vulnerability management policy with its remediation SLAs. If you are assembling this set from scratch, the SOC 2 Documentation Toolkit below is the wider document set, in the order auditors read it.

Fitting SOC 2 into DevSecOps Without Slowing Delivery

Teams practising DevSecOps usually find SOC 2 easier than teams with heavyweight manual approval workflows, because the controls are already technical. A required review in branch protection is a stronger control than a change advisory board, and it generates its own evidence without anyone writing minutes. The work is not slowing the pipeline down; it is making sure the pipeline records what it did.

Three adjustments do most of that work. First, set security gates to block at a defined severity rather than warn, so the pipeline result means something. Second, tie every deployment to an identity — a human approver for production, with the pipeline's service identity distinct from any engineer's. Third, extend retention on the systems that hold your evidence to at least the observation period plus a margin, before the period begins.

Where velocity genuinely conflicts with a control, the answer is a risk-based threshold rather than an exemption: block critical and high findings, track medium and low with an owner and a date. That is defensible to an auditor because it is a documented decision, which is exactly what CC3.2 asks for.

Konfirmity is a security-driven compliance platform. Run it self-serve, or add the fully managed service and a dedicated team implements controls inside your stack, operates them daily, and prepares evidence year-round — so teams spend under 70 hours a year on compliance instead of the 550–600 hours a self-managed program typically consumes. Typical SOC 2 readiness with Konfirmity takes four to five months, against nine to twelve months self-managed, and you can calculate your compliance ROI against your own headcount.

See where your pipeline's evidence gaps are

Book a demo and we'll sample your recent production changes the way a SOC 2 auditor would, and show you which of the five records you can produce today.

Book a demo

SOC 2 Secure SDLC Challenges and How to Overcome Them

Speed versus compliance. The fear is that security gates add latency to every merge. In practice the latency comes from manual gates, not automated ones. Move the checks into the pipeline, set risk-based blocking thresholds, and the median change is unaffected while the risky one is caught.

Documentation going stale. Policies drift from practice within about two quarters unless someone owns them. Assign each document an owner, set a review date, and treat a policy update as a normal sprint item when the process changes — not as an annual chore that rewrites history.

Scan noise. Untuned scanners produce findings faster than any team can triage, and teams respond by ignoring the tool. Tune to the stack, suppress with a recorded rationale rather than silently, and pair automated scanning with periodic manual testing.

Engineers not documenting. Make the artifact a by-product. A pull request template with a security checklist, a required ticket reference, and a deployment record generated by the pipeline collect almost everything an auditor needs without anyone writing a document.

Third-party and dependency risk. Your build pulls in code you did not write. Maintain a dependency inventory or SBOM, subscribe to advisories for what you actually run, assess subservice organizations, and record the action you took when an advisory landed. CC9.2 is tested on the evidence of that action, not on the existence of a vendor list.

Frequently Asked Questions

Conclusion

The secure development life cycle in SOC 2 rewards consistency over sophistication. An auditor sampling twenty production changes is not assessing your architecture; they are checking whether each change was authorized, tested, approved by someone else, and still has a record. Teams that pass comfortably are usually the ones who moved those four things into the pipeline, where they happen by default and record themselves, and then checked that the records survive as long as the observation period does.

The work that makes this true also makes the software better: fewer unreviewed changes reaching production, fewer known vulnerabilities shipping in dependencies, faster detection when something does go wrong. Compliance becomes the by-product rather than the project. If you want to know where your pipeline stands today, the fastest honest test is the quarterly self-sample — pick ten deployments and try to produce the evidence.