GDPR compliance checklist for technical teams

What a GDPR compliance checklist for technical teams must cover

When a customer, contract or regulator asks for GDPR evidence, engineering and operations teams are usually the ones who must produce it. The GDPR requires no audit, attestation or certificate, so compliance is shown through the records, systems and evidence that the controller or processor holds. The checklist on this page turns the obligations that depend on systems into testable items: records of processing, privacy notices rendered in product flows, rights requests answered within one month, processor contracts, security measures, breach documentation with the 72-hour clock, DPIAs and the decision on whether a data protection officer is required. Each item should end with a named owner and a artifact someone can open.

The answer to what the checklist must contain depends on role. A controller decides why and how personal data are processed, while a processor acts on documented instructions, so the same system can generate very different duties. The data types matter as well, since special category data and large-scale monitoring trigger extra requirements such as DPO designation under Article 37(1). Sub-processors, hosting locations and remote support access change the scope of the processor contract and the transfer analysis. Organizations established in the EU, and those offering goods or services to people in the EU, face the same core obligations, so teams should first confirm which role applies to each processing activity and record that decision.

Before drafting the checklist, teams should confirm three things in writing: which processing activities sit in each system, which party is the controller for each one, and which suppliers or hosting locations appear in each flow. The GDPR was published in the Official Journal on 4 May 2016 and has applied since 25 May 2018 (Article 99), so the obligations are not new, but the expectation of current, system-level evidence is. Read the primary text on EUR-Lex before finalizing item wording, and have legal counsel confirm how each item maps to your role and data.

Which records and notices engineering must be able to produce

Two artifacts sit at the front of most GDPR reviews: the record of processing activities and the privacy notice shown at the point of data capture. Both must be generated from systems that actually collect and route personal data, so the cards below cover what each artifact must contain and which system must produce it.

Record of processing contact details

Article 30(1) starts with the controller's identity and contact details, plus the DPO's where one exists. Engineering rarely owns this field, yet it anchors every other entry in the record. Check that each system owner's team, the named controller entity and the DPO mailbox are stored in a single register that the platform team can export, and that the entry is reviewed when a system changes hands or a new entity joins the group.

Processing purposes and data subject categories

Each record entry must state why personal data is processed and which groups of people it concerns, such as customers, job applicants or website visitors. For self-hosted platforms, the purpose is often inferred from configuration rather than documented. Ask the owning team to tie every data store, queue and log source to a named purpose and data subject group, and check that the register matches what the production inventory shows.

Personal data categories and recipients

The record lists the categories of personal data and the categories of recipients who receive them, including internal teams and processors. Engineering must be able to produce this from the data catalog and from integration configuration, such as API connectors, data exports and shared database access. Verify that each outbound integration and each processor with access to the data appears as a recipient category, not only the vendors named in contracts.

Third-country transfers and erasure limits

The record must show any transfer to a third country and, where possible, the time limits for erasure of each data category. Both are operational facts. Confirm that replication targets, backup regions and remote support access are visible in infrastructure inventories, and that retention rules are enforced by jobs whose schedules can be exported as evidence. Where erasure limits cannot be stated precisely, record the rule that applies and the reason it is not yet fixed.

General description of Article 32 measures

Article 30(1) asks for a general description of the security measures under Article 32, where possible. This is a summary, not a full technical specification, but it must match the controls that exist. Keep the summary tied to evidence such as encryption configuration, access reviews and backup test results, and review it whenever a control changes so that the record does not describe a control that no longer runs.

Article 13 notice at the point of capture

Article 13 requires information at the time personal data are collected directly from the person, including the controller's identity, purposes and legal basis, recipients, any third-country transfer and its safeguards, the retention period, the rights available and any automated decision-making. Engineering must render this text in the sign-up, form and checkout flows and version it. Check that each form that collects data links to the current notice and that the version in production matches the approved text.

Article 14 notice for third-party data

When data come from a source other than the person, Article 14 applies, and the information generally must reach the individual within one month. Lead lists, partner feeds and enrichment services are common sources. Engineering should tag records by origin at ingestion so that the notice workflow can be triggered and tracked, and should keep a log showing when each notice was sent. The EDPB's 2026 coordinated enforcement action on transparency and information obligations makes this evidence a likely supervisory focus.

How to test whether rights requests meet the one-month deadline

