SOC2 Type 1 for Engineers.

I’m an engineer. I don’t like audits, but they’re part of life. I’ve done a lot of them, and they always start the same way: someone in sales or leadership says “we need SOC2,” a compliance vendor gets hired, and six weeks later you’re fielding a list full of requests you didn’t know applied to you. This is the primer I wish someone had handed me before my first audit.

What’s a SOC?

System and Organization Controls. SOC2 is an AICPA (American Institute of Chartered Public Accountants) audit framework. Don’t worry about SOC1; it deals with financial reporting. SOC2 deals with security controls. An accounting firm audits your security controls and issues a report attesting to whether they’re designed and/or operating effectively. There’s no pass/fail badge; you can’t fail SOC2. The auditors’ report documents whether any exceptions or qualifications to your controls exist. Enterprise customers ask for vendors’ SOC2 reports because they’re proof of good security practices; if nothing else, they prove an organization’s ability to document their security practices.

Type 1 vs Type 2

SOC1 is not SOC2, and SOC2 Type 1 is materially different to SOC2 Type 2. Yes, it’s confusing. You can stop here and take a breath if you need to.

• Type 1: “Are your controls designed correctly as of a specific date?” It’s a point-in-time assessment. The evidence is policies, configs, architecture docs, access lists as they exist at the time of the audit.
• Type 2: “Were your controls actually operating over a 6-12 month window?” Evidence is logs, ticket history, change records, and so on. The auditors look for consistency, not just whether the controls exist.

Type 1 is a legitimate first milestone and usually a prerequisite to Type 2, but sophisticated buyers eventually want Type 2. If you’re doing Type 1 first, know that you’re building the evidence trail Type 2 will demand a year from now — do it right the first time and you’re not redoing work.

Five categories, one mandatory

SOC2 covers five Trust Services Categories (TSCs). Security (the “Common Criteria,” CC) is always required. The other four are optional, selected based on what you produce:

Within the Security TSC, CC6 (Logical and Physical Access) and CC7 (System Operations) are where most engineering-level evidence requests land. If you only prep for two things, prep for those.

What you’ll actually be asked for

• Access control: IAM exports, MFA enrollment reports, access review records, offboarding tickets. “We removed access via Slack DM” is not evidence. Auditors look for immutable proof of authorized actions.
• Change management: PR approvals, deployment pipeline logs, and yes, a ticket for the thing you fixed directly in prod at 2am. Operationally fine, audit-wise it needs to exist on paper too. This is why you always make a ticket the next morning.
• Vulnerability management: scanner reports, patching tickets with timestamps tied to your defined SLA.
• Logging & monitoring: SIEM configs, audit log exports, and proof someone is actually looking at the alerts. Logs that exist but aren’t centralized or alerting on anything meaningful will be documented as an exception.
• Incident response: an IR policy that covers detection, containment, notification, post-incident review, and evidence you followed it if anything happened during the audit window.
• Encryption: TLS configs, storage encryption, key management docs, web server configs, CA ceremonies.
• Backup & recovery: scheduler configs and restore test records. A backup job running on schedule proves nothing if you’ve never tried to restore from it.
• Vendor management: inventory of third parties with system access, plus their own security posture.

The five phases, from the engineer’s seat

1. Readiness assessment: gap analysis. This is where you learn which of your controls exist only as policy docs versus actually being enforced in config. Usually more of the first than anyone wants to admit.
2. Scope definition: which systems touch customer data and are therefore “in scope.” Resist the urge to narrow the scope too much; it just relocates the risk to next year.
3. Evidence collection: auditors will request a PBC (Prepared By Client) list. This consists of screenshots, config exports, access lists, ticket references, and other tangible artifacts. You’ll learn to love it.
4. Auditor walkthroughs: live explanation of how a control actually works. Be straight about gaps here. Auditors would rather note an exception than catch you overstating something.
5. Report issuance: “unqualified” (no material exceptions) is the outcome you want. Exceptions get documented, and you usually get to attach a management response.

Where engineers create audit problems

These are all process discipline gaps and can be avoided by being meticulous about your work:

• Access granted informally, no ticket trail
• Terminated employees or contractors still sitting in Okta/IAM because nobody ran an access review
• “I fixed it in prod at 2am” with no retroactive ticket
• Logs enabled but not centralized or not alerting on anything
• Backups that run on schedule but have never been restore-tested
• Shadow infra: an AWS account or droplet spun up outside the main environment that touches customer data and has zero controls applied, because nobody remembered it existed

This all sounds terrible, why would I want to put myself through this?

You have to. If nothing else, it’s a discipline exercise. If you know your craft, the technical side of SOC2 is tractable; none of the controls themselves are hard. The audit tests whether you can prove what you already do.

Hopefully this post makes you feel better about your first SOC2 audit.