I'm a Software Engineer. Then I Was Handed Our SOC 2 Audit.

A few months ago, my CTO asked me to "own the SOC 2 audit." I write software for a living. My mental model of compliance was a folder of PDFs nobody read and a checkbox somewhere in a sales deck. I said yes mostly because it was an opportunity to learn about a new area, and I assumed it would be a few weeks of forwarding documents to auditors.

It turned into one of the more useful things I've done as an engineer. Not because I now enjoy compliance (I'm still an engineer), but because it changed how I think about the work I was already doing.

Here's what I learned.

What is SOC 2, actually?

Strip away the jargon and SOC 2 is a simple idea: an independent CPA firm checks whether the security controls you say you have are the controls you actually operate. A SOC 2 Type II report goes further: it checks that those controls operated consistently over a period of time, usually several months, not just on the day someone looked. A Type I is the snapshot; a Type II is the time series.

The unit of work is a control ("access to production requires manager approval") and the currency is evidence ("here are the timestamped tickets showing it happened, every time, during the period").

That second word is where everything clicked for me.

The lesson under all the other lessons: evidence is the product

As engineers we're trained to care about whether something works. An auditor cares about whether you can prove it worked, after the fact, to a stranger, without you in the room.

Those are not the same thing, and the gap between them is enormous.

We had controls that genuinely happened every day and that I could not, at first, prove happened at all. Not because we were sloppy, but because the proof lived in people's heads, in Slack threads that scroll away, in "yeah, we always do that." An auditor can't accept "we always do that." They can accept a ticket with a timestamp, an approval, and a name.

If I had to compress the whole experience into one sentence: if it isn't written down, logged, or linked, it didn't happen. That sentence has quietly rewired how I work.

The seven lessons, for the scanners (each unpacked below):

• Documentation is a feature, not overhead.
• Audit logs are the closest thing to a time machine.
• The map is not the territory, and the auditor checks both.
• "We do it" and "we can prove we do it" are different maturity levels.
• Least privilege stops being an abstraction.
• Your security is only as strong as your vendors', and you have to prove theirs too.
• Repeatable beats heroic.

Lesson 1: Documentation is a feature, not overhead

I've always tried to write proper and useful PR descriptions but mostly treated them as busy work. During the audit, those descriptions became evidence. A well-written PR that says what changed, why, who reviewed it, and what was tested is a small, permanent proof that your change-management process is real.

The messy one-line PRs? Useless. Worse than useless: they made it look like changes shipped without review even when they hadn't.

Same story with the issue tracker. "Access was granted because a manager approved this request on this date" is a sentence an auditor can trust only if there's a ticket behind it. The teams that documented as they worked sailed through. The evidence that was painful to produce was always the evidence that was never written down in the first place.

Lesson 2: Audit logs are the closest thing to a time machine

Half of the requests I got amounted to: who did this, and when? Who accessed customer data. Who changed a permission. Who approved a deploy.

If your systems log those events, with an actor, a timestamp, and an object, you can answer instantly. If they don't, you're reconstructing history from memory and vibes. I came out of this with a much deeper respect for boring, structured logging, and a new habit of asking, when I fix a bug: if someone asks who did this six months from now, will we be able to answer?

Lesson 3: The map is not the territory; and the auditor checks both

One of my first real tasks was our system description, the document that says how the whole system is built and secured. I inherited a version that sounded plausible and was wrong in a dozen small ways: it described infrastructure we'd migrated off of, integrations we no longer used, a posture that didn't quite match production.

Nobody had lied. The document had simply drifted from reality while the system kept moving. Verifying it line by line against what was actually running was tedious and, honestly, one of the most valuable things I did. A system description that doesn't match reality isn't just an audit problem, it's an incident-response problem. When something breaks at 2am, the doc everyone trusts had better be true.

Documentation drift is real, it's invisible until someone checks, and "someone checks" turned out to be the whole point of an audit.

Lesson 4: "We do it" and "we can prove we do it" are different maturity levels

The most uncomfortable, and most useful, discovery was the set of controls we believed we had but couldn't cleanly evidence. A recurring, expected activity that had never been formally recorded. A governance step everyone assumed happened but that left no trail. A safeguard that was true in spirit but not written down as policy.

None of these were disasters. But each one was a place where our process depended on individual memory instead of a system. The fix, almost every time, was the same: make the invisible thing produce a record. A short attestation. A recurring calendar item with minutes. A policy line that states the thing we already do.

That's what "process maturity" actually means, and I never understood it until I went looking for the records and they weren't there.

