Last updated: September 8, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
SOC 2 compliance changes four things for engineering teams day to day: every production change needs a documented approval trail, access reviews become a recurring calendar item, logging can’t get switched off to chase a bug, and someone owns evidence collection as a real job. That’s the practical version. The rest of this is what it looks like when it lands on your team specifically.
The first SOC 2 Type II cycle I sat through wasn’t at a bank. It was a mortgage-tech shop with maybe sixty engineers, a production AWS account nobody had ever really locked down, and a sales team that had already promised two enterprise clients an attestation report that did not exist yet.
Nobody had lied to anyone. They just hadn’t done the math on what “we’ll have SOC 2 by Q3” actually meant for the people who were going to spend the next six months writing the code and building the process behind it.
It meant a lot.
I’ve written before about how engineering leadership in regulated industries actually differs from running an org at a generic SaaS company, and SOC 2 is where that difference stops being theoretical. It shows up in your sprint board, your merge queue, and the calendar of at least one senior engineer who did not sign up to become a part-time auditor.
Most of what I see written about SOC 2 is aimed at whoever’s buying the compliance software. Not the buyer. This is aimed at whoever has to live inside the controls after it’s purchased.
The Five Things the Trust Services Criteria Actually Ask For
The AICPA’s Trust Services Criteria define what a SOC 2 report can attest to: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, sometimes called the Common Criteria, is the only one that’s mandatory. The other four get added to your report’s scope only when they’re actually relevant to what you sell.
Most first-time companies scope Security alone, and that’s the right call. Adding criteria you don’t need just adds evidence you have to produce for something nobody asked about.
| Criteria | What it actually covers | Who owns it day to day |
|---|---|---|
| Security (mandatory) | Access control, change management, monitoring, incident response | Whoever owns IAM and the merge queue |
| Availability | Uptime commitments, disaster recovery, capacity planning | SRE or infrastructure lead |
| Processing Integrity | Data processing is complete, accurate, timely, and authorized | Whoever owns the core transaction pipeline |
| Confidentiality | Data marked confidential stays restricted to people who need it | Platform engineering, plus whoever classifies the data |
| Privacy | Personal data collected, used, retained, and disclosed per stated policy | Legal, plus whoever owns the data model |
What Changes on the Engineering Team, Week One
The framework is abstract. The Monday morning version is not.
- Every merge to production carries a documented approval. Self-approving your own pull request because it’s Friday at 5 doesn’t fly anymore.
- Access reviews become a calendar item. Quarterly, at minimum, and somebody actually revokes the stale access instead of just eyeballing a spreadsheet and moving on.
- Logging stays on. You don’t get to flip it off to chase a weird bug and forget to flip it back on afterward.
- Vendor questionnaires start landing in engineering’s inbox, not just legal’s, because your subprocessors are part of the control environment now.
- Offboarding gets a timestamp. “We got around to it eventually” stops being an acceptable answer, and an auditor will ask for the ticket.
None of these are hard, individually. Stacked together, over a year, they’re a real tax on the team’s attention. Budget for that honestly instead of pretending it’s free.
Who Owns Evidence, and Why That Decision Matters More Than the Tooling
Whether you buy a GRC platform to automate evidence pulls or build your own scripts against your CI/CD and IAM APIs is a legitimate build vs buy decision, and I genuinely don’t have a universal answer for you. Team size, existing tooling, and how many times a year you’ll need this all push in different directions.
What I do have an answer for is the question underneath it. Who owns the outcome, regardless of which tool touches it?
Somebody needs to know what’s happening under the hood of your access control system well enough to answer an auditor’s follow-up question without a demo environment propped up in front of them. That’s not a tooling problem. It’s a staffing and ownership problem, and the tooling is a distraction from it. Pick one anyway.
I’ve watched IAM permission models turn into load-bearing spaghetti over five years of “just add this role real quick.” Nobody planned it that way. It just grew until revoking one person’s access broke three unrelated integrations, and nobody wanted to be the one who touched it. A SOC 2 access review is usually the first time anyone has looked at the whole thing in years. That’s not a comfortable discovery to make three weeks before an auditor’s first request. Not comfortable. Necessary anyway.
The Audit Cycle, Realistically
A SOC 2 Type I report is a point-in-time opinion. It says your controls are designed correctly, as of the day the auditor looked. A SOC 2 Type II report is a different animal entirely, because it opines on whether those same controls actually operated effectively across a review period the AICPA measures in months, not days.
Type I proves you designed the seatbelt correctly. Type II proves you actually wore it. An auditor doesn’t want your assurance that you did. Show me the data is the entire job.
| Phase | What it actually is | What engineering does |
|---|---|---|
| Readiness assessment | Mapping real controls against the criteria you’re scoping | Inventory who has admin, what’s logged, and what’s undocumented |
| Type I report | Opinion on whether controls are designed correctly | Freeze the control set. Don’t change the access model mid-review |
| Observation period | The window the Type II opinion actually covers | Live inside the new habits. This is where they take, or don’t |
| Type II report | Opinion on whether controls operated effectively the whole time | Produce evidence, on request, calmly, for months |
Budgets already say otherwise. Gartner forecasts worldwide end-user spending on information security at $213 billion, with regulatory pressure named as one of the drivers behind that growth, not just yours.
The people qualified to actually run this program are not sitting idle waiting for your requisition. The Bureau of Labor Statistics projects 21% growth in information security analyst jobs from 2025 to 2035, against roughly 14,100 openings a year and a median wage of $129,180. That’s a tight market you’re competing in. It is not a job posting you fill in two weeks because you finally got budget approval.
Where Engineering Leadership Actually Fits
Three decisions matter here. Your job is not to become the compliance officer. Somebody else usually holds that title, and they should. Your job is to make the specific decisions nobody else on that org chart is positioned to make. What blocks a merge outright versus what gets a documented exception. Who has final say when a control and a deadline are in direct conflict. Whether the audit gets staffed with a hire, a contractor, or an outside partner who’s done this before.
If your engineers are waiting on you personally to approve every access exception by Friday, that’s not a security problem. That’s a you problem, and SOC 2 will find it faster than almost anything else you’ll run this year.
You have three real options here, not the two most leaders default to. Hire a security engineer permanently and hope the audit cadence justifies a full-time seat. Bring in contract staffing for the specific ninety to a hundred and twenty days the first audit actually needs, which is usually the right call the first time through. Or lean on a fractional VP of engineering with regulated-industry experience who has already sat in this exact seat and isn’t learning the Trust Services Criteria on your clock.
KORE1 runs a dedicated cybersecurity staffing desk for exactly this kind of stretch. Recruiters on that desk average 17 days to fill a role, which is usually faster than most engineering leaders realize they need to move once the observation window is already ticking.
I’ll argue with anyone about which of the five criteria deserves engineering’s attention first, so connect with me on LinkedIn if you want to make the case for your scope. And if the honest gap you’re staring at is a people gap rather than a process gap, talk to a KORE1 recruiter about getting coverage in place before the observation window starts, not during it.
What Engineering Leaders Ask Me About Their First SOC 2 Audit
Do we need a Type I report before we can go straight to Type II?
Nothing requires it, but most first-timers should still run Type I first. It forces you to freeze and document the control set before the clock starts on months of evidence, instead of discovering gaps mid-observation.
Skip it and you’re debugging your control design and proving it operated correctly at the same time. That’s a genuinely harder problem than most teams expect going in.
How much of this actually lands on engineering versus IT versus legal?
More than most CTOs expect walking in, and mostly engineering rather than IT or legal. Legal negotiates the contract and reviews vendor paper. Engineering produces almost every piece of technical evidence an auditor actually requests.
Access logs, change history, monitoring configuration, incident tickets. All of it lives in systems engineering owns, which means engineering ends up answering the follow-up questions during the audit walkthrough, not legal, no matter how carefully legal negotiated the underlying contract language.
Can we scope just Security and skip the other four criteria?
Yes, and most first-time companies should. Security alone satisfies the majority of enterprise procurement checklists, and adding criteria you don’t need just adds evidence to produce for something nobody asked about.
Add Availability later if uptime SLAs become a real sales conversation. Add Confidentiality if you’re handling data sensitive enough that customers start asking about it by name in security questionnaires.
What’s the single biggest mistake engineering leaders make in their first cycle?
Timing decides everything, because most leaders wait until the audit is already on the calendar to formalize access reviews and change approvals. By then those habits need to already be running, not starting.
The observation period only counts the months where the control was actually operating, which means a policy written the week before the audit started counts for exactly nothing, no matter how good it reads on paper. Retroactive documentation does not count.
Should the SOC 2 program report to engineering or to security and compliance?
Wrong question, mostly. Reporting lines matter less than whether engineering leadership shows up to the weekly readiness check personally instead of delegating it down and asking for a summary later.
I have seen programs succeed reporting either way. I have never seen one succeed with an engineering leader who treated it as somebody else’s project happening near their team.
