How We’re Approaching SOC 2 and ISO 27001 as an Integration Vendor (And What to Ask Yours)

If you hand us your integration, you hand us your employees’ tax file numbers, bank accounts, salaries, and leave records. We think that deserves a straighter conversation about security than the industry usually has.

Most vendor security pages are a wall of badge logos and the sentence “security is our top priority.” This post is the opposite of that. We’ve been SOC 2 certified for four years now, and this is an honest account of what those four years actually looked like — the manual grind of our early audits, the GRC tool that sank underneath us after an acquisition, the findings in our own reports that we’re not proud of, and why we’re now rebuilding the whole program as a combined SOC 2 + ISO 27001 effort on modern automation. 

And because we fill out security questionnaires for a living (every enterprise deal comes with one, and they range from thoughtful to theatrical), it ends with the questions we believe you should ask any integration vendor — including us. Especially us.

Why an integration vendor’s security posture matters more than most

An integration platform occupies an unusual position in your architecture: we’re not the system of record for anything, but the most sensitive data in your company flows through us. Employee PII, banking details, TFNs, super fund information — the payload of an HR-to-payroll sync is essentially a continuously updated file of everything an identity thief could want.

That makes an iPaaS vendor a concentrated target and a classic supply-chain risk. You can run the tightest security program in the country internally and still be exposed through a connector vendor with an API key stored in plain text. Procurement teams know this, which is why the questionnaires keep getting longer — and honestly, they should.

So when we say we’ve held SOC 2 for four years and are now adding ISO 27001 alongside it, it’s not badge collection. It’s the entry fee for asking enterprises to trust us with this category of data, and we think any vendor in our position who treats it as anything less is telling you something.

Why both frameworks, and why together

SOC 2 and ISO 27001 get lumped together, but they prove different things. 

ISO 27001 certifies that you run a management system for information security — that risk assessment, policy, and continuous improvement are institutionalised, not ad hoc. 

SOC 2 Type 2 is an audit of whether your controls actually operated over a monitoring period — not “do you have an offboarding policy” but “show me evidence that every departure in the last six months had access revoked on time.”

For our customer base, the split is practical: Australian and European enterprises tend to anchor on ISO 27001; US-headquartered companies and their subsidiaries ask for the SOC 2 report. And because we serve UK customers too, we’re adding Cyber Essentials Plus to the program — the UK government-backed scheme whose Plus tier requires independent hands-on technical verification, not just a self-assessment, and which UK enterprises and public-sector buyers increasingly treat as table stakes. 

Running the programs together makes sense because the control set overlaps heavily — the same access reviews, encryption standards, incident response drills and vendor management feed all three. Doing them sequentially means paying the organisational cost multiple times.

The honest part: certification is a milestone, not a state of grace. A SOC 2 report tells you the controls operated during the audit window. What matters is whether the machinery that produced that result keeps running the week after the auditor leaves. That’s the thing we’re actually trying to build

Four years of SOC 2: what the first generation actually looked like

Our first SOC 2 audits were done with AssuranceLab (since acquired by Sensiba) — good people, reasonable brands, and a process that was, in the way of that era of compliance, almost entirely manual. Every single piece of evidence was copy-pasted by hand from our internal systems into a shared Trello board for the auditors: screenshots of access reviews, exports of configuration settings, one card at a time. We maintained a GRC tool alongside — Tugboat Logic — but the audit itself still ran on human copy-paste.

That worked, in the sense that we got certified and stayed certified. But it taught us the first hard lesson of compliance operations: a manual evidence process measures your ability to assemble evidence, once a year, under deadline pressure. It doesn’t continuously measure whether your controls are actually operating. The gap between those two things is exactly where findings live.

The second hard lesson came from the tooling itself. Tugboat Logic was acquired by OneTrust — and in our experience as a paying customer, the product then went quiet. Years with essentially no meaningful updates, a roadmap that visibly belonged to the acquirer’s larger platform, and now the product being wound down and folded into OneTrust proper. That’s a sinking ship, and we’re taking the way off it.

There’s a broader lesson in that for anyone buying compliance tooling — or any SaaS, frankly: when your vendor gets acquired, you haven’t just changed logos on an invoice; you’ve inherited a new roadmap you didn’t choose. Sometimes acquisition means investment. Sometimes it means your product becomes a migration funnel into something bigger. Watch the release notes for six months after any acquisition; they’ll tell you which one you got. (We build integrations for a living — we’ve watched this movie from every angle.)

What the next-generation program looks like

So the program we’re building now — combined SOC 2 Type 2 and ISO 27001 — is designed around everything those four years taught us. We’ve been deep in evaluation conversations with the current generation of GRC automation platforms and with auditors, and the selection criteria are blunt:

Evidence must be pulled, not pasted. The platform connects directly to our stack — identity provider, cloud infrastructure, code repositories, HR system — and collects evidence continuously from the source systems via API. When a control drifts (an access review slips, an offboarding step is missed, an encryption setting changes), the system flags the inconsistency in days, not at the annual audit. After four years of Trello archaeology, this is non-negotiable.

The auditor must work natively in the tool. Continuous evidence collection is pointless if the audit firm then asks you to re-export everything into their portal. Part of our auditor conversations is exactly this: will you consume evidence from the platform directly, so that monitoring and audit are the same living system rather than an annual translation exercise?

Cost has to reflect the automation. A combined SOC 2 + ISO 27001 program is a meaningful annual spend for a company our size — platform subscription plus audit and certification fees. The entire economic argument for automation is that the same control set feeds both frameworks and the evidence collects itself; we’re pricing every option against that promise, not against the badge.

