GDPR

GDPR is directly applicable EU law. It regulates how personal data — information relating to an identified or identifiable natural person — may be processed. Controllers determine purposes and means of processing; processors process on behalf of controllers under documented instructions, typically a data processing agreement (DPA). Both roles carry obligations, but they differ: controllers own lawful basis, transparency, and most data-subject rights responses; processors must assist, secure processing, and only use subprocessors with authorization.

Territorial scope is wider than "companies incorporated in the EU." Article 3 can apply to processing in the context of an EU establishment, and to non-EU organizations that offer goods or services to data subjects in the Union or monitor their behavior as far as it takes place in the Union. A US B2B SaaS product with EU customers, EU end users, or behavior-monitoring features often needs a GDPR program even when the company has no EU office.

Security sits in Article 32: appropriate technical and organizational measures, taking into account the state of the art, costs, nature, scope, context, and purposes of processing, as well as risks to rights and freedoms. Encryption, access control, resilience, restore capability, and regular testing appear as illustrative measures — not a fixed product checklist. Article 32 work often overlaps engineering controls you already run for SOC 2 or ISO/IEC 27001, but a SOC 2 report or ISO certificate does not equal GDPR compliance.

Operational pillars for SaaS teams usually include: records of processing, lawful-basis analysis per processing activity, privacy notices, Data Processing Agreements with customers and subprocessors, Data Protection Impact Assessments where required, breach detection and notification playbooks (Articles 33–34), and rights request workflows (access, erasure, portability, and others). Supervisory authorities and the European Data Protection Board (EDPB) issue guidance that shapes expectations; prefer primary Regulation text and EDPB guidelines over vendor marketing.

Use /tools/framework-selector when sequencing GDPR against SOC 2, ISO 27001, or HIPAA for your buyer mix. Deep dives on security-of-processing patterns belong beside Article 32 control pages such as /controls/gdpr/article-32 and adjacent access themes like /controls/soc-2/cc6-1 when you reuse IAM evidence across frameworks. This site does not sell compliance software; treat counsel as authoritative for your facts.

The General Data Protection Regulation — Regulation (EU) 2016/679 — is an EU regulation on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. It repealed the prior Data Protection Directive framework for most purposes and created a more uniform ruleset across Member States, while still allowing national law on specific topics. The Regulation entered into application on 25 May 2018 and remains the baseline for personal-data processing in the EEA context that SaaS teams encounter in contracts and questionnaires.

Personal data is broadly defined: any information relating to an identified or identifiable natural person (data subject). Identifiers can be direct (name, email) or indirect (device IDs, online identifiers, location data combined with other information). Special categories of personal data (Article 9) — including health data, biometric data used for identification, and others listed in the Regulation — trigger stricter conditions. Pseudonymization and anonymization are not the same: properly anonymized data falls outside GDPR's personal-data regime; pseudonymized data typically remains personal data.

Core principles in Article 5 frame almost every product decision: lawfulness, fairness, and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality (security); and accountability. Accountability means you must be able to demonstrate compliance — policies, records, DPIAs, and security measures are evidence of that duty, not optional bureaucracy.

Lawful bases under Article 6 include consent, contract, legal obligation, vital interests, public task, and legitimate interests (with balancing). B2B SaaS often relies on contract and legitimate interests for account administration and product improvement, and on consent where required for certain cookies or marketing — but lawful-basis selection is fact-specific and belongs with counsel. Controllers must also meet transparency duties (Articles 13–14) so people understand what is collected and why.

Controller versus processor is a legal characterization based on who determines purposes and means, not on who has more engineering staff. A SaaS vendor is frequently a processor for customer-uploaded end-user data and a controller for its own billing, website analytics, and employee data. Mixed roles are normal; contracts and privacy notices should reflect the split. Article 28 sets processor obligations and the need for a contract (DPA) that includes required terms — processing only on documented instructions, confidentiality, security, subprocessor flow-down, assistance with rights and breach, deletion or return at end of service, and audit/information rights as specified.

