GDPR for SaaS Companies: The Complete Compliance Guide

When you are the controller vs processor:

• Processor: Customer data stored in your platform (their users, their files, their records)
• Processor: Data processed according to customer instructions via your API or UI
• Controller: Your own customer accounts, billing data, CRM records
• Controller: Product analytics, usage tracking, feature telemetry
• Controller: Marketing email lists, website visitor data, cookie data
• Controller: Employee and contractor personal data

• 1. Maintain a sub-processor list. Publish and keep current a list of every third party that processes personal data on your behalf. Include their name, purpose, and location.
• 2. Notify before changes. Give customers advance notice (typically 30 days) before adding or replacing a sub-processor. Include an objection mechanism.
• 3. Flow down obligations. Every sub-processor contract must impose the same data protection obligations that exist in your DPA with your customer. If your DPA says data must be encrypted at rest, your sub-processor must encrypt at rest.
• 4. Remain liable. If your sub-processor causes a data breach, you are liable to your customer. You can pursue the sub-processor separately, but the initial responsibility stays with you.

Required DPA elements under Article 28(3):

• 1. Subject matter and duration. Define what your product does with the data and how long processing lasts (typically the term of the service agreement plus a deletion period).
• 2. Nature and purpose of processing. Hosting, storage, computation, analytics, communication delivery. Be specific to your product.
• 3. Types of personal data. Names, email addresses, IP addresses, usage data, file contents, payment data. List everything your product handles.
• 4. Categories of data subjects. Your customer's end users, their employees, their clients. Define who the data belongs to.
• 5. Obligations and rights of the controller. The customer's right to audit, instruct, and receive breach notifications.
• 6. Technical and organizational measures. Encryption, access controls, incident response, employee training. Reference your security documentation.
• 7. Sub-processor provisions. The list, notification mechanism, and objection procedure described in the previous section.
• 8. Data deletion or return. What happens when the contract ends. Define retention periods, export formats, and deletion timelines.

Transfer mechanisms:

• 1. Adequacy decisions. The European Commission has decided that certain countries provide adequate data protection. Transfers to these countries need no additional safeguards. The list includes the UK, Switzerland, Japan, South Korea, and as of 2023, the United States (under the EU-US Data Privacy Framework). The US adequacy decision is being challenged in court.
• 2. Standard Contractual Clauses (SCCs). Pre-approved contractual terms adopted by the European Commission. Since June 2021, new SCCs with a modular structure are required. You must use the correct module: Module 2 (controller-to-processor) for most SaaS customer relationships, Module 3 (processor-to-processor) for your sub-processor relationships.
• 3. Binding Corporate Rules (BCRs). Approved internal rules for multinational groups. Expensive and time-consuming to set up (12-18 months for approval). Only practical for large enterprises, not typical SaaS companies.

Encryption

• • In transit: TLS 1.2+ on all connections. No exceptions. This includes internal service-to-service communication, not just the public-facing API. Certificate pinning for mobile clients.
• • At rest: AES-256 for databases, file storage, and backups. If you use managed databases (RDS, Cloud SQL), enable encryption and verify it is active. For sensitive fields (social security numbers, health data), consider application-level encryption so even database administrators cannot read plaintext.
• • Backup encryption: Backups must be encrypted with the same rigor as production data. An unencrypted database dump on an S3 bucket is a breach waiting to happen.

Access Controls

• • Principle of least privilege. Engineers should not have standing access to production databases. Use just-in-time access with approval workflows and automatic expiration.
• • Multi-factor authentication. Mandatory for all internal systems, not optional. Hardware keys (YubiKey) for infrastructure access.
• • Role-based access control (RBAC). Within your product, customers must be able to control who in their organization can access what data. This is both a compliance requirement and a sales enabler.

Audit Logging

• • Who accessed what, when. Log every access to personal data, every modification, every export. Immutable logs stored separately from the application database.
• • Customer-facing audit logs. Enterprise customers will ask for audit trails within your product. Give them visibility into who on their team accessed data and what changes were made.
• • Retention and integrity. Logs must be tamper-evident and retained long enough to support incident investigation (minimum 12 months, often longer for regulated industries).

Data Isolation (Multi-Tenancy)

• • Logical isolation. At minimum, every database query must be scoped to the tenant. A bug that leaks data between customers is both a breach and a business-ending event.
• • Encryption key isolation. Consider per-tenant encryption keys. If one tenant's key is compromised, other tenants' data remains protected.
• • Dedicated infrastructure option. Some enterprise customers will require their data to be physically separated. Offering single-tenant deployment (dedicated database, dedicated compute) addresses this.

