SOC 2 Engineering Guide: Access Control, Encryption in Transit and Vulnerability Management

This guide covers the Matrix’s SOC 2 mappings: access control and RBAC (soc2-1, CC6.1), encryption in transit (soc2-2, CC6.6), and automated vulnerability management (soc2-3, CC7.1). SOC 2 reports are scoped attestation engagements; implementing these patterns does not create a SOC 2 report or certification.

1. Access control evidence (soc2-1)

Use a deny-by-default authorisation layer, an entitlement review cadence, and auditable administrator changes.

export function requirePermission(permission: string) {
  return (request: RequestContext) => {
    if (!request.actor.permissions.includes(permission)) throw new Error('Forbidden');
  };
}

Test cross-tenant access, privilege escalation, stale sessions, and emergency-access review. Capture review results rather than only application logs.

2. Transport protections (soc2-2)

Document service identities, TLS termination, certificate rotation, and exceptions. Continuous checks should reject expired certificates, weak protocol configuration, and plaintext egress from sensitive services.

3. Vulnerability management (soc2-3)

Make the pipeline produce triageable evidence: scanner version, dependency lockfile digest, finding identifier, severity source, owner, due date, and exception approval.

- name: Dependency audit
  run: npm audit --audit-level=high
- name: Record scan evidence
  run: node scripts/record-security-scan.mjs

Do not equate a passing dependency scan with absence of vulnerabilities. Include image, infrastructure, code, and configuration findings in the programme’s scope.

Verification checklist

• Access review evidence identifies reviewer, population, decision, and date.
• TLS tests run against each internet-facing and internal service boundary.
• Vulnerability exceptions expire and require a named risk owner.

Track local implementation state in the SOC 2 Matrix.