SOC 2 Compliance: Security Requirements for Engineering Teams

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.

Credential lifecycle management — provisioning, rotation, and deprovisioning of credentials must be documented and enforced. This includes service account keys, API tokens, and human user credentials. Auditors look for evidence that credentials are rotated on a defined schedule and that access is revoked promptly when a user or service no longer requires it.
Encryption at rest and encryption key protection — data stored in databases, object storage, and backups must be encrypted at rest. Encryption key management — including who has access to keys, how keys are rotated, and where key material is stored — is a distinct sub-requirement. Auditors expect evidence of key access controls separate from the data access controls themselves.

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

What Counts as SOC 2 Compliance Evidence?

Auditors do not accept policies or architecture diagrams as evidence of operating effectiveness. They need artifacts tied to specific controls, timestamped across your review period. Here is what each control area actually requires:

CC6 evidence

Secrets scanning results from CI runs (tool name, scan date, pass/fail, commit SHA)
Access review records showing least-privilege IAM roles and who approved them
MFA enrollment screenshots or logs for source control and cloud consoles

CC7 evidence

SAST scan reports generated on every commit, with vulnerability counts and disposition notes
SCA dependency scan outputs that show CVE detection and remediation tickets
Dated logs showing your monitoring ran continuously — not just at audit time

CC8 evidence

Pull request approval records (reviewer, timestamp, branch, linked scan result)
CI/CD pipeline logs showing which security gates ran before each deployment
Deployment history with who triggered it and which scan artifacts were attached

The pattern across all three: evidence must be commit-level, timestamped, and machine-generated. Manually collected screenshots assembled before an audit do not demonstrate continuous operation.

CC7.1 and CC7.2: What Continuous Monitoring Actually Requires

CC7.1 and CC7.2 are where engineering teams most often under-document their controls. The criteria are more specific than 'run scans.'

CC7.1 requires:

Defined configuration standards that infrastructure is measured against
A change-detection mechanism that alerts on unauthorized modifications to system or configuration files
Periodic vulnerability scans — and scans triggered after any significant environment change
A process to identify unknown or unauthorized components introduced into the environment

CC7.2 requires:

Detection tools deployed on infrastructure and software to recognize anomalies in system behavior
Established measures to identify compromised credentials, unauthorized external access, and unauthorized software execution
Procedures to filter and summarize anomalies so security events can be distinguished from noise
Evidence that detection tools are themselves monitored for effective operation

For most engineering teams, SAST in CI/CD covers the change-detection requirement in CC7.1. SCA satisfies the vulnerability scan requirement. The gap is usually CC7.2: anomaly detection and evidence that someone reviewed the outputs. Audit logs from your CI/CD pipeline — showing scan results were reviewed and acted on — fill this gap.

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.