This sequence shows whether a rights request can move from intake to answer inside the one-month window of Article 12(3), with a record at each step that an assessor or supervisory authority could verify.

Log every request at intake
Record each request in a single register as soon as it arrives, whatever the channel: email, web form, post or a verbal request passed to staff. Capture the date of receipt, the right invoked, the requester, and the deadline clock start. The test passes when a sample of requests from each channel appears in the register with a receipt date, and when no channel exists that bypasses it. Ask engineering to confirm that the ticketing or form tool feeds the register automatically.
Verify the requester's identity
Confirm that the person making the request is the data subject, using a proportionate check that does not itself collect more data than needed. Record the method used and the outcome in the request file. The test is whether a sample of closed requests shows a documented identity check, and whether the check was applied consistently rather than only to some requests. Confirm the method with legal before you test, because the appropriate check depends on the data held.
Locate the data across systems
Search every system in the record of processing that could hold the subject's data, including backups, logs, analytics stores and processor-hosted services. Keep a search log that names each system searched and the query used. The test is whether the list of systems searched matches the current record of processing, which the EDPB guide describes as knowing your data flows through an up-to-date register. Gaps between the register and the systems you actually searched are findings.
Export or erase the data
Produce the access export or carry out the erasure, rectification or restriction the request requires. Store the output in a controlled location, and record who performed the action and when. For erasure, record the systems affected and any data retained under a documented legal reason. The test is a reproducible export or a deletion log that a second engineer can verify against the search log from the previous step.
Pass results to recipients
Where the data was shared with recipients, or where erasure or rectification must reach them, send the instruction to each recipient and log the notice. Include processors and sub-processors that hold copies. The EDPB guide lists passing results on to recipients as one of its seven practices. The test is a notice log entry for each recipient involved in the sample requests, showing the date sent and the recipient named.
Respond within one month
Send the response to the requester within one month of receipt, or within the extension Article 12(3) allows if the request is complex or numerous, provided the requester is told of the extension and the reasons within the first month. Record the response date and calculate the elapsed time against the deadline. The test is whether every sampled request shows a response date inside the window, or a documented extension notice sent in time.
Document refusals and close the file
Where a request is refused in whole or in part, record the reasons, the exemption relied on and the information given to the requester about complaint and judicial remedies. Close the request file only when the response, recipient notices and search log are all attached. The test is whether a sample of refusals contains reasons that a reviewer can follow, and whether every closed file holds the full set of records. Review a monthly sample of closed files to confirm the pattern holds over time.

What processor contracts and sub-processor lists must show

As the controller, your organization remains responsible for choosing processors and for the instructions you give them. Article 28 requires a written contract (or other binding legal act) with each processor, and that written requirement is explicit in Article 28(9), including where the contract is in electronic form. Your technical and operations teams should not treat the contract as a legal artifact only. Each term describes a control your systems must actually support, so the people running the platform need to read it too.

Documented instructions: The processor may process data only on your documented instructions, including instructions on transfers outside the EEA. Your records must show who issues those instructions and how they change.
Staff confidentiality: Confirm that persons authorized to process the data are bound by confidentiality. Ask the processor how this is evidenced.
Article 32 measures: The contract must require the security measures in Article 32. Ask for the measures in writing, not a general promise.
Assistance duties: The processor must help with rights requests and with Articles 32 to 36, which cover security, breach notice, impact assessments and prior consultation. Test how quickly that help arrives in practice.
Deletion or return: Confirm what happens to data at the end of the service, including backups, and how you will receive proof.

Before signing, check that each term maps to a named control and a named owner on both sides.

Which Article 32 security evidence regulators ask for

Article 32 asks for security measures appropriate to the risk, and it names four areas that need proof: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration, and regular testing. The cards below set out what to collect for each area and where regulators have found technical gaps.

Pseudonymisation and encryption settings

Article 32(1)(a) names pseudonymisation and encryption as measures to consider. Evidence is the configuration itself: encryption at rest and in transit settings for databases, object storage and backups, key management records showing who can generate, rotate and revoke keys, and a register of where pseudonymised datasets are held and how the mapping table is separated. Check that key rotation and certificate expiry are tracked, not assumed. The key question for an assessor is whether a breach of one system would expose readable personal data.

Confidentiality through access control