But we’ll say the quiet part out loud: the compliance automation industry has a credibility problem. There have been well-publicised controversies about platforms and vendors gaming evidence — and the uncomfortable truth is that automated compliance tooling makes it easier to look compliant exactly as much as it makes it easier to be compliant. The tooling is neutral; the integrity lives in how you use it.

Our position on that is simple. Evidence should come from source systems via API, not from screenshots. The auditor should be independent and accredited — a real audit firm issuing the SOC 2 report, an accredited certification body for ISO 27001, not an entity with a commercial interest in passing us. And when a control fails, the failure, the remediation, and the timeline should be documented rather than massaged.

Our findings are in the report — and that’s the point

Here’s the part most vendors will never write down. Across four years of SOC 2 audits, we have been caught out. There are findings in our past reports — controls that weren’t followed the way our own policies said they should be. Human failures, mostly: a process step skipped, a review done late. We are not proud of them.

They are also right there, in black and white, for anyone who requests our SOC 2 report to read. They have led to genuinely uncomfortable conversations with prospects — sitting across from a security reviewer explaining why a documented process wasn’t followed is nobody’s favourite meeting.

But this is exactly what the framework is for. Every one of those findings triggered a review: why did the process fail, was the process itself badly designed, what changes — automation, ownership, checklists — prevent the recurrence. Some of our most robust current controls exist because an earlier version of them failed on the record. A security program with zero recorded exceptions across four years isn’t a clean program; it’s a fictional one, or an unaudited one. We’d rather hand you a report with honest findings and documented remediations than a spotless PDF you shouldn’t believe.

What certification doesn’t prove (from someone paying for it)

We’d rather you evaluate us — and every vendor — with clear eyes, so here’s what the badges genuinely don’t tell you.

They don’t tell you the scope. A SOC 2 report can cover one product, one environment, or one office; the marketing logo looks identical either way. They don’t tell you how the vendor handles the specific data flow you care about — certification is about the program, not your integration. They don’t tell you about the subprocessors underneath, each of which is its own link in the chain. And they don’t tell you what happens at 2 am when something breaks — recovery capability is asserted in documents and proven only in incidents and tests.

Which is exactly why the questionnaire matters more than the badge, and why we’d rather arm you with better questions than better logos.

What to ask your integration vendor (the questionnaire we’d want to receive)

These are the questions that separate vendors with a real program from vendors with a nice PDF. Ask them of anyone touching your employee data — including us.

1. Show me the report, not the logo. Ask for the actual SOC 2 report under NDA and read the scope, the exceptions, and the auditor’s name. Ask for reports across multiple years — a multi-year history with documented remediations tells you far more than a single clean year. For ISO 27001, ask for the certificate and the Statement of Applicability scope. If a vendor is mid-certification on either framework, ask for target dates and what’s in place today — a straight answer to that question tells you plenty.
2. Where does my data live, and where does it transit? Region, cloud provider, and whether data residency commitments are contractual or aspirational.
3. Who are your subprocessors? Ask for the full register, what each one sees, and how you’ll be notified when it changes. An integration vendor who can’t produce this quickly doesn’t have one.
4. How are credentials to my systems stored and scoped? OAuth tokens and API keys to your HR and payroll platforms are the crown jewels. Encrypted at rest where, rotated how, accessible to whom, scoped to the minimum permissions or grabbed as full-admin?
5. What data do you retain, and for how long? A sync engine doesn’t need to keep your employee data forever. Ask what’s stored versus passed through, and what deletion looks like when you leave.
6. What are your tested RTO and RPO? Not the numbers in the policy — the numbers from the last actual recovery test, and when that test was run.
7. When did someone last try to break in? Date of the last independent penetration test, whether findings were remediated, and whether they’ll share the summary letter.
8. What’s your breach notification commitment? In hours, in the contract — and how it interacts with your own obligations under the Notifiable Data Breaches scheme.
9. How does access to customer data work internally? Least privilege, MFA everywhere, joiner-mover-leaver process, and whether support staff can see production payroll data as a matter of routine or by exception with logging.
10. What happened during your last incident? Every real company has had something. A vendor who says “we’ve never had a security incident” either isn’t looking or isn’t telling. The quality of the answer matters more than the cleanliness of the record.

If a vendor answers these quickly, specifically, and in writing, you’ve learned more than any badge can tell you. If they stall, you’ve also learned something.

Where we are, plainly

Four years SOC 2 certified, reports available to customers and prospects under NDA — findings, remediations and all. Now mid-transition to a combined SOC 2 Type 2 + ISO 27001 program, with Cyber Essentials Plus alongside for our UK customers, built on continuous, API-driven evidence collection, with a GRC platform and auditor selected for how well they work together rather than how good the badge looks. The underlying practices — encryption in transit and at rest, least-privilege access, MFA-enforced identity, credential vaulting, and a maintained subprocessor register — operate today and predate whichever logo sits on the website next.

For the curious: the GRC platform evaluation was a proper bake-off. We looked hard at Vanta, Drata, Sprinto and ComplyJet — demos, trials, pricing negotiations, the lot — and the process taught us as much about how compliance vendors sell as it did about how they automate. We’ll publish a detailed comparison of the four in an upcoming post, including the pricing structures we were offered, where each platform genuinely shines, and why we ultimately landed where we did. If you’re a SaaS company staring down the same decision, that post will save you a month of demo calls.

Our standing offer is the same one we make in every enterprise deal: send us the hard questionnaire. We’d rather earn trust question by question than ask for it logo by logo.