What a compliance audit proves, and what it does not
A compliance audit differs from a general technology review in one structural way: the criteria come from outside. A standard says what good looks like, and the exercise establishes whether you meet it.
That external criterion is the source of both its value and its limits, and the confusion between the two costs organisations a great deal of money.
Where an it audit services engagement starts from your risks, a compliance audit starts from someone else’s list, and knowing which you need is worth settling early.
What it establishes
That you defined controls, and operated them over a period.
Every word there matters. You define the controls — within the standard’s requirements, the specifics are yours. The audit checks that they were operated, which means evidence spanning months rather than a snapshot taken the week before.
This is why the common panic — trying to become compliant in the fortnight before an assessment — does not work for the period-based standards. There is no way to retroactively have reviewed access quarterly.
What it does not establish
That you are secure. A compliant organisation can be breached, and frequently is. The standard tests whether stated controls were operated, not whether those controls were sufficient against a determined attacker.
That your product is well built. Nothing in the common standards examines whether the software is maintainable, correct, or fit for purpose.
That your data is accurate. Controls govern access and change. They say nothing about whether the numbers coming out are right.
Treating a certificate as evidence of any of those three is the error, and it is made by buyers more often than by the audited.
Why it is still worth doing
Two honest reasons, and neither is security.
It removes a sales obstacle. Enterprise buyers require it. A certificate turns a two-month security review into a document exchange, and that is a commercial benefit with a measurable value.
It forces a floor. The requirements are unremarkable — access reviews, change control, backup testing, incident procedures — and most organisations that have not been through it are missing several. Being obliged to operate them for a period is genuinely useful, independent of the certificate.
The failure is treating the certificate as the goal rather than the residue. The controls are the point; the document says you ran them.
The cost nobody quotes
The assessor’s fee is the visible number and usually the smaller one. The real cost is internal: evidence collection, quarterly access reviews, writing policies somebody will actually follow, and the engineering time spent producing artifacts.
For a small team, budget a meaningful share of one person’s attention as a standing commitment rather than a project. The organisations that find compliance ruinous are the ones that budgeted for the assessment and not for the operating.
Choosing what to pursue
Be led by who is asking. If enterprise customers in one market are asking for a specific standard, pursue that one. If nobody has asked, the honest answer is usually that it is early, and the controls are worth adopting without the certificate.
Pursuing several at once is a common and expensive mistake. They overlap substantially, and sequencing them lets the evidence from the first serve the second.
The controls worth adopting regardless
Whether or not a certificate is in your future, four of the required controls earn their cost on their own.
Quarterly access review. An hour per quarter, and it catches departed employees, over-provisioned accounts and forgotten service credentials. This is the highest return of anything on the list.
Restore testing. Not backup verification — an actual restore, into a usable state, with the date recorded. Most organisations discover something the first time they try.
Change traceability. Available free from version control and a deployment pipeline, provided no path exists that bypasses them.
A written incident procedure. Two pages: who is called, who decides, who communicates. Its value is entirely in having been written before it was needed.
An organisation running those four is most of the way to several standards and, more usefully, meaningfully harder to damage.
What I cannot advise on
I am not an assessor and cannot issue any certification. What I can do is establish the gap between where a system is and what a standard requires, and make the engineering changes that close it — which is a different job from the one that signs the certificate, and deliberately so.
I would also not attempt to interpret a specific regulation for your jurisdiction. That is legal advice, and the point where technical work should hand over rather than improvise.
Related reading: what an IT audit checks covers the risk-led version of this exercise, compliance information covers what records these standards actually require you to hold, and the IT auditor’s role covers who performs the assessment and why independence is the load-bearing part.