Ongoing confidentiality under Article 32(1)(b) is shown by access control evidence. Collect exports of user and role assignments, privileged account lists, multi-factor authentication enforcement settings and records of periodic access reviews with the reviewer's name, date and any removals. Include leaver deprovisioning records and the list of staff with database or backup console access. Ask whether each review compared actual access with the documented need for it.

Integrity and availability monitoring

Integrity and availability under Article 32(1)(b) are evidenced by logs and alerts that show systems are unchanged without authorization and remain up. Keep configuration baselines, change records, file integrity monitoring output, audit log retention settings and uptime or capacity reports. Confirm that logs are protected from modification and that someone reviews alerts. A gap in log review is a common weakness to close before an inquiry, because logs without review show no detection capability.

Timely restoration after an incident

Article 32(1)(c) requires the ability to restore availability and access to personal data in a timely manner after a physical or technical incident. Evidence includes backup job logs, the recovery time and recovery point targets the organization has set, and restore test records showing that a sample of personal data was actually recovered and checked. Confirm where backups are stored, who can delete them and whether backups containing erased personal data are handled under the erasure process.

Regular testing of effectiveness

Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of the measures. Evidence is a dated test plan, the scope and results of vulnerability scans and penetration tests, remediation tickets with closure dates, and management sign-off on residual risk. Keep the test records in one place so an assessor can trace a finding to its fix. Confirm who is accountable for each test and how often the schedule is reviewed.

Technical gaps regulators cite

Recent decisions show regulators testing these measures against real incidents. The Swedish DPA fined Miljödata i Karlskrona for insufficient technical measures, and the CNIL fined Hôpital Privé de la Loire after a health data breach. Use both decisions to review your own evidence: can you show the control was in place before the incident, not added afterwards? Ask your team to walk through each decision against your environment and record what would have been caught and by which control.

Does the organization have to appoint a data protection officer?

Designation is mandatory only in three cases under Article 37(1): processing carried out by a public authority or body, core activities that consist of large-scale regular and systematic monitoring of individuals, and core activities that consist of large-scale processing of special category data or criminal offence data. The first question for a technical or operations team is therefore not whether a DPO would help, but whether the organization's core activities, as its systems actually run, fall into one of these three categories. A platform that monitors employees or customers at scale, or that stores health, biometric or other special category records as its main purpose, needs a documented answer. Words such as "large" and "core activities" are not defined by numbers in the Regulation, so the reasoning must be written down and tied to the real data flows in the record of processing.

Appointing a DPO voluntarily is allowed, but it does not switch off the GDPR's rules for the role. Once an organization designates a DPO, whether required or not, the Article 38 duties on involvement, independence, resources and reporting to the highest management level apply, and the Article 39 tasks such as advising on DPIAs and monitoring compliance apply as well. Teams should record the decision either way, including the criteria checked, the date, who approved it and the trigger for reviewing it when processing changes, such as a new monitoring tool or a new category of sensitive data. A short written decision is usually enough, but the reader should confirm its form and content with counsel or with the guidance published by the supervisory authority in their Member State, since national practice and interpretation can differ.

If the organization decides to use an outsourced DPO, treat the service as a recurring cost in the scope and budget, not a one-time fee. Ask the provider for a written description of the tasks, the time commitment, how it handles conflicts of interest, who holds the role contractually, and how it accesses systems, logs and DPIA material inside your environment. Confirm the appointment is notified to the supervisory authority and published with contact details, as the Regulation requires for designated DPOs. Where DeployOpen is involved, its role is to prepare systems, records and evidence that a DPO can review, not to act as the DPO itself. Final responsibility for the decision and for compliance stays with the controller or processor.

Questions technical teams ask before adopting this checklist

Does the GDPR require a certificate to show compliance?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. What the regulation does require is evidence: a record of processing activities under Article 30, DPIAs for likely high-risk processing, documentation of every personal data breach under Article 33(5) and written processor contracts under Article 28. A customer may still ask for an independent report or certificate in a contract, and that request is a commercial one, not a legal one. Confirm the exact evidence your customers and contracts expect before you scope any work.

How long does a GDPR readiness pass take?

