SOC 2 Type 2 mapping to Secure SDLC Requirements
We started to talk about the SOC2 Type 2 certification and I feel that we neglected it a bit.
I wrote a bit about SDLC, Secure SDLC in particular, but now it is time to bring them together.
SOC 2 Type 2 and Secure SDLC — the big picture
SOC 2 Type 2 evaluates whether controls are operating effectively over time (typically 6–12 months). It is not a point-in-time snapshot.
Your SDLC is not an isolated engineering practice — it feeds directly into several Trust Services Criteria (TSC).
All nine Common Criteria map to the SDLC in some way, but they do so at different layers.
CC1 (Control Environment) is the foundation. It is not about code or process — it is about organizational accountability. The auditor checks that your Secure SDLC has a named owner, that the policy carries formal authority, and that security has a defined role in the development organization. Without this, every other control lacks a governance backbone.
CC2 (Communication) requires that developers know the rules. A Secure SDLC policy that exists but was never distributed or acknowledged does not satisfy this criterion. The auditor looks for training records, policy sign-offs, or equivalent evidence that the people making security decisions in each SDLC phase were aware of their obligations.
CC3 (Risk Assessment) maps directly to the Idea and PoC phases. The criterion requires that risks are identified and analyzed before work begins. A threat model, a risk register entry, or a documented security review of the proposed design all serve as evidence. The auditor wants to see that risk was considered as an input to scope decisions, not evaluated after the fact.
CC4 (Monitoring Activities) requires ongoing evaluation of whether controls are working. In SDLC terms this means SAST, DAST, and SCA scans must run regularly, their results must be reviewed, and findings must be tracked to resolution. Running a scan whose results are never acted on does not satisfy CC4.
CC5 (Control Activities) covers the specific rules that govern how code is written and reviewed. Secure coding standards, mandatory peer review, branch protection, and secrets scanning policies all live here. CC5 is about the guardrails built into the development process itself, not just the approval chain around it.
CC6 (Logical Access) runs across the widest range of SDLC phases. It covers who has access to source code, build pipelines, deployment tools, and production environments — and whether that access is appropriate at each phase. PoC access that was never revoked and production credentials embedded in a repository are both CC6 findings.
CC7 (System Operations) requires that running systems can detect and respond to threats. Its SDLC relevance is that logging, alerting, and incident response readiness must be built into the product before it reaches production. If these are treated as post-launch concerns, CC7 is a gap.
CC8 (Change Management) is the criterion most directly owned by the SDLC. Every code change from PoC through EOL must be authorized, reviewed, and traceable. This criterion generates the highest sample volume in a Type 2 audit — typically 20 to 25 change records — and every sampled item needs a complete evidence chain.
CC9 (Risk Mitigation) addresses third-party and vendor risk. In a software development context this means evaluating open-source libraries, SDKs, and external dependencies before they are adopted. Running a dependency scan satisfies part of this, but CC9 specifically requires that a conscious risk decision was documented — not just that a tool ran.
The practical takeaway is that CC1, CC2, and CC9 are the ones most commonly missing from customers who think their Secure SDLC is well covered.
They focus on CC8 (change management) and CC6 (access) but leave governance, communication, and vendor risk undocumented.
Summary mapping of SOC2 controls to SDLC
| CC | Control Name | Idea | PoC | MVP | Release | EOL | SDLC Intersection / Evidence |
|---|---|---|---|---|---|---|---|
| CC1 | Control environment | ✓ | — | — | — | — | SDLC policy with named owner. Security team has formal authority to block releases. |
| CC2 | Communication | ✓ | ✓ | ✓ | — | — | Secure SDLC policy published and acknowledged. Developer training completion records. |
| CC3 | Risk assessment | ✓ | ✓ | — | — | — | Threat model at Idea phase. Risk register updated before PoC scope is confirmed. |
| CC4 | Monitoring activities | — | — | ✓ | ✓ | — | SAST/DAST results reviewed. Recurring vuln scans in prod. Findings tracked to closure. |
| CC5 | Control activities | ✓ | — | ✓ | ✓ | — | Secure coding standards doc. Code review policy enforced. Branch protection rules active. |
| CC6 | Logical access | — | ✓ | ✓ | ✓ | ✓ | Repo and pipeline access logs. Secrets management reviewed. Prod access revoked at EOL. |
| CC7 | System operations | — | — | ✓ | ✓ | ✓ | Logging enabled pre-release. Alerting configured in prod. Incident runbook referenced. |
| CC8 | Change management | — | ✓ | ✓ | ✓ | ✓ | PR records with approvals. Pipeline gates enforced. EOL change ticket required. |
| CC9 | Risk mitigation | ✓ | ✓ | — | — | — | Third-party libraries assessed. OSS license and security risk reviewed before adoption. |
Practical Checklist — SDLC Evidence by Common Criteria
CC1 — Control environment
SDLC policy with version, date, and named owner. Org chart showing security’s authority. Evidence security can block a release.
CC2 — Communication
Policy acknowledgment log with names and dates. Annual security training completion records. Re-communication evidence if policy changed during the audit period.
CC3 — Risk assessment
Threat model dated before PoC began. Risk register with severity ratings and owners. Security requirements traceable to backlog items.
CC4 — Monitoring activities
SAST and SCA scan reports on a recurring cadence, not one-off. Vulnerability remediation log showing finding, severity, owner, SLA target, and closure date.
CC5 — Control activities
Secure coding standards document. Branch protection configuration blocking direct pushes to main. Secrets scanning active in the repository.
CC6 — Logical access
User access list per environment with roles. Annual access review log. MFA enforcement evidence. Secrets stored in a secrets manager, not in code. Access revocation records for leavers and decommissioned systems.
CC7 — System operations
Logging configuration in place before first production release. Alerting thresholds and escalation paths documented. At least one security alert triaged and recorded during the audit period.
CC8 — Change management
PR records with reviewer names and approval timestamps for every sampled change. Pipeline logs showing tests passed before deployment. Rollback procedure documented. Change ticket for every production deployment including EOL.
CC9 — Risk mitigation
Dependency evaluation process documented. SCA reports showing library risk at adoption and on a recurring basis. Risk acceptance record for each significant new dependency introduced during the audit period.
Secure SDLC and SOC 2 Type 2 — Summary
SOC 2 Type 2 evaluates whether security controls operated consistently over an audit period, typically 6 to 12 months. A Secure SDLC is not a separate compliance workstream. It is the operational mechanism through which most of the Common Criteria are satisfied.
All nine Common Criteria (CC1–CC9) have at least one touchpoint in the SDLC. No phase is audit-free.
Idea is the most governance-heavy phase. CC1, CC2, CC3, CC5, and CC9 all apply here. Before a single line of code is written, the auditor expects a threat model, a risk register entry, a policy that developers have acknowledged, and evidence that third-party dependencies were evaluated. Skipping security at this phase creates gaps that are difficult to close retroactively.
PoC is where CC6 findings most often hide. Auditors check whether PoC environments were isolated from production data and whether access granted during PoC was later revoked. CC8 also applies — even exploratory work needs a change record.
MVP is the most evidence-dense phase and where auditors spend the most time. CC4, CC5, CC7, and CC8 all apply. The auditor will sample pull request records, SAST and SCA scan reports, vulnerability remediation logs, and logging configuration. Controls must have operated on every change, not just most of them.
Release is primarily about authorized change (CC8) and least-privilege access to production (CC6). Pipeline logs are strong evidence because they show controls were enforced automatically. A documented rollback procedure satisfies CC7.
EOL is the most commonly under-documented phase. CC6 requires proof that access was revoked. CC8 requires a change ticket for the decommission. CC7 applies if the system handled live data up to shutdown. Data disposal records satisfy C1.2 if confidentiality is in scope.
The controls most frequently missing in practice are CC1 (no named SDLC policy owner), CC2 (policy exists but was never formally acknowledged by developers), CC7 (logging treated as a post-launch concern rather than a release requirement), and CC9 (dependency risk decisions not documented, even when scans were run).
The key principle for SOC 2 Type 2 is consistency. A control that worked 90% of the time is still a finding. Every sampled change needs a complete evidence chain from its originating phase through to deployment or decommission.
The post SOC 2 Type 2 mapping to Secure SDLC Requirements first appeared on Sorin Mustaca’s blog.
