What should the assessment baseline include, exactly?
Three layers, matched to your determined roles. Management-system requirements: context and scope definition, leadership and privacy policy, roles and authorities, risk assessment and treatment methodology extended to privacy, objectives, competence and awareness, documented information discipline, operational planning, performance evaluation (monitoring, internal audit, management review), and improvement. Controller controls (if you determine purposes and means for any processing): notice and transparency, lawful basis and consent management, purpose limitation enforcement, PII principal rights handling (access, correction, deletion, objection, portability), disclosure recording, joint-controller arrangements, retention and disposal, and transfer safeguards. Processor controls (if you process on customers' instructions): documented instructions and contract conformity, customer assistance duties, subprocessor authorization and flow-down, PII return and deletion at termination, disclosure-request handling, and breach notification to customers. Most SaaS companies hold both roles, controller for their own marketing, HR, and product analytics; processor for customer data, so both sets apply, partitioned by processing activity. Assessing only one set is the most common baseline error and produces a certification scope that collapses at stage 1.
How should we score findings so the output is usable?
Use a five-level maturity scale per requirement, because binary pass/fail hides where the work is. Absent: no policy, process, or practice. Ad hoc: happens sometimes, undocumented, person-dependent. Defined: documented policy and process exist. Operating: the process runs in practice with named owners. Evidenced: operation generates records an auditor can sample (logs, tickets, minutes, signed reviews). Certification requires the top level for everything applicable, and the expensive discovery in most assessments is how much sits at 'defined': the DSAR procedure exists but no request has ever exercised it; the retention schedule exists but no deletion job implements it; the subprocessor policy exists but half the contracts predate it. For each finding, capture: the requirement reference, current maturity, target evidence (what an auditor would sample), remediation actions, effort class (days/weeks/quarter), dependencies (tooling, legal, engineering), and an owner hypothesis. Resist severity theater, everything is 'high' if the goal is certification; sequence by dependency and effort instead, with the long-lead engineering items (data location, deletion automation) started first regardless of how the register sorts.
Which gaps consistently cost the most, and why?
Four repeat offenders. Cross-system data location for DSARs: answering 'everything you hold about me' requires knowing every store containing PII keyed to an individual, including logs, backups, analytics, and vendor systems; companies without a data map discover this is an engineering program, not a procedure, and it is the single most common source of certification-delaying work. Retention execution: schedules are easy; deletion that provably runs, across primary stores, replicas, and defensible backup windows, needs jobs, reports, and exception handling, and auditors sample execution evidence. Consent evidence: capturing that consent happened is common; evidencing its validity (what was presented, when, granularity, withdrawal path) usually requires re-instrumenting the consent surface. Subprocessor flow-downs: the register exists, but contracts predating the privacy program lack required terms, and remediation means renegotiating paper with vendors on their own timelines, start earliest, because the timeline is not yours. Honorable mentions: privacy risk assessments that never consider PII-principal harm, and joint-controller or controller-processor boundary ambiguity in complex product architectures. Budget-wise, these four typically consume 60-70% of remediation effort.
Should we run it internally or bring in outside assessors?
The trade is candor versus calibration. Internal teams know where bodies are buried and assess cheaply, but they miss requirements they have never seen audited, misjudge what evidence certifiers accept, and inherit the org chart's blind spots (the assessor who reports to the CISO tends to under-find in the CISO's domain). External assessors bring audit calibration, they know what a stage 2 sample looks like, and their findings carry weight in budget conversations, but cost real money and still depend on internal honesty for accuracy. The efficient pattern for most: internal execution using a rigorous checklist and the maturity scale, with external validation at two points, methodology review at the start (are we assessing the right baseline for our roles and scope?) and findings challenge at the end (is 'operating' really operating?). Companies with no ISO management-system experience should weight external help higher; the management-system clauses (internal audit, management review, documented information) are where first-timers systematically under-scope. Whoever runs it, insist on evidence-based assessment, 'show me the last three DSARs' rather than 'do you handle DSARs?', or the assessment inherits the optimism it exists to remove.
How does the gap assessment feed the certification plan?
Directly, if structured for it. Convert the findings register into the remediation backlog: group by owner and dependency, sequence long-lead engineering (data location, deletion automation) and external-party work (subprocessor re-papering) first, then policy and process build, then the evidence-generation period. Derive the timeline honestly: the roadmap's audit date is set by the last long-lead item plus the operating-evidence window (roughly three months), not by management preference. Derive scope decisions: if the assessment shows a legacy system needs a quarter of engineering to become certifiable, that is data for a scope-exclusion conversation, better made now than at stage 1. Derive the budget: effort classes across the register, plus certification-body quotes, plus sustainment (about a third of implementation effort annually). And keep the register alive: it becomes the internal-audit checklist during the build, the corrective-action source at first internal audit, and the baseline against which surveillance-year drift gets measured. A gap assessment that ends as a PDF presentation was a diagnostic; one that becomes the program's working backlog was a plan.