Lesson 5: Least privilege stops being an abstraction

"Access based on role, with documented approval, reviewed periodically" is a sentence I'd read many times and never felt. Then I had to produce, for a specific person, the exact ticket that granted their access, the manager who approved it, and the review that confirmed it was still appropriate.

Suddenly, least privilege isn't a principle, it's a paper trail. And building the paper trail is trivial if you do it at provisioning time and miserable if you try to reconstruct it a year later. Do it at the door.

Lesson 6: Your security is only as strong as your vendors', and you have to prove theirs too

A surprising amount of the work was outward-facing: which third parties touch our data, what they're contractually allowed to do with it, and whether they have their own audits and tests. Data processing agreements, sub-processor lists, vendors' own reports and penetration tests. The audit made concrete that your trust boundary doesn't end at your own code. It ends at the edge of every vendor you've integrated, and you're accountable for that edge.

I now read a vendor's security posture the way I'd review a dependency I'm about to import. Because that's exactly what it is. It also changed how I think about the other direction: our customers read our trust center the same way, and everything in it is exactly the kind of evidence this whole essay is about.

Lesson 7: Repeatable beats heroic

The single biggest shift: audits reward systems, not heroics. A control that works because one diligent person remembers to do it is a control that will fail the moment they're on vacation. A control that works because it's automated, logged, and produces evidence on its own is one you never have to think about again.

That's the same instinct good engineers already have about code: we don't trust a fix that only works when you hold it just right. SOC 2 just applies that instinct to how the company runs, and it turns out the instinct transfers cleanly.

What actually changed in how I work

• I write PR descriptions like someone will read them a year from now, because someone will.
• I ask "how would we prove this?" while writing code, not after.
• I treat logs (who, what, when) as a first-class requirement, not a debugging afterthought.
• I keep docs honest, and I assume they've drifted until I've checked.
• I look at our own processes the way I look at code: is this repeatable, or is it a person remembering?

Why this matters for a SaaS company

When you're a SaaS company, your customers hand you their data and trust your process. SOC 2 is, at bottom, a structured way of making that trust inspectable: of turning "trust us" into "here's the evidence." I used to see that as bureaucracy. Now I see it as the same discipline that makes good software: make the important things explicit, observable, and repeatable, so they don't depend on any one person being in the room.

I didn't expect a compliance audit to make me a better engineer. It did, mostly by taking the habits I already valued in code and insisting I apply them to everything else.

Sybill's security posture, reports, and sub-processor list live in our trust center, which is the inspectable version of everything above. And if you want to see the product all that evidence protects, get started for free with Sybill.

Written after helping steer our first SOC 2 audit as the engineer on point. If you're an engineer who just got handed one: it's less about security theater than you fear, and more about writing things down than you'd guess.

Get started for free with Sybill or book a demo.

Frequently Asked Questions

What is a SOC 2 audit, in plain terms?

An independent CPA firm examines whether the security controls a company claims to have are the controls it actually operates, and issues a report customers can rely on. The working unit is a control (a specific, stated practice) and the currency is evidence: timestamped, attributable records proving the control ran.

What is the difference between SOC 2 Type I and Type II?

A Type I report checks that controls are suitably designed and in place at a point in time: a snapshot. A Type II report checks that the controls operated effectively over a review period, typically several months: a time series. Type II is the one enterprise customers usually ask for, because consistency over time is the harder claim.

What counts as evidence in a SOC 2 audit?

Records a stranger can verify without you in the room: tickets with timestamps and approvals, PR descriptions showing review and testing, structured audit logs with an actor, timestamp, and object, access-provisioning records, meeting minutes, and signed policies. Verbal assurances ("we always do that") do not count, which is the audit's entire point.

How involved are engineers in a SOC 2 audit?

More than most expect. Engineers typically produce or explain change-management evidence (PRs, reviews, deploys), access records, audit logs, and the system description, and they fix the gaps where real practices left no trail. The work is less security theater than writing down, logging, and linking what the team already does.

What is a SOC 2 system description?

The narrative document describing how the system is built, secured, and operated: infrastructure, data flows, integrations, and controls. Auditors check it against reality, so drift (describing infrastructure you migrated off of, integrations you dropped) is a finding waiting to happen, and keeping it true is as much an incident-response asset as a compliance one.

How can engineering teams prepare for a SOC 2 audit?

Make daily work produce evidence as a side effect: substantive PR descriptions, tickets behind every access grant, structured who-what-when logging, provisioning-time paper trails, and automated controls that emit their own records. Then verify the system description line by line against production before the auditor does.