International transfers (Chapter V) restrict moving personal data to third countries lacking an adequacy decision unless appropriate safeguards (such as standard contractual clauses) and transfer impact analysis practices expected by regulators are in place. Schrems-related case law and EDPB recommendations continue to shape transfer risk assessments; treat transfer tooling as legal infrastructure, not a checkbox beside encryption alone.

Enforcement includes investigative and corrective powers for supervisory authorities, administrative fines under Article 83 (with upper tiers commonly discussed as up to €20 million or 4% of worldwide annual turnover, whichever is higher, for certain infringements), and private claims. Practical SaaS risk often appears first as blocked enterprise deals, customer audit findings, or regulatory questionnaires rather than headline fines — but fine risk is real for systemic failures.

Version literacy in RFPs matters. Saying "we are GDPR compliant" without describing roles, locations of processing, subprocessors, and transfer mechanisms invites follow-up. Prefer precise statements: you act as processor for defined services under a DPA, implement Article 32 measures described in a security exhibit, and maintain a subprocessor list customers can review.

Any organization that processes personal data within GDPR's territorial or material scope needs a GDPR program — not a badge, a living set of legal and operational controls. For product companies, the common triggers are: offering a SaaS product to organizations or individuals in the EEA/UK (noting UK GDPR as a related but separate regime after Brexit), processing EU employee or contractor data, running marketing sites that collect EU visitor data, or embedding SDKs that monitor behavior of users in the Union.

US and other non-EU startups often underestimate scope. Article 3(2) can pull in a California company with no EU entity if it offers services to data subjects in the Union or monitors their behavior. "We only sell B2B" is not an automatic escape: your customer's employees and end users are natural persons, and you may be a processor for their data while remaining a controller for your own CRM and website. Use /tools/framework-selector to pressure-test whether GDPR, SOC 2, ISO 27001, or HIPAA dominates your next twelve months of buyer asks.

Persona lenses clarify ownership. Legal and privacy counsel own lawful bases, notices, DPIA thresholds, transfer mechanisms, and DPA wording. Security and engineering own Article 32 measures — access control, encryption, logging, backup restore, vulnerability management — often reusing the same control set mapped for SOC 2 CC6-style access and ISO Annex A themes. Product and data teams own minimization and retention. Support and trust operations own rights-request SLAs. Sales must not promise "GDPR certified" (there is no such EU certificate) or claim controller status incorrectly in security questionnaires.

You need GDPR readiness earlier than a vanity policy page when: EU enterprise procurement attaches a security and privacy schedule; a marketplace listing requires a DPA and subprocessor transparency; you expand into EU regions on your cloud; or you process special-category data (for example health-related consumer apps) where Article 9 conditions apply. Waiting until three deals stall on DPA negotiation is more expensive than standing up a standard processor DPA, records of processing, and a coherent Article 32 narrative.

HIPAA is not a substitute. If you handle US protected health information as a covered entity or business associate, HIPAA applies on its own track. Some health-tech products face both HIPAA and GDPR when serving EU individuals' health data — map roles carefully rather than assuming one regime covers the other. Likewise, SOC 2 Privacy category criteria are related to but not identical with GDPR duties; see /compare/soc-2-vs-iso-27001 for how security attestations and certifications relate to legal compliance without replacing it.

Avoid theater scope. Publishing a privacy policy copied from another SaaS while your product retains logs indefinitely, shares data with undocumented subprocessors, or lacks a rights-request channel creates accountability risk under Article 5(2). Match program depth to actual processing: a simple B2B tool with business contact data still needs lawful basis and security, but may not need the same DPIA intensity as a large-scale profiling platform.

Group companies and acquisitions complicate whoNeedsIt: an EU subsidiary can create establishment under Article 3(1) even if the parent thought it was "US-only." Controllers jointly determining purposes may be joint controllers under Article 26 with arrangement duties. Clarify these structures before Stage-of-deal legal review invents them under time pressure.