It depends on scope and on the state of your records. A readiness pass takes longer when the record of processing is missing, when personal data sits in many systems, or when rights requests are handled by hand. The checklist gives you a fixed set of deadlines to test: answering rights requests within one month (extendable by two months under Article 12(3)), notifying the supervisory authority within 72 hours of becoming aware of a notifiable breach under Article 33(1), and giving Article 14 information within one month when data come from third parties. Start by inventorying systems and data flows, because every later step depends on that inventory. Ask any partner to state the systems in scope and the evidence they will produce before agreeing a timeline.

Can our internal staff complete this checklist without outside help?

Often yes, for a bounded scope, provided someone owns the work and has access to engineering and legal input. The GDPR places responsibility on the controller, so the organization must own its records, policies, decisions and sign-off. Internal teams usually carry the cost in staff time: mapping data flows, updating the record of processing, reviewing processor contracts, testing rights request handling and running a breach tabletop exercise. Outside help becomes more useful when systems are numerous, when the team lacks security engineering capacity, or when a DPIA needs an independent review. Decide who approves each artefact before you start, and document that decision.

What does an implementation partner do for GDPR readiness, and what does it not do?

A partner prepares systems, controls and evidence. DeployOpen, for example, plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and it can configure logging, access control, backup and restore and rights-request workflows so that the evidence exists. It does not own your controls, does not decide your lawful bases or retention periods, and does not act as your DPO unless that role is contracted separately. It also does not issue audit reports, attestations or certifications. Only an independent auditor or certification body does that. Keep those roles separate in any contract, and confirm who is accountable for each record.

Do the Omnibus proposals change the GDPR deadlines I should build around?

Not as of October 2026. The GDPR text has not been amended, so the deadlines in the checklist still apply. The Omnibus IV proposal (COM(2025) 501, procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 that awaits Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) is awaiting committee decision. Separately, Regulation (EU) 2025/2518 applies from 2 April 2027 and governs procedures in cross-border enforcement cases. Build your plan on the current text, track the procedure files on the European Parliament Legislative Observatory, and review the plan when a proposal is adopted.

What should we ask a partner to include in a fixed-scope quote?

Ask for the written scope before any price. A useful quote lists the systems in scope, the data flows and processors covered, the artefacts to be delivered (such as the record of processing, rights request runbook, breach documentation template and DPIA draft), the roles of your staff and the partner's staff, and the dates or milestones agreed in writing. Ask which costs are one-time, such as the initial inventory and configuration work, and which recur, such as retainers for upgrades or continuous testing. Ask what is excluded, including legal opinions, DPO services and any independent audit. Confirm that the partner will not issue assurance reports, and that the agreed evidence will be handed over in a form your auditor or supervisory authority can review.

Who owns each checklist item and who only prepares it

Your organization is the controller or processor, and it owns every decision the GDPR makes personal. Accountability under Article 24 sits with you, so the lawful basis, the purposes, the retention periods, the risk judgments in a DPIA and the final answer to a rights request all need an accountable owner inside the organization. Outside partners can draft and assemble material, but they cannot take these decisions for you.

Decisions and lawful basis: Set purposes, choose lawful bases and approve retention periods, recorded in your own register.
Records of processing: Maintain the Article 30 record and keep it current as systems change.
DPO designation and duties: Decide whether a DPO is mandatory under Article 37(1), then resource and protect the role.
Rights responses and breach decisions: Decide and sign off on access, erasure and other responses, and on whether a breach is notifiable within the 72-hour window.
Processor contracts: Sign Article 28 terms with each processor and approve sub-processors.

Check that every checklist item has a named internal owner, a deputy and a dated review, because the evidence will be read as your organization's accountability record.

Where GDPR technical projects usually stall

Most GDPR technical work does not fail on policy text. It stalls on records, contracts and systems that drifted apart after the first documentation sprint. The cards below cover the six places where teams most often find that their evidence no longer matches what their systems actually do, and the check that exposes each gap.

Out-of-date register of processing

The record of processing under Article 30 must list purposes, data subject categories, data categories, recipients, third-country transfers and, where possible, erasure time limits. Records often describe the system as it was at launch, so a new analytics tool or a retained export never appears. Check this by sampling three recent deployments or integrations and confirming each one is in the register with its purpose and recipients. Assign a named owner and a review date to every entry.

Sub-processor lists disconnected from contracts

