What is GDPR compliance? Principles, requirements, and checklist

You may receive a data subject access request on a Friday afternoon. This requires you to provide a complete copy of all personal data you hold within one month. If you do not know the location of that data, the request will cause a difficult search through various departments and old backup files. GDPR compliance requires you to understand your data storage. This ensures that access requests, audits, or new AI projects do not cause unexpected problems for your organisation.

GDPR compliance requires you to understand your data so that subject access requests, audits, or new AI projects do not create unexpected problems. This process is based on seven principles and a specific legal reason for every way you use personal data. You must also maintain documentation, including records of processing, data protection impact assessments, and breach procedures, to provide evidence for your claims.

Shipshape Data builds data and AI systems. GDPR is a factor in almost every project we undertake, regardless of whether a client mentions it. It is impossible to design a functional pipeline, train a model, or create a customer-facing tool without identifying the personal data involved and the legal basis for its use. Since 2018, the consequences for non-compliance have been significant. Penalties can reach €20 million or 4% of global annual turnover, depending on which amount is higher. Regulators throughout Europe have demonstrated that they will apply these maximum fines.

This is a working guide to what GDPR asks of your organisation: the principles behind it, the terms your legal and engineering teams need to share, the lawful bases you can rely on, and the documentation that proves you are doing what you say. It ends with a checklist you can run against your own operation.

Reasons this issue extends beyond legal concerns

Failure to comply with GDPR creates three separate risks that increase in severity when they occur together. Financial penalties are the most visible risk. In 2020, British Airways received a £20 million fine after a data breach affected 400,000 customer records. In France, Google was fined €50 million because of the way it described its data processing methods to users. While these major cases receive media attention, regulators also frequently issue smaller fines and formal warnings to many lesser-known organisations.

Damage to a reputation happens slowly and is difficult to quantify, but it has a significant impact. Most consumers state that they would stop using a service following a major security breach. Trust is difficult to regain once it is lost. Competitors with no history of breaches use their clean records as an advantage during the same bidding processes you are participating in.

Our clients also face pressure regarding artificial intelligence. Automated decision-making is subject to specific regulations. You must be able to explain the logic behind a model's conclusion and ensure a human reviews any outcome that significantly affects a person. You must also provide a way for individuals to challenge these decisions. The principles of purpose limitation and data minimisation apply here as well. You are required to justify every data field used during the training process. If you attempt to add these controls after a model is already live, you will likely need to rebuild the system rather than apply a simple update. Automated decision-making governance must be treated as a design constraint during the first sprint instead of a final approval step at the end of the project.

The audit work required by GDPR and the preparation needed for an AI project are nearly identical. When you map your data flows, document your retention rules, and define ownership, you complete half of the foundational work for an AI rollout.

Who has to comply

The most common mistake we see is a UK or US company assuming GDPR does not apply to them because their office is not in Europe. The location of your business is not the deciding factor. The regulation applies based on whose data you are processing.

The GDPR applies to you if you meet either of two conditions. First, you are covered if you have an establishment in the EU that processes personal data. This includes small branch offices, even if the actual data processing occurs in another location. Second, the law applies if you offer goods or services to individuals in the EU or monitor their behaviour, regardless of where your company is registered. You do not have to charge money for these goods or services to be subject to the law. Actions such as pricing your website in euros, providing a French-language version, or using analytics to track visitors from the EU can be enough to require compliance.

Company size does not change these requirements. A startup with five employees and a corporation with five thousand employees have the same obligations under Articles 5 and 6. Additional requirements scale with the size of the organisation. For example, the rule to appoint a Data Protection Officer only applies once a company reaches specific thresholds for data volume or sensitivity.

If you handle data from UK residents as well as EU residents, you are dealing with two regimes, not one. UK GDPR became separate legislation after Brexit, sharing the same principles but enforced by a different body, the Information Commissioner's Office. Data transfers between the UK and EU currently run on adequacy decisions that could, in principle, be revisited. Watch that status closely.

The words that are important

Legal and engineering teams often have difficulty communicating about GDPR because they use different definitions. You should ensure that everyone agrees on these terms before you begin development rather than waiting until the project is finished.

Personal data is wider than most people assume: it's any information that can be tied back to an identifiable person, not just names and email addresses, including IP addresses, device fingerprints, location history, and behavioural patterns, whether alone or combined with something else you already hold. This matters for AI teams, because a dataset you think is anonymised often isn't, not if re-identification is technically feasible with the data sitting next to it.

A smaller category, special category data, carries tighter rules again: race or ethnicity, political opinion, religion, trade union membership, genetic and biometric data, health data, sex life and sexual orientation. Processing any of this needs an explicit lawful basis, usually consent, and your security around it has to be visibly stronger. Recruitment tools, health applications and financial risk models run into this constantly.

