How Long Does GDPR Readiness Take? The Clocks That Actually Set the Date

GDPR readiness takes as long as it takes to build a specific set of documents and working processes, and the honest answer starts by naming them, because the Regulation has no certificate, no audit and no pass mark. The question "how long does GDPR compliance take" only has an answer once you say what done looks like. For a US company with modest EU exposure, done is a readiness file: a scoping memo, an Article 30 record of processing activities, a lawful basis register, privacy notices that match it, a data subject request runbook, processor agreements, and, where they apply, a representative appointment, a transfer mechanism and a DPIA screening. The three artefacts at the core of that file, the data map, the Article 30 record and the request runbook, are the work this site has already sized at 40 to 80 hours of your own people's time for a small software company, in our GDPR cost article, which owns that figure. Here is the contrarian part: no statute, regulator or standards body publishes a GDPR project duration, and every timeline graphic you have seen is a vendor's estimate with no stated population. This page does not add another one. It names the clocks the Regulation actually contains, and the one input that predicts your calendar better than any of them.

Below: what the readiness file contains, the statutory clocks that sit inside it, the input that predicts your timeline, the sequence dependency that costs teams the most time, and the case for stopping earlier than a consultancy would like.

Key takeaways

• GDPR readiness has no finish line defined by anyone but you, so scope it to a named deliverable before estimating anything. The article names one.
• No primary source publishes a project duration. The Regulation publishes clocks: two years between entry into force and application for the whole Union, eight weeks plus six for a supervisory authority consultation, seventy-two hours for a breach, one month for a rights request.
• The best predictor of your calendar is the number of systems and vendors that hold personal data, because the Article 30 record cannot be finished until every one has been found and described.
• The sequence dependency that costs the most time is lawful basis: the EDPB says it must be decided before collection and cannot be swapped afterwards, so it has to be settled before notices, consent flows and contracts are written.
• The readiness file is a project. Keeping it true is a programme, and the second is where most of the elapsed time in GDPR actually goes.

What done looks like, because nobody else will define it

The absence of a certificate is not a technicality. Under Article 5(2) the controller "shall be responsible for, and be able to demonstrate compliance with" the principles in Article 5(1). Demonstrating is an ongoing state, not an event, which is why a vendor promising to get you "GDPR compliant in ninety days" is selling a milestone the Regulation does not recognise. The same trap exists in US healthcare, and the corpus already handles it at does HIPAA certification exist.

So define the deliverable. The readiness file we would put in front of a European enterprise buyer or a supervisory authority has these parts, in the order they depend on each other:

• A scoping memo answering whether Article 3(2) reaches you at all, and for which processing. The test is walked in does GDPR apply to my US company, and everything below is conditional on it.
• A data map, the working inventory of where personal data sits, where it came from and where it goes.
• The Article 30 record of processing activities, the formal version of that map in the fields the Regulation prescribes. Its contents and its small-company derogation are covered in what is a RoPA.
• A lawful basis register, one basis per purpose, with the legitimate interests assessments behind any purpose that relies on Article 6(1)(f). The six bases and the rule that they cannot be swapped are in what is a lawful basis.
• Privacy notices that state what the register says, because Article 13(1)(c) requires the notice to give "the purposes of the processing for which the personal data are intended as well as the legal basis for the processing".
• A data subject request runbook, with intake, verification and the response clocks. The clocks belong to our DSAR deadlines article and are not restated here.
• Processor agreements with every vendor that handles personal data on your behalf, covered in what is a data processing agreement.
• A breach procedure that can meet the Article 33 clock below.
• Conditional items: an Article 27 representative if you have no EU establishment, a transfer mechanism if data comes to the United States, and a DPIA screening decision for anything that might meet the Article 35 trigger. The representative and DPO triggers are compared in EU representative vs DPO; the DPIA trigger is in what is a DPIA.

That list is the project. When every item exists, is true, and has a named owner, you are ready in the only sense the Regulation supports.

The clocks the Regulation actually publishes

Since no duration is published for the project, the fixed numbers worth knowing are the ones the Regulation itself contains. They set floors and gates inside your plan rather than the length of it.

Two observations. First, the only one of these that is a project duration is the first, and it describes the whole Union rather than your company. Second, the Article 36 gate is the one that most often surprises a launch plan, because it is triggered by your own assessment. If a DPIA is in your file and comes back high risk after mitigation, up to fourteen weeks of regulator time sits between you and go-live, and none of it is under your control.

The input that predicts your calendar

In our experience the length of a first GDPR readiness project is set by one number: how many places personal data lands. Every system, every SaaS tool, every spreadsheet, every vendor, every export. The Article 30 record has to describe the categories of data, the recipients, the transfers and the retention period for each processing activity, and it cannot be finished until each of those places has been found, opened and described by someone who knows what is in it.

That is why our cost article sizes the core three artefacts at 40 to 80 hours for a company with one product, one CRM, one warehouse and a dozen or so subprocessors, and why it is explicit that the band does not describe anyone whose business is built on personal data. Elapsed time is a different thing from hours. Forty hours of work spread across people who each own a system and have a day job is not a week; it is however long it takes to get an hour from each of them. The practical predictor is therefore the length of your system list multiplied by the availability of the people who can describe each one.

