GDPR Compliance for US SaaS Companies With EU Customers

GDPR applies to RegaLoop if you process personal data of EU residents — regardless of where RegaLoop is incorporated, where your servers are, or whether you have a European office. If you have paying customers in Germany, France, or the Netherlands, you are subject to GDPR. Full stop.

Many US SaaS companies treat GDPR as a checkbox: add a consent banner, update your privacy policy, done. That approach worked in 2019 when enforcement was limited. The enforcement landscape in 2024–2026 looks different. The Irish DPC issued 1.3 billion euros in fines over two years. DPAs across the EU are increasingly coordinating on cross-border cases. And large EU enterprise customers are now including GDPR compliance representations in their vendor contracts.

This is not a legal primer — you need EU counsel for that. This is an operational breakdown of what GDPR compliance actually requires at the technical and process level for a typical US SaaS company.

Article 30: Records of Processing Activities

This is the foundation that most companies skip. Article 30 requires you to maintain a written record of every processing activity that involves personal data: what data you process, why, who you share it with, and how long you retain it. For a mid-size SaaS, this is typically 15–40 distinct processing activities once you map them all.

Your Article 30 record needs to cover:

• Customer data processed as part of RegaLoop (you're a data processor for your customers' data)
• Employee data (payroll, HR systems, performance tools)
• Marketing data (CRM, email list, event registrations)
• Operational data (support tickets, usage analytics)

Each processing activity entry needs: controller identity, purposes of processing, categories of data subjects and personal data, recipients (including sub-processors), international transfer mechanisms, and retention periods. This document needs to be maintained and updated as your processing changes — not written once and filed.

Data Processing Agreements

If you process personal data on behalf of your EU customers, you are a data processor under GDPR. Article 28 requires a written Data Processing Agreement (DPA) between you (the processor) and each customer (the controller). Most enterprise customers will have their own DPA template — and it will be long. Budget legal review time for each one.

Your DPA needs to address: instructions for processing, confidentiality obligations, security measures (Article 32), sub-processor management, data subject rights assistance, deletion/return of data, and audit rights. If your DPA template doesn't cover all of these, your customers' procurement teams will flag it.

You also need DPAs with your sub-processors — the SaaS tools you use that touch customer personal data. Most major vendors have standard DPA addenda available. The problem is most companies haven't mapped which of their 40+ SaaS tools are actually sub-processors and which are independent controllers.

International Data Transfers

If you process EU personal data in the US, you are conducting an international transfer. Post-Schrems II, transfers to the US require a valid transfer mechanism. The EU-US Data Privacy Framework (DPF), operational since July 2023, is the current primary mechanism for transfers to US companies that self-certify. Check whether RegaLoop is DPF-certified at dataprivacyframework.gov.

If you use Standard Contractual Clauses (SCCs) instead, you need the 2021 SCCs — the 2010 versions are invalid. And you need to complete a Transfer Impact Assessment (TIA) for each transfer, documenting whether US surveillance laws create risks to EU data subjects' rights.

This transfer mechanism analysis also needs to cascade to your sub-processors. If you use a US-based analytics tool that receives EU personal data, that tool needs a valid transfer mechanism too.

Article 32: Technical and Organizational Security Measures

GDPR requires "appropriate" technical and organizational measures to secure personal data, taking into account the risk to data subjects. It doesn't specify exactly what controls are required — which creates flexibility but also ambiguity. Regulators and courts have generally interpreted "appropriate" by reference to industry standards.

For a SaaS company, the baseline that regulators expect includes:

• Encryption at rest and in transit for personal data
• Access controls limiting who can access personal data to those with a legitimate need
• Regular testing and evaluation of security measures (vulnerability scanning, penetration testing)
• Pseudonymization where technically feasible
• A documented data breach response process meeting the 72-hour notification requirement (Article 33)

The 72-hour notification requirement is one of the areas most US companies are underprepared for. US breach notification laws typically allow 30–60 days. GDPR gives you 72 hours from discovery to notify the relevant supervisory authority. This requires a defined detection-to-notification workflow that most companies don't have.

Data Subject Rights Operationalization

GDPR gives EU individuals rights over their personal data: access, rectification, erasure, portability, restriction, and objection. You are required to respond to these requests within one month. For a SaaS company, operationalizing these rights means:

• A process for receiving and logging requests (dedicated email address, intake form)
• Verified identity check before providing data (to prevent data leakage)
• Technical ability to export a user's data in a machine-readable format (portability)
• Technical ability to delete a user's data across all systems — including backups, logs, and sub-processors
• A tracker to ensure responses are sent within 30 days

The deletion requirement is technically complex. Your primary database may have a clean delete path. Your analytics warehouse, your email marketing platform, your support ticket system, and your log aggregator typically don't have clean per-user delete workflows. Mapping and building this end-to-end is often a 2–4 week engineering project.

What Gets Companies Into Trouble

Based on the pattern of DPA enforcement actions, the highest-risk areas for US SaaS companies are: inadequate legal basis for processing (especially for marketing), transfers without valid mechanisms, failure to respond to data subject requests within the required timeframe, and inadequate DPAs with sub-processors.

Cookie consent issues generate the most visibility but are typically lower-fined than the structural issues above. Fix the structural issues first.