GDPR readiness assessment

The most useful public evidence on where regulators look comes from the EDPB's 2024 coordinated enforcement action on the right of access. Thirty data protection authorities examined 1,185 controllers, and the report adopted in January 2025 found that two thirds of authorities rated compliance as average to high. Larger controllers generally performed better than smaller ones. The gaps that recurred were not exotic: organizations had no documented procedure for handling access requests, and many asked for excessive proof of identity before answering. Both appear in the EDPB's news item on the action, which is the primary read before you build a checklist from it.

A reviewer should treat those findings as test cases, not as headlines. For each recurring gap, ask for the written request procedure and check that it names an owner, the intake channels, the one-month response clock under Article 12(3) and the rule for extending it. Then run a sample request end to end and time it. Check whether the identity check asks only for what is necessary to confirm the requester, and whether the export actually covers the systems that hold the data, including logs and backups where they contain personal data. Record every step, because the evidence a supervisory authority asks for is the record of what happened, not the policy alone.

Interpret the results with the size of the organization in mind. The coordinated action suggests that smaller controllers are more likely to be caught without a documented procedure, so a readiness review should not assume that a lean team is covered by informal practice. Where the review finds a gap, the remediation plan should name the fix, the owner and the date, and the sample request should be repeated after the fix to show it works. Confirm the current status of the related EDPB public consultations and templates with the EDPB before you cite them in your own documentation, since those drafts were still open at the time of writing.

The depth of a GDPR readiness review follows how much personal data an organization handles and where it sits. Start by counting the systems that hold personal data, including SaaS tools, HR platforms, backups, logs and analytics stores. Each system adds records to check, rights requests to find data in, and processors whose contracts must be confirmed. Next, note whether any processing involves special category data such as health, biometric or trade union information, or criminal offence data. Those categories raise the risk weighting in a DPIA and tighten the security expectations under Article 32, so a review that would be proportionate for an internal contact database may be too shallow for a patient or payroll system.

Two status questions change the scope more than most teams expect. The first is whether you act as a processor for customers. If you do, the review must test your Article 28 processor terms, your sub-processor list, your ability to support customer audits and your breach notice path to each controller, because a customer's regulator will look at your evidence through that customer. The second is whether a DPO must be designated under Article 37(1), which applies to public bodies and to organizations whose core activities involve large-scale regular and systematic monitoring or large-scale processing of special category or criminal offence data. Decide this in writing, record the reasoning, and check that the designated person has the access and independence the role requires.

Company size affects one obligation directly. Under Article 30(5), organizations with fewer than 250 employees are exempt from keeping a record of processing activities unless the processing is risky, not occasional or involves special category or criminal offence data. The Omnibus IV proposal (procedure 2025/0130(COD)) would raise that threshold to 750 employees unless processing is likely to be high risk. A text was agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote, indicatively scheduled for 23 November 2026. The GDPR text had not been amended as of October 2026, so a size-based exemption should not be relied on until it is in force. Check the current status on the European Parliament Legislative Observatory) before the review closes, and record the date you checked.

The most common delay is the absence of a current system inventory. A readiness review cannot test whether personal data is processed lawfully, secured or deleted on time if nobody can list which systems hold it, which processors touch it and which backups retain it. Before any other work, assign an owner to build a map of personal data flows that covers production, test environments, logs, backups and the sub-processors behind each service. The same inventory feeds the record of processing activities under Article 30, so building it once saves rework later. Where the organization is small enough to fall under the Article 30(5) exemption, confirm the exemption still applies to each activity rather than assuming it covers everything.

Rights requests are the second frequent blocker. Many organizations can technically export a person's data but rely on an engineer who knows which database tables to query, which tickets to open and which third-party tools to check. Under Article 12(3) the response clock is one month, extendable by two months in defined cases, so a process that depends on one person's memory fails under pressure. Test it with a timed walkthrough: pick a sample access request, trace every system holding the subject's data, and record where a manual step was needed. Each undocumented step should become a written procedure with an owner. Breach runbooks have the same weakness. A runbook that has never been exercised will not meet the 72-hour window in Article 33(1), so run a tabletop exercise that tests who decides to notify, who drafts the content and how the organization documents the breach under Article 33(5).

The third delay is DPIAs written after a system goes live. Article 35 expects the assessment before high-risk processing starts, and a retrospective document rarely shows that necessity, proportionality and risk mitigation were considered in design. Review the DPIA register against recent launches and flag any high-risk processing without one. The EDPB published a DPIA template for consultation with feedback open from 14 April to 9 June 2026 and a personal data breach notification template with feedback open from 10 June to 5 August 2026. Track both on the EDPB public consultations page, and confirm whether each has been finalized, amended or withdrawn before adopting it into your evidence set.