EU GDPR deadlines and compliance calendar

The GDPR was adopted in 2016 and applies from 25 May 2018. Use 25 May 2018 as the baseline applicability date for EU GDPR calendar records and avoid treating adoption, publication, or corrigendum dates as separate operational compliance deadlines unless a specific source-linked task depends on them.

Directive 95/46/EC was repealed with effect from the same 25 May 2018 date. For legacy privacy program records, keep that as a migration context date rather than a recurring deadline.

The two clocks most likely to need operational routing are the data subject request clock and the personal data breach clock. Both should start from a documented trigger, not from an internal weekly privacy meeting.

For rights requests under Articles 15 to 22, the controller must respond without undue delay and in any event within one month of receipt. A two-month extension can be used where necessary because of complexity and number of requests, but the data subject must be told about the extension and reasons within one month of receipt.

For personal data breaches, the controller must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. If the notification is late, the notification must include reasons for the delay.

Schedule the DPIA before processing starts when the planned type of processing is likely to result in a high risk to individuals. The calendar trigger should be a project, product, supplier, architecture, data-category, or scope change that may create high-risk processing, not a fixed annual date.

If a DPIA shows that processing would still result in high risk without mitigation, consult the supervisory authority before processing. The GDPR gives the authority up to eight weeks from receipt of the consultation request to provide written advice, extendable by six weeks for complex processing, and the period can be suspended while requested information is outstanding.

After implementation, review the DPIA where necessary at least when the risk represented by processing operations changes. Treat major design changes, new data categories, expanded monitoring, changed sharing, or changed safeguards as calendar reopen triggers.

Do not put a generic annual SCC deadline in the GDPR calendar unless the organization has adopted that cadence internally. The grounded public rule is event-driven: before concluding SCC-based transfers, assess the specific transfer, destination-country laws and practices, and safeguards; then monitor developments that could affect the assessment.

The European Commission Q&A explains that the SCCs require a transfer impact assessment before concluding the SCCs and that the exporter must suspend the transfer if appropriate safeguards cannot be ensured. The EDPB supplementary-measures roadmap adds an ongoing re-evaluation obligation at appropriate intervals and continuous vigilance for developments affecting protection.

Calendar transfer reviews should therefore be tied to new transfer tools, new data importers, changed destinations, changed processing chains, government-access developments, importer notices that it cannot comply, adequacy decision changes, or material changes to supplementary safeguards.

The GDPR does not give one universal retention period for all personal data. Calendar retention work should therefore be attached to purposes, legal bases, data categories, systems, contracts, statutory retention needs, and deletion or anonymisation controls.

Use the storage limitation principle as the calendar anchor: personal data should not be kept in identifiable form for longer than necessary for the processing purposes, subject to the GDPR's longer-storage conditions for archiving in the public interest, research, or statistical purposes with safeguards.

Article 24 also requires controllers to implement measures to ensure and demonstrate GDPR compliance and to review and update those measures where necessary. That supports recurring operational reviews, but it does not create a single fixed EU-wide date for every organization.

This page intentionally excludes unsupported national authority timelines, informal SLA targets, and sector procedures. Add those only in a separate jurisdiction-specific artifact when the grounding folder contains a source for the exact timeline.

Use this artifact as a public-facing GDPR operations calendar for source-linked clocks. Internal teams can add stricter service levels, but those should be labelled as internal controls rather than GDPR deadlines.