How do the privacy criteria apply when we are a processor, not a controller?
The criteria bend around the customer relationship rather than breaking. Notice and consent: for customer-entrusted data, the controller (your customer) owns notice and consent toward its users; your tested commitments become the DPA's, process only per instructions, support the customer's notice-and-consent obligations, and the examiner tests instruction-boundedness (configuration honoring customer settings, no processing beyond contracted purposes) rather than your consent capture from end users you never meet. Collection: maps to ingestion discipline, you collect what the service requires and the contract defines, tested against product behavior and API scopes. Use, retention, disposal: your DPA's retention and deletion terms are the criteria, termination deletion within N days, backup propagation windows, tested against actual offboarding events from the period. Access: becomes DSAR support, the tooling and SLAs by which customers fulfill their subjects' requests through you (export APIs, deletion endpoints, response-time commitments). Disclosure: subprocessor governance, authorized lists, flow-down terms, change notification, plus legal-request handling. Quality and monitoring: largely as written. The essential reframe for scoping conversations with your examiner: enumerate the commitments per data population (customer-entrusted versus your own corporate data), because the criteria apply differently to each, and reports that blur the populations produce testing chaos and buyer confusion.
How should we draw the system description boundary?
Deliberately, before the examiner drafts it for you. Product scope: which products and service lines are in the system, buyers read the description to see whether the thing they buy is covered, so the flagship product belongs in; the acquired product still running on its own stack is a judgment call (include it and inherit its evidence debt, or exclude it and field the diligence question). Data-store scope: production stores obviously; the decisions that bite are analytics pipelines (product telemetry with personal data in it is in the lifecycle whether or not you enjoy that), data warehouses and BI copies, logs with PII, ML training corpora derived from customer data, and staging or support environments that touch production data, examiners follow personal information wherever the description admits it flows, and undisclosed flows discovered in walkthroughs are worse than included ones. Corporate processing: your own controller-side activities (marketing site, CRM, HR) can be excluded from a system scoped to the service, but then keep the report's privacy story consistent, do not cite the report to answer questions about flows it excludes. Boundary honesty tests: could you hand the description to a new engineer and have them confirm every data flow exists as drawn; does every notice and DPA commitment map to a component inside the boundary; and does anything personal leave the boundary without a description sentence? The description is management's assertion, your document, and imprecision in it converts directly into exceptions during testing.
Which controls make or break SaaS privacy examinations?
Four, empirically. Deletion pipelines: multi-tenant architecture makes deletion the hardest promise, tenant offboarding must remove customer data from primary stores, replicas, search indexes, caches, analytics copies, and (within the committed window) backups, with per-event evidence; the classic exception is a deletion job that covers the primary database while the warehouse retains everything, discovered when the examiner samples an offboarded tenant. DSAR-support machinery: export and deletion capabilities per data subject (not just per tenant), authenticated, complete across stores, inside committed SLAs, tested by tracing sampled requests; 'the customer can query their own database' does not satisfy a commitment to assist. Subprocessor governance: the authorized list current and published, flow-down contracts with equivalent commitments, change notifications actually sent (the examiner will ask for the notification evidence for the subprocessor you added in March), and offboarding of removed subprocessors evidenced. Use-limitation boundaries: the modern stumbling block, product analytics, model training, and 'service improvement' uses of customer-entrusted data tested against DPA language; if the contract says instructions-only and the ML team fine-tunes on customer content, that is not an engineering decision, it is a test failure with contract-liability shadows. A fifth for growth-stage companies: instruction-boundedness under product velocity, every feature that touches personal data in a new way (new integration, new AI feature) needs a lifecycle checkpoint, or the description and the product diverge mid-period.
How do we design evidence so a 12-month observation period is survivable?
Instrument, monitor, and rehearse, the period punishes anything manual. Instrument: every privacy control emits its own evidence as a side effect of operating, deletion jobs write per-tenant completion reports; DSAR tooling logs request, verification, fulfillment, and elapsed time; subprocessor changes flow through a workflow that archives the notification; consent and instruction states are versioned; retention schedules execute as code with run logs. If evidence requires a human remembering to screenshot something monthly, it will have gaps, and gaps in a Type II are exceptions. Monitor: run your own mini-examination continuously, a monthly privacy-controls review that samples exactly as the examiner will (pull two offboardings, trace them; pull three DSARs, time them), because deviations you catch, remediate, and document during the period read as a functioning monitoring criterion, while deviations the examiner finds read as the absence of one. Rehearse the hard cases before the period opens: a full tenant offboarding through every store, a subject-level deletion through the analytics stack, a subprocessor change through the notification path. Calendar reality: the period is a commitment device, freeze notice and DPA language before it opens where possible (mid-period commitment changes complicate criteria), schedule engineering work that touches data flows with the description in mind, and when architecture must change mid-period (it will), update the description and tell your examiner early, surprises at fieldwork are the expensive kind.
We are also a controller for our own marketing and product data. How does that interact?
The dual role is universal in SaaS and regularly mishandled. Your controller-side processing, marketing site visitors, trial signups, product telemetry keyed to individual users, sales CRM, support interactions, runs under your public privacy notice, and if it sits inside the system description (or your report is marketed as covering 'the company's privacy practices'), the examiner tests those flows against that notice with full controller-grade criteria: consent capture for tracking where promised, collection consistent with the notice, retention per stated periods, subject access requests from end users handled directly. The classic mismatches surface immediately: a notice promising opt-out honored while the marketing stack drops trackers pre-consent; telemetry retention 'as long as necessary' operationalized as never-deleted; trial-user data flowing into sales tools the notice does not mention. Handling options: scope the report tightly to the service and let controller-side privacy live under a separate program (defensible, but keep sales from waving the report at questions it does not answer); or include corporate processing and do the reconciliation work, more preparation, but one coherent story. Either way, the reconciliation itself is unavoidable, your public notice is being tested by someone (examiner, regulator, or plaintiff), and the SaaS pattern of pristine processor controls beside an unexamined marketing stack is exactly where FTC and state-AG attention lands. Run the controller-side commitment inventory with the same rigor as the DPA one, and test your own site's behavior against the notice before anyone else does.