Max fines: €20M or 4% of global annual turnover · 72-hour breach clock enforced since 2018
EU GDPR Compliance Consulting

GDPR fines are real. Is your SaaS compliant for EU users?

GDPR applies extraterritorially under Article 3. Any business offering goods or services to EU data subjects — or monitoring their behavior — is in scope, even with no EU office. We deliver the record of processing, DPIA, and SCC package that EU regulators expect.

Compliance scope
GDPR Art. 5–32 72h Breach Notification DPO Assessment Cross-border Transfers (SCCs) NIST CSF Mapping Record of Processing
Territorial scope

GDPR's extraterritorial reach. Three triggers that pull you in.

Article 3 defines when GDPR applies. If your organization meets any of the three triggers below you are a controller or processor — even if your servers, headquarters, and staff are all outside the EU.

Trigger 1 · Art. 3(1)
Established in the EU
Any physical presence, branch, or subsidiary in the EU
Includes remote-only companies with EU employees as their "establishment"
Implication: full GDPR applies; designate a lead supervisory authority based on main establishment
Trigger 2 · Art. 3(2)(a)
Offers Goods/Services to EU Data Subjects
US SaaS with paying EU customers
Free tool used by EU residents (language, pricing in EUR, mentions of EU)
Implication: representative required (Art. 27); cookie/privacy notice in plain language
Trigger 3 · Art. 3(2)(b)
Monitors EU Residents' Behavior
Behavioral analytics, ad-tech, retargeting pixels on EU users
Online-only business that profiles EU visitors
Implication: DPO likely required; legitimate-interest balancing test mandatory
Article 6 — Lawful bases

Six lawful bases. Pick one — and prove it.

Every personal-data processing activity must rest on a documented lawful basis under Article 6. Justify the basis before processing starts; record it in your Record of Processing Activities (Art. 30); tell data subjects which basis applies in your privacy notice.

Check Your Posture →
Consent

Art. 6(1)(a) — Freely Given, Specific, Informed

Requires unambiguous affirmative action; must be as easy to withdraw as to give. Required for marketing email, most cookies, and any processing where the data subject has a genuine choice.

Contract

Art. 6(1)(b) — Necessary for a Contract

Use only when processing is objectively necessary to deliver what the data subject contracted for. Cannot be invoked for "nice-to-have" data extending the scope of the service.

Legal Obligation

Art. 6(1)(c) — Compliance with the Law

Applies when EU or member-state law mandates the processing (tax records, AML, employment law). The specific legal basis must be identified and cited in your ROPA.

Vital Interests

Art. 6(1)(d) — Protect Someone's Life

Narrow scope — limited to life-threatening emergencies. Rarely the right basis for routine SaaS processing; document any reliance on it tightly.

Public Task

Art. 6(1)(e) — Task in the Public Interest

Reserved for public authorities or organizations performing an official public function. Most private-sector companies cannot rely on this basis.

Legitimate Interests

Art. 6(1)(f) — Legitimate-interest Balancing Test

Most flexible basis, but requires a documented three-part test: legitimate purpose, necessity, and balancing against data-subject rights. Cannot be used to override consent when consent is appropriate.

DPO & breach clock

Two non-negotiables. Get them right or pay the fine.

Two obligations get disproportionate scrutiny from supervisory authorities: appointing a Data Protection Officer when triggers are met, and the 72-hour breach notification clock under Articles 33–34.

Art. 37
Data Protection Officer — Mandatory Triggers
Public authorities (always)
Core activities require large-scale, regular, systematic monitoring of data subjects (ad-tech, profiling, behavioral analytics)
Core activities consist of large-scale processing of special-category data (health, biometric, racial/ethnic, political, religious, trade union, sex life/orientation)
DPO must be independent, expert, resourced; can be outsourced (DPO-as-a-Service)
Art. 33
72-Hour Notification to Supervisory Authority
Personal-data breach likely to result in risk to data-subject rights
Clock starts when you become "aware" — robust detection logging matters
Late notification requires a documented justification
Phased reporting permitted when full facts aren't yet known
Art. 34
Without Undue Delay to Data Subjects
Required only when breach is likely to result in a high risk
Notification must describe nature of breach and likely consequences
Exemptions when data was encrypted, subsequently rendered unintelligible, or mitigating measures reduce risk
Pre-approved template communications save critical minutes during an incident
Framework comparison

