Secure Software Development Evidence for SOC 2

Introduction

Secure software development evidence for SOC 2 is the dated record that shows security checks are built into how your team designs, writes, reviews, tests, and releases code, and that those checks actually ran for the changes that reached production. A policy line that says "we follow a secure development lifecycle" is intent. Design review notes, code review approvals, scanner results, triage tickets, and release records tied to specific changes are evidence.

Most SOC 2 programs already have change management evidence: tickets, approvals, and deployments. Secure development evidence sits one layer earlier. It answers whether the change was reviewed for security, whether automated tests and scanners looked at it, and what happened when they found something.

Here is a labeled hypothetical. A 60-person SaaS company has branch protection on its main repository and passes its Type 1 review. During Type 2 fieldwork, the auditor samples 25 production changes. Each one has an approved pull request, but the static analysis tool was turned off on the main service for six weeks after a noisy upgrade, dependency alerts were piling up with no owner, and two hotfixes skipped review because an administrator bypassed branch protection. None of this proves the code was insecure. It means the company cannot show its described development controls operated across the period.

What Secure Software Development Evidence Means

Secure software development evidence answers six questions with records rather than descriptions:

1. What is the process? A documented secure development standard or procedure that says which checks apply to which changes.
2. Was security considered in design? Design reviews or threat models for significant new features, integrations, or architecture changes.
3. Was the code reviewed? Pull request approvals by someone other than the author, with branch protection that enforces it.
4. Did automated checks run? Static analysis, dependency scanning, secret scanning, and other tests in the pipeline, with results retained.
5. Were findings handled? Triage, fixes, or documented exceptions for what the scanners and reviewers found.
6. Did only tested code reach production? Promotion from build to staging to production through a controlled pipeline, with separate environments.

Auditors test the controls your company describes in its system description. If you describe SAST, dependency scanning, and mandatory code review, expect to show all three working for sampled changes across the audit period.

How This Differs From Change Management and Vulnerability Management Evidence

These three evidence sets overlap, and many teams store them in the same tools. They still answer different questions.

Topic	Change management	Secure software development	Vulnerability management
Main question	Was the change authorized, tested, and approved before deployment?	Were security checks built into design, coding, review, and testing?	Are weaknesses in running systems found and fixed on time?
Typical scope	Every production change	Application code and infrastructure code before release	Deployed hosts, containers, cloud services, and applications
Common evidence	Tickets, approvals, deployment logs	Design reviews, code review records, scanner results in CI, finding triage	Scan schedules, findings, severity SLAs, remediation tickets

If you already keep the evidence described in Change Management Evidence for SOC 2 and Vulnerability Management Evidence for SOC 2, keep it. Secure development evidence fills the gap between "the change was approved" and "the running system was scanned."

Why Secure Development Evidence Matters for SOC 2

SOC 2 does not name a development methodology, a scanning product, or a required set of tests. The Trust Services Criteria published by the AICPA ask whether changes to infrastructure, data, software, and procedures are designed, developed, tested, approved, and implemented in a controlled way (CC8.1), and whether the company identifies and responds to vulnerabilities and anomalies (CC7.1 and CC7.2). Development security controls usually support both. See SOC 2 Trust Services Criteria Explained for how the criteria are organized.

In practice, auditors commonly look for three things:

• A defined process that says which security checks apply and who is responsible.
• Evidence that the checks ran for a sample of real production changes.
• Consistent operation across the whole period for a Type 2 report, including emergency changes. See SOC 2 Type 1 vs Type 2 for how the period affects testing.

Defining the Secure Development Standard

Start by writing down what your team actually does, then close the gaps.

Scope

List the in-scope repositories, services, and infrastructure-as-code projects. Record which ones deploy to production systems in your SOC 2 boundary. A repository that is out of scope should be out of scope on purpose, not by omission.

Required checks by change type

Not every change needs the same checks. A common approach is a short table: all changes require peer review and passing automated tests; changes to authentication, authorization, payments, or data handling also require a security-focused reviewer or design review; new third-party dependencies require a dependency check. Keep the rules simple enough that engineers follow them without looking them up.

Ownership

