SaaS & Tech

The Processor Problem in SaaS

When your SaaS product processes personal data on behalf of customers, you are a data processor under GDPR. This is not the default assumption of most SaaS teams, who think of GDPR primarily as "our privacy policy and cookie banner." The processor role creates a distinct set of obligations that most SaaS compliance programmes do not adequately address.

The most common failure mode: you have one DPA template that you send to all customers — but it does not accurately describe the data you actually process, the sub-processors you actually use, or the international transfer mechanisms actually in place. When a large enterprise prospect does a compliance review before signing, this falls apart immediately. Qala builds the infrastructure so that it does not.

Core areas we address

• Controller/processor distinction — for each customer relationship and each data category, establish whether you are acting as processor or controller (sometimes you are both for different parts of the same product)
• DPA template design — customer-facing Data Processing Agreement that accurately reflects your processing activities, sub-processors, and transfer mechanisms; designed to satisfy enterprise procurement reviews
• SCC review and maintenance — 2021 modular SCCs for applicable transfer scenarios; Transfer Impact Assessment (TIA) documentation for US-based infrastructure
• Sub-processor inventory — live register of all sub-processors with service scope, data categories processed, and geographic location; change notification workflow for enterprise customers
• Consent API integration design — for B2C features where you hold the controller role, consent capture and record-keeping architecture that satisfies Art. 7 requirements
• Security obligations under Art. 32 — documented technical and organisational measures (TOMs) for inclusion in DPAs and security questionnaire responses