Compliance software is not a compliance function
By Joe Zhou ยท
Software automates the tasks. Someone still has to own the outcome.
For the last few years the compliance industry has been focused on automation. Connect your cloud environment. Collect evidence automatically. Monitor controls. Generate policies. Draft security questionnaire responses.
All of that is useful. But there is a pattern I keep seeing in growing AI and technology companies: they have compliance software, and they still do not have anyone running compliance.
The dashboard tells you a control has failed. It does not decide how urgently it needs to be fixed. It flags missing evidence. It does not chase the right people, judge whether the evidence is sufficient, or explain it to an auditor. It drafts an answer to an enterprise security questionnaire. Someone still has to stand behind that answer.
And when an enterprise customer asks a hard question about your AI architecture, data handling, model providers or governance, somebody has to make a judgement.
That gap between automation and accountability is why we built Complyd around a different model.
The virtual compliance officer
A virtual compliance officer is not another dashboard. It is an accountable compliance function for companies that need to earn enterprise trust but are not ready, or do not need, to build an internal compliance team.
In practice that means we take ownership of:
- ISO 27001 and ISO 42001 readiness
- enterprise security reviews
- evidence and control management
- customer and vendor due diligence
- risk management
- internal and external audit preparation
- certification body coordination
- AI governance
- ongoing compliance operations
The goal is not to produce more compliance activity. The goal is to make sure the work gets done.
Compliance becomes urgent at exactly the wrong time
Most technology companies do not wake up one morning and decide they would like an ISMS. The trigger usually looks more like this. A major customer sends a security questionnaire. Procurement asks whether you are ISO 27001 certified. A bank or a hospital wants to understand how you govern AI. An investor asks for evidence during due diligence. An auditor wants records nobody can immediately locate.
Suddenly the CTO, the engineering lead or the founder becomes the compliance team. And it usually happens at the point the company is trying to move faster.
That is the contradiction. The bigger the opportunity, the more trust the customer requires, and satisfying those requirements pulls your best technical people away from the work that created the opportunity.
Compliance should not become a tax on engineering velocity.
Enterprise trust is the outcome
The industry talks too much about compliance itself. Customers rarely care how many policies you have. They care whether they can trust you.
Can you protect their information? Do you understand your risks? Are your controls actually operating? Can you explain how your AI systems are governed? Can you demonstrate that what you say is supported by evidence? Can their procurement, security and risk teams approve you?
ISO certification, security reviews and AI governance are mechanisms for answering those questions. The outcome is enterprise trust, and for a growing technology company that is now part of the infrastructure required to sell.
Software is part of the answer
This is not an argument against compliance platforms. Automation is valuable when it removes repetitive work. A good system collects evidence from your stack, monitors controls, organises documentation and reduces the manual effort involved in demonstrating compliance. We use automation wherever it makes sense.
The distinction is what sits above it. Think of the compliance stack in three layers.
| Layer | What sits there | Who owns it |
|---|---|---|
| Systems | Cloud infrastructure, repositories, ticketing, vendors, documentation, business systems | Your engineering and operations teams |
| Automation | Evidence collection, control monitoring, workflow reminders, questionnaire assistance | Your compliance platform |
| Ownership | What matters, what gets fixed first, whether you are audit ready, how to answer this customer, whether this evidence proves the control, how the requirement applies to your AI architecture, who keeps the program moving after certification | Nobody, in most companies |
The Systems and Automation layers make compliance more efficient. The Ownership layer is the one that decides anything, and it is the layer the virtual compliance officer owns.
This matters more for AI companies
Traditional compliance frameworks were not written with changing model providers, generative AI applications and increasingly autonomous systems in mind.
An AI software company might depend on several external model providers. A consultancy might be deploying AI inside a customer environment. An agency may handle sensitive customer data across a dozen tools. A technical services company may operate systems that become part of a client's critical workflow. The business models differ. The enterprise trust problem is close to identical.
Customers want to know:
- what data enters AI systems
- where that data goes
- which model providers are involved
- how models and vendors are assessed
- what happens when outputs are wrong
- what humans remain accountable for
- how AI-related risks are identified and monitored
- whether security and governance claims can be demonstrated
A policy template does not answer those questions. Someone has to understand the requirement and the technology behind it. That is where the compliance function for AI companies has to evolve.
Certification is not the finish line
Another pattern I see repeatedly is companies treating certification as a project. Get ISO 27001. Pass the audit. Move on.
Except compliance does not stop. Customers keep sending questionnaires. Employees, suppliers and systems change. Evidence goes stale. Risks change. New products launch. Models change. Surveillance audits arrive. New enterprise customers ask different questions. The management system has to keep operating.
So our model is not "get certified". It is map, implement, certify, operate.
First, work out what customers, auditors and regulators actually require. Then build the controls and evidence into the way the company already works. Prepare the program for certification. Then keep the compliance function operating once the certificate is on the wall.
What this looks like in practice
Medow Health, a healthcare AI scribe platform, needed to move quickly. We took ownership of its ISO 27001 program end to end and brought the ISMS through to certification with BSI, certificate IS 841347. [CONFIRM: duration claim, previously stated as eight weeks. Confirm against engagement start date and the Stage 2 audit date of 26 February 2026 before publishing.]
The part worth noting is not the timeline. [CONFIRM: "zero engineers were pulled off the roadmap" as written. If accurate, restore the sentence here. If it was a small number of hours from one engineer, state that instead.] The engineering team kept building the product while we ran the compliance work, and after certification we stayed on to operate the compliance function.
That reinforced something I had already seen as a technology leader. Compliance works when somebody is clearly accountable for it.
One question, from a hospital security assessment
Certification is not where most of the work happens. Here is a better illustration.
A private hospital group ran a security assessment on the platform in February 2026. Four domains, ISO 27001 shaped, the kind of document procurement sends when clinical data is involved. One question in it amounted to this: is patient data stored offshore?
Yes and no are both wrong answers.
The accurate answer is that consultation audio is captured in Australia, transmitted by encrypted API to speech-to-text providers in the United States under a contractual zero data retention commitment, processed and deleted without being retained, and returned as a transcript to the Australian environment. Clinical note generation then runs on AWS Bedrock in the Sydney region. The original audio sits in Australia and is deleted by default after 7 days. Under APP 8 that transmission is still a cross-border disclosure, and it has to be disclosed as one, even though nothing is stored offshore.
A questionnaire assistant will produce a fluent answer to that question in about four seconds. What it will not do is check that the answer matches what the same company says on its trust page and in its privacy policy, work out that APP 8 attaches to the disclosure rather than the storage, or recognise that the hospital is not really asking about storage at all. It is asking which legal jurisdiction can reach the data.
Someone has to make that call, put their name on it, and be there when the hospital's security team comes back with the follow-up. That is the work.
[CONFIRM with Joel before publishing: this section discloses the speech-to-text provider architecture and jurisdictions. It is already disclosed in the Epworth vendor response, but disclosing it in a vendor questionnaire and publishing it on Complyd's website are different acts. Also confirm the trust page residency wording has been reconciled first, because this paragraph will be read against it.]
Why we built Complyd this way
Before Complyd, I spent most of my career on the other side of the table: building technology companies, selling to enterprise customers, and dealing with the operational reality of security reviews, due diligence and audits.
I know what happens when the compliance requirement lands with an engineering team. The intention is usually "can someone just get this questionnaire done". Then comes another questionnaire. Then ISO. Then vendor due diligence. Then an audit. Then AI governance. Eventually a set of occasional tasks becomes a function.
At that point the company has two choices. Build the function internally, or have someone own it. Complyd exists for the second.
A different model for compliance
The next evolution of compliance will not be a choice between people and software. It will be both. Automation handles more of the repetitive work. Experienced people make the decisions where judgement and accountability matter. Over time, AI will take on substantially more of the compliance workflow.
But the customer should not have to care which task is being done by software, by an agent, or by a compliance professional. The question they care about is simpler: is compliance handled?
That is the product we are building toward. A compliance function that combines technology, automation and accountable ownership, designed for AI and technology companies that need to earn enterprise trust without slowing down delivery.
Software automates the tasks. Complyd owns the outcome.
Is compliance becoming somebody's second job?
If an enterprise deal, ISO certification, customer security review or AI governance requirement is starting to consume your team's time, tell us what you are up against. In 25 minutes we will identify what actually needs to be done and the shortest path to it.