Name an owner for the standard, an owner for each scanning tool, and who triages findings. Without owners, scanner alerts become background noise.

Keep the standard in your information security policy set or a supporting document, with version history and an annual review date.

Design Reviews and Threat Modeling

Design review evidence shows that security was considered before code was written, when changes are cheapest.

• Triggers: Define what needs a review, such as a new external integration, a new data store with customer data, a change to authentication, or a new public endpoint.
• Format: A short design document with a security section, a lightweight threat model, or a checklist is usually enough. The depth should match the risk.
• Record: Keep the reviewed document, the reviewer, the date, and any resulting tickets linked to the feature work.

Auditors usually sample a few significant features and ask whether the trigger applied and whether a review exists. A small number of complete reviews is stronger than a template nobody fills in.

Code Review Evidence

Code review is often the most tested part of the development lifecycle because it is easy to sample.

• Enforcement: Branch protection or equivalent settings that require at least one approval from someone other than the author before merge to the main branch.
• Status checks: Required passing checks, such as tests and scanners, before merge.
• Bypass control: A record of who can bypass protections and a log of each bypass. Administrator overrides should be rare, justified, and reviewed after the fact.
• History: Pull request records that show the author, the reviewer, the approval time, and the merge time.

Keep exports or screenshots of branch protection settings with dates, and check that they did not change silently during the period. If a setting changed, the change management record for that change is part of the evidence.

Automated Security Testing in the Pipeline

Automated checks turn a written standard into something repeatable. Common checks include:

• Static analysis (SAST): Scans source code for insecure patterns on each pull request or build.
• Dependency scanning (SCA): Flags known vulnerabilities in open source packages and container base images.
• Secret scanning: Catches credentials before or after they are committed. See Secrets Management Evidence for SOC 2.
• Infrastructure-as-code checks: Flags risky cloud configuration before it is applied.
• Dynamic testing (DAST): Tests a running build in a non-production environment.

You do not need every tool. You need the tools you describe, enabled on the repositories you say are covered, with results you can show. Evidence to keep includes pipeline configuration showing the checks, coverage across in-scope repositories, and a sample of scan results for real builds during the period.

Handling Findings

A scanner that runs but whose findings are ignored is weak evidence. Show what happened next.

• Triage: Each finding is reviewed and marked as a true issue, a false positive with a reason, or an accepted risk.
• Severity and timelines: Define fix timelines by severity, and track them. Many teams align these with their vulnerability management SLAs.
• Merge rules: Decide whether high-severity findings block merge, and keep the setting that enforces it.
• Exceptions: Findings that cannot be fixed in time go through exception management with an owner, a reason, a compensating measure, and a review date.

Tickets or tool history that show a finding, its triage, and its closure are the evidence auditors usually trace.

Environments and Release

Secure development also covers how code moves to production.

• Separate environments: Development, staging, and production are separated, and production data is not copied into lower environments without controls. See Data Classification Evidence for SOC 2 for handling rules by data type.
• Controlled promotion: Builds move to production through a pipeline, not manual copies from laptops.
• Restricted deploy rights: Only approved people or service identities can deploy to production. See Privileged Access Management Evidence for SOC 2.
• Emergency changes: Hotfixes follow a defined fast path with after-the-fact review, and each one is recorded.

Training and Responsibilities

Auditors often ask how engineers know the standard. Keep records of secure coding training or onboarding sessions for engineers, along with your general security awareness training records. Training does not need to be long. It needs to be relevant, dated, and tracked.

Type 2 Sampling: What Auditors Commonly Request

Auditors decide their own procedures, but secure development testing commonly includes requests like these:

• The secure development standard or procedure and its last review date.
• Branch protection settings for in-scope repositories, with evidence they were in place across the period.
• A sample of production changes traced from ticket to pull request, approval by a non-author, passing checks, and deployment.
• Pipeline configuration showing which security scans run and on which repositories.
• A sample of scanner findings traced to triage, fix, or approved exception.
• Design reviews or threat models for a sample of significant features.
• A list of branch protection bypasses or emergency changes, with the review of each.

If a population is empty, for example no emergency changes occurred, keep evidence of how you know, such as a deployment log query for the period.