We are deliberately not converting that into a number of weeks. We could, and it would be read as a benchmark, and it would be wrong for any company whose system count differs from the one we imagined.

The dependency that costs the most time

Most first projects run the workstreams in parallel: someone drafts the privacy notice, someone configures the consent banner, someone negotiates vendor agreements, someone builds the record. Then the lawful basis decisions land and half of it has to be redone.

The reason is a rule the EDPB states plainly. Its consent guidelines, Guidelines 05/2020 version 1.1, say at paragraph 123 that "the controller cannot swap from consent to other lawful bases" and that "controllers must have decided in advance of collection what the applicable lawful basis is". Its legitimate interest guidelines, Guidelines 1/2024 in the version published for consultation, add at paragraph 7 that the balancing exercise "must be done before carrying out the relevant processing operation(s)".

So the lawful basis register is upstream of the notice, the banner, the consent records and every clause in a processor agreement that describes instructions. Settle it first, in writing, purpose by purpose. Teams that do this find the rest of the file is largely transcription. Teams that do not find that the notice says consent where the register says legitimate interest, and the EDPB's own words for that state are "fundamentally unfair to individuals".

Readiness is a project; staying ready is the programme

The file described above has a completion date. What does not is the obligation it evidences. The record changes when a system is added. The register changes when a purpose is added. The notice changes when either does. The request runbook runs every time someone writes in. That is the part of GDPR that consumes elapsed time indefinitely, and it is the reason a readiness project that ends with a folder and no owner produces a folder that is false within a quarter.

This is the same failure the corpus describes as compliance debt: documentation that stops describing the business it was written for. The mitigation is unglamorous. Name an owner for the record, tie its review to change events you can actually detect (a new vendor, a new data category, a new market), and treat a request that arrives through the wrong inbox as the process test it is.

The honest caveat, and when to stop early

Against our own interest: for a great many US companies the right readiness project is shorter than a consultancy would scope it.

If the scoping memo comes back out of scope, stop there. Date the memo, name who decided, and set a reminder for when your go-to-market changes. If you are in scope but small, with one product, no special-category data and no Article 37 trigger, the file above is a project a competent operations lead can run in-house, and our cost article says so in money terms. Outside help compresses the hours and, more usefully, tells you which of them mattered, but it does not remove the need for the person who knows your systems to sit down and describe them.

Where a longer project is genuinely warranted: several product lines with different scope answers, an advertising stack whose monitoring analysis is unclear, special-category data, or a DPIA that may need the Article 36 gate. Those are the cases where the calendar is set by regulator time and judgment calls rather than by your own effort.

Where Top Floor fits

We build the readiness file, and we build it in the dependency order above so the lawful basis decisions are made before anything that depends on them is written. That is GDPR work. Where a company faces the EU and the US state laws at once, global privacy treats them as one programme, which is nearly always shorter than two. Where the owner of the record, the review cadence and the request runbook needs to be someone who will still be there next year, that is what compliance as a service is for.

How to decide this week

Write the scoping memo first; everything else waits on it. Then count: list every system, tool and vendor that holds personal data, and next to each write the name of the one person who can describe what is in it. That list, and those names' availability, is your timeline, and it takes an hour to produce. Third, decide the lawful basis for each purpose before anyone drafts a notice or configures a banner, because the EDPB says that decision cannot be revisited after collection. Finally, if any processing might meet the DPIA trigger, put the Article 36 consultation window on the plan now rather than discovering it as a slipped quarter.

Frequently asked questions

Is there a GDPR certification we can get at the end of the project?

No. The Regulation contains no certificate, no audit and no pass mark that ends the obligation; Article 5(2) makes the controller responsible for being able to demonstrate compliance, which is a continuing state. Readiness therefore means a defined set of documents and working processes, such as a scoping memo, an Article 30 record, a lawful basis register, matching notices and a request runbook, each with a named owner and a review trigger. Any vendor promising to make you compliant by a date is describing a milestone of its own invention.

Why does this article not give a number of weeks or months?

Because no statute, regulator or standards body publishes one, and a figure with no stated population is worse than no figure. What can be sourced are the clocks inside the Regulation: two years between entry into force and application, eight weeks plus six for a supervisory authority consultation under Article 36, seventy-two hours for breach notification under Article 33, and one month for a rights request under Article 12. The hours for the core artefacts are sized in our GDPR cost article at 40 to 80 for a small software company, and elapsed time depends on how many systems hold personal data and how available their owners are.

What is the single biggest cause of a GDPR readiness project running long?

Deciding lawful basis late. The EDPB's consent guidelines state that a controller must decide the applicable lawful basis in advance of collection and cannot swap from consent to another basis afterwards, and its legitimate interest guidelines require the balancing test to be done before processing begins. When that decision lands after the notice, the consent banner and the vendor agreements have been drafted, all three have to be rewritten. Settling the basis for each purpose first turns most of the remaining file into transcription.

When does a supervisory authority get involved in the timeline?

Only if your own DPIA indicates a high risk that your mitigations do not remove, in which case Article 36 requires prior consultation before the processing starts. Article 36(2) gives the authority up to eight weeks to provide written advice, extendable by six weeks for complex processing, and the period can be suspended while the authority waits for information it has requested from you. That gate is triggered by your assessment, so the time to discover it is when the DPIA is screened, not when the launch date is fixed.