How GDPR compares to HIPAA, SOC 2, CCPA, and PCI-DSS.

Most US-headquartered companies face overlapping requirements. GDPR is a regulation — enforceable by data-protection authorities with fines up to 4% of global turnover. SOC 2 and PCI-DSS are market or industry obligations. HIPAA, CCPA, and GDPR all touch personal data but define it differently and trigger different breach clocks.

vs HIPAA

Broader scope, harder breach clock

Both protect personal data but GDPR covers any personal data of EU subjects, while HIPAA covers only Protected Health Information held by covered entities and business associates. GDPR requires an explicit lawful basis (consent, contract, legitimate interest, etc.); HIPAA's "minimum necessary" rule is narrower. Breach clock: GDPR 72 hours, HIPAA 60 days.

vs SOC 2

Mandatory regulation vs voluntary attestation

GDPR is a binding regulation enforced by EU data-protection authorities with penalties tied to global turnover. SOC 2 is an attestation report voluntarily commissioned to win enterprise SaaS deals. Both share security, availability, and confidentiality concepts, but GDPR adds lawful basis, ROPA, DPO, and data-subject rights that SOC 2 does not directly address.

vs CCPA/CPRA

Stronger penalties, stricter transfers

Both grant consumer rights (access, deletion, opt-out of sale), but GDPR has steeper penalties (4% global turnover vs CCPA's $7,500 per intentional violation / $2,500 per unintentional) and stricter cross-border transfer rules (SCCs, adequacy decisions, EDPB guidance). CCRPA's right to correct, limit use of sensitive PI, and opt-out of automated decisioning overlap partially with GDPR Art. 22.

vs PCI-DSS

Different data subject, different enforcer

Both demand strong technical controls — access control, encryption, logging, vendor due diligence. But the data subject differs (EU residents vs. cardholders), the enforcer differs (DPAs vs. card brands and acquiring banks), and the penalty structure differs (GDPR fines capped at 4% of global turnover vs. PCI penalties ranging from fines to lost card-processing privileges).

Cross-framework mapping

Already working on NIST CSF? You have a foundation — but not full coverage.

NIST CSF and GDPR share meaningful overlap on technical controls — access control, encryption, monitoring, incident response. But GDPR-specific obligations (lawful basis, ROPA, data-subject rights, cross-border transfer rules) are not addressed by NIST and require dedicated work. Here is a realistic coverage estimate.

NIST CSF Function Description Primary GDPR Articles Est. Coverage
GV — Govern Organizational context, risk management strategy, supply chain Art. 24 (Controller accountability), Art. 28 (Processor contracts), Art. 30 (ROPA)
~50%
ID — Identify Asset management, risk assessment, improvement planning Art. 30 (ROPA), Art. 35 (DPIA), Art. 39 (DPO tasks)
~55%
PR — Protect Access control, awareness, data security, platform security Art. 25 (Privacy by Design), Art. 32 (Security of Processing), Art. 6 (Lawful basis)
~65%
DE — Detect Continuous monitoring, anomaly detection Art. 32 (Security of Processing — testing & monitoring), Art. 33 (Breach detection)
~55%
RS — Respond Incident management, analysis, communication, mitigation Art. 33 (Notify supervisory authority within 72h), Art. 34 (Notify data subjects)
~60%
RC — Recover Recovery planning, communications Art. 32 (Restoration of availability), Art. 5(1)(f) (Integrity & confidentiality)
~40%

What this means for you: If you've already invested in a NIST CSF program — or purchased a Rhodigital NIST Policy Package — roughly half of your GDPR technical-control work is already done. A cross-mapping assessment identifies exactly which GDPR articles your existing controls satisfy and which still need dedicated attention (lawful-basis identification, ROPA, DPIA, DPO designation, data-subject-rights procedures, SCCs). See the NIST Policy Package →

How we work

From GDPR readiness assessment to ongoing DPO support.

GDPR compliance is not a single project — it's an ongoing program. We follow a phased engagement model that ends with sustained operational coverage (DPO-as-a-Service, transfer-mechanism maintenance) rather than an open-ended consulting relationship.

01
Phase 1 · Week 1–2
Scoping & DPIA

Define your role(s) — controller, joint controller, or processor — across each processing activity. Identify EU data subjects, data types, volumes, and transfer routes. Map each high-risk processing activity to a Data Protection Impact Assessment (DPIA) under Art. 35. The scoping decisions made here determine your supervisory authority, your DPO trigger, and your representative obligation under Art. 27.

02
Phase 2 · Week 2–5
Gap Analysis & ROPA

Systematic review against the full GDPR accountability package. Each control area — lawful basis, ROPA, data-subject rights procedures, security of processing, breach notification, vendor due diligence — is marked Compliant, Partially Compliant, or Non-Compliant. The deliverable is your Record of Processing Activities (Art. 30) and a prioritized gap register.

03
Phase 3 · Week 5–10
Remediation & Documentation

Close the gaps. This phase produces privacy notice updates, cookie-consent flows, ROPA inventory, data-subject-rights intake processes, Standard Contractual Clauses for cross-border transfers, vendor due-diligence questionnaires, and an updated internal register of processing activities. For organizations with existing NIST CSF policies, this phase is materially shorter.

04
Phase 4 · Ongoing
Ongoing DPO-as-a-Service & Transfers (SCCs)

Sustained coverage: outsourced DPO fulfilling Art. 38–39 duties, periodic ROPA review, supervisory-authority liaison, breach-response coordination, and ongoing cross-border transfer rule maintenance (SCC updates, EDPB guidance, adequacy decisions). GDPR doesn't end at certification — it requires continuous accountability.

GDPR exposure doesn't wait for certification.

Start with a free security posture check. Understand where you stand before a data subject access request or breach forces the issue.

Frequently asked

Common GDPR questions.

Does GDPR apply to US companies or only EU-based organizations? +
Yes — GDPR applies extraterritorially under Article 3. Any organization anywhere in the world that processes personal data of individuals located in the EU is in scope if it (a) offers goods or services to EU data subjects, or (b) monitors the behavior of EU data subjects. A US SaaS company with paying EU customers, a free tool used by EU visitors, or analytics tracking of EU users is fully subject to GDPR obligations and enforcement by EU supervisory authorities, with fines up to 4% of global annual turnover or €20 million — whichever is higher.
What are the six lawful bases for processing personal data under GDPR? +
Article 6 enumerates six lawful bases for processing: (1) consent — freely given, specific, informed, and withdrawable; (2) contract — processing necessary to perform a contract with the data subject; (3) legal obligation — required to comply with a legal duty; (4) vital interests — protecting someone's life; (5) public task — performing a task in the public interest; (6) legitimate interests — your legitimate interests, weighed against the rights and freedoms of the data subject. The basis must be identified before processing starts, documented in your Record of Processing Activities (Art. 30), and disclosed in your privacy notice.
When is a Data Protection Officer (DPO) mandatory under GDPR? +
Under Article 37, you must designate a DPO when your core activities require large-scale, regular and systematic monitoring of data subjects (most ad-tech, profiling, and behavioral analytics companies), or when your core activities consist of large-scale processing of special-category data (health, biometric, racial/ethnic, political, religious, trade union, sex-life/orientation data). Public authorities must always have a DPO. The DPO can be an employee or an outsourced service provider, but must be independent, expert, and adequately resourced (Art. 38–39).
How quickly must we notify the supervisory authority of a breach under GDPR? +
Article 33 requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to the rights and freedoms of data subjects. If notification is later than 72 hours, you must provide reasons for the delay. Article 34 additionally requires notification to affected data subjects "without undue delay" when the breach is likely to result in a high risk to their rights. Both clocks are tight — incident response runbooks must specify how the contact details for the lead supervisory authority are obtained in advance.
How does GDPR compare to HIPAA, SOC 2, CCPA/CPRA, and PCI-DSS? +
GDPR vs HIPAA: both protect personal data but GDPR covers any personal data of EU subjects, requires explicit lawful basis, and has a 72-hour breach clock (HIPAA: 60 days). GDPR vs SOC 2: GDPR is a binding regulation enforced by DPAs with 4% global turnover fines; SOC 2 is a voluntary market-driven attestation. GDPR vs CCPA/CPRA: both grant consumer rights but GDPR has steeper penalties and stricter cross-border transfer rules. GDPR vs PCI-DSS: both demand strong technical controls but serve different data subjects (EU residents vs cardholders) and have different enforcement bodies.