Why SOC 2 CC8 is the most-tested control after access management
SOC 2 Trust Service Criteria CC8 covers change management — specifically whether changes to infrastructure and software are authorised, tested, and deployed in a controlled way. ISO 27001 A.8.25 (A.14 in 2013 version) covers secure development lifecycle.
For most SaaS startups, this is where the audit gets uncomfortable. The engineering team has good informal practices — code review, staging environments, CI/CD pipelines — but they're not documented, not consistently enforced, and definitely not generating the evidence auditors ask for.
The good news: you don't need a CISO or a dedicated AppSec team. You need documented processes, branch protection rules, and a CI/CD pipeline with security scanning baked in.
What compliance frameworks require for secure SDLC
| Framework | Reference | Requirement |
|---|---|---|
| SOC 2 | CC8.1 | Changes to infrastructure, data, and software are authorised; testing environments separated from production; change deployment is controlled and documented |
| ISO 27001:2022 | A.8.25 | Secure development lifecycle — security requirements integrated into development process from design through deployment |
| ISO 27001:2022 | A.8.26 | Application security requirements — information security requirements specified for new or changed applications |
| ISO 27001:2022 | A.8.29 | Security testing in development and acceptance — testing of security functionality during development |
| ISO 27001:2022 | A.8.32 | Change management — formal change management procedure for changes to information processing facilities and systems |
| PCI DSS v4.0 | Req 6.2 | Bespoke and custom software developed securely; secure coding practices |
| PCI DSS v4.0 | Req 6.3 | Security vulnerabilities identified and addressed; code reviews that address common vulnerabilities |
| PCI DSS v4.0 | Req 6.4 | Public-facing web applications protected against known attacks; WAF or code review by specialised organisation |
| PCI DSS v4.0 | Req 6.4.3 | Payment page scripts managed and authorised; script integrity verified (mandatory March 2025) |
| NIS2 | Art. 21(2)(e) | Security in network and information systems acquisition, development and maintenance; vulnerability handling and disclosure |
The 6 core secure SDLC controls
1. Separate development, staging, and production environments
This is the foundational requirement for SOC 2 CC8.1 and ISO 27001 A.8.31. Auditors want to see that production changes go through a controlled deployment path — not directly committed and pushed.
Minimum viable separation:
- Development — engineer's local environment + feature branch; no production data
- Staging/Pre-production — integrated environment; mirrors production configuration; uses anonymised/synthetic test data (never production PII)
- Production — live customer environment; all changes require successful staging deployment first
GDPR point: using production customer data in development or staging without masking/anonymisation violates the data minimisation principle (Art. 5(1)(c)). This is also an ISO 27001 A.8.33 (test information) requirement. Set up database masking or use synthetic data generators.
2. Code review requirements
Every production change must be reviewed by at least one person other than the author. This is the single most important control for SOC 2 CC8 evidence.
Branch protection configuration (GitHub/GitLab/Bitbucket):
- Require pull request before merging to main/master
- Require at least 1 approving review (2 for security-sensitive changes)
- Dismiss stale reviews when new commits are pushed
- No self-approval (author cannot be sole approver)
- Require status checks to pass (CI pipeline)
- No force push to protected branches
- No direct push from admin accounts without PR (admins are not exempt)
Security-sensitive changes (additional reviewer or security team sign-off required): authentication/authorisation changes, cryptographic implementation changes, external API integrations processing personal data, database schema changes affecting PII/PHI/PCI data, changes to security logging or monitoring.
3. Automated security scanning in CI/CD
Security scanning integrated into your CI/CD pipeline gives you continuous vulnerability detection AND automated audit evidence. Every CI run generates a timestamped record of what was scanned and what was found.
| Scan Type | When to Run | Common Tools | SOC 2 / ISO Evidence |
|---|---|---|---|
| SCA (dependency scanning) | Every PR + weekly scheduled | Snyk, Dependabot, npm audit | CC7.1 — vulnerability identification |
| SAST (static analysis) | Every PR | SonarQube, Semgrep, CodeQL | SOC 2 CC8 — code security review |
| Secret scanning | Every commit (pre-commit + CI) | git-secrets, TruffleHog, GitHub Advanced Security | CC6.7 — credentials not exposed |
| Container scanning | Every build | Trivy, Snyk Container | CC7.1 — container vulnerabilities |
| IaC scanning | Every terraform/CloudFormation PR | tfsec, Checkov, KICS | CC8.1 — infrastructure change security |
| DAST | Pre-production (staging) | OWASP ZAP, Burp Suite | CC8.1 — pre-deployment testing |
4. Change documentation
For SOC 2 Type II, auditors will sample 10–15 production deployments during the audit period and ask for evidence that each was: (a) reviewed by an appropriate approver, (b) tested before deployment, (c) deployed via a controlled process. Your PR history, CI/CD logs, and deployment records are your evidence.
What a pull request should document:
- What changed and why (business context)
- Security implications (if any)
- Testing performed
- Rollback plan for significant changes
- Linked ticket/issue number
Your PR is your change record. You don't need a separate change management ticketing system if your PR process is thorough — the PR history IS your change log.
5. Emergency change procedure
The scenario: it's 2am, production is down, a critical bug needs fixing NOW. Your normal PR-and-review process introduces 30+ minutes of delay. You need a documented emergency change procedure.
Emergency change process that satisfies SOC 2:
- Engineering Lead or CTO approves verbally/via Slack that emergency procedure is activated
- Engineer makes minimal-scope fix and deploys
- Post-incident: PR raised retrospectively documenting the change (even if already deployed)
- Second engineer reviews and approves the retrospective PR within 24 hours
- Incident documented in incident register with root cause and follow-up actions
Key point: the retrospective PR is what auditors check. The documentation exists even if the timing was reversed. Keep an emergency change log showing who authorised each emergency deployment.
6. Security requirements in design (threat modelling)
ISO 27001 A.8.25 and A.8.26 require that security is considered at design, not retrofitted. For small SaaS teams, this doesn't mean formal STRIDE threat modelling for every feature — it means a lightweight security review question at the design stage.
For any new feature involving: user authentication changes, data collection (new fields), external integrations, file upload/download, payment processing, automated decision-making — ask these questions before building:
- What data is collected/processed? Is it necessary (data minimisation)?
- What's the worst thing an attacker could do with this feature?
- Are there access control implications?
- Does this require a DPIA (GDPR Art. 35)?
- What logging is needed?
Audit evidence guide for secure SDLC
| What Auditors Ask For | Where to Find It | Retention |
|---|---|---|
| Branch protection configuration | GitHub/GitLab repository settings screenshots | Annual snapshot |
| Sample PRs with reviews | PR history — 10–15 sampled by auditor from audit period | Git history (permanent) |
| No self-approvals | PR history — auditor verifies author ≠ sole approver | Git history |
| CI/CD pipeline security scanning | Pipeline configuration + sample scan reports | CI logs (retain 1 year) |
| No direct pushes to main | Git log (no commits directly to main without PR) | Git history |
| Staging environment exists and is used | Deployment logs showing staging before production | CI/CD logs |
| Emergency changes documented | Emergency change log / retrospective PRs | Retain 2 years |
| Security scanning for new vulnerabilities | Snyk/Dependabot/SonarQube reports over audit period | Retain 1 year |
PCI DSS Req 6.4.3: Script integrity (mandatory from March 2025)
If your SaaS handles payments and has a payment page (checkout page), PCI DSS v4.0 Requirement 6.4.3 requires you to: (1) maintain a documented list of all scripts on the payment page with business justification for each, (2) confirm integrity of all scripts using Subresource Integrity (SRI) hashes or equivalent, (3) verify no unauthorised scripts have been added (script tamper detection). This applies to first-party and third-party scripts on the payment page. It became mandatory in March 2025.
Minimum viable secure SDLC for early-stage SaaS (checklist)
- ☐ Branch protection enabled on main/master with required PR review
- ☐ No self-approval rule configured
- ☐ CI pipeline runs on every PR with automated tests
- ☐ Dependency scanning (Dependabot or Snyk) enabled on all repos
- ☐ Secret scanning enabled (GitHub Advanced Security or git-secrets)
- ☐ Staging environment exists and all changes deployed to staging before production
- ☐ No production personal data in development/staging (masking or synthetic data)
- ☐ Emergency change procedure documented and known to engineering team
- ☐ SAST integrated into CI pipeline (SonarQube free tier, Semgrep, or CodeQL)
- ☐ Annual penetration test by qualified third party
Generate your security policies
Related generators for your compliance stack: Secure SDLC Policy Generator (new!), Information Security Policy, Access Control Policy, Vulnerability Management Policy, Cryptography & Encryption Policy, SOC 2 Gap Assessment, ISO 27001 Gap Assessment.
Related reading: SOC 2 Gap Analysis Before Audit, Change Management Policy Guide, Access Control Policy Guide, Vulnerability Management Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. SOC 2 and ISO 27001 requirements vary by scope and assessor interpretation. Engage a qualified auditor or security consultant for your specific programme.