CyphrQ
Menu

GDPR Requirements for Businesses: Bases, Rights, 72 Hours, Fines

GDPR requirements for businesses in plain language: lawful basis, people's rights, the 72-hour breach report, data transfers, fines, and a checklist.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

What are the GDPR requirements for businesses? A lawful basis for every use of personal data, honest notices, answers to people who exercise their rights, security that fits the risk, a report to the regulator within 72 hours of becoming aware of a breach that risks people's rights, safeguards when data leaves the EU, and records to prove it. Fines can reach 4% of worldwide turnover.

This is not legal advice. It is a plain-language reading by CyphrQ.ai, with links to the official sources so you and your legal adviser can check each point.

A note on sources. The Regulation's official text is on EUR-Lex. The fine caps in Article 83 and the one-month deadline in Article 12(3) were checked there. The breach guidance, the transfer decision and the example fine come from the European Data Protection Board (EDPB), European Commission and CNIL pages listed under Sources.

What do the GDPR requirements for businesses cover?

The General Data Protection Regulation (Regulation (EU) 2016/679, the GDPR) governs how organisations collect, use, store and share personal data: anything that identifies a living person, directly or indirectly. It applies to organisations in the EU, and to organisations elsewhere that offer goods or services to people in the EU or monitor their behaviour (Article 3).

Two roles matter throughout. The controller decides why and how personal data is used. The processor handles it on the controller's behalf, such as a payroll vendor or a cloud host.

Duty Where to look In one line
Follow the principles Article 5 Lawful, fair and transparent; limited purpose; minimal; accurate; time-limited; secure; and you can prove it
Have a lawful basis Article 6 One of six, chosen before you start
Respect people's rights Articles 12 to 22 Access, correction, erasure, objection and more
Secure the data Article 32 Measures that fit the risk
Use processors properly Article 28 A written contract with set terms
Keep records Article 30 A record of processing activities
Report breaches Articles 33 and 34 The regulator within 72 hours; people if the risk is high
Assess high risk Article 35 A data protection impact assessment (DPIA)
Control transfers Articles 44 to 49 Adequacy decision or safeguards

The sections below take the ones that cause the most trouble.

Which lawful basis can your organisation use under the GDPR?

Article 6(1) lists six: consent, a contract with the person, a legal obligation, protecting someone's vital interests, a task in the public interest, and legitimate interests. You need at least one before you process, and you should record which one and why.

Consent is the one people reach for first, and often the wrong one. It must be freely given and can be withdrawn. If you could not stop processing when someone withdrew, consent is not your basis. A contract basis fits data you need to deliver what the person bought. Legitimate interests fits uses a customer would reasonably expect, but you must weigh your interest against their rights and write that weighing down.

This is where GDPR differs from some neighbouring laws. Legitimate interests is a standard route here, whereas the UAE PDPL has no such basis, and the Saudi PDPL allows it only on conditions.

In practice: if marketing wants to reuse support-ticket data for a campaign, that is a new purpose. Check the original basis and the Article 5 purpose-limitation principle before anyone exports a list.

What rights do people have over their personal data under the GDPR?

Articles 12 to 22 give individuals these rights:

  • to be told what you do with their data (Articles 13 and 14);
  • to access a copy (Article 15);
  • to have errors corrected (Article 16);
  • to have data erased in listed cases (Article 17);
  • to restrict processing (Article 18);
  • to take their data to another provider (Article 20);
  • to object, including to direct marketing (Article 21);
  • not to be subject to solely automated decisions with significant effects, subject to exceptions (Article 22).

Article 12(3) sets a default response time of one month, which can be extended in complex cases if you tell the person why. You cannot usually charge for a first request.

The operational question is not the law but the plumbing. If a customer asks for erasure, can you find their data in the CRM, the backups policy, the analytics export and the vendor tools? Map where personal data lives before the first request arrives.

How fast must you report a GDPR data breach?

Within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights and freedoms. The EDPB's small-business guide says to notify the data protection authority "within 72 hours after having been made aware of the breach" (EDPB: Data breaches). That duty is Article 33.

