What can a GDPR fine cost, and which tier applies to our systems?
When a customer questionnaire or a regulator inquiry puts GDPR fines on the budget, the first question is how large the exposure could be. Article 83 sets two maximums: EUR 10 million or 2% of total worldwide annual turnover for infringements of obligations such as security of processing, breach notification and data protection impact assessments, and EUR 20 million or 4% for infringements of the principles, lawful basis, data subject rights and transfer rules. In each case the higher figure applies, and the tier depends on the provision that was infringed, not on the size of the incident. For a systems team, that means a missed rights request or an unlawful transfer can fall in the higher tier even when the underlying security was sound, while a weak security control usually falls in the lower one.
The figure a supervisory authority actually reaches is far below the maximum in most cases, but it is not predictable from the tier alone. Under the EDPB's Guidelines 04/2022, the authority classifies the infringement, sets a starting point that reflects its seriousness and the undertaking's turnover, then adjusts for aggravating and mitigating factors such as duration, negligence, categories of data and cooperation. Article 83(2) gives particular weight to the degree of responsibility shown through technical and organisational measures under Articles 25 and 32, so the evidence your systems produce matters directly to the outcome. The organization owns its controls and decides what it can show. An implementation partner can prepare systems, logs, configurations and evidence, but only the supervisory authority or a court decides whether a fine is imposed and how much it is.
Which costs make up GDPR exposure, and who pays each one
This table separates the fines, compensation, corrective orders and remediation effort that make up GDPR exposure, and shows who bears each one. Read it to see which costs fall on the controller, which on the processor, and which are one-time or recurring. The main takeaway is that the fine caps are only one part of the exposure, and remediation effort usually costs more to manage than the fines themselves.
| Cost component | Who bears it | One-time or recurring, and what drives it |
|---|---|---|
| Administrative fines under Article 83(4) (up to EUR 10 million or 2% of worldwide turnover, whichever is higher) | Controller or processor found in breach of security, breach notification, DPIA, DPO or processor duties | One-time per decision. Size driven by turnover, gravity, duration, data categories and technical and organisational measures under Articles 25 and 32 |
| Administrative fines under Article 83(5) (up to EUR 20 million or 4% of worldwide turnover, whichever is higher) | Controller or processor found in breach of principles, lawful basis, data subject rights or transfer rules | One-time per decision. Higher tier applies to principles, rights and transfers, so the same turnover base drives a larger cap |
| Fines for ignoring an authority order under Article 83(6) | Controller or processor that fails to comply with an order under Article 58(2) | One-time per decision, but a sign of prolonged non-cooperation. Driven by how quickly the organisation responds to corrective orders |
| Compensation claims under Article 82 | Controller for its own infringements. Processor only where it breached processor duties or acted outside lawful instructions. Claimant receives the award | Can recur across many individuals. Driven by number of affected people, type of damage claimed and whether a complaint or collective action follows |
| Corrective orders and processing bans under Article 58(2) | Controller or processor whose processing is ordered to stop or change | Can halt revenue-generating processing. Driven by how central the processing is and whether the authority orders suspension of data flows to third countries |
| Internal remediation effort (engineering, security, legal, DPO time) | Controller, and processor for its own systems | One-time for forensic work and fixes, recurring for monitoring and evidence upkeep. Driven by system complexity, logging quality and how well records of processing are kept |
| External remediation support (forensics, legal counsel, independent assessors) | Controller, and processor where the processor is at fault | Usually one-time per incident or project. Driven by scope, urgency and whether evidence was preserved. Ask any provider for a written scope before work begins |
How supervisory authorities calculate a fine under the EDPB method
The EDPB method turns a single infringement into a proposed fine through five documented steps, then checks the result against the legal maximums and the tests of effectiveness, dissuasiveness and proportionality. Each step leaves a record that the controller or processor can examine and contest.
Identify the processing operations concerned
The authority first fixes which processing operations are in scope and which provisions they may have breached. For a controller, this means mapping the systems, datasets and purposes behind the complaint or inquiry, usually drawn from the record of processing and the inquiry letters. The output is a written list of operations and the infringed articles. If the same or linked operations breach several provisions, that list feeds the Article 83(3) check at the end of the sequence.
Classify the infringement and its seriousness
The authority places each infringement in the Article 83(4) or 83(5) tier, which sets the statutory maximum, then judges its seriousness. Factors include the nature, gravity and duration of the infringement, the number of data subjects affected, the categories of data and the level of damage suffered. The output is a documented classification and seriousness rating for each operation, which compliance leads should expect to see referenced in the draft decision.
Set the starting point using turnover
The authority sets a starting amount from the seriousness rating and, where the undertaking is an undertaking, relates it to total worldwide annual turnover of the preceding financial year. The EDPB guidelines explain how the starting point is calibrated so that it reflects the gravity of the case. The output is a stated starting figure with the turnover basis recorded. Organizations should ask for the turnover figure used, since it determines the ceiling in Step 5.
Adjust for aggravating and mitigating factors
The authority moves the starting point up or down using the Article 83(2) factors. Aggravating factors include intent, negligence in failing to apply appropriate technical and organizational measures under Articles 25 and 32, and previous infringements. Mitigating factors include prompt action to limit damage, cooperation, and adherence to approved codes of conduct or certification. Evidence of documented security measures, tested controls and timely breach handling is what moves this step. The output is a written list of each factor with its direction and weight.
Apply the legal maximum for the tier
The adjusted amount is compared with the statutory cap for the tier. Under Article 83(4) the cap is EUR 10 million or 2% of total worldwide annual turnover, and under Article 83(5) it is EUR 20 million or 4% of that turnover, in each case whichever is higher. If the adjusted amount exceeds the cap, the cap applies. The output is the capped amount per infringement, recorded alongside the turnover basis used.
Test effectiveness, dissuasiveness and proportionality
Before settling the fine, the authority checks that it is effective, dissuasive and proportionate in the specific case, as Article 83(1) requires. This final test can lead the authority to revisit earlier steps. The output is a reasoned statement explaining why the amount meets each test. Organizations responding to a draft decision can use this stage to argue that their means, cooperation and remediation justify a lower amount.
Apply the Article 83(3) combined cap
Where the same or linked processing operations infringe several provisions, the total fine may not exceed the amount set for the gravest infringement. The authority therefore compares the amounts for each linked infringement and keeps the total within the highest one. The output is a final combined figure that is documented with the gravest infringement identified. This rule applies to the total, so it limits stacking across linked findings but does not remove separate exposure for unrelated operations.
Which factors raise or lower a fine after an incident
After a personal data incident, a supervisory authority weighs the factors listed in Article 83(2) before it sets an amount. Most of them are decided by evidence the organization produced before the incident, such as documented measures, prompt reporting and a clear record of what it knew and when.
Nature, gravity and duration
The authority asks what kind of infringement occurred, how serious it was for the people affected, and how long it lasted. A short lapse that affected a few records is weighed differently from a months-long exposure of a large dataset. Keep logs that show when the gap started, when it was found and when it was closed, because the duration is often disputed. Check the number of people affected and the harm that is reasonably foreseeable from the failure.
Intent or negligence
A deliberate breach is treated more severely than an oversight. Negligence is judged against what a reasonable organization of similar size and sector would have done, so an unpatched system with a known fix counts against you. Evidence that helps includes written policies, training records and a record of how known vulnerabilities were prioritized and tracked. Confirm that these records reflect what staff actually did, not only what the policy says.
Technical and organizational measures
Under Articles 25 and 32, the authority examines the measures the controller or processor had in place and how they were chosen for the risk. This is often the factor that moves a case most. Prepare a risk assessment, the access control and encryption design, logging and monitoring coverage, and the review cycle that kept these current. Certification and codes of conduct are relevant here, but they do not replace the measures themselves.
Previous infringements
Earlier findings against the same organization can raise the fine, particularly when the same failure recurs after an earlier order or warning. The authority checks its own records and, where relevant, those of other supervisory authorities. Keep a register of past complaints, decisions and corrective actions, and show how each finding was closed. An organization with no prior history and a documented remediation trail is in a stronger position than one repeating the same gap.
Cooperation with the authority
Responsiveness during the inquiry can reduce the fine. Answering requests completely and on time, providing the documentation the authority asks for, and taking remediation steps before a decision are the practical signals. Name a contact who can answer technical questions and make sure they can produce logs, configurations and decisions quickly. Avoid the appearance of delay or selective disclosure, since the authority compares what it receives against what it later finds.
Categories of data and how the authority learned of it
Special categories of data, such as health data, and data about children or financial circumstances weigh more heavily than ordinary contact details. The way the authority learned of the incident also matters: a self-reported breach within the 72-hour window generally counts in your favor, while a discovery through a complaint or press report counts against you. Check whether your breach register captures both the data categories and the notification timeline with dates.
Why processing bans and compensation claims can cost more than the fine
A supervisory authority can stop the processing itself, and that can cost more than any fine. Under Article 58(2), an authority may order a controller or processor to bring processing into compliance, order a personal data breach to be communicated to the people affected, impose temporary or definitive limitations including a ban on processing, and suspend data flows to a recipient in a third country. These powers can be used alongside an administrative fine or instead of one. For a platform team, a ban on a core system or a suspended transfer can halt revenue, break customer contracts and force an emergency rebuild. Ask what the business would do if a regulator ordered a system offline for weeks, which datasets could keep running, and whether backups and failover were designed with that scenario in mind.
Anyone who suffers material or non-material damage can claim compensation directly, and the claims are separate from the fine. Article 82 gives individuals a right to compensation from the controller or processor for damage caused by an infringement. Liability for a processor is narrower: it applies where the processor failed to meet obligations placed on processors or acted outside or contrary to the controller's lawful instructions. In practice, this means a service provider that follows documented instructions and meets its processor duties has a more defined exposure than one that departs from them. Contracts, instruction records and processor-side logs therefore matter as evidence of who did what. Confirm with legal counsel how your processing agreements allocate this liability and whether your own logs would show which party acted on which instruction.
Fining rules differ for public authorities, and penalties outside Article 83 are set nationally. Under Article 83(7), each Member State decides whether and to what extent public authorities and bodies can be fined. Article 84 leaves Member States to set other penalties for infringements that are not subject to administrative fines. Organizations in the public sector, and those working with them, should check the national rules that apply in each country where they process data, because the exposure can differ from the headline Article 83 amounts. Confirm the position with the relevant national supervisory authority or local counsel rather than assuming a single EU-wide answer.
What the recent Uber and Miljödata decisions show about security and automated decisions
The two most recent decisions in this topic point to different failures, and systems owners should read them as separate lessons. The Dutch DPA fined Uber EUR 824,990,000 for unlawful automated decision-making about drivers and insufficient information on profiling, under Articles 22 and 13. The case started from complaints by 171 drivers, and Uber has appealed. The fine turns on whether decisions with significant effects on individuals were made by automated means without a valid basis, and whether the information given to people about that profiling was adequate. For a system owner, the practical question is whether the team can explain, for any individual decision, what data went in, what logic produced the outcome, what human review existed, and what the person was told beforehand. If those answers live only in a vendor's model documentation or in someone's memory, the gap is visible before any regulator asks.
Sweden's IMY fined IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) for negligent failure to ensure security under Article 32(1), following an attack that affected 2.2 million people. The decision was dated 22 September 2026. The lesson is that a fine can follow an ordinary, documented-looking control gap rather than a deliberate breach of the law. Owners of self-hosted or operated platforms should check whether they can show the security measures they relied on, who approved them, when they were last tested, and how they responded to the incident. Confirm the current text of the decision with the authority before relying on any summary, since the reasoning carries more weight than the headline amount.
Both decisions are individual cases, decided on their own facts, and they do not establish a fine level for another organization. Turnover, the number of people affected, the duration of the infringement, cooperation and prior conduct all feed the assessment under Article 83(2), and the Uber amount reflects a company of very large scale. Use the decisions to test your own evidence: ask whether automated decisions are inventoried and explained, and whether your security measures are documented well enough to show they were appropriate at the time of an incident.
How exposure differs for controllers, processors and self-hosting operators
A controller decides why and how personal data is processed, and it carries the broadest exposure under the GDPR. Failures in lawful basis, transparency or rights handling fall under the higher Article 83(5) tier, while security failures under Article 32 fall under the Article 83(4) tier. For compensation, Article 82 makes the controller liable for damage caused by processing that infringes the Regulation, so an individual can claim against the organization that decided the purpose.
- Ownership: the organization owns the lawful basis, the records of processing, privacy notices, retention rules and the security measures on its own systems.
- Tier most relevant: Article 83(4) for security and breach notification failures, and Article 83(5) for principles, rights and transparency failures.
- Liability route: Article 82(1) claims for material or non-material damage, which the controller cannot pass to a vendor.
- Evidence requested: the record of processing, the Article 32 risk assessment, access logs, breach records and proof that rights requests were answered within deadline.
Before relying on any internal file, check that the documents match what the systems actually do.
A processor handles personal data on the controller's behalf and on its documented instructions. Its direct exposure is narrower than the controller's, but it is real: Article 32 applies to processors in their own right, and the processor must meet the duties placed on it by the processing contract. Under Article 82(2), a processor is liable only where it breached obligations directed at processors or acted outside or contrary to the controller's lawful instructions. Most customer disputes therefore turn on whether the contract and instructions were followed.
- Ownership: the processor owns its own security controls, sub-processor management and the instructions it actually follows.
- Tier most relevant: Article 83(4) for processor duties and security, since processor obligations sit in that tier.
- Liability route: Article 82(2), which turns on contract breaches or acting outside instructions.
- Evidence requested: the signed processing agreement, the sub-processor list and change history, audit reports the customer can review, and the processor's own breach notices to controllers.
Check which customer obligations your contract actually transfers to you and which remain with the customer.
An organization that self-hosts open-source platforms in its own infrastructure is usually the controller for that data, so it carries controller exposure without a vendor in the chain. The open-source project does not hold the data and is not a processor for it, which removes one party from the liability picture but leaves the organization responsible for every control. Security failures, slow breach detection and gaps in records all land on the operator directly under Article 83(4), and the Article 82(1) damage route applies to the operator as controller.
- Ownership: the organization owns patching, hardening, backups, logging, access control, breach detection and the processing records.
- Tier most relevant: Article 83(4) for Article 32 and Article 33 failures, which are the most common self-hosting gaps.
- Liability route: Article 82(1) claims, with no vendor to share the claim with unless a separate support contract exists.
- Evidence requested: configuration baselines, centralized logs, tested restore records, vulnerability and patch history, and a breach response log showing how quickly the 72-hour clock was handled.
Confirm with the platform vendor which security features its release actually provides before assuming any of them are in place.
Which mistakes raise GDPR exposure most often
Most GDPR fines trace back to a small set of avoidable failures: security measures nobody verified, breaches handled without a clock, unclear processor roles, backups never restored, automated decisions nobody can explain, and certificates mistaken for compliance. Each card names the check that catches the failure, the internal owner and the evidence to keep.
Unverified security measures
Article 32 requires security appropriate to the risk, and regulators judge whether controls were actually operating, not just written down. A firewall rule or encryption setting that nobody has tested after a change is a gap an authority can cite. Test controls on a schedule, record the results and confirm that access reviews and patch cycles really run. Owner: the CISO or head of security engineering. Evidence to keep: dated configuration baselines, test results and remediation tickets.
Slow or undocumented breach handling
Article 33 requires notice to the supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Organizations that cannot show when they became aware, what they assessed and why they decided not to notify face fines for the notification failure itself. Keep a written incident procedure, a breach register and a decision log for every incident. Owner: the DPO or privacy lead, with the incident response lead. Evidence to keep: incident timelines, risk assessments and the register entry for each breach.
Unclear roles with processors
Authorities often find that a company acted as a processor while behaving as a controller, or that a processing agreement was missing or out of date. Map every vendor that touches personal data, confirm whether each is a controller or processor, and check that contracts state instructions, sub-processors and security duties. Re-check roles when a product or vendor changes. Owner: the legal or procurement lead, with the privacy team. Evidence to keep: a processor register, signed processing agreements and sub-processor approvals.
Untested backups
A backup that cannot be restored does not protect availability or show that the controller can meet its security duties after an incident. Regulators have treated loss of access to personal data as a security failure. Run restore tests on a defined schedule, include encrypted and access-controlled backup copies in scope, and record what was restored and how long it took. Owner: the infrastructure or platform engineering lead. Evidence to keep: restore test records, backup policies and encryption and key custody documentation.
Automated decisions without explanation
Decisions made solely by automated means that significantly affect people fall under Article 22, and privacy notices must describe the logic involved under Article 13. The Dutch DPA fined Uber EUR 824,990,000 for unlawful automated decision-making about drivers and insufficient information on profiling, a case that started from complaints by 171 drivers. Inventory systems that score, rank or decide, document the human review route and confirm that notices explain the logic. Owner: the product owner for the system, with legal review. Evidence to keep: automated decision inventories, human review procedures and updated notices.
Treating certification as compliance
Article 42 certification is voluntary and does not reduce the responsibility of the controller or processor for compliance. A certificate that covers one product or scope gives no protection for processing outside it, and an authority still assesses the actual practice. Use certification as one input to accountability, not as a shield. Owner: the DPO, with a named executive sponsor. Evidence to keep: the certificate scope statement, its validity period and internal evidence that the certified processing matches live operations.
Frequently asked questions about GDPR fines
Which GDPR fine tier applies to a security failure?
A security failure under Article 32 usually falls in the lower tier: a maximum of EUR 10 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher (Article 83(4)). The higher tier of EUR 20 million or 4% applies when the failure is linked to infringements of the principles, lawful basis, data subject rights or transfer rules, or when it breaches an order of a supervisory authority (Articles 83(5) and 83(6)). Where several linked infringements occur, the total fine cannot exceed the amount for the gravest one (Article 83(3)). As an illustration of scale, Sweden's IMY fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) for negligent failure to ensure security under Article 32(1) after an attack affecting 2.2 million people, in a decision of 22 September 2026. Confirm with counsel which provisions an authority could engage in your case.
Can hiring a consultant prevent a GDPR fine?
No. No outside party can take over the controller's or processor's responsibility for compliance, and an implementation partner cannot remove exposure to a fine. The GDPR requires no audit or certificate, and certification under Article 42 is voluntary and does not reduce responsibility. What does affect the amount is evidence that measures match the risk. Article 83(2) asks authorities to weigh the degree of responsibility given technical and organisational measures under Articles 25 and 32, cooperation, mitigation and any adherence to certification. A consultant can help prepare systems, controls and records that show those measures. DeployOpen, for example, prepares systems and evidence for assessments but does not issue reports or certificates. Ask any provider which evidence the work produces, who owns each control afterwards, and what is delivered in a fixed-scope written agreement.
How does the EDPB method calculate a GDPR fine amount?
The EDPB's Guidelines 04/2022 on the calculation of administrative fines (version 2.1, adopted 24 May 2023) describe a five-step method that supervisory authorities use as guidance:
- Identify the processing operations and whether the same or linked operations are involved.
- Set a starting point from the classification and seriousness of the infringement and, for undertakings, the turnover basis.
- Adjust the amount for aggravating and mitigating factors, such as duration, intent or negligence, and the measures taken.
- Apply the legal maximums in Article 83(4) to (6).
- Check that the result is effective, dissuasive and proportionate.
The turnover figure is the total worldwide annual turnover of the preceding financial year, so the cap grows with the size of the group. Confirm how the method applies to your structure and facts with counsel, and treat the guidelines as the starting point for that discussion.
Can a DPO or auditor be blamed for a GDPR fine?
The fine is addressed to the controller or processor under Article 83, so the organization that infringed the GDPR receives it. A data protection officer advises and monitors, and an auditor tests and reports, but neither issues a GDPR certificate, and a clean report does not protect against enforcement. Whether a DPO, auditor or consultant can face contractual claims from the organization depends on the terms of the engagement and national law, so those terms should be reviewed before signing. Ask each provider to state in writing what it is responsible for, what it is not responsible for, and which deliverables it will sign. Counsel should confirm the liability position for each role before a readiness effort begins, particularly where a provider's work is cited in a supervisory authority's findings.
Can a GDPR fine be appealed?
Yes, fines can be challenged, but the forum, procedure and deadlines depend on the Member State of the authority that issued the decision. Fines are imposed by independent national supervisory authorities (Article 51), and the EDPB resolves certain disputes between authorities through binding decisions (Articles 65 and 70). Uber has appealed the EUR 824,990,000 fine that the Dutch DPA imposed for unlawful automated decision-making and insufficient information on profiling under Articles 22 and 13, according to the EDPB's national news item of 8 October 2026. An appeal does not reset the underlying facts, so records of decisions, measures and incidents matter from the start. Confirm the appeal route, deadlines and the status of any proceeding with local counsel as soon as a decision is received.
What must our own team do before a readiness effort starts?
Your team must own the decisions that the GDPR places on the controller or processor, because no implementation partner can make them for you. Internal owners should decide the lawful basis for each processing activity, the scope of personal data in each system, the acceptance of residual risk, sign-off on DPIAs, and whether a personal data breach must be notified. The team should also review and approve the records of processing and technical and organisational measures, and run the process for handling rights requests and breaches. An implementation partner can prepare systems, configuration and evidence, but the organization must review and approve it. Before work starts, agree in writing which decisions sit with your staff, which deliverables the partner produces and how each one will be reviewed.
How long does a GDPR readiness effort take?
No duration can be stated from the supplied facts, so ask for milestones in the written scope rather than relying on a general estimate. The length depends on the number of systems that hold personal data, how many data flows and sub-processors must be mapped, the current state of records and policies, and how many decisions must be taken by people inside the organization. The 72-hour clock for notifying a supervisory authority of a personal data breach under Article 33 is fixed by the regulation, and readiness work should include the process that meets it. DeployOpen plans most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. It does not publish a price list, and a quote follows from that written scope. Confirm your applicable deadlines with counsel.
How DeployOpen prepares systems and evidence before a regulator asks
DeployOpen works on the systems and evidence that determine how a fine case looks from the regulator's side: security measures, breach handling and records. We plan, implement and document self-hosted open-source platforms inside your own infrastructure, and we prepare the evidence, but your organization owns its controls and any compliance conclusion.
How we scope
- We agree a written scope covering the systems, data flows and processing operations you want to show regulators are controlled.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work starts.
- Scope names which Article 32 measures, breach procedures and records are in and out, so gaps are visible from day one.
How we build
- We implement or harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We configure access control, logging, backup and restore so that security measures can be demonstrated, not only described.
- We run security testing on the in-scope systems and record findings, fixes and retests as part of the evidence trail.
How we hand over
- You receive documentation of configurations, security measures and test results, mapped to the processing operations in scope.
- We document how the controls relate to the Article 83(2) factors a supervisory authority weighs, such as technical measures and cooperation.
- Your staff are trained to run the evidence process, and ownership of controls and records stays with your organization.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers when systems change after handover.
- We can prepare updated evidence when your processing or infrastructure changes, so records stay current.
- Confirm with us in writing which findings we retest and which decisions remain with your DPO, counsel and the independent assessor.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), Articles 58, 82, 83 and 84 ↗
- EDPB Guidelines 04/2022 on the calculation of administrative fines under the GDPR (version 2.1) ↗
- EDPB national news: Dutch DPA fines Uber EUR 824 990 000 ↗
- EDPB national news: Swedish DPA fines Miljödata i Karlskrona ↗
- EDPB public consultations ↗

