GDPR Considerations in SaaS Selection

GDPR imposes specific obligations on data processors (vendors processing personal data on your behalf):

**Data processing agreement (DPA)**: A contract meeting Article 28 requirements is mandatory. This must include subject matter, duration, nature of processing, personal data types, and categories of data subjects.

**Processing only on instructions**: Processors must only process data according to controller instructions, unless required by law.

**Personnel obligations**: Processor staff must be bound by confidentiality and must be appropriately trained.

**Security measures**: Processors must implement appropriate technical and organisational measures.

**Sub-processor management**: Processors must obtain authorisation before engaging sub-processors and must impose equivalent obligations on them.

**Assistance obligations**: Processors must assist controllers with data subject requests, security breach responses, and impact assessments.

**Audit rights**: Controllers must have the ability to audit processor compliance (or access to third-party audit reports).

**Data return or deletion**: Upon termination, processors must return or delete personal data as directed.

Vendors that cannot clearly demonstrate these capabilities warrant additional scrutiny.

The DPA is legally required for any SaaS processing personal data. Evaluation should cover:

**Article 28 completeness**: Does the DPA address all mandatory elements? Incomplete agreements suggest immature compliance.

**Processing scope clarity**: Is it clear what data is processed, for what purposes, and under what limitations?

**Sub-processor provisions**: How are sub-processors managed? Is the controller notified of changes? Is there a right to object?

**Audit provisions**: Can you audit or access audit reports? Some vendors provide SOC 2 reports as the audit mechanism.

**International transfer mechanisms**: If data may be processed outside the EEA, what transfer mechanisms are in place?

**Liability allocation**: How is liability for breaches allocated between controller and processor?

**Termination provisions**: What happens to data upon contract termination? Is there a defined data return/deletion process?

Beware of imbalanced terms that limit processor liability excessively or impose unreasonable conditions on exercising controller rights. Standard DPA templates from vendors should still be reviewed, not just accepted.

Most SaaS vendors use sub-processors (other companies that process data on their behalf). This creates a compliance chain:

**Sub-processor transparency**: Does the vendor publish a complete list of sub-processors? This is an Article 28 requirement.

**Update notification**: How are controllers notified of sub-processor changes? Email notification with objection rights is standard practice.

**Sub-processor locations**: Where are sub-processors located? This affects transfer mechanism requirements.

**Sub-processor obligations**: The vendor must impose GDPR-equivalent obligations on sub-processors. How is this verified?

**Infrastructure providers**: Cloud infrastructure providers (AWS, Azure, GCP) are typically sub-processors. Their jurisdiction affects the entire chain.

Long sub-processor chains increase complexity and may introduce unexpected jurisdiction exposure. Vendors with simpler chains present lower compliance risk.

Review sub-processor lists before signing contracts, not after. Changes to sub-processors may affect your risk assessment.

Beyond legal agreements, technical controls affect actual compliance:

**Encryption**: Is data encrypted at rest and in transit? What algorithms are used? Who controls encryption keys?

**Access controls**: How is access to customer data controlled within the vendor organisation? What authentication is required?

**Audit logging**: What activities are logged? Are logs available to customers? How long are they retained?

**Data segregation**: How is customer data segregated? Multi-tenant architectures require logical separation controls.

**Backup and recovery**: How is data backed up? Where are backups stored? How is backup data secured?

**Breach detection**: What monitoring exists for security incidents? How are anomalies detected?

**Data minimisation**: Does the system collect only necessary data? Can unnecessary data collection be disabled?

**Retention controls**: Can data retention periods be configured? Is automatic deletion available?

Request security documentation and certifications (SOC 2, ISO 27001). These don't guarantee compliance but indicate security investment.

GDPR grants data subjects various rights. Your organisation remains responsible for fulfilling these rights, but vendors must assist:

**Access requests**: Can you export an individual's data when they request access?

**Rectification**: Can you correct data within the system when requested?

**Erasure**: Can you delete an individual's data completely? Are there technical limitations?

**Portability**: Can data be exported in machine-readable formats?

**Processing restrictions**: Can you restrict processing of specific records without deleting them?

Vendors that make data subject right compliance difficult create operational burden and compliance risk. Evaluate the actual tools available for responding to requests.

Test export and deletion capabilities during evaluation, not after contracting. Some vendors make these rights theoretically possible but practically difficult.

Certain patterns suggest inadequate GDPR compliance:

**No DPA available**: Any vendor processing personal data must offer a DPA. Absence is a basic compliance failure.

**Unclear data locations**: Vendors unable to specify where data is processed may lack proper controls.

**No sub-processor list**: This is a legal requirement. Vendors without one are non-compliant.

**No security certifications**: While not strictly required, lack of SOC 2 or ISO 27001 suggests limited security investment.

**No breach notification commitment**: Vendors should commit to notifying customers of breaches within specified timeframes.

**Excessive data collection**: Tools that collect far more data than needed for their function present unnecessary exposure.

**No data retention controls**: Systems that retain data indefinitely without customer control create ongoing liability.

**Terms changes without notice**: Vendors that can change data handling practices unilaterally reduce predictability.

These red flags don't necessarily preclude use, but indicate areas requiring specific attention and risk acceptance.