Five points from that guide and Article 33 that trip people up:

  • When "aware" starts. The EDPB treats a controller as aware once it is reasonably certain that an incident has compromised personal data. You may run a short check first, but the clock is not waiting for the full investigation.
  • Late is allowed, unexplained is not. If you miss 72 hours, the notification must explain the delay.
  • Phases are allowed. If you do not have every detail, send an initial notice and add information in stages.
  • Not every breach is reported, but every breach is recorded. Breaches unlikely to result in a risk need no report to the authority. The EDPB page still says you must document them, including how you became aware and how you assessed the risk (Article 33(5)).
  • Your vendor has a duty too. A processor must tell the controller "without undue delay", so the controller can meet its own deadline (Article 33(2)).

A second duty sits on top. If a breach is likely to result in a high risk to people, you must also tell the individuals affected, without undue delay and in plain language (Article 34). The EDPB page lists the exceptions: the data was encrypted and the keys are safe, later steps have removed the high risk, or contacting everyone would take disproportionate effort, in which case a public notice is needed.

What to do this week: write down who decides that an incident is a reportable breach, who files, and who calls the processors. The Saudi explainer shows the same 72-hour idea under another law, with a different trigger. If you may also fall under NIS2, the clocks differ, so compare them in the NIS2 guide.

Can you transfer personal data outside the EU under the GDPR?

Yes, but only by a route Chapter V allows. There are two main ones.

  1. An adequacy decision (Article 45). The European Commission decides that a country or framework gives essentially equivalent protection, and data can then flow without extra steps.
  2. Appropriate safeguards (Article 46). Standard contractual clauses (SCCs), binding corporate rules (BCRs) and similar tools, used where there is no adequacy decision.

The best-known adequacy decision for businesses is the EU-US Data Privacy Framework. The Commission's page says it adopted the decision on 10 July, with the Official Journal reference dec_impl/2023/1795, and that "personal data can flow freely from the EU to companies in the United States that participate" (European Commission). The same page says the new binding US safeguards apply to all transfers under the GDPR to companies in the US, so they also support SCCs and BCRs.

Two limits. The framework covers participating US companies, not the US as a whole, so ask each vendor to show its certification. And the page I read does not discuss legal challenges to the decision, so check the Commission's page for its current status before you build a transfer plan on it alone.

In practice: an AI or SaaS vendor that processes prompts or files in the US is a transfer. Your file should say which Chapter V route covers it.

How big are GDPR fines, and what has a regulator actually fined?

Article 83 sets two tiers. For the more serious infringements, including breaches of the basic principles, lawful basis and people's rights, the cap is €20 million or 4% of worldwide annual turnover, whichever is higher. For others, including many obligations on controllers and processors, the cap is €10 million or 2% of turnover (Article 83(4) and (5), EUR-Lex). These are ceilings, not tariffs.

Here is what a real decision looks like. On 22 December 2025 the CNIL, France's regulator, fined the software company NEXPUBLICA FRANCE €1.7 million (deliberation SAN-2025-015). In late November 2022, several of its customers told the CNIL of breaches in its PCRM software, used by some departmental disability centres. Portal users had seen documents that belonged to other people (CNIL).

The CNIL found a breach of Article 32, security of processing. It said that most vulnerabilities came from ignorance of the state of the art and basic security principles, that several audit reports had already flagged them, and that they were fixed only after the breaches. It weighed the company's financial capacity, the number of people concerned and the sensitivity of the data, which reveals disability, and treated its IT specialism as aggravating. It issued no compliance order because the fixes were already in place.

The lesson is not the size of the number. A known weakness left open after an audit became the regulator's case. For an example centred on lawful basis, see the OpenAI decision in the UAE PDPL article.

Do you need a data protection officer or a DPIA under the GDPR?

Sometimes. A DPIA (Article 35) is a written assessment of risk before you start processing that is likely to result in high risk, such as large-scale monitoring, large-scale sensitive data or automated decisions about people. A data protection officer (DPO, Article 37) is mandatory for public authorities and for organisations whose core activities involve large-scale regular monitoring or large-scale sensitive data. Check the exact triggers and your national law on EUR-Lex.

