SaaS companies usually wear two hats at once. For customer data inside the product they act as a processor on documented instructions; for their own marketing, billing, support and analytics they are a controller making their own decisions. Most privacy failures in this sector begin with the two roles being confused in a single system.
The second recurring pressure is commercial. Enterprise buyers assess privacy during procurement, so the quality of a sub-processor list, a security page and a DPA turns directly into sales cycle length.
Where personal data flows
- Customer tenant data
- Personal data uploaded by customers and processed under their instructions, often including special-category data the vendor never anticipated.
- Product telemetry
- Usage events, session recordings, error traces and feature analytics — frequently containing identifiers, free text and occasionally payload fragments.
- Support interactions
- Tickets, screenshots and shared logs, which routinely carry customer end-user data into a separate system with different retention.
- Growth and marketing
- Website analytics, advertising tags, enrichment providers and CRM records, all controller-side and subject to marketing rules.
- AI features
- Prompts, retrieved context and outputs, plus any vendor-side logging that customers were not told about.
Priority risks
- Role confusion
- Using customer tenant data for product improvement without a clear instruction or basis, which converts a processor activity into an unauthorised controller activity.
- Unbounded telemetry
- Event pipelines that collect first and define purpose later, producing datasets nobody can justify or delete on request.
- Sub-processor drift
- New vendors added by engineering faster than the published sub-processor list and customer notification process can track.
- Session replay and free text
- Recording tools capturing form fields, support notes and identifiers that were never in scope.
- AI feature sprawl
- Model providers introduced into the data path without contract review, retention limits or customer-facing disclosure.
Practical controls
- Separate controller and processor processing in your records, and enforce the boundary technically where possible.
- Define an event taxonomy with an owner and a retention period per event before instrumentation is merged.
- Publish a sub-processor list with change notification, and gate new vendors through a lightweight review that engineering can actually use.
- Mask sensitive fields in session replay, logs and error traces by default rather than by exception.
- Give customers a documented route for deletion and export that operates across the product, backups, logs and analytics.
- Review AI features for training use, retention, region and sub-processor status before launch, and disclose them.
- Maintain a trust page with the DPA, security overview, sub-processors and certifications to shorten due diligence.
Worth measuring
- Median time to complete a customer deletion request end to end, including analytics and logs.
- Percentage of production data stores with an assigned owner and retention period.
- Number of vendors in the data path that are not on the published sub-processor list.
Privacy Practice Lab publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.