The Screenshot Problem
Walk into most organisations two months before a SOC 2 or ISO 27001 audit and you'll find the same scene: a security lead screenshotting MFA settings, chasing access-review sign-offs by email, and assembling a spreadsheet of 150-300 controls into evidence folders by hand. It costs weeks, proves compliance only for the moment the screenshot was taken, and starts again next year. Meanwhile GDPR obligations — subject access requests, retention, breach timelines — run as ad-hoc fire drills.
The alternative isn't a tool purchase; it's a stance: compliance is a property of systems, continuously verified — not a document, annually assembled.
Layer 1: Continuous Evidence Collection
Most controls are checkable by API. So check them constantly:
- Identity: MFA enforcement, leaver deprovisioning within SLA, quarterly access reviews — pulled from your IdP (Okta, Entra) daily, with drift alerting the moment a control slips rather than a discovery in audit week.
- Infrastructure: encryption at rest, public-bucket checks, patched AMIs, backup success — via cloud config rules (AWS Config, Azure Policy) mapped to control IDs.
- Change management: evidence that every production change had review and CI passing — harvested from GitHub/GitLab, where it already exists.
Compliance platforms (Vanta, Drata, Secureframe) do the collection well for standard stacks and are usually worth their fee; the differentiating work is wiring your custom systems into the same evidence stream — which is an engineering task, and exactly where we're typically brought in.
Layer 2: Policy-as-Code — Prevention Beats Detection
Better than alerting on drift is making drift impossible: infrastructure-as-code modules with encryption and logging on by default, CI checks that fail a deploy creating a public bucket or an unencrypted database, and admin access granted just-in-time with expiry instead of standing forever. Every control enforced in the pipeline is a control you never screenshot again — and the audit conversation changes from "show me evidence" to "here's the rule that makes violation impossible", which auditors, it turns out, rather like.
An audit should be a read-only operation on systems that were compliant anyway — not a seasonal performance staged for the auditor's benefit.
Layer 3: The GDPR Workflows Worth Automating First
- Subject access requests: a DSAR against ten systems is days of manual work per request — or an orchestrated workflow that queries each system by identifier, compiles, redacts third-party data for review, and delivers inside the 30-day clock with a full audit trail. Highest-volume, highest-risk, automate first.
- Retention and deletion: policies mean nothing until they execute. Scheduled, logged deletion jobs per data category — with legal-hold exceptions — turn your retention schedule from a document into a behaviour.
- Records of processing & breach response: generate the RoPA from your integration catalogue (if you followed our API strategy guidance, the data-flow map already exists), and codify the 72-hour breach playbook so the clock starts with a runbook, not a debate.
What Stays Human
Automation collects evidence and enforces mechanics; it doesn't make judgements. Risk assessments, DPIAs on new processing, vendor risk decisions, and the annual "are these controls still the right controls?" review remain human work — better human work, because the toil is gone. A typical engagement wires continuous evidence and the top GDPR workflows into your estate in 6-8 weeks, fixed price; the deliverable your team feels is the quarter where audit prep took an afternoon.
Audit fatigue setting in?
Book 15 minutes — we build compliance into architecture, not bolt it on before the auditor arrives.
Book a 15-Minute Call →