SOC 2 Compliance Testing: Security Controls You Must Automate

SOC 2 is a voluntary standard, but if you sell software to enterprises, you'll be asked for your SOC 2 report. What many teams discover too late is that SOC 2 isn't just a policy document — it requires demonstrable, tested controls with evidence.

This guide covers the SOC 2 controls that engineering teams are responsible for testing, which ones should be automated, and how to approach continuous compliance.

What SOC 2 Is (and Isn't)

SOC 2 is an auditing standard developed by the AICPA that evaluates how service providers manage customer data. It's organized around five Trust Service Criteria (TSC):

1. Security (required for all audits)
2. Availability (optional)
3. Processing Integrity (optional)
4. Confidentiality (optional)
5. Privacy (optional)

Most SaaS companies pursue SOC 2 Type II reports covering Security, Availability, and Confidentiality.

SOC 2 doesn't prescribe specific controls — it describes outcomes. Your auditor evaluates whether your controls effectively achieve those outcomes. This means you have flexibility in how you implement controls, but you must be able to prove the controls exist and work.

The Engineering Team's SOC 2 Responsibilities

SOC 2 is often treated as a compliance/legal project, but engineering owns significant portions:

• Access control implementation and testing
• Encryption at rest and in transit
• Vulnerability management
• Incident detection and response mechanisms
• Change management processes
• Backup and recovery systems

If these controls aren't testable and tested, they're not controls — they're claims.

Access Control Testing

Least Privilege Access

SOC 2 CC6.3 requires limiting access to systems and data to authorized users and programs. Least privilege means users get access to only what they need for their role.

What to test:

• User roles are defined with specific, limited permissions
• Users cannot elevate their own privileges
• Permissions are checked server-side (not just in the UI)
• Privilege escalation attempts are blocked and logged

Test approach — privilege escalation:

Scenario: User cannot access admin-only endpoints
  Given I am authenticated as a standard user
  When I request GET /api/admin/users
  Then the response is 403 Forbidden
  And an access violation is logged
  And my user account is not modified

Scenario: User cannot modify another user's data  
  Given I am authenticated as user A
  When I attempt to update user B's profile via PUT /api/users/{user-B-id}
  Then the response is 403 Forbidden

Access Review

SOC 2 CC6.2 requires periodic review of access rights. This is process-level, but testing can verify the mechanism:

• Does the system generate access reports showing who has what access?
• Are terminated user accounts disabled within the required timeframe?
• Are access changes logged with approver information?

Automated test:

Scenario: Terminated employee access is revoked
  Given employee account exists with active access
  When account status is set to "terminated" in HR system
  Then access to all systems is revoked within 24 hours
  And the revocation is logged with timestamp
  And any active sessions are terminated

Multi-Factor Authentication

SOC 2 CC6.1 requires logical access security software and authentication mechanisms. MFA is increasingly expected as a compensating control for password-only systems.

What to test:

• MFA is required for all accounts (or documented exceptions)
• MFA is enforced on all access paths (web, API, admin console)
• MFA bypass attempts are blocked
• MFA enrollment and recovery are secure

Encryption Testing

Encryption at Rest

SOC 2 CC6.7 requires protecting data from unauthorized disclosure. For most applications, encryption at rest means database encryption and file storage encryption.

What to test:

• Database encryption is enabled (verified at infrastructure level)
• Sensitive fields (passwords, PII, API keys) are encrypted at the application level even if database encryption exists
• Encryption keys are stored separately from encrypted data
• Key rotation works without data loss

Test key rotation:

Scenario: Encryption key rotation preserves data access
  Given sensitive data is stored encrypted with key version 1
  When encryption keys are rotated to version 2
  Then existing data encrypted with version 1 is still readable
  And new data is encrypted with version 2
  And key version 1 can be revoked after migration completes

Encryption in Transit

All data in transit should be encrypted. SOC 2 doesn't specify TLS versions, but auditors expect current standards.

What to test:

• All HTTP connections redirect to HTTPS
• TLS 1.2 minimum; TLS 1.3 preferred
• No deprecated cipher suites
• Certificate validity and expiration monitoring
• Internal service-to-service communications encrypted

Automated TLS check:

# Run in CI against staging environment
testssl.sh --quiet --json staging.yourapp.com 2>/dev/null <span class="hljs-pipe">| \
  jq <span class="hljs-string">'.findings[] | select(.severity == "HIGH" or .severity == "CRITICAL")'
<span class="hljs-comment"># Fail build if any HIGH/CRITICAL findings

Vulnerability Management Testing

SOC 2 CC7.1 requires that vulnerabilities in system components are identified and addressed. This requires an actual vulnerability management process, not just having a firewall.

Dependency Scanning

Your application's third-party dependencies are attack surface. Dependency vulnerabilities need to be caught and remediated.

What to test in CI:

# Node.js
npm audit --audit-level=high

<span class="hljs-comment"># Python  
safety check --full-report

<span class="hljs-comment"># Java
./mvnw dependency-check:check -DfailBuildOnCVSS=7

SOC 2 auditors will ask: how do you know about vulnerabilities in your dependencies? The answer needs to include automated scanning in CI, not just "we check periodically."

Penetration Testing

SOC 2 doesn't mandate penetration testing frequency, but most auditors expect annual pen tests for mature organizations. Evidence of penetration testing and remediation of findings is strong evidence for CC7.

What auditors look for:

• Engagement scoping documentation
• Report from qualified tester
• Remediation tracking for findings
• Re-test confirmation for critical findings

Container and Infrastructure Scanning

If you use containers or infrastructure-as-code:

# Container image scanning
trivy image yourapp:latest --exit-code 1 --severity HIGH,CRITICAL

<span class="hljs-comment"># Terraform/IaC security scanning  
tfsec infra/ --no-color

Logging and Monitoring Testing

SOC 2 CC7.2 requires monitoring system performance, changes, and anomalies. For engineering, this means verifiable logging and alerting.

What Logs Must Exist

User activity:

• Authentication events (success and failure)
• Authorization failures
• Privileged actions
• Data access and modification

System events:

• Configuration changes
• Service start/stop events
• Infrastructure modifications

Security events:

• Failed authentication bursts (potential brute force)
• Unusual access patterns
• Error rate spikes

Testing Log Completeness

Scenario: Authentication events are logged
  When a user successfully authenticates
  Then a log entry exists with: timestamp, user_id, source IP, success=true
  
  When a user fails authentication
  Then a log entry exists with: timestamp, attempted_user, source IP, success=false, reason
  
  When 5 consecutive authentication failures occur
  Then an alert is triggered to the security team
  And the account is temporarily locked

Alert Testing

SOC 2 requires that anomalies are detected and responded to. Alerts that nobody receives or responds to don't satisfy this requirement.

What to verify:

• Alert delivery works (test on-call rotation receives alerts)
• Alert thresholds are appropriate (not too noisy, not too quiet)
• Alert runbooks exist and are current
• Alert-to-response time is within policy

Change Management Testing

SOC 2 CC8.1 requires that changes to system components are authorized, tested, and documented. For engineering, this is your deployment process.

What auditors look for:

• Code review is required before merge
• Tests pass before deployment
• Deployments are logged with who, what, and when
• Rollback capability exists

What to test:

Scenario: Unauthorized deployments are prevented
  Given a deployment requires code review approval
  When a pull request without approval attempts to merge
  Then the merge is blocked
  And the attempt is logged

Scenario: All deployments are logged
  When a deployment occurs
  Then a deployment record exists containing: deployer identity, timestamp, version, environment

Backup and Recovery Testing

SOC 2 A1.2 (Availability) requires that backups are performed and restorable. This is often stated in policy but rarely actually tested.

What to test — actually, not just verify configuration:

Scenario: Database backup is restorable
  Given a complete database backup was taken at T
  When the backup is restored to a test environment
  Then all data present at time T is available
  And the restoration completes within the RTO target
  And the restored data integrity is verified via checksums

Run backup restoration tests quarterly. Auditors ask whether you've actually restored from backup. "We've never needed to" is not an acceptable answer.

Evidence Collection for SOC 2 Audits

Testing alone isn't enough — you need evidence. SOC 2 audits are evidence-based.

What auditors collect:

• Screenshots or logs showing controls operating
• Configuration exports showing security settings
• Reports from scanning tools
• Access review records
• Training completion records
• Penetration test reports and remediation tracking

Build evidence collection into your process:

• Automated tests should output evidence (screenshots, log extracts)
• Store test results with timestamps
• Generate quarterly access review reports
• Archive penetration test reports and remediation status

Continuous SOC 2 Testing vs. Point-in-Time

Traditional SOC 2 preparation involves a mad scramble 2-3 months before the audit window. This is painful, expensive, and misses the point — SOC 2 is supposed to demonstrate that controls were operating throughout the audit period (typically 12 months).

The engineering approach that makes SOC 2 manageable:

1. Automate control testing in CI — access control, encryption, vulnerability scanning run on every deployment
2. Schedule periodic control tests — backup restoration quarterly, access review monthly
3. Log everything with audit trail — every control test produces evidence artifacts
4. Track exceptions formally — when a control fails or is bypassed, document the reason and remediation

When the audit window approaches, you're presenting a 12-month history of control evidence, not scrambling to demonstrate controls that may not have been working.

Common SOC 2 Control Failures

Access review process exists but isn't followed. Policy says quarterly access review, but the last review was 18 months ago. Solution: automate access report generation; put access review in the quarterly engineering calendar.

MFA is policy but not enforced. Policy requires MFA, but legacy service accounts and API keys bypass MFA. Automated test: verify every access path requires MFA or has a documented exception.

Backups are taken but never tested. Backup exists; nobody has ever confirmed it's restorable. Solution: quarterly restoration test with evidence.

Vulnerability scanning is done but not actioned. Scanning runs but findings sit unresolved for months. Solution: critical/high findings block deployment in CI; medium findings require closure within 30 days.

Logs exist but nobody reads them. Logs are generated but alerting is configured for the wrong things. Solution: weekly log review for anomalies plus automated alerts for specific patterns.

Conclusion

SOC 2 compliance is achievable, but it requires engineering discipline beyond documentation. The controls that satisfy auditors are the same controls that make your application more secure: rigorous access management, encryption verification, vulnerability management, and monitored alerting.

The teams that handle SOC 2 audits without scrambling are the ones who treat compliance as continuous engineering practice. Automated control testing in CI, scheduled evidence collection, and proper exception tracking mean the audit is a review of your ongoing practice, not a performance.

HelpMeTest supports automated testing workflows useful for continuous verification of security controls — access control testing, uptime monitoring, and integration testing that generates evidence artifacts for compliance purposes.