What Are the SOC 2 Security Requirements for Engineering Teams?
Written by the Rafter Team
SOC 2 security requirements are defined by the Trust Services Criteria (TSC), a set of controls that govern how organizations protect customer data. For engineering teams, three criteria carry the most implementation weight: CC6 (logical and physical access controls), CC7 (system monitoring), and CC8 (change management). Passing a SOC 2 audit means proving — with evidence — that these controls are in place and operating continuously.
SOC 2 audits cover a review period of 3 to 12 months. A control implemented last week does not satisfy the requirement. Auditors want timestamped evidence that controls run automatically — policies in a wiki do not count.
Start generating SOC 2-ready evidence with Rafter — continuous scanning produces audit artifacts on every commit.
CC6: Access Controls That Auditors Verify
CC6.1 requires logical access controls that restrict system access to authorized users. For engineering teams, this means:
- Secrets management — no credentials hardcoded in source. Secrets detection scanning in CI catches leaked API keys, database passwords, and tokens before they reach production.
- Least-privilege access — repository permissions, cloud IAM policies, and service accounts scoped to minimum required access.
- Authentication enforcement — MFA on source control, cloud consoles, and production systems.
Auditors verify CC6 by sampling access logs and reviewing your secrets detection results. A single leaked credential in your git history is an audit finding.
CC7: Continuous Monitoring, Not Quarterly Scans
CC7.1 and CC7.2 require your organization to detect unauthorized changes, security events, and vulnerabilities through ongoing monitoring.
Engineering teams satisfy CC7 with three scanning types:
SAST (Static Application Security Testing) runs on every commit and flags vulnerabilities in your own code. This satisfies the "detect unauthorized changes" requirement because every code modification is analyzed before merge.
SCA (Software Composition Analysis) monitors your dependency tree for known vulnerabilities. When a CVE is published against a library you use, SCA detects it — satisfying the "monitor for anomalies" requirement in CC7.2.
DAST (Dynamic Application Security Testing) probes running applications for runtime vulnerabilities. This covers the detection surface that static analysis cannot reach.
The key word in CC7 is "ongoing." A quarterly vulnerability scan does not satisfy continuous monitoring. Your scanning must run in CI/CD on every change, producing dated evidence that auditors can trace.
CC8: Change Management as a Security Gate
CC8.1 requires that changes to systems are authorized, tested, and approved before deployment. Engineering teams implement this through:
- CI/CD gates — SAST and SCA scans that block merges when critical vulnerabilities are found. This proves changes are tested before deployment.
- Pull request approvals — required code reviews create an authorization trail.
- Deployment audit logs — who deployed what, when, and what scans passed.
Mapping Scanning Tools to SOC 2 Controls
| SOC 2 Criteria | Control Requirement | Scanning Tool |
|---|---|---|
| CC6.1 | Prevent unauthorized access | Secrets detection |
| CC7.1 | Detect unauthorized changes | SAST in CI/CD |
| CC7.2 | Monitor for vulnerabilities | SCA + DAST |
| CC8.1 | Test changes before deploy | SAST + SCA as merge gates |
SOC 2 for startups often feels overwhelming because the criteria are written in audit language, not engineering language. The mapping above translates each control into the tooling decision it actually requires.
Add Rafter to your pipeline and start building your SOC 2 evidence trail — scanning runs on every commit, and every result is an audit-ready artifact.