A GDPR controls framework is the documented set of technical safeguards, organizational policies, and evaluation processes an organization uses to protect personal data and prove it is protecting that data. The proof half matters as much as the protection half: Article 5(2)’s accountability principle requires controllers to demonstrate compliance, not just achieve it. Get the framework wrong and the exposure is real. Fines reach €20 million or 4% of global annual turnover for the most serious violations, with a lower tier of €10 million or 2% of turnover for failures involving security, record-keeping, and other operational obligations.
The regulation applies to any organization processing personal data of people in the European Union, wherever the organization itself sits. A company in Tokyo or New York handling EU residents’ data needs the same framework as a company in Berlin.
What the Framework Has to Cover
Article 32 divides controls into two broad categories, technical and organizational, and takes a risk-based approach instead of a prescribed checklist. The intensity of your controls should match the danger the processing poses. A newsletter list calls for a lighter touch than patient health records or biometric scans.
Article 25 adds two design-level requirements. Data protection by design means building privacy safeguards into products and systems from the earliest development stage. Data protection by default means configuring systems so the most protective settings apply automatically, without requiring users to opt in to their own protection. Supervisory authorities expect evidence of both when they investigate.
Know What Data You Have
Before you can protect data, you need to know what you have, where it lives, why you have it, and who touches it. Article 30 requires controllers to keep a written record of processing activities. That record must include the purposes of each activity, the categories of personal data involved, the categories of people whose data you process, and any recipients you share data with.
Personal data extends well past names and email addresses. IP addresses, cookie identifiers, device fingerprints, and location data all qualify. Sensitive categories under Article 9, including health, genetic, biometric, religious, and political information, carry a general prohibition on processing unless a limited exception applies. Which categories you hold determines which tier of controls you need.
Each processing activity also needs a legal basis under Article 6. The regulation recognizes six: consent, contractual necessity, legal obligation, vital interests, public interest, and legitimate interests. Choose wrong and problems follow, because each basis carries different requirements and gives individuals different rights. Consent-based processing, for example, can be withdrawn at any time and triggers the right to data portability.
Data flow mapping finishes the inventory. Trace how information enters your systems, which internal teams access it, which external vendors receive it, and whether it crosses international borders. This map is the reference document for nearly every other control decision.
Technical Security Controls
Article 32(1) requires technical measures that ensure a level of security appropriate to the risk. Two measures are named explicitly. Encryption encodes data so it cannot be read without a key, protecting information at rest and in transit. Pseudonymization separates data from direct identifiers so analysis can happen without exposing identities. Both reduce the impact of a breach, because stolen data that is unreadable or unlinkable is far less harmful.
Access controls deliver the biggest practical benefit for most organizations. Multi-factor authentication should protect any system storing personal data, and least-privilege access should govern who can see what. An employee in marketing has no reason to access payroll records, and a payroll clerk has no reason to browse customer databases. Role-based access, enforced through identity management, makes this workable at scale.
Article 32(1)(b) requires ongoing confidentiality, integrity, availability, and resilience of processing systems. Article 32(1)(c) specifically requires the ability to restore access to personal data promptly after a physical or technical incident. Tested backups, redundant infrastructure, and documented recovery procedures fall under this obligation.
Physical security still counts. Servers, network equipment, and any hardware holding personal data need restricted access, surveillance, and environmental controls. Paper records need locked storage with access limited to authorized staff. The best firewall is irrelevant if someone can walk into an unlocked server room.
Organizational Controls
Policies and Training
Technical tools only work when the people using them follow the rules. Internal policies should cover how employees collect, store, access, share, and delete personal data day to day, and they need to be written plainly enough for non-technical staff to follow without interpretation.
Regular training is not optional. Human error is the leading cause of breaches, and accountability means you must show staff are trained, not just that a policy document sits on the intranet. Training records, completion dates, and periodic refreshers all become evidence of compliance when a regulator asks.
Data Processing Agreements
Any time you share personal data with a third-party vendor, Article 28 requires a binding contract. These agreements must cover the subject matter and duration of the processing, the types of personal data involved, the vendor’s obligation to process data only on your documented instructions, confidentiality commitments for the vendor’s staff, the vendor’s duty to implement Article 32 security measures, restrictions on sub-processors, assistance with data subject rights requests, and the requirement to delete or return all personal data when the contract ends.
The agreement must also give you audit rights. A vendor that resists audit clauses is a vendor that will create liability for you. Joint and several liability rules mean a data subject harmed by a breach can pursue the controller for the full compensation amount even when the processor caused the problem.
Data Protection Officer
Article 37 requires a Data Protection Officer in three situations: when the controller is a public authority, when core activities involve large-scale monitoring of individuals, or when core activities involve large-scale processing of Article 9 sensitive data. Organizations outside these triggers often appoint a DPO voluntarily because a dedicated compliance lead simplifies the framework considerably.
The DPO must operate independently. The role cannot be combined with any position that determines the purposes or means of processing. Senior titles including CEO, CFO, and department heads over IT, HR, or marketing are incompatible with DPO duties. The DPO reports directly to the highest level of management and cannot be penalized for performing oversight.
Data Subject Rights Infrastructure
Your framework needs documented procedures and technical capability to handle every right the GDPR grants to individuals. Organizations have one month from a valid request to respond, with a possible two-month extension for complex cases.
- Access under Article 15: individuals can request confirmation of whether you process their data and, if so, a copy along with details about purposes, categories, recipients, and retention.
- Rectification under Article 16: correction of inaccurate data or completion of incomplete records.
- Erasure under Article 17: deletion when data is no longer necessary for its original purpose, when consent is withdrawn, or when processing was unlawful.
- Restriction under Article 18: pausing active processing while a dispute about accuracy or lawfulness is resolved.
- Portability under Article 20: when processing is based on consent or a contract and carried out by automated means, individuals can request their data in a structured, machine-readable format and have it transmitted directly to another controller where technically feasible.
- Objection under Article 21: objection to processing based on legitimate interests or public interest grounds. For direct marketing, the right is absolute with no balancing test.
- Automated decisions under Article 22: the right not to be subject to decisions made entirely by automated processing, including profiling, that produce legal or similarly significant effects, except where necessary for a contract, authorized by law, or based on explicit consent.
Building these rights into your framework means your systems need to locate all data associated with a specific individual across every database and processor, then export it, suppress it, correct it, or delete it on demand. Organizations that never designed for these operations often find that a single access request takes weeks of manual work across disconnected systems. Fix the gap early or pay for it later.
Breach Response
Article 33 requires controllers to notify the relevant supervisory authority of a personal data breach within 72 hours of becoming aware of it, unless the breach is unlikely to pose a risk to individuals’ rights. The notification must describe the nature of the breach, the approximate number of people and records affected, the likely consequences, and the measures taken or proposed. Miss the 72-hour window and you have to explain the delay.
When a breach is likely to create a high risk to individuals, Article 34 adds direct notification to the affected people, in clear plain language, with the same core information. You can skip individual notification only if the data was rendered unintelligible to unauthorized parties by technical protections already in place, if subsequent steps eliminated the high risk, or if individual notification would require disproportionate effort, in which case a public communication is required instead.
Your framework should include a written incident response plan that assigns roles, defines escalation paths, and sets internal deadlines tighter than the regulatory clock. Test the plan through tabletop exercises at least annually. A breach discovered at 4 PM on a Friday gives you until Monday afternoon to notify the authority, and organizations that find gaps in their plan during an actual incident find them too late.
International Data Transfers
Any transfer of personal data outside the European Economic Area has to satisfy Chapter V. Article 44 sets the principle: no transfer can undermine the level of protection the regulation guarantees.
The simplest route is transferring data to a country covered by an adequacy decision from the European Commission. As of early 2026, the adequate jurisdictions include Andorra, Argentina, Brazil, Canada (commercial organizations), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, and the United States for organizations participating in the EU-U.S. Data Privacy Framework. Transfers to those destinations need no additional safeguards.
Where no adequacy decision applies, Article 46 requires appropriate safeguards. The most common mechanism is standard contractual clauses adopted by the European Commission, pre-approved templates that bind the data importer to EU-level protections. Binding corporate rules serve a similar function for transfers within a multinational corporate group. Approved codes of conduct and certification mechanisms are also available but less common in practice.
U.S. organizations relying on the EU-U.S. Data Privacy Framework must self-certify through the International Trade Administration. Participation is voluntary, but once an organization self-certifies, compliance is legally enforceable under U.S. law. Certified organizations must publicly commit to the framework’s principles, maintain their listing on the Data Privacy Framework List, and complete annual re-certification.
Non-EU organizations that process EU residents’ data on a regular basis must also designate a written representative within the EU under Article 27. The requirement does not apply if the processing is only occasional, does not involve sensitive data on a large scale, and is unlikely to risk individuals’ rights.
Retention and Disposal
The storage limitation principle in Article 5(1)(e) requires personal data to be kept only as long as necessary for the purposes it was collected for. Your framework needs a retention schedule with specific timeframes for each category of data and processing purpose. A vague “as long as needed” statement will not survive a regulator’s reading.
Retention periods often depend on external legal requirements. Employment records, tax documentation, and contractual data may need to be kept for statutory minimums that vary by jurisdiction. Your schedule should account for those overlapping obligations, but the default position under the GDPR is deletion once the purpose is fulfilled and no other legal obligation requires continued storage.
Disposal has to be verifiable. Deleting a database record means nothing if backup tapes, development environments, or vendor systems still hold copies. Your procedures should cover every location personal data exists, including backups, test environments, and processor systems. The vendor deletion or return clause in your data processing agreements is what closes the loop on the vendor side; without it, your retention schedule has a gap you cannot control.
When a Data Protection Impact Assessment Is Required
Article 35 requires a Data Protection Impact Assessment before any processing likely to result in a high risk to individuals’ rights. This is not optional for qualifying activities, and the assessment has to happen before processing begins, not after launch.
High-risk triggers include innovative technology such as AI or machine learning, large-scale profiling, processing of biometric or genetic data, systematic monitoring of public spaces, automated decision-making affecting access to services or opportunities, and combining data from multiple sources in ways individuals would not reasonably expect. When two or more of these overlap, a DPIA is essentially automatic.
The assessment itself must document the planned operations, evaluate their necessity and proportionality, assess the risks to individuals, and identify the measures you will take to address those risks. If the assessment reveals a high risk your proposed measures cannot adequately mitigate, you must consult the relevant supervisory authority before proceeding. That consultation can delay a project significantly, which is why DPIA screening belongs in project planning rather than compliance cleanup.
Testing and Evaluation
Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of your technical and organizational measures. A framework solid at launch degrades as threats evolve, systems change, and staff turn over.
Internal audits verify that departments are actually following the policies. Those audits should produce written reports with specific findings, remediation deadlines, and follow-up verification. Penetration testing evaluates your technical defenses against simulated attacks. Tabletop exercises test breach response under time pressure. Each type catches different weaknesses; relying on only one leaves blind spots.
Framework updates should also track external changes. New guidance from the European Data Protection Board, rulings from the Court of Justice of the European Union, and evolving adequacy decisions all affect what the framework must cover. Internal triggers matter too: a new product, a new market, a new vendor, or a data system restructuring should each prompt a review.
Document every review, every finding, and every remediation action. That documentation is the proof of ongoing accountability Article 5(2) demands. When a supervisory authority investigates, the question is rarely whether your framework was perfect. It is whether you had a functioning process for identifying and fixing problems.
What Non-Compliance Costs
Article 83 sets a two-tier fine structure. The lower tier covers violations of obligations related to security measures, record-keeping, breach notification, impact assessments, and Data Protection Officer requirements, with fines up to €10 million or 2% of global annual turnover, whichever is higher.
The upper tier covers violations of the core processing principles, lawfulness conditions, consent requirements, data subject rights, and international transfer rules, with fines up to €20 million or 4% of global annual turnover, whichever is higher.
Fines are not the whole exposure. Article 82 gives any person who suffers material or non-material damage from a GDPR violation the right to compensation from the controller or processor responsible. Controllers are liable for any processing that violates the regulation. Processors are liable when they fail to meet obligations directed specifically at them or when they act outside the controller’s lawful instructions. The only defense is proving you were not responsible for the event that caused the damage in any way.
When multiple parties are involved in the same processing, liability is joint and several. A data subject can pursue the full compensation amount from any one responsible party, leaving the parties to sort out contribution among themselves. Your choice of processors and the strength of your data processing agreements is a financial risk decision, not a paperwork exercise.