SOC 2 for engineering teams: what the auditor will ask for

SOC 2 arrives the same way at most startups: a large customer's security team sends a questionnaire, and somewhere in it is the line "please provide your SOC 2 Type II report". The framework can look like paperwork, but most of the work lands on engineering, because most of the controls are about how you build, change and access production.

The good news is that the controls are reasonable. If your team already reviews code, uses SSO and keeps audit logs, you are a good part of the way there. The work is closing the gaps and, above all, being able to prove that the controls ran.

Type I, Type II and the trust criteria

• A SOC 2 report is issued by an independent CPA firm against the AICPA's Trust Services Criteria.
• Security, also called the common criteria, is always in scope. Availability, confidentiality, processing integrity and privacy are optional; add them only when customers ask for them.
• A Type I report says your controls are designed properly at a point in time. A Type II report says they operated effectively over an observation period, typically three to twelve months.
• Enterprise buyers usually want Type II. Many companies do a Type I first to unblock deals while the Type II observation period runs.

Because Type II looks back over a period, the controls need to be running before the window starts. That is why readiness work comes first: you cannot retroactively produce three months of access reviews.

Access control

This is where auditors spend the most time, and where engineering teams have the most to fix. Expect to show:

• Single sign-on with MFA for the cloud console, source control, CI and every production system.
• Least-privilege roles instead of shared admin accounts, and no long-lived access keys for people.
• Quarterly access reviews, with a record of who reviewed what and what was removed.
• Onboarding and offboarding that follow a checklist, with access removed promptly when someone leaves — the auditor will sample leavers and check the dates.
• A controlled path for production access, such as just-in-time elevation, with a log of who used it and why.

Change management

Auditors want to see that every change to production was reviewed and tested, and that nobody can bypass the process quietly. A modern delivery pipeline already does most of this, as long as it is enforced rather than conventional:

• Branch protection on main: required pull request review by someone other than the author, and required status checks.
• Deployments only from the pipeline, never from a laptop, with infrastructure changes in Terraform going through the same review.
• A record that links each deployment to its pull request and approver — most CI systems give you this for free.
• A documented emergency path for hotfixes, with a review after the fact.

If you already work this way, the main task is turning settings into evidence. If you do not, it is also the change that pays off most outside the audit — see how we cut deployment lead time without giving up review.

Logging, monitoring and incident response

• Audit logs from the cloud provider and key systems, retained for at least the observation period and protected from deletion.
• Alerting on security-relevant events, with someone clearly responsible for responding.
• A written incident response plan, and evidence that you followed it — or a tabletop exercise if nothing happened.
• Backups that are tested by restoring them, not just configured.

Vulnerability management

Show that you find vulnerabilities and fix them within a defined time. Dependency and container image scanning in CI, a regular scan of cloud configuration, and a policy that says how quickly critical and high findings must be resolved cover most of it. Many auditors also expect an annual penetration test. For Kubernetes, the five mistakes we see in every cluster audit are a good place to start hardening.

Secrets and data protection

Keep secrets in a secrets manager, not in repositories, CI variables copied by hand, or environment files on laptops. Encrypt data at rest and in transit, which on the major clouds is mostly a matter of turning it on and proving it is on everywhere. Know where customer data lives, and make sure test environments do not quietly contain copies of production data.

Evidence is the real work

During a Type II audit you will be asked for samples: a list of all changes in the period, then proof of review for twenty of them; a list of leavers, then proof their access was removed. Collecting this by hand is miserable. Compliance automation platforms such as Vanta, Drata or Secureframe connect to your cloud, identity provider and source control and gather much of it continuously. They help a great deal, but they report on controls — they do not implement them. The engineering still has to happen.

Codifying controls helps too. When IAM boundaries, logging and encryption are Terraform modules, the evidence that every account follows the policy is the code and its plan output.

A realistic order of work

1. Pick an auditor and a compliance platform, and agree the scope: which systems, which trust criteria.
2. Run a gap assessment against the criteria and rank the gaps by effort and risk.
3. Fix access first: SSO, MFA, least privilege, offboarding.
4. Enforce change management in source control and CI.
5. Centralize logging and secrets, and add scanning to the pipeline.
6. Write the policies to match what you actually do, then start the observation period.

That is the shape of our security and compliance work, and it is how we took a healthtech startup to SOC 2 readiness in eight weeks. If an enterprise deal is waiting on your report, get in touch.