There are two main roles to consider. You are a controller if you determine the purpose and methods of data processing. Most organisations act as controllers for most of their activities. A processor manages data based on instructions from another party. This category includes cloud providers, payroll vendors, and most commercial AI tools. Acting as a controller does not remove your liability for a processor's mistakes. You are still responsible for their failures. Because of this, your vendor contracts must include specific GDPR clauses instead of a single standard sentence in the general terms.

The seven principles everything else hangs off

Article 5 sets out seven principles.

If you understand these concepts thoroughly, the remaining parts of the GDPR consist mostly of specific details.

• You must have a lawful basis to process personal data. You are not allowed to use this data in ways that people would find unexpected or unfair. You must explain how you process data using clear language instead of legal terminology.
• Purpose limitation: you must state your purpose at the start and follow it. You may only use data for a new purpose if you obtain new consent or demonstrate that the new use is compatible with the original one.
• Data minimisation means you should collect only the data you need for a specific purpose. You should not collect data because it might be useful in the future. Most organisations collect too much information because it is their standard practice.
• Maintain accurate data. Refresh information on a regular basis and correct any errors promptly when reported.
• Storage limitation: remove or anonymise data once its original purpose has been fulfilled. Apply retention schedules and make sure they are enforced.
• Preserve data integrity and confidentiality by employing security measures that match the risk level. Regularly test these measures to confirm they stay effective as threats change.
• Accountability: supply continuous documentation and records that demonstrate all the points above. This obligation also covers documentation for each processor you employ.

Transparency is an important aspect for AI because it is hard to uphold. Explaining the operation of a marketing email is straightforward. Yet describing why a model generated a particular score in terms that a non-technical person can grasp is a tough design challenge. GDPR mandates that organisations supply these explanations.

Choosing a lawful basis and the role of consent

Each processing activity must have a lawful basis under Article 6. This requirement covers every task, such as newsletter sign-ups and training models on support transcripts. Choosing the wrong basis leads to applying incorrect obligations to the data. Consequently, privacy notices may be wrong, the wrong individual rights may be applied, and inappropriate rules for international data transfers may be used.

Six legal bases are available: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Consent is commonly used but tends to be the weakest option since individuals may withdraw it at any moment. The contract basis is relevant when processing is needed to deliver a promised service, for example fulfilling a customer order. Legitimate interests provides greater flexibility but demands a documented balancing test. That document must fairly compare your reasons for processing data with the effect on the individual. Legal obligation covers processing that a law requires. Public task and vital interests are applied in particular circumstances that most commercial firms do not face.

Consent must be obtained for special-category data and for most direct electronic marketing. For consent to be valid, it must involve a clear affirmative action. Pre-ticked boxes or silence are not considered consent. Consent requests must be kept separate from other terms and conditions. Draft these requests in plain language so an average person can understand what they agree to. Finally, the method for withdrawing consent must be as straightforward as the method for granting it.

Cookies matter because they are the most recognisable element of the GDPR for most users. Strictly necessary cookies do not need consent. In contrast, cookies used for analytics, advertising, and social sharing do require consent. The technical implementation must block those cookies until a user actively opts in via specific category-level controls. Cookie walls that force a user to accept tracking or to leave the site are encountering increased legal scrutiny across Europe.

Proving it: records, DPIAs, DPOs, and vendor contracts

Accountability is the principle that obliges organisations to document their GDPR compliance. Many organisations fall short of this standard because they do not have the required records to demonstrate legal compliance, even when their internal practices are correct.

Article 30 obliges most organisations to maintain a record of processing activities: what data you hold, why you hold it, who can access it, how long you retain it, and where it is transferred, including any transfers abroad. Create this as a live register that departments truly maintain, rather than a spreadsheet completed once for an audit and never reopened. It pays for itself the day a DSAR is received, because it shows exactly where to look.

A Data Protection Impact Assessment is required when processing activities are likely to pose high risks. This covers systematic monitoring, large-scale processing of special-category data, or automated decision-making that creates legal or significant effects on individuals. You must carry out a DPIA before beginning development. Its purpose is to spot design flaws early, when they are still easy and inexpensive to fix.

Data governance maturity and DPIA quality tend to move together in our experience. Organisations with a real governance function write DPIAs that change designs; organisations without one write DPIAs that describe a system nobody in the room is willing to question.

You must designate a Data Protection Officer when your core activity involves large-scale systematic monitoring or large-scale processing of special-category data. Public authorities must appoint one irrespective of the size of their operations. The officer must be independent and have adequate time and resources to carry out their duties.

You must maintain a written contract with each processor, cloud host, AI vendor, and payroll provider you use. These contracts must contain specific GDPR clauses addressing processing instructions, security requirements, and rules for sub-processors. They must also provide for assistance with data-subject requests. You should read these contracts carefully before signing. If a vendor does not comply with regulations, you share the legal liability.

Data subject rights and the DSAR timeline