GDPR compliance for a SaaS company is a system of role clarity, lawful processing, rights operations, security measures, and vendor governance — not a single audit event. Start by inventorying processing activities: what personal data you collect, from whom, for what purposes, where stored, who accesses it, which vendors receive it, and how long retained. That inventory feeds records of processing activities (Article 30) for controllers and the corresponding processor records where applicable.

Role mapping comes next. For each data flow, decide controller, processor, or joint controller. Customer content in a multi-tenant app is often processed as a processor; your billing email list is typically controller processing. Document instructions boundaries in the DPA so engineering features (for example AI training on customer content) do not silently exceed authorized purposes. Subprocessors — cloud hosts, email providers, support tools, analytics — require controller authorization and flow-down of Article 28 terms; maintain a current list and a change-notification process customers expect in enterprise DPAs.

Lawful basis and transparency connect product copy to legal reality. Each controller purpose needs a basis under Article 6 (and Article 9 if special categories). Privacy notices must be intelligible and reflect actual practices. Consent, where used, must be freely given, specific, informed, and unambiguous — pre-ticked boxes and bundled "agree to everything" patterns remain high-risk. Legitimate interests require a documented balancing test and attention to opt-out where appropriate.

Data-subject rights (Chapter III) need operational playbooks: intake channels, identity verification proportionate to risk, retrieval from production and backups per policy, and response timelines (generally one month, extensible under conditions). SaaS processors must assist controllers — meaning your product may need admin export tools, deletion workflows, and support runbooks so customers can meet their deadlines.

Article 32 security-of-processing is where engineering lives. Measures must be appropriate to risk. Illustrative measures in the Regulation include pseudonymization and encryption of personal data; ability to ensure ongoing confidentiality, integrity, availability, and resilience; ability to restore availability and access in a timely manner after an incident; and a process for regularly testing, assessing, and evaluating effectiveness. Access control — least privilege, strong authentication, joiner-mover-leaver — is almost always material; see /controls/gdpr/article-32 and reuse patterns from /controls/soc-2/cc6-1 when evidence can serve both attestation and GDPR accountability. Article 32 does not prescribe SOC 2 or ISO 27001, but an ISMS-style program often helps demonstrate organizational measures.

DPIAs (Article 35) are required when processing is likely to result in a high risk to rights and freedoms — for example systematic large-scale monitoring or large-scale special-category processing. EDPB and supervisory authority lists help interpret thresholds. DPIAs are design tools: mitigate before launch, do not staple a questionnaire after go-live.

Breach notification (Articles 33–34): controllers notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to rights and freedoms. High-risk breaches may require communication to data subjects. Processors must notify controllers without undue delay after becoming aware. Detection, classification, and counsel-engaged notification decisions need rehearsed incident response — not ad-hoc Slack threads.

Transfers and localization choices interact with architecture: EU regions, customer-managed keys, and subprocessor geography affect transfer assessments. Security measures support but do not alone legalize restricted transfers.

Accountability binds the system: training, vendor reviews, audit rights exercise, and management oversight show you can demonstrate compliance when a customer or authority asks. Align metrics with reality — number of rights requests closed on time, subprocessor reviews completed, restore tests performed — rather than vanity policy counts.

Begin with a processing inventory and role map endorsed by legal and engineering. Name systems of record for personal data (production databases, logs, support desks, CRM, billing, analytics). Classify data types, including any special categories. Draft or refresh records of processing. Identify international transfers and subprocessors early — late discovery during enterprise DPA negotiation is a common deal delay.

Select and document lawful bases per controller purpose; update privacy notices and in-product disclosures to match. For processor services, prepare a standard Article 28 DPA, security exhibit aligned with Article 32, and subprocessor disclosure process. Route exceptions through legal rather than letting each sales engineer invent annexes.

