You Can’t Get “SOC 2 Certified”
What We Actually Delivered for a Digital Health Platform’s US Launch
A look at the most common misunderstandings in US market compliance, why the Trust Services Criteria you choose decide the size of the job, and how we scoped SOC 2 Type II for a digital health platform without dragging the whole company into the audit.
If you’ve spent any time near US enterprise procurement, you’ve heard someone ask for a “SOC 2 certificate.” Sales teams put it on their website. Job ads list it as a requirement. Almost everyone says it. And almost everyone is, technically, wrong.
It’s a report, not a certificate
SOC 2 doesn't produce a certification in the way ISO 27001 does. There's no accreditation body standing behind it and no official register you appear on. You can get a badge, usually issued by your auditor or compliance platform, that you're free to display on your website, but that badge is marketing collateral, not the deliverable. The actual output of the engagement is a report: an independent CPA firm's written opinion on whether your controls are suitably designed and, for a Type II, whether they actually operated effectively over a period of time, usually six to twelve months.
SOC 2 is an opinion, not a pass or fail. There’s no certificate to hang on the wall, only a report your customers will actually read.
That distinction matters more than it sounds like it should. A certificate is binary, you have it, or you don’t. A report has nuance: an auditor can issue a clean opinion, a qualified opinion, or note specific exceptions against specific controls. Customers who know what they’re doing will read the report itself, not just ask whether you “have SOC 2.” So when we took on this work for the client, the goal wasn’t to tick a box. It was to make sure the report itself, warts and all, would stand up to a careful reader on the other side.
The pillars decide the size of the job
The other thing people miss is that SOC 2 isn’t one fixed list of controls. It’s built around five Trust Services Criteria, think of them as pillars, and you only report against the ones that are relevant to what you do. Security is the one mandatory pillar. Everything else is a scoping decision, and that decision has a real effect on how much work you’re signing up for.
Security: the baseline. Access control, network security, and change management are the fundamentals every SOC 2 report includes.
Availability: relevant if customers care about uptime commitments. Brings in monitoring, incident response and capacity planning evidence.
Processing Integrity: relevant if your system processes data that has to be complete, accurate and timely, common for platforms handling clinical or financial data.
Confidentiality: relevant where specific data is contractually designated as confidential, on top of general security.
Privacy: The heaviest pillar to add, and the one most often confused with GDPR. It covers how personal information is collected, used, retained and disclosed. Whether you need it isn't decided by whether you already have a GDPR programme, GDPR compliance is something you assert about yourself, whereas SOC 2's Privacy criteria means an independent auditor has tested and confirmed those controls actually operate as designed. The two aren't substitutes for each other, which is why some organisations end up needing both.
For the client, all five Trust Services Criteria went in scope, not just the mandatory Security pillar. Given the platform monitors patients in something close to real time and handles genuine health data, Availability, Processing Integrity, Confidentiality and Privacy all mattered to the customers driving the requirement, and leaving any of them out would have created a gap in exactly the areas a healthcare buyer asks about first. On top of the five criteria, we also built in a HIPAA bolt-on, mapping the same control set against the HIPAA Security and Privacy Rule so the engagement could demonstrate HIPAA alignment alongside SOC 2, rather than running a second, separate exercise for the US healthcare customers who ask about it specifically. Scoping in everything that was genuinely relevant, rather than trimming pillars to save time, is what made the report hold up to the kind of buyer who reads past the cover page.
Scoping the boundary, not the whole company
Once the pillars were set, the next question was what actually sits inside the audit. The client’s platform spans multiple products and country-specific configurations, and the instinct in a lot of organisations is to put everything in scope out of caution. We didn’t do that. The US customers driving this requirement only cared about the systems that touch their data, so that’s what went in the boundary; corporate IT and country deployments with no US footprint stayed out.
The client’s infrastructure sits on Google Cloud Platform, and a Type II report has to be honest about where the client’s responsibility ends and a vendor’s begins. We used the standard carve-out approach: Google’s own SOC 2 report covers the infrastructure layer, and the client’s report focuses on what the client controls on top of it. We also spelt out clearly what customers themselves are responsible for, so nobody downstream is left guessing.
Twelve months is a long time to stay consistent
A Type II isn’t a snapshot, it’s a report on how controls behaved over an observation window, and the client ships product on an agile cycle. The control environment in month one of the window looked different to month nine. Rather than scrambling to reconstruct a year of evidence right before the audit, we built evidence collection into the cadence the client already had: quarterly, tied to existing change management and access review cycles, with a check-in at the midpoint of the window specifically to catch anything drifting before it became a finding.
The client also already held ISO 27001, and there was no reason to prove the same things twice under two different names. We mapped ISO 27001’s existing controls directly onto the relevant Trust Services Criteria, so the bulk of the evidence, access reviews, risk assessments, and incident records was produced once and reused, rather than collected in parallel for two separate audits.
Where it landed
The report came back clean on the first attempt: no exceptions against any tested control, across all five Trust Services Criteria plus the HIPAA bolt-on. The audit boundary stayed proportionate to the actual US commercial requirement rather than ballooning into a group-wide exercise. Roughly three-quarters of the evidence came straight out of the existing ISO 27001 programme, and the crosswalk we built for this engagement, HIPAA mapping included, now speeds up how every subsequent framework gets scoped against the client's ISMS.
If you’re heading into a US deal and someone’s asked you to “get SOC 2 certified,” the honest first conversation is usually about what that actually means, which pillars you genuinely need, and what a boundary that matches your real risk looks like, rather than the biggest one you can imagine. That’s usually where the time and the budget get saved.
Contact Us
If you're weighing up SOC 2, ISO 27001, or both, we can help you scope the work to what your customers and contracts actually require.
Get in touch with Periculo to talk through your compliance roadmap before you commit budget to the wrong audit.