Common Mistakes

• Enabling scanners on the main repository only and assuming coverage is complete.
• Turning off a noisy scanner "temporarily" with no ticket or end date.
• Letting administrators bypass branch protection with no log review.
• Marking findings as false positives without a recorded reason.
• Writing a standard that requires threat models for every change, then not doing any.
• Approving pull requests from shared or service accounts so the reviewer cannot be identified.
• Losing scan history because the tool keeps results for a shorter time than the audit period.

A Practical Operating Model

A workable model for a growing team looks like this:

1. Write a short secure development standard with scope, required checks by change type, and owners.
2. Enforce peer review and required status checks on every in-scope repository.
3. Run static analysis, dependency scanning, and secret scanning in the pipeline for those repositories.
4. Route findings to owners with tickets and severity-based timelines.
5. Define design review triggers and keep a lightweight record for each triggered review.
6. Restrict production deploys to the pipeline and approved identities.
7. Log and review every bypass and emergency change.
8. Retain the records across the full audit period.

Framework Notes

• SOC 2: Secure development controls typically support CC8.1 for controlled changes and CC7.1 and CC7.2 for identifying and monitoring vulnerabilities. Your control descriptions define what is tested.
• ISO 27001: ISO/IEC 27001:2022 Annex A includes controls for a secure development life cycle (8.25), application security requirements (8.26), secure system architecture and engineering principles (8.27), secure coding (8.28), security testing in development and acceptance (8.29), outsourced development (8.30), and separation of development, test, and production environments (8.31). One program can often support both frameworks. See Mapping Controls Across SOC 2 and ISO 27001.
• NIST: NIST SP 800-218, the Secure Software Development Framework (SSDF), groups practices into preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. Many teams use it as a design reference even when it is not a formal requirement.
• OWASP: The OWASP Application Security Verification Standard (ASVS) and the OWASP Software Assurance Maturity Model (SAMM) are widely used practical references for test requirements and program maturity.

How AuditFlo.co Helps

AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.

For secure development, that can mean dated history for pull request reviews, change tickets, finding triage tickets, exception records, and design review tasks, so you can show the work across the period without rebuilding it from memory. Your source control, CI/CD platform, and scanning tools remain the systems of record for code and scan results. AuditFlo.co does not scan code, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.

To see the workflow for your stack, request a demo.

Final Thoughts

Secure development evidence proves that security is part of how code gets built, not a review bolted on at the end. Write a short standard, enforce review and automated checks on every in-scope repository, handle findings with tickets, review significant designs, control releases, and log every bypass. If you can trace a sampled change from design to deployment with dated records, secure development testing becomes routine.

For related evidence, see What Is Change Management?, What Is Vulnerability Management?, Penetration Test Evidence for SOC 2, and how to prepare for a SOC 2 audit.

FAQ

Does SOC 2 require static analysis or a specific scanning tool?

No. SOC 2 does not require a specific tool or test type. Auditors test the controls your company describes, so if you describe static analysis or dependency scanning, expect to show that it ran on in-scope code across the period.

Is peer code review required for SOC 2?

SOC 2 does not use those exact words, but CC8.1 asks that changes be controlled, tested, and approved. Peer review enforced by branch protection is a common way companies meet that expectation for code changes.

How should we handle a solo developer who cannot get a second reviewer?

Common approaches include review by a technical leader outside the immediate team, after-the-fact review of merged changes on a defined schedule, or stronger automated checks as a compensating measure. Document the approach and keep the records. See What Is a Compensating Control?.

Do we need a threat model for every change?

Usually not. Most teams define triggers for design review, such as new integrations, new data stores, or authentication changes, and keep records for changes that meet them. What matters is following the rule you wrote.

Is a penetration test a substitute for secure development evidence?

No. A penetration test is a point-in-time assessment of a running system. Secure development evidence shows that checks ran on changes throughout the period. Many companies keep both.

Does AuditFlo.co scan our code?

No. Your source control, CI/CD platform, and security tools run reviews and scans. AuditFlo.co helps organize dated evidence such as tickets, pull request history, and workflow records from systems you already use, and does not replace your engineers or your auditors.