Stand up rights-request and breach playbooks with owners, SLAs, and tooling. Verify you can locate a data subject's data across tenants and environments within the response window. Test backup deletion and retention interactions so erasure commitments are honest. Train support and on-call engineers on escalation paths that include privacy counsel for breach risk assessment.

Implement and evidence Article 32 measures: identity and access management, encryption in transit and at rest as appropriate, logging and monitoring, vulnerability management, secure development, backup and restore testing, and vendor security review for material processors. Prefer controls that already serve SOC 2 or ISO 27001 so engineering maintains one set with multiple mappings — sequencing discussion at /compare/soc-2-vs-iso-27001. Link technical deep dives from /controls/gdpr/article-32 into your internal runbooks.

Run DPIAs before launching high-risk features (new biometrics, extensive profiling, novel AI on personal data). Record mitigations and residual risk acceptance at the right level. Review cookies and tracking on marketing sites; consent management where required is part of GDPR operations, not a separate "marketing IT" island.

Establish governance cadence: periodic review of records of processing, access reviews for systems with personal data, subprocessor due diligence, tabletop breach exercises, and training for staff who handle personal data. Appoint contacts for privacy inquiries; larger organizations may designate a Data Protection Officer where Articles 37–39 require or where it is otherwise appropriate.

When entering enterprise sales cycles, prepare a packet: DPA, security overview mapped to Article 32 themes, subprocessor list, transfer mechanism summary, and optional SOC 2 or ISO artifacts as supporting evidence — clearly labeled as complementary, not as GDPR certification. Keep claims consistent across trust center, MSA, and questionnaire answers.

Close the loop after incidents and audit findings with corrective action. Accountability fails when policies update but production retention and logging practices do not. Assign deputies for critical privacy operations so leave-of-absence or attrition does not freeze rights responses.

GDPR is continuous legal compliance, not a three-month certification project. That said, first-time SaaS programs often take three to nine months to reach a credible enterprise-ready state: inventory and role mapping, DPA and notice refresh, Article 32 hardening, rights and breach playbooks, and subprocessor governance. Teams with mature SOC 2 access, change, and logging evidence compress the security track; they still need legal analysis, records, and rights operations that attestation fieldwork does not create by itself.

Critical path items that slip: agreeing controller versus processor positions for ambiguous product features; finishing a complete subprocessor inventory including shadow IT; implementing durable deletion and export tooling; aligning marketing analytics with consent requirements; and completing transfer assessments for US or other third-country tools. Parallelize legal drafting of the DPA with engineering work on Article 32 gaps — serializing them doubles calendar time.

DPIA-heavy launches need extra runway. Building a feature that profiles users at scale or processes health data may require DPIA workshops, mitigation engineering, and sometimes prior consultation patterns in edge cases — bake weeks into product roadmaps rather than discovering the duty at launch review. Breach readiness tabletops should run before you need them; the 72-hour controller notification clock does not pause for undocumented on-call ownership.

Ongoing timeline is quarterly and annual rhythms: access reviews, vendor reviews, notice updates when purposes change, and training refreshers. Major cloud region expansions or AI features should trigger privacy review gates comparable to security architecture review. If you are dual-tracking ISO 27001, remember surveillance and management review calendars can share security evidence but do not replace DPIA or DPA maintenance — see /compare/soc-2-vs-iso-27001 for dual-program sequencing.

Deal-driven accelerations are real: a strategic EU customer may force a thirty-day scramble. Scrambles succeed only when inventory and DPA templates already exist; otherwise you negotiate under duress and accept unfavorable audit clauses. Invest in the foundation before pipeline urgency peaks.

UK customers may require UK GDPR and ICO-oriented wording in parallel with EU GDPR. Plan dual-notice and transfer language if UK is material revenue, rather than assuming EU DPA text automatically satisfies UK counsel. Brexit did not remove privacy scrutiny from UK enterprise procurement.