Incident Detection and Response

• • Real-time alerting. Anomaly detection on authentication events, data access patterns, and API usage. You cannot notify a breach within 72 hours if you do not detect it for weeks.
• • Incident response runbook. A documented, tested procedure for classifying, containing, and reporting breaches. Include communication templates for customers and supervisory authorities.
• • Vulnerability management. Regular dependency updates, container image scanning, and penetration testing. Document your patching cadence and mean time to remediate.

Step 1: Data Mapping

Before you can protect personal data, you need to know where it is. A comprehensive data mapping exercise identifies every system, database, and third-party service that processes personal data. For SaaS companies, this must cover both your own data (controller side) and customer data flows (processor side).

Map each data flow: what data enters, where it is stored, who can access it, where it is transferred, and when it is deleted. This becomes the foundation for every other compliance activity.

Step 2: Records of Processing Activities (ROPA)

Article 30 requires both controllers and processors to maintain records of processing activities. As a SaaS company operating in both roles, you need two sets of records.

Controller ROPA: document every processing activity where you determine the purpose (marketing, analytics, billing, HR). Include the lawful basis, data categories, retention periods, and transfer mechanisms. Processor ROPA: document the categories of processing you carry out on behalf of each customer, the sub-processors involved, and the international transfers.

Step 3: Data Protection Impact Assessments (DPIA)

Article 35 requires a DPIA when processing is "likely to result in a high risk" to individuals. For SaaS companies, this typically applies when you launch features involving profiling, automated decision-making, large-scale processing of sensitive data, or systematic monitoring of public areas.

Practical triggers for SaaS: adding AI/ML features that process personal data, building analytics dashboards that profile user behavior, introducing biometric authentication, or expanding into health or financial data processing. Build DPIA into your product development process so it happens before launch, not after.

Step 4: Breach Notification Procedures

Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 requires notification to affected individuals when the breach is likely to result in a high risk to their rights.

As a SaaS processor, you also have obligations under Article 28 to notify your customers (the controllers) without undue delay. Your DPA will typically specify a timeframe. Build this into your incident response: who makes the call, what information is included, which supervisory authority to contact, and how you communicate with affected customers.

Step 5: DPO Considerations

Article 37 requires a Data Protection Officer when your core activities involve regular and systematic monitoring of data subjects at scale, or large-scale processing of special category data. Many SaaS companies fall into the first category.

If you are not legally required to appoint a DPO, consider whether a designated privacy lead achieves the same goal. Enterprise customers will ask who is responsible for data protection. Having a named person with clear authority makes compliance tangible and gives customers a point of contact for data protection questions.

Security Questionnaires

Most enterprise buyers use standardized questionnaires: CAIQ (Consensus Assessment Initiative Questionnaire), SIG (Standard Information Gathering), or their own internal templates. These questionnaires contain 200-400 questions covering encryption, access controls, incident response, business continuity, vendor management, and regulatory compliance.

Prepare a master response document and keep it current. Pre-filling a CAIQ or SIG Lite and publishing it on your trust page saves weeks per deal. Include references to your policies, certifications, and technical documentation.

SOC 2 vs ISO 27001

SOC 2 is the standard for US-focused enterprise sales. It evaluates controls against five Trust Service Criteria (security, availability, processing integrity, confidentiality, privacy). A SOC 2 Type II report covers a 6-12 month observation period and is what most US enterprise buyers expect.

ISO 27001 is the international standard for information security management systems. It is more recognized in Europe and provides a broader framework. Certification involves an external audit and annual surveillance audits.

For SaaS companies selling to European enterprise customers, ISO 27001 carries more weight. For US customers, SOC 2 is expected. If you can only invest in one, choose based on your primary market. Either certification dramatically reduces the friction in security reviews.

Compliance Documentation Checklist

Build a trust center (a public or gated page on your website) with these documents ready:

• • Data Processing Agreement (DPA) with pre-filled annexes
• • Sub-processor list with update history
• • Technical and organizational measures (TOM) document
• • Privacy policy and cookie policy
• • Penetration test summary (not the full report)
• • SOC 2 report or ISO 27001 certificate
• • Business continuity and disaster recovery overview
• • Incident response policy summary
• • Data retention and deletion policy
• • Completed CAIQ or SIG Lite questionnaire