Perspective

Koora has its SOC 2 Type I report

An independent auditor examined how Koora's security controls are designed and issued an unqualified opinion, no exceptions. What it covers, where the Type II sits, and how it fits Australian law.

5 min read

Koora's SOC 2 Type I report was issued in September 2026, with an unqualified opinion and no exceptions noted. The examination was performed by Advantage Partners against the Security trust services criteria, as at 20 July 2026.

In plain terms: an independent licensed firm went through how Koora's security controls are built, and found they were designed to do what we say they do. Nothing was flagged.

What this is worth to a worker and a provider

Workers and providers both hand Koora the most sensitive workforce data there is, and they hand over different halves of it. A worker gives us their identity documents and work rights, their qualifications and their screening clearances. A provider gives us the credential records it already holds about its own workforce. On top of that sits what Koora produces: ban register screening, expiry tracking, and in time the results of the police checks we run. Until now, the answer to "how do we know your security is any good" was Koora describing its own controls, which is the weakest form of assurance there is. Everyone describes their own controls well.

A SOC 2 report replaces that self-description with somebody else's opinion. The auditor read the description of the system, tested whether the controls stated in it were suitably designed against the criteria, and put their name to the result. That is a different kind of claim, and it is the one a security team is actually asking for.

It is also practical. A vendor security review usually means a questionnaire, a few rounds of email, and a meeting. Most of that is answered inside the report, so the review gets shorter and the answers stop depending on who at Koora happens to reply.

What the report covers, and what it leaves out

A few things are worth knowing before you read it.

The scope is Security. There are five trust services criteria: security, availability, processing integrity, confidentiality and privacy. An engagement picks which of them are in scope, and ours covers security. That is the usual starting scope, and it means the report is silent on the other four. The first question to ask about anyone's SOC 2 report, ours included, is which criteria it covers.

Three subservice organisations are carved out: Cloudflare, Supabase and Vercel, the cloud hosting the platform runs on. Their controls sit underneath ours and were not tested in our examination, so for that layer the report leans on their own reports. Those reports are theirs to give, so we point you at where they live rather than handing them over.

"Subservice organisation" is a narrow term and it is not the vendor list. The report's description of the system also names the sub-processors Koora relies on for identity verification, payments, email, AI, telephony, analytics and error monitoring, and the current register is in the trust centre. Where they sit matters, and the line is a clean one: sensitive compliance and identity data stays in Australia and is never transferred overseas. The database, authentication, storage, edge functions and identity verification all run in AWS Sydney. The overseas providers that handle email, AI, analytics, error monitoring and telephony hold none of it. Anyone assessing Koora should read that split rather than take a single sentence about data residency at face value, ours included.

Why we are not calling this a certification

SOC 2 does not certify anyone. It is an attestation report from a licensed firm, with an opinion, a scope and a date attached. "SOC 2 certified" is a phrase that appears on a lot of websites and in no audit standard, so we say "SOC 2 Type I compliant" or, where there is room for it, "SOC 2 Type I report". We would rather sound duller than sound like something we are not.

Type II is running now, and we are past halfway

A Type I opinion covers the design of controls as at a single date. It says the controls were built right. It does not say they ran, because a Type I engagement performs no procedures on operating effectiveness.

Type II is the one that answers that. It samples a period and tests whether the controls actually operated across it. Ours opened on 21 July 2026 and closes on 21 October 2026, which puts us past the halfway mark as this is published. That report will say whether the controls held up over three months of real operation rather than on one day.

We will publish it in the same shape when it lands, including anything it finds. Naming the result in advance would be the kind of claim this piece exists to avoid.

SOC 2 is an American standard, and we did it anyway

SOC 2 comes from the American Institute of Certified Public Accountants. Our service auditor is in Seattle. No Australian regulator asks a company like Koora for one.

We did it because it is the question serious software companies get asked and are expected to answer, and because the alternative was asking providers to take our word for it. A workforce lead evaluating Koora against a larger vendor should not find that the larger vendor is the only one who can produce a report. Australia has its own frameworks, and they are real, but none of them plays the role SOC 2 plays in a vendor security review. So we went and got the thing the review actually asks for.

The obligations that bind us here are Australian

SOC 2 is not law anywhere. The rules Koora genuinely has to meet are local ones.

The Privacy Act 1988 and the Australian Privacy Principles govern how we collect, use, secure and disclose personal information, including cross-border disclosure and a person's right to reach their own data and correct it. The Notifiable Data Breaches scheme sits alongside them and sets what happens if something goes wrong.

Then there is the ACIC. Koora Care Pty Ltd has been an accredited body under the Australian Criminal Intelligence Commission's National Police Checking Service since July 2026. That accreditation is granted by a Commonwealth agency against its own requirements, under an access agreement with binding obligations attached. In the areas it covers it is more prescriptive than a SOC 2 examination: an auditor tests whether the controls you described were suitably designed, while the ACIC tells you what the control has to be, down to how long a record may exist before it must be destroyed. In-platform National Police Checks are being switched on.

Read together, that is the shape of it. Australian law and a Commonwealth accreditation set what Koora must do. The SOC 2 report is independent evidence about how we do it.

What none of this tells you

No SOC 2 report of any type says whether Koora's compliance verdicts are right.

SOC 2 is about how we run the system that holds the data: access control, change management, monitoring, incident response. It has nothing to say about whether a worker's working with children check was genuinely confirmed against the state portal, whether the compliance engine's rule for a role is correct, or whether "reviewed" and "verified by Koora" mean what we claim they mean. Those are answered by the difference between reviewed and verified and by what the engine actually checks.

Both questions matter and they are not the same question. A vendor waving a SOC 2 report at one about credential accuracy is answering the other.

Getting the report

SOC 2 reports are restricted-use documents. The specified parties are customers, prospective customers, business partners, regulators and their auditors, which is why nobody publishes one as an open download.

Ours sits in the trust centre alongside the sub-processor register and the control set, and customers and prospective customers can request it there. If your security team wants to go deeper than the report, we will go as deep as they want.

Related reading: security and privacy on your Career Passport, reviewed vs verified, and the AICPA's own explainer on SOC for Service Organizations.

This is general information, not compliance advice. Always confirm requirements with the relevant regulator, and remember that providers keep the legal responsibility to sight credentials and decide who can work.

We work hard to keep everything accurate, and our compliance engine keeps up with the rules as they change. Even so, we might get a detail slightly wrong or miss something. No one's perfect. If you think something here needs updating, email us at resources@koora.care. We would genuinely rather know, because we all do better when we help each other get it right.

Bring your compliance into one place

See how Koora keeps your workforce credentials checked, current and audit-ready. Your first five workers are free.