GDPR program cost is mostly people and process: privacy counsel (internal or external), engineering time for Article 32 and rights tooling, vendor security reviews, possible consent-management and privacy-operations tooling, training, and opportunity cost when deals wait on DPA negotiation. Unlike SOC 2, there is no standard "GDPR audit fee" that produces a public certificate — though customers may contractually require audits, certifications as supporting evidence, or third-party assessments.

External counsel costs vary with complexity: a straightforward B2B processor DPA and notice refresh differs from a multi-product, multi-subsidiary controller program with special-category data and global transfers. Budget separately for transfer mechanism updates when standard contractual clauses or regulatory guidance change. Tooling for data subject requests, data discovery, and consent can reduce manual toil but does not replace legal ownership of lawful bases.

Security spend for Article 32 often overlaps SOC 2 and ISO 27001 budgets — fund IAM, logging, encryption, and incident response once and map outward. Educational ranges for adjacent attestation programs live at /costs/soc-2/overview; use them to model shared control investment, not as a GDPR fine estimate. Regulatory fine exposure is a risk metric for the board, not a substitute for building accountable operations.

Soft costs dominate post-mortems: engineers building one-off export scripts per enterprise customer; sales cycles slipping while legal redlines subprocessors; and rework when product launches AI features without a DPIA. Underfunding rights-request operations creates both regulatory and customer-trust risk when volumes spike after a public incident.

Compare build-versus-buy for privacy operations platforms against actual ticket volumes. A small B2B SaaS with few rights requests may operate shared inboxes and runbooks; a consumer-facing product may need automated discovery. Revisit cost each year as processing activities and EU revenue share change.

Insurance, customer contractual liability caps, and indemnity clauses interact with privacy risk but do not implement Article 32. When finance asks for a single annual GDPR number, give a range tied to counsel retainer, tooling seats, and estimated engineering weeks for privacy features — and separate the shared security control budget already counted under SOC 2 or ISO initiatives.

SOC 2 and ISO/IEC 27001 frequently support the security narrative customers want alongside GDPR. Article 32 measures map naturally to access control, encryption, logging, incident response, and supplier security — themes familiar from Trust Services Criteria and Annex A. A SOC 2 Type II or ISO 27001 certificate can evidence technical and organizational measures, yet neither proves lawful basis, DPIA quality, or successful rights operations. Sequencing guidance for the two assurance artifacts sits at /compare/soc-2-vs-iso-27001; use /tools/framework-selector when deciding what to lead with for US versus EU buyers.

UK GDPR and the UK Data Protection Act regime remain relevant for UK customers after Brexit; many SaaS vendors maintain EU GDPR and UK GDPR aligned documents with jurisdiction-specific contacts. Adequacy and transfer tools differ by destination; do not assume an EU-focused transfer story automatically satisfies UK counsel.

CCPA/CPRA and other US state privacy laws may apply in parallel for US residents; they are not GDPR clones. Where product one-pagers blur "GDPR/CCPA compliant," prefer precise multi-regime language. ePrivacy rules and national implementations affect cookies and electronic communications beyond the GDPR text alone.

HIPAA applies to PHI in US healthcare contexts. A product can be in-scope for HIPAA as a business associate and simultaneously process EU personal data under GDPR — run both programs with clear role maps rather than stretching a BAA into a DPA or vice versa.

NIST CSF and similar frameworks can structure risk discussions that feed Article 32 appropriateness analysis without substituting for legal compliance. Maintain one crosswalk from engineering controls to SOC 2 criteria, ISO Annex A, and GDPR articles so teams do not implement three conflicting access-control policies. Practical entry points include /controls/gdpr/article-32 and /controls/soc-2/cc6-1.

Avoid claiming "ISO 27001 means GDPR done" or "SOC 2 Privacy category equals GDPR." Precise artifact naming reduces questionnaire churn and supervisory risk when marketing overclaims.