In practice: a new AI tool that scores or profiles customers is a good prompt to run a DPIA, whatever your size.

A GDPR checklist for business owners

  1. Can you list every purpose you use personal data for, with one lawful basis each?
  2. Is each privacy notice accurate and written in plain language?
  3. Who answers a rights request, and can they find the data in every system within one month?
  4. Is there a written breach plan naming who decides, who files, and who calls processors?
  5. Does every processor have a written contract that covers breach reporting?
  6. For every vendor outside the EU, which Chapter V route do you rely on?
  7. Is your record of processing current?
  8. Do any of your uses call for a DPIA or a DPO?

Start with question 4. It is the one with a clock attached.

Going deeper: for security and IT teams

The legal duties become four pieces of evidence: security controls, records, processor contracts and a breach runbook.

Security of processing (Article 32). The text requires "appropriate technical and organisational measures" for the risk, and its examples include pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore data after an incident, and regular testing of the measures. The NEXPUBLICA decision shows how a regulator reads that: it cited the state of the art, the cost, and the nature and context of the processing, and it counted known audit findings left unfixed against the company. Make remediation tracking part of your evidence. Show that each audit finding has an owner, a date and a closure record, with risk acceptance signed where you chose not to fix.

For a customer portal like the one in that case, test authorisation, not just login. Can user A request user B's document by changing an identifier? Check that in code review and in penetration tests, and look for it in access logs, where one account requests many other accounts' record identifiers.

Records of processing (Article 30). Keep one entry per purpose. The Regulation's list covers the controller's details, the purposes, the categories of people and data, recipients, transfers to third countries, retention periods where possible, and a general description of security measures. Build it from your data flow diagram, and link each entry to the lawful basis and the Chapter V route.

Processor contracts (Article 28). The EDPB's guide says breach-reporting terms belong in the controller-processor contract. Put a time limit in it, for example that the processor reports suspected incidents within hours of discovery, because your 72 hours may already be running when the processor tells you. Also record sub-processors, locations, deletion on exit, and audit rights.

Breach triage workflow. A runbook that maps to Articles 33 and 34:

  1. Log the time of first detection, and who reported it. Evidence of when you became aware is what a regulator will test.
  2. Confirm with reasonable certainty whether personal data was affected. This is the EDPB's test for awareness, so do not wait for root cause.
  3. Assess risk to individuals: what data, how many people, how sensitive, whether it was encrypted with keys intact.
  4. Decide: no report with a documented reason, report to the authority, or report and notify individuals.
  5. File within 72 hours. If details are missing, send the initial notice and update in phases. If late, state the reason.
  6. Notify individuals in plain language if risk is high, with a contact point and steps they can take.
  7. Record the breach, the assessment and the response, even if you did not report it (Article 33(5)).

The EDPB's Guidelines 9/2022 on personal data breach notification (version 2.0) work through breach scenarios. I could open the EDPB's page for them but not read the full text, so read the PDF before you finalise your template.

Questions for vendors and auditors.

  • How quickly will you tell us about a suspected incident, and in what format?
  • Which Chapter V route covers each region you use, and can you show your Data Privacy Framework certification if you rely on it?
  • Who are your sub-processors, and how do you announce changes?
  • How would you erase one person's data from live systems, logs and backups, and what proof can you give us?
  • When did your last independent security test happen, and what happened to its findings?

Key takeaways

  • Every use of personal data needs one of six lawful bases under Article 6, chosen and recorded before you start.
  • Rights requests (Articles 12 to 22) have a default one-month response time, so map where data lives before the first one.
  • Report a breach that risks people's rights within 72 hours of becoming aware (Article 33), and document every breach, reported or not.
  • Transfers need an adequacy decision or safeguards. The EU-US Data Privacy Framework covers participating US companies only.
  • Fines cap at €20 million or 4% of worldwide turnover for the top tier. The CNIL's €1.7 million decision against NEXPUBLICA FRANCE turned on known security weaknesses left unfixed.

Sources