SOC2 Compliance: Access Control Requirements

Why SOC2 Matters for Infrastructure Access

If you're selling to enterprises, you'll hear "Do you have SOC2?" within the first three sales calls. SOC2 Type II certification demonstrates that your organization has robust security controls in place and has been operating them effectively for at least six months.

Among the five Trust Service Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy), Security is mandatory and includes some of the most challenging requirements around access control.

SOC2 Access Control Requirements

The AICPA Trust Service Criteria outline specific requirements for logical and physical access controls. For infrastructure access, the critical controls are:

CC6.1 - Logical and Physical Access Controls

Your organization must restrict logical and physical access to information and system components to authorized users. For infrastructure access, this means:

• Identity verification: Strong authentication for all infrastructure access
• Authorization mechanisms: Role-based access control (RBAC) with least privilege
• Access removal: Timely deprovisioning when access is no longer needed
• Privileged access: Additional controls for administrative access

# TigerAccess provides auditor-friendly evidence
# Generate SOC2 compliance report for Q4 2024
tacctl compliance report soc2 \
  --start-date=2024-10-01 \
  --end-date=2024-12-31 \
  --output=soc2-q4-2024.pdf

# Report includes:
# ✓ All access grants and revocations
# ✓ MFA coverage (must be 100% for privileged access)
# ✓ Session logs with full audit trail
# ✓ Access review completion status
# ✓ Privileged access justifications
# ✓ Certificate lifetimes (short-lived is better)

CC6.2 - Access Provisioning and Deprovisioning

Prior to issuing credentials, the entity enrolls and authenticates users. Credentials are removed when user access is no longer required or authorized.

This is where many organizations fail. They can provision access quickly (developers need to ship code!), but offboarding is manual, delayed, or incomplete. I've seen companies with credentials active for employees who left 18 months ago.

CC6.3 - Access Reviews

The entity reviews access rights at least quarterly to ensure they remain appropriate. This is non-negotiable for SOC2 Type II and one of the most time-consuming manual processes.

Quarterly access reviews typically involve:

1. Export all user access grants from various systems
2. Send spreadsheets to managers for review
3. Chase managers for weeks to complete reviews
4. Manually remove inappropriate access
5. Document everything for auditors

TigerAccess automates this entire workflow:

# Schedule quarterly access reviews
tacctl compliance access-reviews schedule \
  --frequency=quarterly \
  --reviewers=manager \
  --slack-notifications=true

# On Jan 1, Apr 1, Jul 1, Oct 1:
# 1. TigerAccess generates access review
# 2. Managers receive Slack message with review link
# 3. UI shows all direct reports' access grants
# 4. Manager approves/revokes with single click
# 5. Revocations happen immediately
# 6. Completion tracked for auditors

# View access review status
tacctl compliance access-reviews status

# Output:
Q4 2024 Access Review: ✓ Complete (100% reviewed)
  Engineering (Alice): ✓ Reviewed 2024-10-05
  Product (Bob): ✓ Reviewed 2024-10-03
  Sales (Carol): ✓ Reviewed 2024-10-02

# Auditor exports evidence
tacctl compliance access-reviews export \
  --quarter=Q4-2024 \
  --format=pdf

Audit Logging Requirements

SOC2 auditors will request detailed logs for a sample period (typically one full quarter). Your logs must demonstrate:

TigerAccess logs every infrastructure access event to immutable storage with cryptographic integrity verification:

# Example audit event (JSON)
{
  "event_id": "evt_abc123xyz",
  "timestamp": "2024-11-20T15:30:45.123Z",
  "event_type": "session.start",
  "user": {
    "id": "user_alice",
    "email": "alice@company.com",
    "mfa_verified": true,
    "device_id": "dev_laptop_001"
  },
  "resource": {
    "type": "node",
    "id": "node_prod_db_01",
    "environment": "production",
    "sensitivity": "high"
  },
  "action": {
    "type": "ssh",
    "login": "postgres"
  },
  "context": {
    "reason": "Investigating slow queries - TICKET-12345",
    "approval": "auto",
    "role": "database-admin"
  },
  "network": {
    "ip": "203.0.113.42",
    "location": "San Francisco, CA, US",
    "vpn": false
  },
  "outcome": "success",
  "certificate": {
    "serial": "123456789",
    "ttl": "4h",
    "expires_at": "2024-11-20T19:30:45Z"
  }
}

