Compliance Software Has to Be Compliant Too

AI has made it ridiculously easy to build software.

That isn't necessarily a bad thing. A decent idea can now be turned into a working web app in a fraction of the time it would have taken a few years ago. Authentication, dashboards, databases, subscriptions and document generation can all be put together remarkably quickly.

The problem is that being able to build an application doesn't automatically mean you understand how to operate a secure SaaS platform.

That matters when the software is being sold into fire and security.

We're not talking about apps storing shopping lists or holiday photos. These systems can end up holding the primary record of work carried out on life-safety systems, including client details, site information, defects, certificates, photographs, signatures, engineer competency records, service histories and potentially sensitive staff information.

At that point, the interface is the easy bit.

A Nice Dashboard Isn't a Security Model

It's very easy to make modern software look mature.

You can add SSO, user roles, dashboards, client portals, PDF generation, QR-code verification, audit trails and automated backups without necessarily having put much thought into how any of it behaves when something goes wrong.

An audit trail is a good example.

A database trigger which records changes into an audit table is useful. It prevents application code from simply forgetting to create an audit entry.

That doesn't make the audit trail tamper-evident.

If someone with sufficient database access can change the original record and then change the audit record to match, disable the trigger, edit the audit table directly or restore an older database state, where is the evidence of tampering?

Calling something tamper-evident should mean there is actually a mechanism for detecting that the history has been altered.

That could involve hash chaining, signed records, immutable storage, append-only logs or copying audit information into a separate system which doesn't share the same trust boundary.

The same applies to claims about "tamper-proof" PDFs.

Hashing a completed PDF is a perfectly sensible way of checking whether the file you have now matches the file that was originally issued.

It does not stop somebody modifying the PDF.

It tells you that it has been modified.

Those aren't the same thing, and when you're selling software around compliance and evidence, terminology matters.

A Privacy Policy Doesn't Prove Anything

Another thing we're seeing more of is incredibly detailed privacy and security documentation attached to relatively new SaaS products.

They'll talk about encryption, data residency, tenant isolation, backup retention, disaster recovery, audit trails, subprocessors, cookies and deletion procedures.

All good things to document.

But the existence of the document doesn't prove the implementation matches it.

That distinction has become more important with AI because generating the documentation is now trivial. Give an AI agent a list of services being used, tell it to produce a UK GDPR privacy policy, and it'll happily produce several thousand words of very convincing material.

The actual system underneath it may not have received anywhere near that level of thought.

That's why small, visible problems are worth paying attention to.

If a website says analytics don't run until the user consents, but its own cookie rejection button doesn't work properly, that's obviously not evidence of some enormous security vulnerability.

It does, however, make you wonder how thoroughly the things you can't see have been tested.

If the simple public-facing control doesn't behave as the documentation says it should, why should a customer blindly assume everything behind the login screen does?

Start With the Really Basic Stuff

Before getting anywhere near penetration testing, encryption or disaster recovery, there's a much simpler question:

Who are you actually buying the software from?

For a UK limited company, that shouldn't be difficult to establish.

The company's registered name, company number, registered office and place of registration are basic corporate particulars.

Yet we've recently looked at several new fire, security and engineering platforms where even that information isn't readily apparent on the public website.

In one case, an engineering recruitment platform's published Terms of Service still refers to an entirely different product, including features that don't appear to have anything to do with the service currently being sold.

That's not some obscure technical flaw.

It's basic housekeeping.

But that's exactly the point.

If you're selling software designed to help other businesses manage their compliance, it's reasonable for customers to expect you to have got your own basics right first.

Using Cloud Services Isn't the Problem

There's nothing inherently wrong with building software on managed cloud platforms. AWS, Azure, Google Cloud, Cloudflare, Vercel, Supabase, Firebase and dozens of similar services are used perfectly legitimately by companies of every size.

In plenty of cases they're a better option than somebody trying to run production infrastructure themselves without knowing what they're doing.

The question isn't whether something is "in the cloud".

The useful questions are where the data actually goes, which companies process it, who has access to it and what happens when one of those services fails.

A fairly ordinary SaaS application can depend on a surprising number of separate companies.

The frontend might be delivered through one provider, authentication and the database handled by another, email sent through another, payments processed elsewhere and backups pushed into yet another platform.

