A large customer has made a SOC 2 report a condition of the contract, and nobody on your team has been through one. The first thing worth knowing is that SOC 2 is not a product certification and there is no list of features that makes an application compliant. It is an independent examination of controls that your organization defines, documents, and then demonstrably operates. Two companies running very different stacks can both come out of an audit with a clean report, because the auditor is testing whether you do what you said you do.
Most of the work is not in the code
Teams tend to assume a SOC 2 request is an engineering project. In practice, the majority of the effort in a first audit is organizational. Someone has to own security. Policies have to exist, be approved, and be acknowledged by staff. Onboarding and offboarding need a defined process with a record. Risk has to be assessed on a stated cadence. Vendors that touch customer data need to be inventoried and reviewed. None of that is a pull request.
The second surprise is that evidence matters as much as the control. A control that exists but produces no record is difficult to evidence, and one that is applied inconsistently is worse than one that is narrowly scoped and followed every time. This is the single most useful lens for an engineering team: prefer controls that generate their own trail as a by-product of normal work, and be conservative about what you commit to operating.
- Name an accountable owner for security before you name a target date.
- Write down what you actually do today, then decide what to change, not the reverse.
- Prefer fewer controls you can operate every time over a broad set you follow occasionally.
- Assume every commitment will be sampled across the whole observation window.
The parts that land on the application
A meaningful share of the work does reach the product and the pipeline that delivers it. The table below is a practitioner's summary of the areas where engineering usually has to do something, and what each one tends to mean in a codebase. The specific criteria in scope for your report are for your auditor to set.
| Control area | What auditors typically look for | What it means for your codebase |
|---|---|---|
| Access control and least privilege | Evidence that access is granted by role, approved, and reviewed periodically. | Authorization resolved in one well-tested place rather than scattered through screens, with roles that map to real job functions. |
| Joiners, movers, and leavers | A record that access was provisioned on hire and removed promptly on departure. | Deactivation that revokes sessions, tokens, and API keys (not just a flag on a user row), plus a way to list who has access today. |
| Change management | Changes are reviewed, tested, approved, and traceable from request to deployment. | Enforced pull request review, protected branches, a CI pipeline that gates merges, and a deployment record tying releases to commits and tickets. |
| Logging and monitoring | Security-relevant events are captured, retained, and actually watched by someone. | Structured application and infrastructure logs, alerting with a defined recipient, and retention that survives a redeploy. |
| Encryption in transit and at rest | Customer data is protected on the wire and on disk, with managed keys. | TLS enforced end to end, managed encryption on databases, object storage, and backups, and no unencrypted data copies in analytics or support tooling. |
| Backup and restore | Backups run on schedule and restoration has been tested, not assumed. | A documented restore procedure that someone has executed into a non-production environment, with the result written down. |
| Vendors and subprocessors | An inventory of third parties handling customer data, with periodic review. | Knowing which services your application actually calls in production, including the ones added quietly during a sprint. |
| Incident response | A defined process, exercised rather than only written. | On-call routing, a severity definition, and a place where incidents and their follow-up actions are recorded. |
Read down the third column and a pattern appears. Almost none of these ask for a new feature. They ask for existing behavior to be consistent, centralized, and observable. That is why teams with disciplined delivery practices find the audit unremarkable, and teams that deploy from a laptop find it expensive.
Type I, Type II, and why the calendar rules the timeline
A Type I report speaks to whether your controls are suitably designed at a point in time. A Type II speaks to whether they operated effectively across a period of observation. Enterprise buyers usually want the second one, and often accept a Type I as an interim signal while the observation period runs.
This is the part that most often disrupts a sales timeline. Once your controls are in place, the observation window has to elapse. Engineering cannot compress it, and neither can budget. If a customer needs a Type II report by a particular date, work backwards from that date to when controls must be live, and have that conversation with your auditor early rather than discovering the constraint late.
Engineering practices that make an audit boring
The teams that get through an audit with the least disruption are not the ones that prepared hardest. They are the ones whose normal way of working already produced the evidence. Four practices carry most of that weight.
Code review as a gate, not a courtesy
Required review on protected branches means every change already has an approver, a timestamp, and a discussion attached. That is change management evidence generated by work you were doing anyway. Direct pushes to the main branch destroy it.
A deployment pipeline with a trail
Automated checks that must pass before merge, and deployments triggered by the pipeline rather than by a person with production credentials, answer two questions at once: was the change tested, and who released it. Manual deployment is not only riskier, it is harder to evidence.
Real environment separation
Distinct development, staging, and production environments with separate credentials keep the blast radius small and make the access story simple to explain. The related habit matters just as much: keep production customer data out of lower environments, because a copied database undoes a great deal of careful control design.
Infrastructure as code
When environments are defined in version-controlled configuration, infrastructure changes go through the same review as application changes and the current state is readable rather than reconstructed from a console. It also makes drift visible, which is the quiet failure mode behind a surprising number of security gaps.
Cost, effort, and a sensible order of operations
Budget for four distinct things: the audit firm, compliance tooling if you use it, internal time, and engineering remediation. Internal time is the line most often underestimated. A first audit consumes meaningful attention from whoever owns it, and that person usually has another job. Figures vary widely by scope, region, and firm, so get quotes rather than working from a number you read somewhere.
Engineering remediation cost tracks how far your current practices sit from the ones above. A team already reviewing code, deploying through a pipeline, and running managed infrastructure may need little more than tightening access reviews, retention, and documentation. A team deploying by hand onto long-lived servers is looking at a delivery modernization project wearing a compliance label, which is worth doing on its own merits but should be scoped and funded as what it is.
- 1
Ask the customer what they actually need and by when: a Type I, a Type II, or a completed security questionnaire.
- 2
Engage an audit firm early and agree the scope: which systems, which trust services categories, and which observation period.
- 3
Inventory what exists today: access paths, environments, vendors touching customer data, and where that data lives.
- 4
Fix the engineering gaps that are also good practice: review gates, pipeline deployments, environment separation, tested restores.
- 5
Write policies that describe what you will genuinely do, then operate them consistently through the observation window.
- 6
Treat the report as a starting point. Controls have to keep running afterward, and the next report covers the next period.
One last framing that helps. A SOC 2 request from an enterprise customer is not a hostile act; it is that customer's own risk process reaching your company. Most of what it asks for (knowing who has access, reviewing changes before they ship, being able to restore your data, noticing when something breaks) is what you would want in an operationally serious business regardless. The audit sets a deadline for work that was already worth doing.
Common questions
- Does SOC 2 require us to rewrite our application?
- Almost never. The controls that reach engineering concern access, change management, logging, encryption, backups, and incident handling rather than product features. Rewrites become part of the conversation only when the existing architecture makes those controls impractical to operate, such as an application with no meaningful role model or no way to deploy without manual production access.
- Should we do a Type I first or go straight to Type II?
- That depends on what your customer will accept and how quickly they need it, and it is a decision to make with your auditor. A Type I can serve as an interim signal because it speaks to a point in time, while a Type II requires an observation period to elapse. Some teams do both; others go directly to Type II when the timeline allows.
- Can compliance automation tooling handle this for us?
- Tooling helps considerably with evidence collection, policy templates, and continuous monitoring of connected systems. It does not decide your scope, operate your controls, or replace the audit firm. Teams that expect a platform to produce compliance on its own usually discover the gap during fieldwork.
- What is the single most common gap you see in engineering?
- Untested backups, closely followed by production access that was granted for a legitimate reason and never removed. Both are cheap to fix and awkward to explain. Restoring a backup into a non-production environment and writing down the result is a good first afternoon of work.
- We use a lot of third-party services. Is that a problem?
- Not inherently, but you need to know which ones handle customer data and be able to show that you review them. The practical difficulty is usually inventory rather than risk, because services get added during delivery without a central record. Establishing that list, and a rule for adding to it, is worth doing before an auditor asks.
- How does this affect how fast we can ship?
- Well-designed controls should cost you very little day to day, because review gates and pipeline deployments are practices strong teams already use. Velocity suffers when controls are bolted on as manual approval steps outside the tools engineers work in. Push the process into the pipeline wherever you can, so following it is the path of least resistance.