SOC 2 Is a Technical Problem

Most SOC 2 guides are written for compliance managers or CEOs. This one is written for the engineering lead who just got asked to "own the SOC 2 program" on top of everything else.

The good news: SOC 2 is largely a technical problem. The 9 Trust Services Criteria map directly to things your infrastructure either does or doesn't do. Once you understand the mapping, the path is clear.

The 9 Criteria and What They Mean for Your Stack

CC1 — Control Environment: Organization structure, background checks, security training, policies. Not your infrastructure, but your team. Who's responsible for what? Do people sign security policies? Are there background checks?

CC2 — Communication: Are security policies communicated to employees and relevant external parties? Is there a way for customers to report security concerns? Your Trust Center covers most of this.

CC3 — Risk Assessment: Do you have a risk register? Have you identified the top risks to your environment and documented treatment decisions? Not a technical control — a documented process.

CC4 — Monitoring Activities: This is where penetration tests live. You need periodic testing by a third party plus continuous monitoring of your control posture. This is what SecureSpect's control checks cover.

CC5 — Control Activities: The heart of the technical controls. IAM configuration, encryption, logging, network security, application security. If you work in AWS, this is your CloudTrail, GuardDuty, KMS, S3, and IAM configuration.

CC6 — Logical Access: Who can access what systems, at what privilege level, and how is that tracked and reviewed? Access reviews, MFA enforcement, least-privilege, offboarding procedures.

CC7 — System Operations: Incident detection, response, and resolution. You need a defined incident response process, evidence that you detect incidents (GuardDuty, CloudWatch alerts), and records of incidents handled.

CC8 — Change Management: How do production changes get approved and deployed? PR review requirements, branch protection, deployment pipeline controls, four-eyes principle for high-risk changes.

CC9 — Risk Mitigation: Vendor management and insurance. How do you assess third-party risk? What's your subprocessor list? Do you have cyber insurance?

The Technical Controls That Matter Most

From an auditor's perspective, the most scrutinized technical controls are:

IAM configuration (CC5, CC6)

• MFA on all IAM users with console access
• No active root user access keys
• Access keys rotated within 90 days
• Inactive IAM users removed
• Least-privilege policies (no wildcard permissions except where justified)
• Password policy enforced (complexity, rotation)

Encryption (CC5)

• All S3 buckets encrypted at rest (SSE-S3 or SSE-KMS)
• S3 public access block enabled on all buckets
• KMS keys with automatic rotation enabled
• No unencrypted database instances
• TLS 1.2+ required for all external endpoints

Logging and monitoring (CC4, CC7)

• CloudTrail enabled in all regions, with log validation
• GuardDuty enabled in all accounts
• CloudWatch alarms on critical events (root login, policy changes, MFA disable)
• Application logs shipped to a centralized, tamper-resistant store
• Log retention ≥90 days for audit trails

GitHub security (CC5, CC8)

• Branch protection on main/master: require PR review, no direct push
• Required PR approvals (at least 1)
• Secret scanning enabled
• Actions security: restrict OIDC token permissions, pin action versions

Access management (CC6)

• Periodic access reviews (quarterly for production systems)
• Offboarding checklist: revoke access to AWS, GitHub, all SaaS tools within 24 hours
• No shared accounts (everyone has individual IAM users or SSO identities)
• Admin access via separate role assumption, not standing access

Evidence: What It Actually Is

Auditors don't want screenshots of your AWS console. They want:

• API-sourced snapshots: JSON or structured data from AWS APIs showing the actual state of controls (e.g., the output of aws iam get-account-password-policy — not a screenshot of it)
• Configuration records: The actual IAM policy attached to a role, not a description of what it does
• Change records: Git commit history, deployment logs, PR approval records
• Process records: Meeting notes, Jira tickets, access review results

This is why automated evidence collection matters: SecureSpect pulls this data via API continuously. The evidence is always current, always structured, and always timestamped. No screenshots.

Running This From Infrastructure

If you're infrastructure-as-code (Terraform, CDK, CloudFormation), the most efficient approach is:

Map every failing control to a Terraform resource change

Remediate through your standard IaC review and deployment process

Let the compliance platform pick up the change on the next scan

This way, compliance fixes become code changes — reviewed, tested, and deployed through your normal engineering process. Evidence collection is automatic.

What SecureSpect Does Specifically for Engineering Teams

• Jira integration: Failing controls auto-create Jira tickets assigned to the right team
• Slack alerts: Control drift triggers Slack notifications before auditors see them
• Run-all-tests API: Trigger a full control scan from your CI/CD pipeline
• Evidence health scoring: Each piece of evidence gets a health score (0–100) so stale evidence gets flagged before the audit
• CSV import: Bulk-import evidence from existing tools that don't have a direct integration

The goal is zero manual evidence collection. Every control either has automated evidence or a documented exception.