Again, none of that is automatically a problem.

But it means the supplier needs to understand the entire chain.

Where is customer data held?

Where are the backups?

How are credentials managed?

How are tenants separated?

What happens when an account with an upstream supplier gets suspended?

Can the application be moved somewhere else?

What happens to customer information when a contract ends?

Who needs to be contacted if one of those providers suffers a breach?

Writing a page saying the platform is secure doesn't answer any of those questions.

What Happens if the Supplier Vanishes?

This is probably one of the most important questions to ask before making any SaaS product the main home for your compliance records.

What happens if the supplier disappears tomorrow?

It doesn't have to involve a cyberattack.

The company could fail. The developer could stop maintaining it. An upstream service could suspend an account. A payment issue could take infrastructure offline. A small software company could simply decide the product isn't worth running anymore.

Can you get your data back?

And by "your data", I don't just mean a CSV containing customer names.

Can you retrieve the sites, assets, certificates, photographs, defects, service visits, attachments and audit history in a format that is actually useful?

Could you move that data into another system?

How long would it take?

Who holds the backups?

Has anybody ever actually restored one of them?

If a company has spent twenty years building up service records, it shouldn't discover after a supplier disappears that the only usable copy of those records existed inside somebody else's web app.

For fire-safety records in particular, that information may still matter years after the work itself was carried out.

The Problem Isn't AI

AI-assisted development isn't inherently bad.

We use it ourselves.

Used properly, it's an extremely useful development tool. It can remove repetitive work, generate boilerplate, help investigate bugs, explain unfamiliar libraries and allow a small development team to get far more done.

The problem is when somebody mistakes being able to generate software for understanding software engineering.

An AI agent can produce the authentication system, database schema, dashboard, audit table and privacy policy.

What it can't give somebody overnight is the experience that makes them ask what happens when the authentication provider goes down, the database credentials leak, two customers somehow see each other's records or the supposedly reliable backup turns out not to restore.

That knowledge usually comes from years of designing systems, breaking systems and fixing systems.

AI has massively lowered the barrier to creating an application.

It hasn't removed the need to understand the application you've created.

In a regulated or safety-critical industry, that distinction matters.

Questions Worth Asking Before You Buy

If you're considering putting your company's fire or security records into a SaaS platform, there are a few questions worth asking before committing to it.

Who is actually providing the service?

There should be a clearly identifiable legal entity behind it.

Where is the live data?

"In the cloud" isn't an answer. Which provider, which service and which country?

Where are the backups?

Who can access them, how long are they retained and when was one last successfully restored?

How are different customers separated?

There is a significant difference between properly enforced tenant isolation and hoping every application query includes the right customer_id.

Who can access production data?

That includes developers, support staff and third-party providers.

If something is described as tamper-evident, what actually makes it tamper-evident?

There should be a technical answer to that question.

Can the entire account be exported?

Not just customer names and addresses. Certificates, photographs, attachments, audit history and everything else should be considered.

What happens when you cancel?

How long is the data retained? Can you still export it? When is it deleted?

Who else processes the data?

The company whose logo appears on the login screen probably isn't the only one involved.

What happens after a security incident?

Who investigates it, who contacts customers and what records exist to establish what happened?

None of these are particularly exotic requirements.

They're sensible questions to ask any company that wants to become part of your compliance record keeping.

Compliance Software Has to Be Compliant Too

The fire and security industry probably needs more software, not less.

We've put up with ancient desktop applications, proprietary databases, paper forms and increasingly complicated spreadsheets for far too long.

New products and more competition should be a good thing.

But the fact that software is easier to build means buyers need to be a bit more critical about what they're actually buying.

A polished dashboard doesn't tell you whether the architecture behind it is secure.

A long privacy policy doesn't prove that the application behaves as described.

An audit table isn't automatically tamper-evident.

A hash doesn't make a document tamper-proof.

And putting "compliance" in the product name doesn't automatically make the software compliant.

In this industry, we already understand the difference between a fire alarm system that appears to work and one that has actually been designed, installed, commissioned and documented properly.

It probably isn't unreasonable to apply the same thinking to the software holding the records.

The dashboard was always the easy bit.