What a cybersecurity review actually covers

“Are you compliant?” is usually the wrong first question, because compliance is a byproduct of a system that was actually reviewed, not a checkbox you buy separately. For donor-funded organisations and financial-sector clients especially, a funder or regulator doesn’t just want to hear that a review happened — they want to see what it covered and what changed as a result.

What we actually assess

• Access control. Who can reach payroll, donor, and customer data, and does that list match who should be able to. Shared logins and stale accounts from former staff are the most common finding, by a wide margin.
• Data in transit and at rest. Is traffic to the ERP and telemetry systems encrypted, and are backups protected the same way the live system is.
• Patch and update posture. Whether the server, ERP instance, and any exposed field devices are actually receiving updates, or were configured once and left alone.
• Network exposure. What’s actually reachable from the public internet versus what only needs to be reachable internally — a surprising number of internal admin panels turn out to be open to anyone who finds the URL.
• Backup and recovery. Not just whether backups exist, but whether a restore has ever actually been tested.

Turning a review into evidence

The output that matters isn’t a pass/fail — it’s a written record of what was checked, what was found, and what was remediated, dated and specific enough to hand to an auditor, a donor, or a regulator without having to reconstruct it from memory six months later. That written trail is usually the actual deliverable a funder is asking for when they say “show us your compliance.” We build it as part of the review, not as a separate paperwork exercise afterwards.