Technology companies and SaaS providers operate in a particularly demanding GDPR environment. They typically process large volumes of personal data on behalf of customer organisations (as processors), face data subject rights obligations when they also act as controllers for their own user data, and encounter rigorous enterprise due diligence from European customers who require detailed compliance evidence before signing contracts. For SaaS companies targeting EU markets, GDPR compliance is not only a legal obligation — it is a commercial prerequisite.
The dual role of technology companies — controller for their own users (employees, free-tier users, prospects) and processor for their customers’ data — creates a complexity that requires careful role characterisation and segregated compliance programmes for each role. The failure to distinguish between processing activities conducted as a controller and those conducted as a processor is one of the most common structural compliance errors in technology companies.
Controller vs. Processor: Clarifying the SaaS Dual Role
TECHNOLOGY COMPANY ROLE CHARACTERISATION
| Activity | Role | Obligations | Key Documentation |
|---|---|---|---|
| Processing customer data on behalf of a customer (CRM, HR, analytics, support tools) | Processor | Art. 28 DPA with customer; process only on instructions; security per Art. 32; assist with rights; breach notification to customer | Art. 28-compliant DPA; TOM schedule; sub-processor list; security certifications |
| Own employee data (HR, payroll, access logs) | Controller | Full GDPR obligations: lawful basis, transparency, rights, retention, security | Employee privacy notice; HR data LIA or contract basis; retention schedule; access controls |
| Own prospect and marketing data (lead generation, email marketing) | Controller | Full GDPR obligations: consent for marketing, legitimate interests for B2B, privacy notice, rights, suppression | Marketing consent records or LIA; privacy notice; unsubscribe mechanism; suppression list |
| Product usage analytics on customer’s behalf | Processor (if instructed by customer) or joint controller / independent controller (if used for own product development) | Depends on how data is used: if solely for customer’s purposes, processor; if used for product improvement or own analytics, separate lawful basis required as controller | DPA if processor; privacy notice and LIA/consent if controller for product analytics; transparency to customer |
| Identity provider / authentication for end users | Often joint controller with customer | Art. 26 joint controllership arrangement required; roles and responsibilities for user data clearly defined; transparency to users about joint controllership | Art. 26 arrangement; privacy notice disclosing joint controllership; user communication |
The SaaS Data Processing Agreement
For SaaS providers acting as processors, the Article 28 DPA is not merely a contract formality — it is the commercial instrument that enables enterprise sales into regulated markets. Large European enterprise clients will not sign without an executed DPA that meets Article 28(3) requirements. Many will have their own DPA templates or will require negotiation of the provider’s standard DPA. Building a robust, enterprise-grade standard DPA and a clear negotiation position on its key terms is a commercial investment that removes friction from the sales process.
SAAS DPA — KEY ENTERPRISE-GRADE PROVISIONS
| DPA Provision | Enterprise Requirement | SaaS Provider Consideration |
|---|---|---|
| Data processing instructions | Processing limited strictly to the documented instructions of the controller; provider notifies controller of any instruction it believes breaches GDPR | Standard DPA should clearly limit what data is processed and for what purpose; service description is the instruction; product analytics on customer data requires separate treatment |
| Sub-processor management | Named sub-processors listed; notification of sub-processor changes (14–30-day notice standard); objection mechanism; equivalent obligations flow down | Maintain and publish sub-processor list; build notification workflow; ensure sub-processors are also bound by equivalent DPA terms |
| Security measures | Specific TOM schedule incorporated by reference; ISO 27001 certificate or SOC 2 Type II report referenced; pen test summary available on request | Maintain detailed TOM schedule; keep security certifications current; pen test annually; provide security report to enterprise clients on request |
| Breach notification to controller | Notification within 24–48 hours of awareness (to allow controller to meet 72-hour DPA obligation); full breach details; cooperation with investigation | Build 24-hour internal SLA for customer breach notification; designate breach notification owner; prepare notification template |
| Data subject rights assistance | Assist controller to fulfil rights requests; provide data within defined SLA; support erasure and restriction; data in portable format for portability | Build rights request fulfilment tooling (export, delete, restrict per individual); SLA for response; format for data export |
| Cross-border transfers | Transfer mechanism for any processing outside EEA; SCCs or adequacy; TIA documentation available | Execute SCCs with customer where relevant; maintain TIAs for non-adequate countries where sub-processors are located; DPF certification for US-based operations |
| Audit rights | Customer right to conduct audit or commission third-party audit; audit questionnaire as alternative to on-site; reasonable frequency and notice | Develop audit questionnaire response capability; third-party audit (SOC 2) reduces demand for customer-specific audits; on-site audit rights are standard — do not attempt to remove |
| Return/deletion at end of contract | Customer data returned or deleted within defined period after contract end; certification of deletion provided | Build data export tool for contract end; define deletion timeline in DPA (30–90 days standard); provide deletion certificate; retain logs per own retention obligations |
Multi-Tenant Data Architecture and Privacy
Multi-tenant SaaS architectures — where multiple customers’ data is stored and processed on shared infrastructure — create specific GDPR challenges around data segregation, access control, and breach scope management. The key obligation is that a breach or misconfiguration affecting one customer’s data must not expose another customer’s data, and that access controls prevent any customer’s staff from accessing another customer’s personal data.
MULTI-TENANT PRIVACY CONTROLS
| Risk Area | Required Control | Implementation Approach |
|---|---|---|
| Customer data segregation | Personal data for each customer tenant must be logically segregated; no cross-tenant data access possible through any application function | Tenant ID enforced at all database query levels; row-level security or schema separation; automated testing of segregation controls |
| Access control by tenant | Provider’s support staff should access only the specific tenant’s data for the specific support ticket; no standing access to all customer data | Support access workflows with tenant-specific approval; privileged access management for support; session logging for all customer data access |
| Breach scope management | When a breach occurs, accurately determine which tenants’ data was affected; notify only affected customers | Audit logging by tenant; forensic capability to determine breach scope; per-tenant breach notification workflow |
| Sub-processor impact | When a sub-processor is involved in processing, the sub-processor’s security posture affects all tenants whose data it handles | Sub-processor security assessment; right to audit sub-processors; sub-processor breach notification SLA that allows onward notification to customers within 24 hours |
Enterprise Client Due Diligence: What to Prepare
Enterprise customers in regulated European sectors — financial services, healthcare, public sector, professional services — conduct rigorous data protection due diligence before signing contracts with SaaS providers. Having pre-prepared, current responses to the most common due diligence requests reduces sales cycle friction and demonstrates maturity. The following represents the standard information enterprise clients request.
ENTERPRISE DUE DILIGENCE READINESS PACK
| Due Diligence Request | Preparation Required |
|---|---|
| Completed DPA (customer’s template or provider’s standard DPA) | Maintain enterprise-grade standard DPA; prepare negotiation positions on key terms; track DPA versions by customer |
| Sub-processor list with country of operation | Maintain current, published sub-processor list; update with each change; include all infrastructure, analytics, and support sub-processors |
| Security certifications (ISO 27001 / SOC 2 Type II) | Maintain current certifications; provide scope documentation; prepare for scope questions |
| Penetration test summary or executive report | Annual pen test; prepare sanitised executive summary for enterprise clients; track remediation to demonstrate response |
| Data location and transfer mechanism | Document all data locations; identify non-EEA locations; confirm SCCs or adequacy for each; prepare TIA summary for US locations |
| Encryption standards (at rest and in transit) | Document encryption standards in TOM schedule; be specific (AES-256, TLS 1.3); provide key management summary |
| Breach notification SLA | State the notification commitment to customers in the DPA; confirm internal SLA that supports it; reference IR procedure |
| Data subject rights support capability | Describe the tooling and processes for fulfilling rights requests on the customer’s behalf; SLA for response; export format |
| BITLION INSIGHT | For SaaS companies in growth mode, GDPR compliance is increasingly the difference between closing and losing enterprise deals in the EU. The pattern is predictable: a large financial services or healthcare prospect sends a security and privacy questionnaire; the SaaS company’s responses are vague, certifications are pending, the DPA is inadequate, and the sub-processor list is incomplete. The deal stalls or is lost. Investing in a comprehensive compliance programme before enterprise sales become material — ISO 27001, enterprise-grade DPA, published sub-processor list, pen test, TOM schedule — is not a compliance cost. It is a sales infrastructure investment. |