\n| European Data Protection Board<\/td>\n | Body of all supervisory authorities (Art. 68)<\/td>\n | Issues guidelines, opinions and binding decisions on cross-border disputes<\/td>\n | EDPB guidelines on consent, transfers and anonymisation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWho is a controller and who is a processor?<\/h3>\nThe controller is the organisation that decides why<\/em> and how<\/em> personal data is processed. The processor executes those decisions. The determination test is factual, not contractual: you cannot escape controller obligations by labelling yourself a processor in a contract if you in reality decide the purposes and means.<\/p>\nSeveral patterns trip organisations up. A SaaS provider that processes customer data strictly according to documented instructions is a processor \u2014 but if it reuses that data for its own product analytics, benchmarking or AI model training, it becomes a controller for that activity and needs its own lawful basis. A marketing agency that decides which audience segments to target is a controller even though its client owns the customer relationship. Where purposes are set jointly, Article 26 joint controllership applies and an arrangement must be documented.<\/p>\n The practical consequence: one organisation can hold several roles simultaneously for different processing activities. Mature GDPR compliance programmes maintain a role map per data flow rather than a single organisation-wide label.<\/p>\n What Are the Seven Principles of GDPR Compliance?<\/h2>\nArticle 5 contains the seven principles that govern everything else in the regulation. Every right, obligation, DPIA and fine ultimately traces back to one of them. Read as a list they look abstract; read as engineering requirements they are highly specific.<\/p>\n The seven principles, one by one<\/h3>\n1. Lawfulness, fairness and transparency \u2014 Article 5(1)(a).<\/strong> Processing must rest on one of the six lawful bases in Article 6, must not be unduly detrimental, unexpected or misleading to the data subject, and must be communicated clearly. In engineering terms this is a field in your processing register, a purpose tag on every data flow, and a privacy notice that a non-lawyer can understand.<\/p>\n2. Purpose limitation \u2014 Article 5(1)(b).<\/strong> Data collected for one specified, explicit and legitimate purpose cannot be repurposed for an incompatible one. Compatibility is assessed considering the link between purposes, the context of collection, the nature of the data, the consequences for data subjects and the existence of safeguards. Reusing a customer’s billing address for fraud screening is usually compatible; reusing it to train a general-purpose AI model is usually not.<\/p>\n3. Data minimisation \u2014 Article 5(1)(c).<\/strong> Collect only what is adequate, relevant and limited to what is necessary. This is the principle most frequently violated by analytics implementations, CRM lead forms and log pipelines that capture more than anyone can justify. Every additional field increases breach exposure, DSAR effort and storage cost.<\/p>\n4. Accuracy \u2014 Article 5(1)(d).<\/strong> Personal data must be accurate and, where necessary, kept up to date, with reasonable steps taken to erase or rectify inaccurate data without delay. Practically, this means data quality controls, duplicate management, correction workflows that propagate to downstream systems including analytics and backups.<\/p>\n5. Storage limitation \u2014 Article 5(1)(e).<\/strong> Data must not be kept in identifiable form longer than necessary. The word “necessary” requires an actual retention schedule per data category and purpose, plus automated enforcement. Retention schedules that exist only in a policy document but not in code are the most common audit finding in the entire regulation.<\/p>\n6. Integrity and confidentiality \u2014 Article 5(1)(f).<\/strong> Appropriate technical and organisational security measures, including protection against unauthorised or unlawful processing, accidental loss, destruction or damage. Article 32 elaborates: pseudonymisation and encryption, ongoing confidentiality and integrity assurance, resilience, restoration capability and regular testing.<\/p>\n7. Accountability \u2014 Article 5(2).<\/strong> The controller is responsible for demonstrating compliance with the other six principles. Accountability is the meta-principle that converts intention into evidence, and it is the reason records of processing, DPIAs, training logs and design documentation exist.<\/p>\nHow does accountability change what you must build?<\/h3>\nAccountability has an uncomfortable implication that IT leaders should internalise early: the absence of evidence is treated as evidence of absence.<\/strong> A supervisory authority does not need to prove that you processed data unlawfully. It can ask you to demonstrate compliance, and if you cannot, the accountability principle itself is breached.<\/p>\nThat reframes several engineering decisions. A consent management platform that records the exact wording, timestamp, interface version and scope of each consent is not bureaucracy; it is the evidence that makes the lawfulness principle defensible. A DPIA that documents considered risks and rejected alternatives is not overhead; it is the artefact that shows accountability. A CI\/CD pipeline that runs privacy-relevant tests and archives the results is a compliance control, not just a quality control.<\/p>\n Accountability also demands that compliance is monitored rather than assumed. Article 32(1)(d) explicitly requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. This is where testing discipline becomes a GDPR requirement rather than a nice-to-have.<\/p>\n The seven principles mapped to concrete controls<\/h3>\n\n\n\n| Principle<\/th>\n | Article<\/th>\n | What it demands of the business<\/th>\n | Concrete IT and engineering controls<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Lawfulness, fairness and transparency<\/td>\n | 5(1)(a)<\/td>\n | A valid lawful basis and honest, clear communication<\/td>\n | Processing register with a lawful basis field per activity; consent management platform; layered privacy notices; purpose tagging in data pipelines<\/td>\n<\/tr>\n | \n| Purpose limitation<\/td>\n | 5(1)(b)<\/td>\n | No repurposing without a compatibility assessment or new basis<\/td>\n | Data catalogue with purpose metadata; access controls scoped by purpose; change control that flags new use cases; separation of production and analytics datasets<\/td>\n<\/tr>\n | \n| Data minimisation<\/td>\n | 5(1)(c)<\/td>\n | Collect only what is necessary<\/td>\n | Schema review gates; mandatory-field justification in design reviews; form and API field audits; log redaction policies; disabling default telemetry collection<\/td>\n<\/tr>\n | \n| Accuracy<\/td>\n | 5(1)(d)<\/td>\n | Data must be accurate and correctable<\/td>\n | Master data management; duplicate detection; correction propagation to downstream systems, caches and derived datasets; documented rectification SLA<\/td>\n<\/tr>\n | \n| Storage limitation<\/td>\n | 5(1)(e)<\/td>\n | Defined retention periods, enforced<\/td>\n | Retention schedule per data category; automated deletion and archival jobs; backup expiry alignment; deletion verification reporting<\/td>\n<\/tr>\n | \n| Integrity and confidentiality<\/td>\n | 5(1)(f), 32<\/td>\n | Security proportionate to risk<\/td>\n | Encryption in transit and at rest; key management; pseudonymisation; least-privilege RBAC; MFA; logging and monitoring; backup and restore testing; vulnerability management; penetration testing<\/td>\n<\/tr>\n | \n| Accountability<\/td>\n | 5(2), 24<\/td>\n | Demonstrate compliance on demand<\/td>\n | Records of processing (Art. 30); DPIA repository; training records; audit trails; privacy requirements in the definition of done; test evidence retention<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat Are the Lawful Bases for Processing Personal Data?<\/h2>\nProcessing personal data is prohibited unless a lawful basis applies. Article 6 provides six. Choosing correctly matters because the basis determines what you can do, what you must tell data subjects, and whether they can object or withdraw.<\/p>\n The six lawful bases under Article 6<\/h3>\nConsent \u2014 Article 6(1)(a).<\/strong> Any freely given, specific, informed and unambiguous indication of the data subject’s wishes. Consent must be as easy to withdraw as to give, must not be bundled into unrelated terms, and must meet a higher standard for explicit consent under Article 9(2)(a). Consent is the most over-used basis and the most fragile, because it can be withdrawn at any moment and requires a full audit trail.<\/p>\nContract \u2014 Article 6(1)(b).<\/strong> Processing necessary for the performance of a contract with the data subject, or to take steps at their request before entering one. This covers order fulfilment, delivery, account management and payment processing \u2014 but not marketing, analytics or product improvement, which are separate purposes requiring separate bases.<\/p>\nLegal obligation \u2014 Article 6(1)(c).<\/strong> Processing necessary to comply with a legal obligation to which the controller is subject, and the obligation must be in Union or member state law. Tax records, anti-money-laundering checks, employment law duties and statutory reporting fall here. The obligation must be specific; a general desire to retain data defensively does not qualify.<\/p>\nVital interests \u2014 Article 6(1)(d).<\/strong> Processing necessary to protect someone’s life. This is a narrow basis intended for emergencies \u2014 medical treatment, disaster response, safeguarding \u2014 and is not a general-purpose fallback for health-related data.<\/p>\nPublic task \u2014 Article 6(1)(e).<\/strong> Processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority. Relevant to public bodies and to organisations exercising functions of a public nature.<\/p>\nLegitimate interests \u2014 Article 6(1)(f).<\/strong> Processing necessary for legitimate interests pursued by the controller or a third party, unless overridden by the interests or fundamental rights and freedoms of the data subject. This is the most flexible basis and the one requiring the most discipline: a legitimate interests assessment must document the interest, the necessity of the processing, the balancing test against the data subject’s rights, and the safeguards applied. It is unavailable to public authorities for their public tasks, and it is never available for processing by public authorities in the performance of their duties.<\/p>\nTwo rules govern selection. First, you must choose before processing begins<\/strong>, not retro-fit a basis after a complaint. Second, the basis must be identified in your privacy notice<\/strong> under Article 13(1)(c) and 14(1)(d), and you cannot swap bases at will \u2014 switching from legitimate interests to consent mid-processing is generally not permissible, because consent obtained under pressure of “consent or we stop” is not freely given.<\/p>\nWhat changes when you process special category data?<\/h3>\nArticle 9(1) prohibits processing of special category data \u2014 racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for unique identification, health data, and data on sex life or sexual orientation \u2014 unless one of the Article 9(2) conditions applies. These include explicit consent, employment and social security law obligations, vital interests where the subject cannot consent, data manifestly made public by the subject, legal claims, substantial public interest, preventive or occupational medicine, public health, and archiving or research purposes.<\/p>\n Most Article 9(2) conditions require a basis in Union or member state law, which means the practical analysis is jurisdiction-specific. Article 10 adds a further layer: processing personal data relating to criminal convictions and offences requires authorisation by Union or member state law or the control of an official authority.<\/p>\n For IT teams, the operational implications are direct. Special category data demands stronger controls \u2014 typically encryption with separate key management, strict purpose-based access, enhanced audit logging, and frequently a DPIA because the risk threshold in Article 35(3)(b) is met by large-scale processing of this data. Biometric authentication deserves particular caution: if the biometric template is used for unique identification, it is special category data even when the template is a mathematical representation rather than an image.<\/p>\n Lawful bases in practice<\/h3>\n\n\n\n| Lawful basis<\/th>\n | Definition<\/th>\n | Typical enterprise use case<\/th>\n | Common failure mode<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Consent \u2014 Art. 6(1)(a)<\/td>\n | Freely given, specific, informed, unambiguous indication of wishes<\/td>\n | Marketing emails to prospects; non-essential cookies; optional profiling<\/td>\n | Pre-ticked boxes, bundled consent, no withdrawal mechanism, consent walls that make the service conditional on unrelated consent<\/td>\n<\/tr>\n | \n| Contract \u2014 Art. 6(1)(b)<\/td>\n | Necessary to perform a contract with the data subject<\/td>\n | Order processing, delivery, account provisioning, support<\/td>\n | Using contract as the basis for analytics, personalisation or marketing that is not necessary to deliver the service<\/td>\n<\/tr>\n | \n| Legal obligation \u2014 Art. 6(1)(c)<\/td>\n | Necessary to comply with a specific legal duty<\/td>\n | Tax and accounting records; AML\/KYC checks; statutory employment records<\/td>\n | Citing legal obligation without identifying the specific statute; using it to justify open-ended retention<\/td>\n<\/tr>\n | \n| Vital interests \u2014 Art. 6(1)(d)<\/td>\n | Necessary to protect life<\/td>\n | Emergency medical data sharing; disaster response<\/td>\n | Treating it as a general basis for health-related processing<\/td>\n<\/tr>\n | \n| Public task \u2014 Art. 6(1)(e)<\/td>\n | Necessary for a task in the public interest or official authority<\/td>\n | Municipal services; statutory registries; publicly funded research<\/td>\n | Private organisations claiming public task without a legal mandate<\/td>\n<\/tr>\n | \n| Legitimate interests \u2014 Art. 6(1)(f)<\/td>\n | Necessary for legitimate interests, unless overridden by data subject rights<\/td>\n | Network and information security; fraud prevention; intra-group administration; some direct marketing to existing customers<\/td>\n | No documented balancing test; using it where consent is required; ignoring the absolute right to object to direct marketing<\/td>\n<\/tr>\n | \n| Explicit consent for special category data \u2014 Art. 9(2)(a)<\/td>\n | Explicit, specific consent to process Article 9 data<\/td>\n | Health app data; diversity monitoring on a voluntary basis; accessibility accommodations<\/td>\n | Treating ordinary consent as explicit consent; no separate granular consent per data type<\/td>\n<\/tr>\n | \n| Substantial public interest \u2014 Art. 9(2)(g)<\/td>\n | Processing on a Union or member state law basis for a substantial public interest<\/td>\n | Anti-fraud registers; safeguarding; whistleblowing schemes<\/td>\n | Assuming a general commercial interest qualifies<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat Rights Do Data Subjects Have and How Do You Fulfil Them?<\/h2>\nData subject rights are where GDPR compliance becomes an operational service with deadlines. Each right has a trigger, a response window and an evidence trail, and each one touches multiple systems.<\/p>\n The eight data subject rights explained<\/h3>\nRight to be informed \u2014 Articles 13\u201314.<\/strong> Data subjects must receive specific information at the point of collection, including the identity of the controller, purposes, lawful basis, recipients, transfers, retention periods, rights and the right to lodge a complaint. Where data is not obtained directly from the subject, information must be provided within one month (or at first communication, whichever comes first).<\/p>\nRight of access \u2014 Article 15.<\/strong> Data subjects may obtain confirmation of whether their data is processed, a copy of it, and details including purposes, categories, recipients, retention and the existence of automated decision-making. This is the highest-volume right in practice and the one that most often exposes poor data mapping, because a response must cover every system holding the individual’s data \u2014 including logs, backups, support tickets, spreadsheets and shadow IT.<\/p>\nRight to rectification \u2014 Article 16.<\/strong> Inaccurate data must be corrected without undue delay, and incomplete data completed. Correction must propagate to downstream systems, derived datasets and analytics.<\/p>\nRight to erasure \u2014 Article 17.<\/strong> Also known as the right to be forgotten. It applies where data is no longer necessary, consent is withdrawn, the subject objects and there is no overriding legitimate ground, processing was unlawful, or a legal obligation requires erasure. It is not absolute: it does not apply where processing is necessary for legal compliance, legal claims, public health, or archiving and research in the public interest. Deletion must extend to third parties to whom data was disclosed.<\/p>\nRight to restriction of processing \u2014 Article 18.<\/strong> Processing can be paused while accuracy or lawfulness is contested. Technically this is a status flag that must suppress all processing while preserving the record.<\/p>\nRight to data portability \u2014 Article 20.<\/strong> Where processing is based on consent or contract and carried out by automated means, the subject may receive their data in a structured, commonly used, machine-readable format and have it transmitted to another controller where technically feasible.<\/p>\nRight to object \u2014 Article 21.<\/strong> Subjects may object to processing based on legitimate interests or public task, and the controller must stop unless it demonstrates compelling legitimate grounds. For direct marketing, the right is absolute and unconditional: processing must stop as soon as the objection is received.<\/p>\nRights related to automated decision-making \u2014 Article 22.<\/strong> Data subjects have the right not to be subject to decisions based solely on automated processing, including profiling, that produce legal effects or similarly significantly affect them \u2014 unless necessary for a contract, authorised by law, or based on explicit consent. Where such decisions are permitted, safeguards must include human intervention, an explanation of the logic, and the ability to contest the decision. This article is increasingly relevant to credit scoring, recruitment screening, insurance pricing and AI-driven fraud detection.<\/p>\nHow do you operationalise a data subject access request?<\/h3>\nA DSAR is an access request under Article 15 and must be answered within one month<\/strong> of receipt. That period may be extended by a further two months for complex or numerous requests, but the extension must be communicated with reasons within the first month. The clock starts when the request is received by any part of the organisation, not when it reaches the privacy team.<\/p>\nVerification is permitted and expected. A controller may ask for information necessary to confirm identity, but must not collect more than needed for that purpose. Where the request is manifestly unfounded or excessive, a reasonable fee may be charged or the request refused \u2014 but the burden of demonstrating that is on the controller.<\/p>\n A working DSAR process needs six components:<\/p>\n \n- A single intake channel<\/strong> that is published in the privacy notice and monitored, with every request logged on receipt.<\/li>\n
- A documented search scope<\/strong> listing every system, database, log store, backup, mailbox and third-party processor that may hold personal data for that individual.<\/li>\n
- A retrieval workflow<\/strong> including assistance from processors, who must respond under Article 28(3)(e).<\/li>\n
- A redaction step<\/strong> to remove third-party data and any legally privileged or exempt material, with the exemption basis recorded.<\/li>\n
- A secure delivery mechanism<\/strong> \u2014 encrypted transfer or an authenticated portal \u2014 never plain email attachment.<\/li>\n
- A closure log<\/strong> recording dates, decisions, exemptions applied and evidence retained for accountability.<\/li>\n<\/ol>\n
Organisations that handle DSARs well almost always invested in data mapping first. You cannot retrieve what you have never inventoried, and the 30-day clock is unforgiving of discovery work.<\/p>\n Data subject rights at a glance<\/h3>\n\n\n\n| Right<\/th>\n | Article<\/th>\n | Trigger<\/th>\n | Response window<\/th>\n | Typical system touchpoints<\/th>\n<\/tr>\n<\/thead>\n | \n\n| To be informed<\/td>\n | 13\u201314<\/td>\n | Collection of personal data<\/td>\n | At collection; within 1 month if data obtained indirectly<\/td>\n | Website, app onboarding, privacy notice CMS, CRM<\/td>\n<\/tr>\n | \n| Of access<\/td>\n | 15<\/td>\n | Subject request<\/td>\n | 1 month (extendable by 2 months with notice)<\/td>\n | CRM, ERP, data warehouse, logs, mailboxes, support tickets, processor systems<\/td>\n<\/tr>\n | \n| To rectification<\/td>\n | 16<\/td>\n | Inaccurate or incomplete data<\/td>\n | 1 month<\/td>\n | Master data systems, downstream caches, analytics, exports already shared<\/td>\n<\/tr>\n | \n| To erasure<\/td>\n | 17<\/td>\n | Request or legal trigger; no overriding ground<\/td>\n | 1 month<\/td>\n | All production stores, backups, derived datasets, third-party processors, search indexes<\/td>\n<\/tr>\n | \n| To restriction<\/td>\n | 18<\/td>\n | Contested accuracy or lawfulness<\/td>\n | 1 month<\/td>\n | Processing flags, workflow engines, API gateways, marketing suppression lists<\/td>\n<\/tr>\n | \n| To data portability<\/td>\n | 20<\/td>\n | Consent- or contract-based automated processing<\/td>\n | 1 month<\/td>\n | Export services, schema documentation, format converters<\/td>\n<\/tr>\n | \n| To object<\/td>\n | 21<\/td>\n | Objection to legitimate interests or public task<\/td>\n | 1 month; immediate for direct marketing<\/td>\n | Marketing automation, consent platform, suppression lists, ad platforms<\/td>\n<\/tr>\n | \n| Automated decision-making<\/td>\n | 22<\/td>\n | Decision based solely on automated processing<\/td>\n | 1 month<\/td>\n | Scoring engines, ML models, decision logs, human review queues<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat Are the Core Operational Requirements of GDPR Compliance?<\/h2>\nBeyond the principles and rights, the GDPR imposes a set of named operational obligations. Each has a trigger condition, a required deliverable and a natural owner. Treating them as a checklist of documents is the fastest route to an audit finding; treating them as controls with owners is the fastest route to durable compliance.<\/p>\n Records of processing activities and data mapping \u2014 Article 30<\/h3>\nArticle 30 requires controllers and processors to maintain a record of processing activities. For controllers the record must include the purposes, categories of data subjects and personal data, recipients, third-country transfers and safeguards, retention periods, and, where possible, security measures. Organisations with fewer than 250 employees benefit from a limited exemption, but the exemption is narrower than it appears: it does not apply where processing is not occasional, where it is likely to result in a risk to rights and freedoms, or where it involves special category data \u2014 conditions that describe most commercial data processing.<\/p>\n The record is only as good as the data mapping behind it. A useful map is built from system-level discovery, not from interviews. It should answer, for every field of personal data: which system holds it, who owns it, what the purpose is, which lawful basis applies, who accesses it, where it is transferred, how long it is retained and how it is deleted. In most organisations this is the single largest piece of work in the entire programme \u2014 and the foundation for everything else.<\/p>\n Data protection by design and by default \u2014 Article 25<\/h3>\nArticle 25 requires data protection to be embedded into processing from the outset and, by default, to apply the most privacy-protective settings without the data subject having to act. “By default” is the clause that catches organisations out: an application that shares profile data publicly unless the user finds a setting has failed the test, regardless of how well documented the setting is.<\/p>\n Implementing Article 25 means privacy requirements enter the development lifecycle as testable criteria, not as a legal appendix. Typical design patterns include data minimisation at the schema level, pseudonymisation as a default for analytical use, purpose-bound access tokens, automated retention enforcement, consent state as a first-class attribute in the data model, and privacy-protective default settings in user interfaces.<\/p>\n Data Protection Impact Assessments \u2014 Article 35<\/h3>\nA DPIA is required where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) identifies three cases that almost always trigger one: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the subject; large-scale processing of special category data or criminal offence data; and systematic monitoring of a publicly accessible area on a large scale.<\/p>\n Supervisory authorities publish lists of processing operations requiring a DPIA, and the EDPB’s criteria \u2014 evaluation or scoring, automated decision-making with legal or similar effect, systematic monitoring, sensitive data, data processed on a large scale, matching or combining datasets, data concerning vulnerable subjects, innovative use of technology, and processing that prevents data subjects from exercising a right \u2014 are used to determine whether the threshold is crossed. Two or more criteria normally indicate that a DPIA is required.<\/p>\n A defensible DPIA is a structured risk assessment, not a form. It should describe the processing systematically, assess necessity and proportionality against the purpose, identify risks to data subjects, define mitigation measures, record the advice of the DPO where one exists, and document the decision taken \u2014 including a decision to proceed with residual risk, which must be recorded and, where the residual risk remains high, consulted on with the supervisory authority under Article 36.<\/p>\n Do you need a Data Protection Officer? \u2014 Articles 37\u201339<\/h3>\nA DPO is mandatory in three situations under Article 37(1): where processing is carried out by a public authority or body, except for courts acting in their judicial capacity; where the core activities of the controller or processor consist of processing operations which, by virtue of their nature, scope or purposes, require regular and systematic monitoring of data subjects on a large scale; and where the core activities consist of large-scale processing of special category data or of personal data relating to criminal convictions and offences.<\/p>\n The DPO must be involved properly, must report to the highest management level, must not receive instructions regarding the exercise of their tasks, must not be dismissed or penalised for performing them, and must have adequate resources. A DPO may be external under a service contract, which is common in mid-sized organisations that need independence without a full-time hire. The tasks are set out in Article 39: informing and advising, monitoring compliance including training and audits, advising on DPIAs, cooperating with the supervisory authority and acting as the contact point. A DPO who is also the head of IT, the CISO or the head of marketing creates a structural conflict of interest that regulators have repeatedly criticised.<\/p>\n Controller\u2013processor contracts and due diligence \u2014 Article 28<\/h3>\nWhere processing is carried out on behalf of a controller, Article 28 requires a written contract that binds the processor to specific terms: processing only on documented instructions, confidentiality, Article 32 security measures, authorisation before engaging sub-processors, assistance with data subject rights and DPIAs, breach notification to the controller, deletion or return of data at the end of the engagement, and audit and inspection rights. The contract must also specify the subject matter, duration, nature and purpose of processing, the type of personal data and the categories of data subjects.<\/p>\n Contracts alone are not due diligence. Article 28(1) requires the controller to use only processors providing sufficient guarantees, which means assessing security posture before onboarding \u2014 certifications, penetration test summaries, sub-processor transparency, breach history, data residency options and incident response commitments. This assessment must be repeated periodically, because a processor’s posture changes as it grows, is acquired or adopts new AI features that reuse customer data.<\/p>\n Security of processing and breach notification \u2014 Articles 32\u201334<\/h3>\nArticle 32 requires technical and organisational measures appropriate to the risk, and explicitly names pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore availability and access after an incident, and a process for regularly testing and evaluating the effectiveness of measures. It also allows adherence to an approved certification mechanism as an element of demonstrating compliance.<\/p>\n Article 33 requires notification of a personal data breach to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours<\/strong> after becoming aware of it. The notification must describe the nature of the breach, categories and approximate numbers of data subjects and records concerned, the DPO or contact point, likely consequences, and measures taken or proposed. Where notification is not made within 72 hours, it must be accompanied by reasons for the delay. Where the breach is unlikely to result in a risk to rights and freedoms, notification is not required \u2014 but the decision must still be documented internally, and processors must notify controllers without undue delay under Article 33(2).<\/p>\nArticle 34 requires communication to data subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms, unless the data was rendered unintelligible through encryption, subsequent measures have eliminated the high risk, or communication would involve disproportionate effort. In the last case, a public communication is required instead.<\/p>\n The 72-hour clock is a capability requirement, not a paperwork requirement. Meeting it means having detection, triage criteria, severity classification, escalation paths, legal review and notification templates all prepared in advance \u2014 and having practised them. Organisations that test breach response through tabletop exercises and simulated incidents routinely meet the deadline. Organisations that write a policy and never rehearse it do not.<\/p>\n International data transfers after Schrems II<\/h3>\nChapter V restricts transfers of personal data outside the EEA. Transfers are lawful where the Commission has adopted an adequacy decision, or, in the absence of adequacy, where appropriate safeguards apply. The main safeguards are standard contractual clauses (SCCs), binding corporate rules, approved codes of conduct and certification mechanisms. The 2021 SCCs require a transfer impact assessment that analyses the laws and practices of the destination country and, where necessary, implements supplementary measures.<\/p>\n The adequacy landscape has become more complex. The EU\u2013US Data Privacy Framework provides an adequacy route for organisations that certify under it, while the earlier Privacy Shield was invalidated by the Court of Justice in 2020 in the Schrems II judgment. Because adequacy decisions can be challenged, mature programmes avoid treating any single transfer mechanism as permanently settled. Practical steps include maintaining a transfer register, reviewing vendor data residency and sub-processor chains, applying encryption and key custody arrangements that keep keys in the EEA where risk requires it, and documenting transfer impact assessments per destination and per data type.<\/p>\n Core operational obligations at a glance<\/h3>\n\n\n\n| Obligation<\/th>\n | Article<\/th>\n | Trigger<\/th>\n | Required deliverable<\/th>\n | Typical owner<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Records of processing<\/td>\n | 30<\/td>\n | Any processing (exemption is narrow)<\/td>\n | Maintained record of processing activities, kept current<\/td>\n | Privacy office with system owners<\/td>\n<\/tr>\n | \n| Data protection by design and by default<\/td>\n | 25<\/td>\n | Any new or changed processing<\/td>\n | Privacy requirements in design; privacy-protective defaults<\/td>\n | Architecture and engineering leads<\/td>\n<\/tr>\n | \n| Data Protection Impact Assessment<\/td>\n | 35<\/td>\n | High-risk processing; Art. 35(3) cases; authority lists<\/td>\n | Documented DPIA with risks, mitigations and decision<\/td>\n | Business owner with DPO advice<\/td>\n<\/tr>\n | \n| Data Protection Officer<\/td>\n | 37\u201339<\/td>\n | Public authority, large-scale monitoring, large-scale special category data<\/td>\n | Appointed, independent, resourced DPO<\/td>\n | Board \/ executive leadership<\/td>\n<\/tr>\n | \n| Processor contracts<\/td>\n | 28<\/td>\n | Any processor engagement<\/td>\n | Article 28-compliant contract plus due diligence record<\/td>\n | Procurement with legal<\/td>\n<\/tr>\n | \n| Security of processing<\/td>\n | 32<\/td>\n | All processing<\/td>\n | Risk-appropriate measures plus regular testing evidence<\/td>\n | CISO and engineering<\/td>\n<\/tr>\n | \n| Breach notification<\/td>\n | 33\u201334<\/td>\n | Awareness of a personal data breach<\/td>\n | Authority notification within 72 hours; subject notification where high risk<\/td>\n | Incident response with DPO<\/td>\n<\/tr>\n | \n| International transfers<\/td>\n | 44\u201349<\/td>\n | Transfer outside the EEA<\/td>\n | Adequacy basis or safeguards plus transfer impact assessment<\/td>\n | Legal with architecture<\/td>\n<\/tr>\n | \n| Prior consultation<\/td>\n | 36<\/td>\n | Residual high risk after DPIA<\/td>\n | Consultation with the supervisory authority before processing<\/td>\n | DPO with business owner<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nHow Does GDPR Compliance Differ From Other Data Protection Laws?<\/h2>\nMultinational organisations rarely face a single privacy regime. Understanding where the GDPR sits relative to its neighbours prevents the common error of building one control set and assuming it travels.<\/p>\n GDPR vs CCPA\/CPRA<\/h3>\nThe California Consumer Privacy Act, as amended by the California Privacy Rights Act, is a consumer privacy law with a different architecture. It applies to for-profit businesses meeting revenue or data-volume thresholds and dealing with California residents, and it is built around rights over “personal information” and “sensitive personal information”. It requires notice at collection, rights to know, delete, correct, opt out of sale or sharing, and limit use of sensitive data, and it is enforced primarily by the California Privacy Protection Agency and the Attorney General with civil penalties rather than administrative fines based on global turnover.<\/p>\n The practical differences that matter to engineering teams are the opt-out model (CCPA\/CPRA allows sale and sharing unless the consumer opts out, whereas the GDPR requires a lawful basis before processing begins), the absence of a general lawful basis framework in California, the narrower definition of sensitive data, and the different treatment of employee and B2B data, which the GDPR covers fully. A well-built GDPR programme usually satisfies much of the CCPA\/CPRA, but the consent architecture is genuinely different and cannot simply be reused.<\/p>\n GDPR vs UK GDPR<\/h3>\nFollowing the UK’s withdrawal from the EU, the UK retained the GDPR in domestic law as the UK GDPR, read alongside the Data Protection Act 2018. The two texts were substantially identical at the point of divergence, which means a single compliance programme can cover both. Divergence is nonetheless cumulative: the UK has pursued its own reform agenda, its own international transfer framework with its own adequacy regulations, its own approach to some consent and cookies questions, and its own regulator in the Information Commissioner’s Office. For organisations operating in both markets, the practical approach is a common core control set with a documented register of jurisdiction-specific deviations.<\/p>\n GDPR vs LGPD, PIPL and other regimes<\/h3>\nBrazil’s LGPD borrows heavily from the GDPR’s structure, with lawful bases, data subject rights, a national authority in the ANPD and administrative sanctions, but it includes a distinct legal basis of credit protection and different rules on legitimate interest. China’s PIPL combines GDPR-like concepts with a state-security framing, requires separate consent in more situations, imposes data localisation and security assessment obligations for certain transfers, and has no independent supervisory authority in the European sense. India’s DPDP Act takes yet another approach, with a consent-manager model and government-designated significant data fiduciaries. Switzerland’s revised FADP is close enough to the GDPR to be managed within the same programme, with its own registration and notification nuances.<\/p>\n The strategic conclusion for a CTO is that global privacy architecture should be modular: a common data inventory, a common rights engine and a common security baseline, with jurisdiction-specific decision layers for lawful basis, consent, transfer and retention. Attempting a single global policy produces either over-compliance that costs money or under-compliance that costs more.<\/p>\n Cross-jurisdiction comparison<\/h3>\n\n\n\n| Dimension<\/th>\n | EU GDPR<\/th>\n | UK GDPR<\/th>\n | CCPA\/CPRA (California)<\/th>\n | LGPD (Brazil)<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Core model<\/td>\n | Rights-based, accountability-driven<\/td>\n | Substantially aligned with EU GDPR<\/td>\n | Consumer rights and opt-out model<\/td>\n | Rights-based, GDPR-inspired<\/td>\n<\/tr>\n | \n| Who is covered<\/td>\n | Any organisation processing EU data subjects’ data, including non-EU organisations<\/td>\n | Processing by UK controllers and processors<\/td>\n | For-profit businesses meeting revenue or data thresholds<\/td>\n | Processing in Brazil or of data collected in Brazil<\/td>\n<\/tr>\n | \n| Lawful basis framework<\/td>\n | Six bases under Art. 6, plus Art. 9 for special categories<\/td>\n | Six bases, closely mirroring Art. 6<\/td>\n | No general lawful basis framework; notice and opt-out<\/td>\n | Ten legal bases including credit protection and legitimate interest<\/td>\n<\/tr>\n | \n| Consent model<\/td>\n | Opt-in, freely given, specific, withdrawable<\/td>\n | Opt-in, similar standard<\/td>\n | Opt-out for sale and sharing; opt-in for minors’ data<\/td>\n | Opt-in with specific requirements for sensitive data<\/td>\n<\/tr>\n | \n| Sensitive data<\/td>\n | Special categories under Art. 9 with prohibition and derogations<\/td>\n | Same structure as EU GDPR<\/td>\n | “Sensitive personal information” with right to limit use<\/td>\n | Sensitive data with stricter bases<\/td>\n<\/tr>\n | \n| DPO requirement<\/td>\n | Mandatory in three defined situations<\/td>\n | Similar triggers<\/td>\n | No DPO; no equivalent role<\/td>\n | Data protection officer required in defined cases<\/td>\n<\/tr>\n | \n| Breach notification<\/td>\n | 72 hours to supervisory authority; subjects if high risk<\/td>\n | 72 hours to the ICO; subjects if high risk<\/td>\n | No general breach notification; state laws govern<\/td>\n | Reasonable timeframe to ANPD and data subjects<\/td>\n<\/tr>\n | \n| Maximum penalty<\/td>\n | \u20ac20m or 4% of global annual turnover, whichever is higher<\/td>\n | \u00a317.5m or 4% of global turnover<\/td>\n | USD 2,500 per violation, 7,500 for minors’ data<\/td>\n | 2% of Brazilian revenue, capped at R$50m per infraction<\/td>\n<\/tr>\n | \n| Regulator<\/td>\n | National supervisory authorities plus EDPB<\/td>\n | Information Commissioner’s Office<\/td>\n | California Privacy Protection Agency and Attorney General<\/td>\n | ANPD<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nHow Do You Implement a GDPR Compliance Programme Step by Step?<\/h2>\nGDPR compliance programmes fail for predictable reasons: they begin with policy drafting instead of discovery, they have no named owners, they treat the work as a one-off project, and they never produce evidence. A phased programme that front-loads discovery and ends with operating routines avoids all four.<\/p>\n Phase 1 \u2014 Discover and assess (days 0\u201390)<\/h3>\nThe first phase answers three questions: what personal data exists, where it flows, and what the highest risks are. Nothing else can be sequenced reliably until these are answered.<\/p>\n \n- Scope determination.<\/strong> Confirm whether Article 3(1), Article 3(2) or both apply, and identify the lead supervisory authority where cross-border processing occurs.<\/li>\n
- Role mapping.<\/strong> Determine controller, joint controller and processor status per data flow \u2014 not per legal entity.<\/li>\n
- Data discovery and inventory.<\/strong> Combine automated discovery tooling with structured interviews of system owners. Cover production systems, data warehouses, logs, backups, SaaS applications, spreadsheets, support tools and shadow IT. Record data category, purpose, lawful basis, retention, recipients and transfers.<\/li>\n
- Gap assessment.<\/strong> Compare current state against the seven principles and the core obligations, and rate each gap by likelihood and impact on data subjects.<\/li>\n
- High-risk inventory.<\/strong> Identify processing likely to require a DPIA and any processing requiring prior consultation.<\/li>\n
- Governance set-up.<\/strong> Name an executive sponsor, a programme lead, system-level owners and a DPO decision with rationale recorded.<\/li>\n<\/ul>\n
Phase 2 \u2014 Remediate and document (days 90\u2013180)<\/h3>\nThe second phase converts findings into controls and produces the accountability evidence that Phase 1 revealed to be missing.<\/p>\n \n- Complete the Article 30 record<\/strong> and put it under change control so new processing is added before go-live.<\/li>\n
- Close high-risk gaps first.<\/strong> Prioritise special category data, large-scale monitoring, cross-border transfers and any processing with an unaddressed DPIA.<\/li>\n
- Implement retention enforcement.<\/strong> Convert the retention schedule into automated deletion, archival and backup expiry jobs, and verify that they work.<\/li>\n
- Rebuild the rights process.<\/strong> Publish an intake channel, define the search scope per system, build retrieval workflows, and start logging requests and closure times.<\/li>\n
- Fix contracts.<\/strong> Bring processor agreements to Article 28 standard, identify sub-processors, and close gaps in transfer safeguards.<\/li>\n
- Harden security.<\/strong> Implement the Article 32 measures identified in the gap assessment, including encryption, access control, logging, monitoring and vulnerability management.<\/li>\n
- Build the breach runbook.<\/strong> Define detection, triage, severity classification, escalation, legal review, notification templates and a rehearsal schedule.<\/li>\n
- Train.<\/strong> Role-based training for engineering, marketing, HR, sales and support, with completion records retained.<\/li>\n<\/ul>\n
Phase 3 \u2014 Operate and prove (days 180\u2013365, then steady state)<\/h3>\nThe final phase moves compliance from project to routine. This is the phase that determines whether the programme survives the first change of leadership or the first major product launch.<\/p>\n \n- Embed privacy in delivery.<\/strong> Add privacy requirements to the definition of done, and add DPIA screening to intake and change advisory processes.<\/li>\n
- Run a monitoring cycle.<\/strong> Monthly metrics on DSAR volumes and closure times, breach events, consent rates, retention job success, training completion and vendor reviews.<\/li>\n
- Test.<\/strong> Annual penetration testing, periodic restore testing, and at least annual tabletop breach exercises with documented lessons learned.<\/li>\n
- Audit.<\/strong> Internal audit or external assessment against the seven principles and core obligations, with findings tracked to closure.<\/li>\n
- Review vendors.<\/strong> Reassess processor posture, sub-processor lists and transfer arrangements on a defined cycle and whenever a vendor materially changes its service.<\/li>\n
- Report upward.<\/strong> A short board-level report on compliance posture, residual risks and decisions required.<\/li>\n<\/ul>\n
If your organisation needs to run this programme alongside product delivery \u2014 and most do \u2014 the Greyson consulting team<\/a> works with IT leadership to sequence discovery, remediation and operating routines without stalling the roadmap.<\/p>\nTwelve-month GDPR programme roadmap<\/h3>\n \n\n\n| Phase<\/th>\n | Timeframe<\/th>\n | Key activities<\/th>\n | Deliverables<\/th>\n | Owner<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Discover and assess<\/td>\n | Days 0\u201390<\/td>\n | Scope and role determination; data discovery; gap assessment; high-risk inventory; governance set-up<\/td>\n | Data inventory and flow map; role map; gap register; DPIA pipeline; programme charter<\/td>\n | Programme lead with system owners<\/td>\n<\/tr>\n | \n| Remediate and document<\/td>\n | Days 90\u2013180<\/td>\n | Article 30 record; retention enforcement; rights process build; contract remediation; security hardening; breach runbook; training<\/td>\n | Records of processing; retention schedules in code; DSAR workflow; compliant processor contracts; incident runbook; training records<\/td>\n | Privacy office with engineering, procurement and HR<\/td>\n<\/tr>\n | \n| Operate and prove<\/td>\n | Days 180\u2013365<\/td>\n | Privacy in the definition of done; monitoring metrics; testing; internal audit; vendor reassessment; board reporting<\/td>\n | Monitoring dashboard; test reports; audit findings log; vendor review records; board reports<\/td>\n | DPO with CISO and engineering leads<\/td>\n<\/tr>\n | \n| Steady state<\/td>\n | Year 2 onward<\/td>\n | Continuous intake of new processing; annual DPIA refresh; regulatory change monitoring; AI Act convergence<\/td>\n | Updated registers; refreshed DPIAs; regulatory watch briefs<\/td>\n | Privacy office with executive sponsor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nHow Does GDPR Compliance Change Software Development and Testing?<\/h2>\nThis is the area where GDPR compliance is most often misunderstood as a legal matter and most often fails as an engineering one. The obligations under Articles 25 and 32 are design and test obligations. They cannot be satisfied by a policy document written after the release.<\/p>\n Privacy by design across the software development lifecycle<\/h3>\nData protection by design works only when privacy requirements behave like every other non-functional requirement: captured early, made testable, tracked to completion and verified before release.<\/p>\n Requirements phase.<\/strong> Each feature that touches personal data should declare its purpose, lawful basis, data categories, retention period, recipients and applicable data subject rights. A screening question in intake \u2014 does this process personal data, and does it meet any DPIA criterion? \u2014 catches the cases that need assessment before architecture is committed.<\/p>\nDesign phase.<\/strong> Data minimisation is applied at the schema and API level, not at the form level alone. Pseudonymisation, purpose-bound access, encryption and key management are designed in. Default settings are privacy-protective, satisfying the “by default” limb of Article 25.<\/p>\nBuild phase.<\/strong> Consent state, purpose tags and retention metadata are modelled as first-class data attributes rather than bolted on. Logging is configured to exclude or redact personal data by default, since log stores are among the most frequently overlooked personal data repositories.<\/p>\nTest phase.<\/strong> Privacy requirements are tested like functional requirements: that deletion actually deletes across all stores including derived datasets and search indexes, that retention jobs fire, that consent withdrawal suppresses processing downstream, that access controls restrict by purpose, that export produces a complete and machine-readable record, and that automated decisions produce an explanation and route to human review.<\/p>\nRelease phase.<\/strong> Privacy checks become part of the definition of done. A release that changes how personal data is processed without an updated register entry or a completed DPIA screen should not pass the gate.<\/p>\nOperate phase.<\/strong> Retention enforcement, access reviews, monitoring, and periodic re-assessment of DPIAs as processing evolves. Article 32(1)(d) explicitly requires regular testing of the effectiveness of security measures, which makes continuous testing a legal expectation rather than an engineering preference.<\/p>\nTest data management \u2014 pseudonymisation versus anonymisation<\/h3>\nTesting is where GDPR compliance and engineering practice collide most visibly. Development and test environments need realistic data to find realistic defects, but production personal data must not be copied into environments with weaker controls. The GDPR provides two routes, and they are not interchangeable.<\/p>\n Anonymisation<\/strong> removes identifiability to the point where the data falls outside the GDPR entirely. To achieve this the data must resist singulation (isolating an individual), linkability (connecting records about the same person) and inference (deducing attributes from other data), considering all means reasonably likely to be used. Genuine anonymisation is hard, and in many enterprise datasets \u2014 particularly ones with rich quasi-identifiers such as postcode, date of birth and transaction patterns \u2014 it is not achievable without destroying analytical utility.<\/p>\nPseudonymisation<\/strong> replaces direct identifiers with artificial ones while keeping re-identification possible via separately held key material. Pseudonymised data remains personal data and stays in scope, but Article 32 explicitly recognises pseudonymisation as a security measure, and Article 25 recognises it as a design technique. For most test environments, pseudonymisation with strict key segregation is the practical and defensible choice: it preserves referential integrity and data realism while removing direct identifiability, and it demonstrates a technical measure under Article 32.<\/p>\nWhichever route is chosen, several controls are non-negotiable. Test environments must not be reachable with production credentials. Data must be masked at the point of extraction rather than in the destination environment. Referential integrity must be preserved so tests remain meaningful \u2014 the same synthetic identifier must map consistently across related tables. Free-text fields, attachments, notes and document metadata must be covered, because these are where personal data most often survives masking. And the masking process itself must be tested: sampling masked datasets for residual identifiers is a legitimate and expected control.<\/p>\n Cloud, vendors and processor assurance<\/h3>\nMoving to cloud does not transfer accountability. Under Article 28 the controller remains responsible for choosing a processor that provides sufficient guarantees, and for ensuring the contract covers the required terms. For cloud specifically, four areas warrant attention.<\/p>\n Data residency and transfer chains.<\/strong> A cloud service may replicate data across regions and use sub-processors in multiple jurisdictions. Transfer mapping must follow the actual data path, including support access from third countries, which is a transfer in its own right.<\/p>\nSub-processor transparency.<\/strong> Article 28(2) requires authorisation for sub-processors. In practice this means monitoring published sub-processor lists and having a mechanism to object to changes, with a documented process for what happens if you do object.<\/p>\nDeletion and exit.<\/strong> Article 28(3)(g) requires deletion or return of data at the end of the engagement. In multi-tenant and backup-heavy architectures, verify what “deletion” actually means, what the timescales are, and whether residual copies persist in backups or analytics stores.<\/p>\nFeature creep and secondary use.<\/strong> Many cloud platforms now offer AI-assisted features that may process customer data. Each such feature must be assessed: does it reuse data for model training, and if so, on what legal basis and with what contractual protection?<\/p>\nPrivacy controls mapped to the development lifecycle<\/h3>\n\n\n\n| SDLC phase<\/th>\n | Privacy objective<\/th>\n | Concrete controls<\/th>\n | Evidence produced<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Requirements<\/td>\n | Identify and bound personal data processing<\/td>\n | Privacy intake screening; purpose and lawful basis declaration; DPIA trigger check; data category classification<\/td>\n | Completed privacy screening records; DPIA decisions<\/td>\n<\/tr>\n | \n| Design<\/td>\n | Apply data protection by design and by default<\/td>\n | Schema-level minimisation; pseudonymisation design; encryption and key management design; purpose-bound access model; privacy-protective defaults<\/td>\n | Design documents with privacy sections; architecture review records<\/td>\n<\/tr>\n | \n| Build<\/td>\n | Make privacy attributes first-class in the data model<\/td>\n | Consent state as a modelled attribute; purpose tags on data flows; retention metadata; log redaction by default; secrets management<\/td>\n | Code review records; data model documentation<\/td>\n<\/tr>\n | \n| Test<\/td>\n | Verify privacy behaviour, not just functional behaviour<\/td>\n | Deletion verification across all stores; retention job tests; consent withdrawal propagation tests; access control and purpose tests; DSAR export completeness tests; masked-data residual identifier sampling<\/td>\n | Test reports retained as Article 32 evidence; masking validation reports<\/td>\n<\/tr>\n | \n| Release<\/td>\n | Prevent undocumented processing from shipping<\/td>\n | Privacy checks in the definition of done; register update gate; DPIA completion gate; release sign-off<\/td>\n | Release checklists; updated records of processing<\/td>\n<\/tr>\n | \n| Operate<\/td>\n | Maintain effectiveness over time<\/td>\n | Retention job monitoring; periodic access reviews; DPIA refresh triggers; incident response rehearsals; vulnerability and penetration testing<\/td>\n | Monitoring reports; review minutes; test and rehearsal records<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat Are the Most Common GDPR Misconceptions?<\/h2>\nMost stalled programmes are not blocked by complexity. They are blocked by a small set of persistent beliefs that lead teams to spend effort in the wrong place.<\/p>\n Nine myths that stall compliance programmes<\/h3>\n“We are not in the EU, so GDPR does not apply to us.”<\/strong> Article 3(2) applies the regulation to organisations offering goods or services to people in the EU or monitoring their behaviour, with no establishment required.<\/p>\n“Our data is anonymised, so it is out of scope.”<\/strong> Only irreversibly anonymised data is out of scope. Pseudonymised data, and data that can be re-identified through combination with other datasets, remains personal data.<\/p>\n“Consent is the only lawful basis we need.”<\/strong> Five other bases exist, and using consent where contract or legal obligation applies creates avoidable risk because consent can be withdrawn at any time.<\/p>\n“We deleted the record, so we are compliant.”<\/strong> Erasure must reach backups, derived datasets, analytics stores, search indexes, caches and third-party processors. Deletion that stops at the primary database is incomplete.<\/p>\n“The DPIA is a formality for the legal team.”<\/strong> A DPIA is a risk assessment that informs design decisions and must be produced before processing begins, with the DPO’s advice recorded and residual risk accepted at the right level.<\/p>\n“Our cloud provider handles GDPR for us.”<\/strong> Processors provide guarantees and contractual commitments; the controller retains accountability under Article 5(2) and Article 24, including for transfers and sub-processors.<\/p>\n“We have a privacy policy on our website, so we are covered.”<\/strong> A privacy notice satisfies one transparency obligation. It does nothing for retention enforcement, rights fulfilment, security testing or breach readiness.<\/p>\n“Compliance is a one-time project.”<\/strong> Every new system, vendor, integration, marketing channel and AI feature changes the processing landscape. Compliance without a change-control intake decays within a quarter.<\/p>\n“The GDPR and the AI Act are separate problems.”<\/strong> AI systems that process personal data must satisfy both. Data minimisation, purpose limitation and lawful basis analysis apply to training data, and Article 22 restricts automated decisions that significantly affect individuals.<\/p>\nMyth versus reality<\/h3>\n\n\n\n| Misconception<\/th>\n | Reality<\/th>\n | Governing provision<\/th>\n<\/tr>\n<\/thead>\n | \n\n| GDPR only applies to EU-based organisations<\/td>\n | It applies to non-EU organisations that offer goods or services to, or monitor, people in the EU<\/td>\n | Art. 3(2); Recitals 23\u201324<\/td>\n<\/tr>\n | \n| Pseudonymised data is outside GDPR scope<\/td>\n | Pseudonymised data remains personal data; only irreversible anonymisation removes it from scope<\/td>\n | Art. 4(1), 4(5); Recital 26<\/td>\n<\/tr>\n | \n| Consent is always the safest lawful basis<\/td>\n | Consent is fragile and withdrawable; the correct basis depends on the processing purpose<\/td>\n | Art. 6(1); Art. 7<\/td>\n<\/tr>\n | \n| Deleting the primary record is enough<\/td>\n | Erasure must cover backups, derived data, analytics, indexes and processors<\/td>\n | Art. 17; Art. 19<\/td>\n<\/tr>\n | \n| A DPIA is a legal document<\/td>\n | A DPIA is a risk assessment that must precede high-risk processing and inform design<\/td>\n | Art. 35; Art. 36<\/td>\n<\/tr>\n | \n| The cloud provider is responsible for compliance<\/td>\n | Accountability stays with the controller; processors provide guarantees and assistance<\/td>\n | Art. 5(2), 24, 28<\/td>\n<\/tr>\n | \n| A published privacy policy means compliance<\/td>\n | Transparency is one of many obligations; operational controls are also required<\/td>\n | Art. 5, 12\u201314, 24, 30, 32<\/td>\n<\/tr>\n | \n| Compliance is a one-off project<\/td>\n | It is a maintained state that must absorb every new system, vendor and data flow<\/td>\n | Art. 5(2), 24, 32(1)(d)<\/td>\n<\/tr>\n | \n| Breach notification always requires 72 hours<\/td>\n | Notification is required where there is a risk; where there is no risk, the decision must still be documented<\/td>\n | Art. 33, 34<\/td>\n<\/tr>\n | \n| A DPO is required for every organisation<\/td>\n | A DPO is mandatory in three defined situations; others may appoint one voluntarily<\/td>\n | Art. 37(1)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat Does Non-Compliance Cost?<\/h2>\nFines dominate the discussion, but they are rarely the largest cost. Understanding both the statutory structure and the operational consequences helps build a business case that survives budget review.<\/p>\n The two-tier fine structure under Article 83<\/h3>\nArticle 83 sets out two tiers of administrative fines. The lower tier covers obligations including the general principles, controller and processor responsibilities, certification bodies, and the obligations of monitoring bodies. It allows fines of up to | | | | | | | | |