Processor contracts must set out how sub-processors are engaged, and the list a customer sees should match the processors actually receiving data. When the vendor list lives in a wiki and the signed agreement points to an older version, the two drift apart. Check this by comparing each published sub-processor against the signed contract annex and against the technical systems that transmit data to it. Any mismatch needs an owner and a notice step.

Rights requests without cross-system search

Answering an access or erasure request within one month requires knowing where a person's data sits across applications, data warehouses, support tools and archives. Teams often find that each system has its own identifier and no one can search them together. Check this by running a timed test request for a sample identifier and recording every system that returned data. Gaps found in that test define the connectors or indexes that must be built before a real request arrives.

Backups and logs left out of deletion planning

Erasure plans frequently cover the production database and forget backups, replicas, search indexes, log pipelines and exports. Those copies can keep personal data long after the live record is gone, and the deletion plan then does not reflect reality. Check this by listing every copy of a sample dataset, confirming its retention period, and documenting how erased data is handled when a backup is restored. Write the result into the retention schedule so the position is explicit.

Breach registers never created

Article 33(5) requires the controller to document every personal data breach, including the facts, effects and remedial action, whether or not it was notified. Many organizations have an incident process but no breach register, so near misses and internal breaches leave no trace. Check this by asking for the register from the last twelve months and testing whether it holds entries for minor incidents as well as notified ones. Confirm that the 72-hour clock under Article 33(1) starts from a defined awareness point in the incident workflow.

DPIAs completed after launch

A data protection impact assessment for likely high-risk processing should exist before the processing starts, so that its findings can shape design. Teams often write it after a feature ships, which turns the assessment into a record of decisions already made. Check this by comparing release dates with DPIA sign-off dates for every system that processes special category data, monitors individuals or profiles them. Where the DPIA came late, schedule a review that can still change the design.

What may change in 2026 and what to keep on the checklist now

As of October 2026 the GDPR text has not been amended, so every obligation in this checklist still applies as written. The Omnibus IV proposal (COM(2025) 501) has a text agreed in interinstitutional negotiations on 26 June 2026 and is awaiting Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837) is awaiting committee decision. Neither has changed a rule your systems must follow today, and nobody can say with confidence which parts will survive into the final text. Treat both as watch items on the compliance calendar, not as reasons to remove a record, a deadline or a contract clause.

The practical rule is to keep current obligations on the checklist until an amended text is published in the Official Journal and your data protection lead confirms its effect. Keep the Article 30 record of processing, the one-month rights request clock, the 72-hour breach notification path, the Article 33(5) breach documentation and the Article 28 processor terms in service. Ask your legal or DPO function to log each pending proposal, its current procedural stage and the owner who will review it when the text moves. Where a proposal would relieve a duty, such as a record-keeping exemption, do not switch the duty off in tooling until the change is in force and you have confirmed it applies to your organization.

Regulation (EU) 2025/2518 on additional procedural rules for cross-border enforcement applies from 2 April 2027. It concerns complaints and investigations that span several supervisory authorities, so it is most relevant to organizations processing personal data across several Member States. Plan now for the evidence that will matter in those cases: a current record of processing that shows where data flow, a documented lead authority analysis where relevant, and breach and complaint files that can be produced quickly. Confirm with your counsel which of your processing activities would fall under the cross-border procedures and whether your current case-handling tooling can export that evidence.

How DeployOpen prepares GDPR systems and evidence

DeployOpen works on the systems and evidence behind a GDPR compliance checklist, not on legal opinions. We plan and implement self-hosted open-source platforms in the client's own infrastructure, then prepare the records, controls and documentation that the client's team and an independent assessor can review.

How we scope

Each engagement starts with a written scope listing which checklist items, systems and data flows are covered.
We confirm which records of processing, rights workflows and breach logs must exist before any build begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure access controls, logging, backup and encryption on the platforms in scope, mapped to Article 32 measures.
We set up rights request handling so access, erasure and rectification requests can be found, answered and recorded.
We test breach detection and alerting so the 72-hour notification clock can be met with documented facts.

How we hand over

We document the processing register entries, processor contract inputs, security measures and DPIA inputs for your review.
We deliver runbooks for rights requests and breach documentation, including templates your staff can reuse.
Your organization owns the controls and decisions, and an independent auditor or certification body issues any report.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover updates to records, logs and rights workflows as your systems and processors change.
Confirm with us in the quote which items remain the responsibility of your DPO, legal team or assessor.