Multi-Factor Authentication Requirements

SOC2 doesn't explicitly require MFA, but auditors expect it for privileged access. In practice, 100% MFA coverage on production access is table stakes for passing a SOC2 audit.

# Enforce MFA for all production access
# /etc/tigeraccess/policy.yaml
mfa:
  required_for:
    - environment: production
    - role: admin
    - role: database-admin
    - action: ssh.root

  allowed_methods:
    - webauthn  # Hardware keys (YubiKey, etc.)
    - totp      # Authenticator apps
    - push      # Duo, Okta push notifications

  enforcement:
    grace_period: 0  # No bypass
    session_timeout: 8h  # Re-verify after 8h

Separation of Duties

SOC2 requires separation of duties for critical functions. In infrastructure access, this typically means:

• No developer should have production admin access without approval
• No single person should be able to grant themselves access and cover their tracks
• Access requests and approvals should involve different people

# Enforce separation of duties with TigerAccess RBAC
tacctl roles create production-access \
  --allow-nodes='env=production' \
  --require-approval=true \
  --approvers=role:sre-manager \
  --max-duration=4h

# Developer Alice requests production access
tac request create \
  --role=production-access \
  --reason="Deploy hotfix for TICKET-999"

# Request workflow:
# 1. Request created, Alice cannot approve her own request
# 2. Slack notification sent to SRE managers
# 3. Manager Bob (different person) approves
# 4. Alice receives 4h certificate
# 5. Full audit trail: requester, approver, reason, duration

# Audit event shows separation of duties
{
  "requester": "alice@company.com",
  "approver": "bob@company.com",  // Different person!
  "approval_time": "45 seconds",
  "access_granted": "2024-11-20T15:31:30Z"
}

Session Recording for Forensics

While not strictly required by SOC2, session recording provides valuable evidence for audit investigations and incident response. If an auditor asks "Can you show me exactly what this user did during this session?", the answer should be "Yes, let me pull up the recording."

# Query sessions for audit investigation
tacctl sessions query \
  --user=alice@company.com \
  --resource=prod-db-01 \
  --start-date=2024-11-01 \
  --end-date=2024-11-30

# Output:
Found 12 sessions matching criteria

Session ID: ses_abc123
  User: alice@company.com
  Resource: prod-db-01 (PostgreSQL)
  Started: 2024-11-20 15:30:45
  Duration: 1h 23m
  Commands: 47 total
  Data accessed: users table (read), orders table (read)
  Recording: available

# Play back session for auditor
tacctl sessions play ses_abc123
# Full terminal replay with commands and output

Preparing for Your SOC2 Audit

Here's a 90-day preparation checklist for the access control portions of your SOC2 audit:

Common Auditor Questions

Be prepared to answer these questions during your SOC2 audit:

The ROI of Automated Compliance

Manual SOC2 compliance for access control typically requires:

• 40 hours per quarter: Access reviews and evidence collection
• 2 weeks during audit: Responding to auditor requests
• Ongoing risk: Incomplete offboarding, audit log gaps

With automated compliance via TigerAccess:

• 2 hours per quarter: Review automated reports
• 1 day during audit: Export evidence, answer questions
• Continuous compliance: Real-time visibility and enforcement

That's 150+ hours saved annually, but more importantly—your SOC2 audit becomes a formality rather than a scramble.

Conclusion

SOC2 compliance isn't just checking boxes for auditors. It's implementing security controls that actually make your infrastructure more secure and auditable. The companies that pass SOC2 audits smoothly are the ones that build compliance into their access control architecture from day one.

Certificate-based access with comprehensive logging, automated reviews, and evidence collection isn't just SOC2 compliant—it's the foundation of a mature security program that scales with your business.