The GDPR grants individuals eight specific rights. These include the rights of access, rectification, erasure, restriction, portability, and objection, as well as rights concerning automated decision-making and the right to lodge a complaint with a regulator. The most common of these is the Data Subject Access Request. This happens when a person requests a copy of all information you hold about them.

You have one month to answer the request. You may extend this period by two more months if the request is complex and you inform the individual within the first month. Not knowing where data is located or delays in identity verification are not valid reasons for an extension. You should resolve these procedural issues before a request arrives, not during the response period.

The right to erasure is not absolute. You may deny a request if you need the data to meet a legal obligation, defend a legal claim, or fulfil a contract. If you deny it, you must explain your reasons. Data portability obliges you to supply data in a structured, commonly used, and machine-readable format when a person wishes to transfer their information to a competitor.

Automated decision-making rights grow in importance as you deploy more AI systems. If a model's output creates a legal effect or a similarly significant impact on a person, that individual has the right to request a human review. They may also present their case and challenge the outcome. You should embed this process in the system during the design phase. Adding a human review process later is difficult if the original design omitted it. We often help clients solve this specific problem.

To build a functional DSAR process, begin with identity verification suitable for the request. Direct all requests through a single team to guarantee consistent responses across departments. The search must cover backups and archives as well as the live database. You must also involve your data processors in the search. Before delivering the files, strip any personal data belonging to third parties. Keep a record of the reasons for these redactions.

Security and the 72-hour breach reporting window

Article 32 asks for security measures that match the risk you've assessed, not a generic checklist bought off a shelf. Pseudonymisation, encryption, and access controls built on least privilege are the baseline for most organisations. Test these measures regularly: what counted as adequate protection two years ago isn't automatically adequate today.

Cloud providers and other processors are required to meet the same standards as your organisation. You stay responsible if they suffer a data breach, which means due diligence is needed before you sign a contract with a vendor. You ought to include audit rights in your contracts so you can verify their compliance.

The 72-hour deadline starts as soon as you discover a breach. You must not delay the start of this period until your investigation is finished.

If you experience a data breach, you must notify your supervisory authority within 72 hours. You are only exempt from this requirement if you can demonstrate that the risk to the rights of individuals is low. You are not required to provide all details immediately. You may file an initial report and then supply additional information in stages, as long as the first notification is made within the 72-hour period. If the breach presents a high risk to individuals, you must also inform them directly. This communication should be written in simple language that explains the nature of the breach and the actions they need to take.

A breach is not limited to unauthorised system access by a hacker. Sending an email to the wrong person, losing a laptop, or an employee viewing records without a business need all count as breaches. Your incident response process must recognise these events just as consistently as it recognises a ransomware attack.

A practical GDPR compliance checklist

Follow these steps in the order presented. Organisations that skip the first stage often spend a long time correcting compliance issues.

Start with an honest audit. Map every system that touches personal data: what you collect, where it resides, who can access it, how long you retain it, and which third parties receive it. This is where shadow IT and half-forgotten databases appear, and it serves as the record on which everything else on this list depends. While you are at it, verify the lawful basis for each processing activity you identify; it is common to find activities based on consent that should actually rely on legitimate interests, or on no documented basis at all.

• Update your privacy notices to describe your specific data processing activities in plain language rather than using a generic template.
• Install a cookie consent tool that blocks non-essential cookies from loading until a user gives consent. The tool must enable users to control settings for specific cookie categories.
• Create a DSAR workflow that incorporates identity verification, centralised management, and a search process for backups and third-party processors.
• Implement encryption and least-privilege access controls. Adjust these measures based on the sensitivity of the data you store.
• Write retention schedules and automate deletion wherever you can
• Establish breach detection and an escalation process that enables you to meet the 72-hour notification deadline.
• Review every vendor contract to confirm it contains the specific GDPR clauses required. Do not accept general references to applicable law.
• Run DPIAs on high-risk processing before you build it, especially anything involving AI or automated decisions.

Regulatory requirements evolve and your data volume grows. The AI systems you develop later will need different compliance standards than those applied to earlier data processing. You should treat GDPR as an ongoing maintenance task rather than a finished project.

Where this leaves you

GDPR compliance, beneath the terminology, reduces to knowing your own data: what you hold, why you hold it, who can access it, and how long it remains. All other elements-the DPIAs, the DSAR workflows, the breach procedures-are built on that knowledge. Organisations that skip the mapping step often perform this work twice: first poorly under audit pressure, then correctly afterwards.

If you are building AI systems or updating your data infrastructure, you should not treat these tasks as separate projects to be added later. The GDPR work-data mapping, retention, and governance-offers the same foundation your AI initiatives need to be reliable.

We assist organisations with this type of foundational work before it becomes a critical issue. If you would like to identify your specific compliance gaps, talk to us.

Our data consultants build these systems for UK organisations. We prioritise the foundation first to ensure the results are reliable.

Frequently asked questions