Somewhere around 2022, SOC 2 stopped being a differentiator for SaaS companies and became table stakes. If you sell software to any enterprise with a procurement team worth its salary, someone is going to ask for your SOC 2 report before they sign a contract. This is not news.
What is news — or at least what keeps surprising me — is how badly most SaaS companies prepare for it. They either spend eighteen months and a quarter of a million pounds building a compliance programme from scratch, or they buy a GRC platform they do not need, hire a consultant to fill in templates, and end up with a stack of PDFs that technically satisfy the auditor but teach the organisation nothing about its own security posture.
I have been on both sides of this. As an enterprise architect in financial services, I was the person requesting SOC 2 reports from vendors. I knew what I was looking for, and I could tell within ten minutes whether a company actually understood its controls or had paid someone to manufacture evidence. Now, building HelixGate, I have been through the preparation from the vendor side. The gap between what people think SOC 2 requires and what it actually requires is enormous.
SOC 2 is a framework, not a checklist
This is the single most important thing to understand, and most companies get it wrong immediately.
SOC 2 is built on the Trust Service Criteria (TSC), published by the AICPA. It defines five categories of controls that your auditor will evaluate. But — and this matters — it does not prescribe specific implementations. There is no list of 147 controls you must tick off. The TSC describes principles. Your job is to demonstrate that you have controls in place that satisfy those principles, and that those controls actually work.
This is fundamentally different from something like PCI DSS, which tells you exactly what encryption standard to use and exactly how many days you have to patch a vulnerability. SOC 2 says: prove that you have a reasonable approach to security, and prove that you follow it.
That flexibility is both the good news and the bad news. Good, because you do not need to rebuild your infrastructure to satisfy a rigid specification. Bad, because it means you have to think. You cannot outsource thinking to a compliance checklist.
The five Trust Service Criteria
Every SOC 2 audit covers Security by default. The other four categories are optional, and your auditor will help you decide which ones are relevant. Here is what each one actually means in practice:
Security (Common Criteria)
This is the foundation. It covers logical and physical access controls, system operations, change management, and risk mitigation. If you can answer these questions clearly, you are in reasonable shape: Who has access to what? How do you know? What happens when someone joins or leaves? How do you detect and respond to incidents? How do you manage changes to your systems?
Every SaaS company includes Security. It is not optional.
Availability
This covers your ability to keep systems running. Uptime SLAs, disaster recovery, capacity planning, backup procedures. If your customers depend on your service being available — which, for SaaS, is essentially always — you should include this. Most companies do.
Processing Integrity
This one is relevant if your system processes transactions or calculations that need to be accurate and complete. Payment platforms, financial calculations, data pipelines. If you are a project management tool, you probably do not need this. If you handle money or regulated data transformations, you do.
Confidentiality
This covers how you protect information designated as confidential. Not the same as privacy (which is about personal data). Confidentiality applies to intellectual property, financial data, business plans — anything your customers expect you to keep restricted. Encryption at rest and in transit, access restrictions, data classification.
Privacy
This applies if you collect, store, or process personal information. It maps closely to GDPR principles: notice, consent, purpose limitation, data minimisation, retention, disposal. If you already take GDPR seriously, you have a significant head start here.
SOC 2 does not tell you what to build. It asks you to prove that what you built is governed.
What auditors actually look for
Here is what I wish someone had told me earlier: auditors are not looking for perfection. They are looking for evidence of controls.
The distinction matters. If you had a security incident and handled it properly — detected it, contained it, documented it, reported it, and improved your controls afterwards — that is a positive signal, not a negative one. It demonstrates that your incident response process works. An auditor would rather see a well-handled incident than a company that claims nothing has ever gone wrong.
What they need is documentation. Specifically:
- Policies that describe what you commit to doing
- Procedures that describe how you do it
- Evidence that you actually did it — logs, screenshots, tickets, approval records
The third item is where companies fall apart. It is easy to write a policy. It is easy to document a procedure. Producing evidence that you followed the procedure, consistently, over the entire audit period? That is hard. And it is hard because most companies do not build evidence collection into their daily operations. They try to reconstruct it at audit time.
The governance gap
This is the problem I see over and over again. A SaaS company has decent security practices. Their engineering team uses multi-factor authentication. They review pull requests before merging. They rotate secrets. They have a reasonable incident response plan.
But when the auditor asks to see the evidence, the team scrambles. Who approved this access change? When was the last access review completed? Can you show me the change management record for this deployment? Where is the risk assessment that led to this architectural decision?
The answers exist, scattered across Jira tickets, Slack messages, Git commits, and someone's memory. Assembling them into a coherent narrative takes weeks. And that is for a company that is actually doing the right things. Imagine the company that is not.
The governance gap is not about whether you have good security. It is about whether you can prove you have good security. Those are two different things, and the second one is what SOC 2 actually evaluates.
Building evidence as a byproduct
The approach I took with HelixGate — and the one I recommend to any SaaS company — is to make compliance evidence a byproduct of normal operations, not a separate activity.
Consider access control. Every SaaS platform has roles and permissions. But do you have an immutable audit trail that records every permission change, who made it, when, and why? If you do, you have SOC 2 evidence for access management generated automatically. If you do not, you are going to spend days pulling access change records from database logs at audit time.
Consider change management. Every engineering team uses pull requests. But do you record the approval chain, the deployment timestamp, and the rollback procedure in a way that an auditor can retrieve in five minutes? Or is that scattered across GitHub, your CI pipeline, and a deployment channel in Slack?
In HelixGate, we designed the audit trail to be immutable and comprehensive specifically because we knew from the start that compliance evidence should generate itself. Every state change, every approval, every access modification is logged with the actor, timestamp, IP address, and outcome. The audit trail cannot be modified or deleted. That is not a feature we added for marketing. It is a design decision rooted in the reality that if you cannot produce evidence on demand, your controls are only as good as your team's memory.
Role-based access control with TOTP enforcement, structured approval workflows for business cases and architecture decisions, supplier management with documented review cycles — these all generate audit evidence as a natural consequence of people doing their jobs. Nobody fills in a compliance form. The form fills itself.
Practical timeline: your first SOC 2 audit
If you are starting from scratch, here is a realistic timeline. I am assuming a Type II audit, because that is what enterprise buyers actually care about. A Type I report confirms that your controls exist at a point in time. A Type II confirms that they worked consistently over a period — usually six to twelve months.
Months 1–2: Scoping and gap analysis
Decide which Trust Service Criteria you need. For most SaaS companies, that is Security plus Availability, and possibly Confidentiality. Assess your current controls against those criteria. Identify gaps. This does not require a consultant, but it does require someone who has read the TSC and understands what the criteria actually ask for.
Months 2–4: Remediation
Close the gaps. Write the policies you are missing. Implement the procedures. Set up evidence collection. This is where most companies make their biggest mistake: they buy a GRC tool before they understand what evidence they need. You do not need a £40,000 platform to pass SOC 2. You need your systems to produce records of what they do. If your application already has a proper audit trail and access controls, your remediation work might be smaller than you expect.
Months 4–5: Select an auditor
Choose a CPA firm experienced with SaaS companies. The Big Four are expensive and rarely necessary for a first audit. Mid-tier firms that specialise in technology companies will give you more pragmatic guidance. Talk to at least three. The relationship matters, because your auditor is not your adversary — they are the person who will tell you what you need to fix before the report is issued.
Months 5–11: Observation period
This is the period your auditor will evaluate. Your controls need to be operating consistently throughout. Six months is the minimum most auditors will accept for a first Type II. During this period, keep your evidence flowing. Do not let things slide because "we will clean it up later." Later does not exist in an audit window.
Month 12: Audit and report
The auditor examines your evidence, conducts interviews, tests your controls, and issues the report. If you have been generating evidence consistently, this phase is straightforward. If you have not, this is where the panic starts.
Common mistakes
I will be direct about the patterns I see companies repeat:
Buying compliance tooling before understanding your controls. A GRC platform cannot manufacture governance that does not exist. If your application does not record who changed what and when, no amount of compliance software will fix that. Start with your product architecture. Make your systems produce evidence. Then decide if you need additional tooling on top of that.
Paying consultants to build evidence that should generate itself. If you are paying someone to manually compile access review evidence every quarter, you have an engineering problem, not a compliance problem. Build the access review into your system. Export the report. The cost of automating evidence collection is almost always lower than the cost of paying someone to assemble it by hand, and the result is more reliable.
Treating SOC 2 as a one-time project. Your first audit is a milestone, not a finish line. SOC 2 reports are issued annually. If your evidence collection is manual, you are signing up for annual pain. If it is automated, you barely notice.
Ignoring the observation period. I have seen companies sprint to get controls in place and then relax during the observation window, assuming the hard part is done. The observation period is the hard part. Consistency is what the auditor evaluates. A control that works in month one and slips in month four is worse than a control that was implemented slightly later but maintained throughout.
Scoping too broadly. You do not need to include every Trust Service Criterion in your first audit. Start with Security and Availability. Add more in subsequent years if your customers require it. The scope you choose determines the complexity and cost of the audit. Be strategic about it.
If your evidence collection is manual, you are signing up for annual pain. If it is automated, you barely notice.
The real cost of SOC 2
People always ask what SOC 2 costs. The honest answer is: it depends on how much governance you already have.
The audit itself typically runs £25,000 to £60,000 for a Type II from a mid-tier firm, depending on scope and complexity. But the audit fee is the small part. The real cost is in preparation — the engineering time to build evidence collection, the operational time to maintain controls during the observation period, the management time to write policies and conduct reviews.
If your product already generates compliance evidence as a byproduct of its normal operation — because you designed it that way — your preparation cost is low. You are essentially formatting evidence you already have into the structure your auditor expects.
If your product was built without governance in mind, the preparation cost is high. You are retrofitting evidence collection onto systems that were never designed to produce it. That retrofit is expensive, disruptive, and usually produces evidence that is less reliable than what you get from purpose-built systems.
The cheapest SOC 2 programme is one where the founder or CTO thought about auditability from day one. The most expensive is one where it was bolted on three weeks before an enterprise deal requires it.
What this means for your SaaS company
SOC 2 is not going away. If anything, enterprise buyers are getting more rigorous about it. The companies that treat compliance as an engineering problem — building evidence collection into their products from the start — will spend less, pass audits faster, and build more trust with their customers.
The companies that treat compliance as a procurement problem — buying tools, hiring consultants, manufacturing evidence — will keep spending more every year and wondering why it never gets easier.
If you are early enough in your journey, you have the opportunity to get this right from the start. Build your audit trail. Implement proper RBAC. Record your decisions. Make your systems tell the story of what happened and why.
That is not just SOC 2 preparation. That is good engineering. SOC 2 just happens to reward it.