Evidencing compliance without buying a GRC platform

Organisations approaching their first framework assessment frequently conclude they need a governance, risk and compliance platform. Sometimes that is right. Often it is an expensive answer to a problem that is actually about retention and assembly rather than about tooling.

It is worth understanding what an auditor is really asking for before deciding what to buy.

Auditors want records, not assertions

A control is a defined, repeatable process with a stated scope, a stated frequency, evidence that it ran, and documented treatment of the exceptions. That is the whole shape of it. An auditor is not evaluating whether your security is good in some general sense; they are evaluating whether the specific things you claim to do are actually done and demonstrable.

This reframes the problem usefully. You do not need a system that manages compliance. You need the facts your existing operations already generate to be retained, scoped and assemblable. Most organisations are generating those facts continuously and discarding, over-writing or failing to scope them.

What you probably already have

Endpoint inventory collected by an agent tells you the population — which machines existed, when, and what was on them. This is the foundation for the scope question that underpins nearly every other control.

Patch inventory retained per endpoint tells you position over time rather than today. That answers a large share of the technical control questions directly.

An audit log of privileged actions with actor, action and target answers access-control questions. So does a record of login attempts, and a record of which operator revealed which credential and when.

Compliance scoring against control frameworks, with a findings register, turns "are we compliant" from an opinion into a queue of specific divergences on specific machines that a technician can actually work down.

Between them these cover a great deal of a typical assessment. What they do not do on their own is scope and assemble themselves, which is the actual work.

The three things that go wrong

Retention that is too short. Evidence you cannot produce for the period in question is not evidence. A tool holding ninety days of history cannot support an assessment covering a year, no matter how good it looks in a demonstration. Check retention explicitly, per data type, before assuming a system covers you.

Scope that cannot be established retrospectively. When an auditor samples fifteen machines from a period nine months ago, you need to be able to say what the population was at that time. Estates change constantly, and reconstructing a historical population from a current list is not something anyone should have to attempt.

Exceptions that were never recorded. Every real estate has machines that could not be patched, users who needed elevated access, systems pinned to old versions by a vendor. If these were handled informally — an engineer decided, sensibly, and moved on — there is nothing to show. Handled formally they are unremarkable; unhandled they look like control failures.

A sequence that works

Start by writing down the controls you actually operate, in the plainest possible language. Not the ones you aspire to. If patching happens monthly with exceptions for a handful of servers, write that. Overstating here is what generates findings later.

For each control, identify which system already produces the evidence, and check its retention. This exercise usually reveals that most controls are covered and two or three are not, which is a much smaller and cheaper problem than the one you started with.

Then build the exception process, because it is nearly always the biggest gap. Make it lightweight — who can approve, for how long, recorded where. If raising an exception takes more than a couple of minutes, engineers will not do it, and you will be back to informal decisions with no record.

Then rehearse. Pick a control, pick a period, and produce the evidence as though asked. You will find the gaps immediately, in a week where nothing is at stake, which is a substantially better time to find them.

When a GRC platform is genuinely the answer

When you are managing many frameworks with overlapping controls and the mapping work is itself the burden. When policy lifecycle, attestation and workflow across a large organisation are the problem. When you need to demonstrate the compliance programme as a programme, rather than demonstrating its individual controls.

If you are a mid-sized organisation working towards a single framework, those are probably not your problems yet. Your problem is likely that patch history is retained for ninety days, nobody can establish historical scope, and exceptions live in people's heads. None of those are solved by another platform on top; they are solved by fixing retention, scoping evidence properly, and writing exceptions down.

One thing no tool provides

Compliance is a property of your organisation's controls and practices, not of your software. Any vendor — including us — implying that installing something makes you compliant is describing a product that does not exist. What tooling can do is collect evidence continuously instead of in a panic, and show you where the estate diverges from what you claim. That is genuinely valuable, and it is a different claim.