Security documentation tends to get written after a system is built, under time pressure, right before a review. That's backwards, and it shows — gaps get papered over with policy documents that don't match what the system actually does. The checklist below is roughly the order in which these controls get tested in practice, and the order we build them in.
Access control mapped to role, not convenience
Every account should have the minimum access required for its function, reviewed on a schedule rather than left in place indefinitely. Shared logins and standing admin access are the two findings that come up most often in a first-pass review.
Encryption in transit and at rest, documented
Encryption itself is table stakes. What auditors actually ask for is the documentation — which standard, applied where, and since when. Undocumented encryption is treated the same as no encryption in most formal reviews.
Audit logs that are actually reviewed
Logging access events is only half the control. The other half is a documented process for who reviews those logs, how often, and what happens when something looks wrong. A log nobody reads doesn't satisfy most compliance frameworks.
Data residency matched to client jurisdiction
For clients in the UK or Germany, this usually means confirming where data physically sits and under what legal basis it can be processed elsewhere. This is one of the most common gaps we find in systems built before a company started serving European clients.
Third-party and sub-processor visibility
Every vendor with access to client data — hosting providers, analytics tools, support platforms — should appear in a maintained list, with its own data handling terms reviewed, not assumed.
An incident response plan that's been tested, not just written
A response plan sitting untouched in a shared drive since it was written is a common finding. The stronger position is a plan that's been walked through at least once, with names attached to each step.
Why this order matters
Access control and encryption are the two items every reviewer checks first, because they're the fastest way to gauge whether security was designed in or bolted on. Get those two right and documented, and the rest of a review tends to go faster — reviewers extend more benefit of the doubt to an organization that clearly has its fundamentals in order.
The common thread across all six items isn't a specific technology. It's documentation that matches reality. A control that exists but isn't written down doesn't help you in a review, and a policy that's written down but isn't actually followed is worse than having no policy at all, because it creates a paper trail that contradicts itself.
Preparing for a security or compliance review?
We'll audit your current setup against this checklist before the reviewer does.