SOC 2 Type II and the Code Controls Auditors Are Now Testing

Auditors stopped accepting "we have a policy" as evidence

A SOC 2 Type II report used to be a binder of policies, access-review screenshots, and a narrative about control design. The control was the document. Whether the implementation matched was largely a matter of trust between the audit firm and the auditee.

That model broke when too many breached companies turned out to have clean SOC 2 reports. Enterprise buyers responded by asking for the technical artifacts behind the controls. The audit firms followed. Penetration test reports, code review records, scan output with triage and remediation history are now standard requests inside a CC (Common Criteria) evaluation, particularly in the CC6 and CC7 ranges where the controls touch code most directly.

Common Criteria That Live in Code

CC6.1: Logical Access Controls

CC6.1 requires that access to systems and data is restricted to authorized users. At the application layer, this means:

• Authentication is present on all routes that expose sensitive data
• Session management is implemented correctly (CWE-384: Session Fixation)
• Password storage uses appropriate hashing (CWE-916: Insufficient Password Hashing)
• Token expiration is enforced (CWE-613: Insufficient Session Expiration)

CC6.6: Vulnerability Management

CC6.6 requires processes for identifying, assessing, and managing vulnerabilities. Code scanning is a direct control mechanism. Auditors increasingly request:

• Evidence that scanning occurred (SARIF report or equivalent)
• Evidence that findings were triaged (ticket or annotation)
• Evidence that critical findings were remediated before deployment

"We have a scanner" is not CC6.6 evidence. "We ran the scanner, here are the results, here is the triage and remediation record" is CC6.6 evidence.

CC7.1: Change Detection

CC7.1 requires detection of unauthorized changes to configurations and infrastructure. At the code level, this includes:

• Integrity verification for deployed artifacts
• Detection of unexpected changes in configuration files
• Audit logging sufficient to reconstruct change history

CC8.1: Change Management

CC8.1 requires that changes to infrastructure, data, software, and procedures include authorization and security testing. Code changes that introduce new attack surface without security review are CC8.1 gaps.

The Evidence Package Auditors Want

For a well-evidenced SOC 2 Type II audit covering CC6.1 and CC6.6:

CC6.1 evidence:

• Authentication test results showing all routes protected
• Code review records showing authorization logic reviewed
• Dependency list with no known authentication bypass CVEs

CC6.6 evidence:

• SARIF scan report with finding severity distribution
• Triage records linking findings to tickets
• Remediation evidence (fixed version commits or risk acceptance)

How Deva Addresses SOC 2

Deva's SOC 2 preset maps findings to SOC 2 Trust Services Criteria with the evidence-package framing auditors expect. SARIF export includes TSC metadata. The compliance gap analysis shows current coverage percentage by TSC category.

For CC6.6, Deva's continuous scanning (scan-on-save) produces a running evidence record of vulnerability management activity across the development period. Exactly what a Type II audit (which covers a period of time, not a point in time) requires. Teams pursuing parallel financial-services audits should also review the financial compliance preset, which covers SOX ITGC and PCI-DSS v4.0 alongside SOC 2.