Running SOC 2 and KY3P as an Engineering Manager

When I took on SOC 2 Type II at Schema App, there was no existing compliance program. No gap analysis, no control documentation, no relationship with an auditor. The board wanted certification, and it landed on my desk because I was the engineering leader closest to the infrastructure.

Most engineering managers I know treat compliance as something that happens to them. An auditor shows up, someone from legal sends a spreadsheet, and you spend two weeks finding evidence for controls you didn't know existed. I decided to run it differently.

Starting from zero

The first thing I did was a gap analysis against the SOC 2 Trust Services Criteria. Not the simplified version you find in blog posts, but the actual AICPA criteria mapped to our infrastructure. We had decent practices in some areas (access controls were reasonable, we had monitoring) and significant gaps in others (no formal incident response plan, no documented change management, logging retention was inconsistent).

I mapped every gap to an owner on the engineering team. Not “the engineering team is responsible” but “Sarah owns the incident response runbook and it's due in three weeks.” That level of specificity matters because compliance work is the easiest thing to deprioritize when a production issue comes in.

Getting the team to actually care

Nobody wakes up excited about compliance documentation. The way I got my team to engage with it was by connecting each control to something they already cared about. Access review? That's the same principle as least-privilege in your infrastructure code. Change management? That's the PR review process you already follow, just documented. Incident response? You already do postmortems, we're just making the process explicit.

Once people saw SOC 2 as a formalization of good engineering practices rather than a bureaucratic checkbox, resistance dropped. Not to zero, but enough that the work moved forward.

Managing the auditor relationship

I chose to manage the auditor relationship directly rather than delegating it to someone in operations. This meant I was on every call, reviewed every evidence request, and knew exactly where we were strong and where we were stretching. Some managers might see this as a waste of their time. I found it was the fastest way to unblock the process and avoid surprises.

The auditors were thorough but reasonable. They cared about evidence of consistent practice, not perfection. A control that you follow 95% of the time with documented exceptions is better than a control that you claim to follow 100% of the time but can't prove.

KY3P for US banking clients

Around the same time, we started getting KY3P (Know Your Third Party) questionnaires from US banking customers evaluating Schema App as a vendor. KY3P is a standardized third-party risk assessment used heavily in financial services. The questions overlap with SOC 2 in places but go deeper on data residency, business continuity, and subprocessor management.

Having the SOC 2 program in place made KY3P significantly easier. About 60% of the KY3P responses could reference SOC 2 controls directly. The remaining 40% required new documentation, mostly around data flow diagrams and disaster recovery specifics. We built a response template that we could adapt per customer, which cut the time per questionnaire from weeks to days.

What compliance taught me about management

Running compliance end to end changed how I think about engineering management. It forced me to document things that should have been documented already. It gave me a clearer picture of who on the team owned what. And it built trust with the executive team because I could show them exactly where we stood at any point.

The engineers who worked on compliance controls with me are better engineers for it. They think about audit trails when they design systems now. They write change management into their PRs without being asked. That's the part that doesn't show up in the certification but matters more than the badge.