A good privacy consultant leaves you with a program your own people can run. A bad one leaves a binder of templates nobody opens. The difference shows up mostly in how you scope the engagement, so start there, not with the shortlist.
Consultant, lawyer or fractional DPO?
These three roles overlap, and plenty of firms offer all of them. They still answer different questions, and mixing them up is the most common way to pay for the wrong thing.
| Privacy consultant | Privacy lawyer | Fractional / external DPO | |
|---|---|---|---|
| Main question | "How do we actually do this?" | "What does the law require of us, and what's our exposure?" | "Who independently oversees our compliance on an ongoing basis?" |
| Typical work | Data mapping, ROPAs, DSR process design, tool selection, assessments, training, program roadmaps | Legal interpretation, DPAs and contract negotiation, regulator correspondence, breach and enforcement response, litigation | The statutory DPO tasks under GDPR Article 39: advising, monitoring compliance, advising on DPIAs, acting as the contact point for the regulator |
| Privilege | Usually not privileged on its own | Legal advice can be privileged | Not a privileged role; the DPO reports to top management and works with the regulator |
| Duration | Project, sometimes followed by a retainer | As needed | Ongoing, by design |
Some rules of thumb:
- You need a lawyer when there's a regulator inquiry, a breach, a lawsuit, a contested reading of the law, or a contract to negotiate. If a consultant's assessment might end up in front of a regulator or a court, ask counsel whether to engage the consultant through them.
- You need a DPO if GDPR Article 37(1) requires one: you're a public authority, or your core activities involve regular and systematic monitoring of people on a large scale, or large-scale processing of special-category or criminal-offence data. Article 37(6) explicitly allows the DPO to be an external person under a service contract. That's the legal basis for "DPO as a service".
- You need a consultant when you know roughly what's required but lack the hands, the method, or the experience to build it: a first data map, a DSR process, a readiness program for a new law, a tool evaluation.
What you're actually hiring for
Write down the outcome before you talk to anyone. Typical engagements, roughly from most to least common:
- Gap assessment. Where you stand against GDPR, the CCPA and other US state laws, or a framework such as the NIST Privacy Framework or ISO/IEC 27701. The output is a prioritized list, not a pass/fail.
- Data mapping and ROPA. Interviews and system reviews that produce an inventory you can maintain. See Data mapping and discovery and the data map cost calculator to estimate the internal effort a consultant would replace.
- DSR operations. Designing intake, verification, fulfillment and response, often alongside a tool rollout. Background: Data subject request automation.
- Assessments. DPIAs under GDPR, and in California, the risk assessments required under the CCPA regulations that took effect on January 1, 2026 (first submissions to the agency are due April 1, 2028).
- Vendor and contract operations. Building a vendor review process, DPA templates and a sub-processor register. The contract language itself is lawyer work. See Data processing agreements.
- Tool selection. Requirements, demos and a proof of concept. If you hire for this, ask whether the consultant gets referral fees or resells any vendor (see red flags below). The buyer's checklist is a good basis for the work.
- Program build. Governance, policies, roles, metrics and a roadmap. See Planning a privacy program: the first 90 days.
Credentials that mean something
Certifications show that someone passed an exam on a body of knowledge. They don't show judgment, but they're a fair filter, and the right ones tell you what kind of expertise you're getting.
| Credential | Issuer | What it covers |
|---|---|---|
| CIPP (by region, e.g. /E Europe, /US, /C Canada, /A Asia) | IAPP | Privacy law and regulation in that jurisdiction. CIPP/E for GDPR work, CIPP/US for US federal and state law. |
| CIPM (Certified Information Privacy Manager) | IAPP | Running a privacy program: governance, operations, metrics. |
| CIPT (Certified Information Privacy Technologist) | IAPP | Privacy in technology and engineering: privacy by design, data handling in systems. |
| AIGP (AI Governance Professional) | IAPP | Governance of AI systems. Relevant if the work touches automated decision-making or AI training data. |
| FIP (Fellow of Information Privacy) | IAPP | A senior designation. Holders need a CIPP plus a CIPM, CIPT or AIGP, three years of work where privacy is at least half the job, and peer references (IAPP requirements). |
| CDPSE (Certified Data Privacy Solutions Engineer) | ISACA | Technical privacy implementation and data lifecycle. |
| CISSP, CISA | ISC2, ISACA | Security and audit, not privacy. Useful when the work includes security controls or audit readiness. |
Match the credential to the job. A data mapping project wants someone with a CIPT or CIPM and hands-on systems experience. A GDPR gap assessment wants a CIPP/E. A CISSP alone is a security credential and doesn't tell you the person knows privacy law. Ask for the exact credential and holder details and confirm them with the issuer. Certifications lapse if the holder stops meeting continuing-education requirements.
Look past the letters too. Ask for work samples (redacted ROPAs, a DPIA, a DSR runbook) and for references from organizations of similar size and industry.
Engagement models and how fees are structured
Rates vary widely by region, seniority and firm size, and there's no reliable public benchmark worth quoting. Focus on how the structure matches the work.
| Model | Fits | Watch for |
|---|---|---|
| Fixed-fee project | Well-defined deliverables: a gap assessment, a first ROPA, a set of DPIAs. | Scope that's tight on paper but loose in practice. Agree how change requests are priced before you start. |
| Time and materials (hourly or daily) | Open-ended or exploratory work, advisory hours, work where scope truly can't be known upfront. | Cost drift. Ask for a not-to-exceed cap and weekly burn reports. |
| Monthly retainer | Ongoing advice, fractional privacy lead or external DPO, regular DSR or vendor review support. | Unused hours that expire. Define response times and what's in and out of scope. |
| Phased (assessment then build) | Most program builds. Pay for a fixed assessment, then decide on the build with real information. | The assessment written mainly to sell phase two. Make sure it's usable by someone else. |
Get every proposal priced on the same scope so you can compare them. Ask what's excluded: travel, tooling licenses, translation and work outside the named jurisdictions are common extras.
Scoping the engagement
A tight scope protects both sides. Put these in the statement of work:
- Jurisdictions and laws in scope. "GDPR, UK GDPR, CCPA" is a scope. "Global privacy compliance" isn't.
- Business units, products and systems in scope, with a count where possible (for example, "the 35 systems in the attached list").
- Deliverables, named and formatted. "ROPA in our spreadsheet template," "DSR runbook in our wiki," "risk register with owners." Specify that deliverables are yours to edit and reuse.
- Your obligations. Who on your side gives access, sets up interviews and reviews drafts, and how fast. Most delays are on the client side.
- Data access and handling. If the consultant will see personal data, they're your processor for that work and you need a DPA. Prefer access to metadata and samples over production exports.
- Knowledge transfer. Handover sessions and documentation so your team can maintain the work.
- Acceptance criteria and change control. How a deliverable is accepted, and how scope changes are priced.
Questions to ask before you hire
- Who exactly will do the work, and what are their credentials? Will the senior person in the pitch be on the project?
- Show us a redacted deliverable from a similar engagement.
- How do you handle a finding that contradicts what leadership wants to hear?
- Which laws and frameworks have you implemented, not just assessed against?
- What do you need from us each week to stay on schedule?
- Do you receive referral fees, resell, or hold partnerships with any privacy software vendor?
- When do you tell us to call a lawyer instead of you?
- What will our team be able to do on its own when you leave?
Red flags
- Guaranteed compliance. No one can guarantee you'll pass a regulator's scrutiny. A consultant who promises it either doesn't understand the work or is selling.
- Template-first delivery. If the policies arrive before anyone has looked at your systems, they describe someone else's company.
- Undisclosed vendor ties. A tool recommendation from someone who earns a referral fee on it isn't independent advice. Ask, and get the answer in writing.
- Legal opinions from non-lawyers. Consultants can explain requirements. A definitive "you don't need to comply with X" on a contested point should come from counsel.
- No knowledge transfer. Deliverables in a proprietary portal you lose access to when the engagement ends.
- Vague staffing. "Our team" with no names. You're hiring people, not a logo.
- Overreach on DPO independence. Offering to be your DPO while also running your processing decisions, with no separation (see Article 38(6) above).
This article is general information, not legal advice. For the regulators and laws a consultant should know for your footprint, the privacy regulators directory is a starting point. In California, that's the California Privacy Protection Agency, which now goes by CalPrivacy, plus the Attorney General. See California's CPRA and the 2026 regulations.