The SDLC as a SOC 2 Control Surface

SOC 2's CC8 (change management) is the primary criteria covering your software development process. But the Trust Services Criteria touch the SDLC at multiple points beyond change management. Understanding these touchpoints helps engineering teams build a development process that's both secure and auditable — without adding bureaucratic overhead.

This guide maps each SDLC phase to the relevant SOC 2 criteria and describes practical controls that generate audit evidence as a byproduct of normal development workflows.

Phase 1: Requirements and Design

Relevant criteria: CC3 (risk assessment), CC2 (communication and information)

Security requirements belong in the design phase, not discovered during testing or audit preparation. For each new feature or system change, engineering teams should address:

Threat modeling: What are the security implications of this change? What data flows are introduced? What could an attacker exploit? A lightweight threat model — even a short section in the design document — creates evidence for CC3 (risk assessment) and shows auditors that security was considered from the start.

Data classification: Does this feature introduce a new data type? How is it classified (public, internal, confidential, restricted)? What retention requirements apply? This feeds into your [SOC 2 asset inventory](/blog/soc2-asset-inventory-management) and access control design.

Access requirements: What permissions does this feature require? Documenting minimum-required permissions during design makes IAM policy implementation easier and ensures least-privilege is applied from day one.

Phase 2: Development

Relevant criteria: CC8.1 (change management), CC7.1 (vulnerability detection)

Coding standards and security guidelines: CC8.1 requires that changes are implemented according to established procedures. A documented secure coding standard — even a short internal guide covering the top risks for your language and framework — satisfies this requirement. Cover: input validation, parameterized queries, output encoding, dependency management, secret handling.

Dependency management: Third-party libraries are a major source of vulnerabilities. Track your dependencies with a Software Bill of Materials (SBOM) and use automated scanning to identify known vulnerabilities. For Node.js: npm audit. For Python: pip-audit. For Go: govulncheck. Run these in CI and fail on high/critical findings.

Secret management in code: No secrets in code. No exceptions. [GitHub secret scanning](/blog/github-secret-scanning-soc2-guide) catches committed secrets before they reach production. Configure it for your organization and set it as a required check.

Phase 3: Code Review

Relevant criteria: CC8.1 (authorization of changes)

Code review is the primary control for CC8.1. For SOC 2 purposes, the review must be:

• Mandatory: No code merges to main without at least one approved review. Configure [branch protection](/blog/github-branch-protection-soc2) to enforce this.
• Independent: The author cannot approve their own PR. Require reviews from someone who didn't write the code.
• Documented: The review record is preserved in your version control system. GitHub pull request history is acceptable audit evidence.

For security-sensitive changes (authentication, authorization, cryptography, payment flows), consider requiring review from a second engineer or a security-aware team member.

What reviewers should check from a security standpoint:

• Input validation and sanitization
• Authorization checks (does this code verify the caller is authorized?)
• Secret handling (no hardcoded credentials)
• Error handling (no sensitive data in error messages)
• Dependency additions (is this a reputable library? Does it introduce vulnerabilities?)

Phase 4: Testing

Relevant criteria: CC8.1 (testing before deployment), CC7.1 (vulnerability detection)

CC8.1 requires that changes are tested before deployment. For SOC 2, testing evidence should include:

Automated testing: Unit tests, integration tests, end-to-end tests that run in CI on every PR. The CI build log is evidence that testing ran and passed before each deployment.

SAST: Static application security testing catches vulnerability classes that functional tests miss — SQL injection, XSS, insecure deserialization. GitHub CodeQL is free for open-source projects and available for private repositories. Run it as a required CI check.

Dependency scanning: Run a dependency vulnerability scanner in CI and fail on high/critical findings. This generates a continuous vulnerability detection record for CC7.1.

Security regression tests: For any security-relevant finding or incident, write a test that verifies the fix and prevents regression. These tests become permanent evidence of your ongoing vulnerability management.

Phase 5: Deployment

Relevant criteria: CC8.1 (authorization of changes), CC6.1 (logical access)

Deployment authorization: Production deployments should require explicit approval. Using GitHub Actions environment protection rules (covered in [GitHub Actions CI/CD security for SOC 2](/blog/github-actions-cicd-security-soc2)), you can require that a designated approver signs off on every production deployment. The approval is logged and timestamped.

Separation of duties: The engineer who wrote the code shouldn't be the only person who can approve and deploy it. This doesn't require a large team — even requiring a second engineer's approval satisfies the control.

Deployment record: Each deployment should be traceable: what commit, when, deployed by whom, approved by whom, to which environment. Your CI/CD system captures this automatically if you structure workflows to log these fields.

Phase 6: Operations and Monitoring

Relevant criteria: CC7.1 (system monitoring), CC7.2 (evaluation of security events), CC7.3–CC7.5 (incident response)

Post-deployment monitoring closes the SDLC loop. From a SOC 2 perspective:

Application logging: Log security-relevant events at the application layer — authentication successes and failures, authorization decisions, administrative actions, data access events. Logs should be forwarded to a centralized, tamper-resistant store (S3 with Object Lock, CloudWatch Logs with retention policies).

Error monitoring: Unhandled exceptions and application errors can indicate security events (attack probes, unexpected inputs). Tools like Sentry or Datadog APM catch these. Reviewing error rates after deployments is both good operations practice and SOC 2 evidence.

Dependency monitoring: Vulnerabilities are discovered continuously. Set up automated alerts (GitHub Dependabot, Snyk) for newly discovered vulnerabilities in your production dependencies. CC7.1 requires continuous vulnerability detection, not just scanning at deployment time.

Putting It Together: A Minimal SDLC Controls Program

For an engineering team of 5–20 people, a SOC 2-compliant SDLC looks like:

|---|---|---|---|

This doesn't require a dedicated security engineer or a separate security team. Each control is built into the existing development workflow, and the evidence is generated automatically.