How to scale a privacy practice past 20 clients

Where the time actually goes at 20 clients

At five clients, the practice runs on memory. You know which one is on Azure, which one moved its support desk to a vendor nobody has papered, which one has a DSAR that will land badly. Memory is a perfectly good index at five. It fails somewhere in the teens, and the failure is quiet: nothing goes wrong on any single engagement, you simply stop being able to answer questions that span the portfolio.

It helps to decompose the engagement into the work that actually recurs:

Component	What drives its volume
Fact gathering	one intake per client, then maintenance
Qualification — regimes, roles, scope	one decision per client, revisited on change
Document production	derived from the facts, repeated on every change
Questionnaire answering	your client's customers, not your client
Response to external change	number of clients × number of vendors each uses
Reporting your work back to the client	renewal cycle

Three of those grow linearly with headcount. One does not. Tracking whether a vendor changed its DPA, swapped its contracting entity or added a subprocessor is work whose size is the product of your client count and their vendor counts, and it arrives on the vendor's schedule rather than yours. This is the component that gets dropped first, because dropping it produces no immediate symptom. The symptom arrives later, when a client's enterprise customer reads a subprocessor list that names an entity which no longer exists, and asks your client who prepared it.

The second sink is re-derivation. Every time you answer "who processes personal data for this client, in which country, under which transfer mechanism", you either read it off a record or work it out again from source. If the answer lives only as a sentence inside a Word file you pay for it again each time, and you cannot answer the portfolio version of the question at all. "Which of my clients use this vendor" is a query against a table and a forty-document afternoon against a folder.

So the first operating rule, and the one that everything else depends on: anything you have looked up twice is a record with a date on it, not a paragraph inside a deliverable. Prose is an output format. It is a terrible storage format.

Standardise the interview, not the advice

The distinction that makes standardisation safe is between intake — which is the same every time — and qualification, which is never the same and is the thing you are paid for.

Standardise intake as a list of named slots. Each slot carries: a key, a type (boolean, enumeration, number, list of vendors, free text), which regimes make it mandatory, which documents it feeds, and a review date. Not a questionnaire document — a list of fields with identity. The identity is what lets you say "this fact changed, therefore these four documents are stale", which is impossible if the answer only exists as a reply in an email thread.

What it looks like when you don't have this: each consultant asks their own subset in their own order, two engagements at the same firm produce non-comparable files, nobody can say whether a client is finished or 80% finished, and when a client's circumstances change nobody knows which deliverables are implicated.

Give each slot a lifecycle rather than a value: empty, captured, confirmed, stale. Confirmed is the state that matters, because you are the one signing the document that rests on it — a fact extracted from a client's own policy is a starting point, not an assertion you have made. Stale matters because facts have shelf lives. Hosting regions move, subprocessors are added, retention periods get rewritten after someone reads the storage bill.

Delegate the half of the intake the client is better placed to answer, but delegate it as a structured form with a link, not as an emailed spreadsheet. The spreadsheet comes back partially filled, with prose in the boolean columns, and with no record of who asserted what on which date. It also shows the client every question, including the ones about their own security posture that you would rather discuss than publish into a shared drive. Keep a flag on slots that the client should never see, and use a simplified wording for the questions they do.

Treat negative answers as answers. "No independent penetration testing" is a closed slot, not a gap. If your process treats every "no" as an unresolved item, engagements park at 90% forever and the documents that depend on them never get produced. The correct output of a negative fact is an honest sentence and, where the client wants one, a plan — not silence and not a euphemism.

What stays with you: which regimes apply, controller or processor, risk categorisation, whether an entity falls in scope. Those judgements are the practice. Record each one with the trigger that prompted it, the date, and the person who made it, because in two years somebody will ask why, and the answer will not be in anyone's head.

Two shortcuts are worth the habit. New engagements rarely start from zero: a client with an existing policy and a subprocessor list can have much of its intake populated from those documents, leaving you confirming rather than interviewing. And you serve similar companies — copying infrastructure, process and retention answers from a comparable client, marked unconfirmed until checked, is legitimate and fast. Copying them silently into a finished document is how the wrong company name ends up in clause nine.

Firm wording as an asset

Your differentiator is not the section order of a privacy policy. It is a few hundred clauses you have argued over with counsel and with clients: the retention rationale you are willing to defend, the DSAR procedure that matches how your team actually escalates, the incident notification wording you will stand behind at three in the morning.

In most practices that wording exists, and it lives in whichever document was last used as a base. That is the failure mode: a new engagement starts by copying the file of a client who seemed similar, which drags that client's facts along with the wording, and the copy is now a second, divergent original. After twenty clients you have twenty dialects of your own house style and no way to push an improvement into any of them.

The fix is a clause library keyed by document type and section, not by client. Three properties make it work:

• Clauses contain no facts. Legal name, jurisdiction, generated tables and dates go in as placeholders substituted at assembly time. A clause with a vendor name baked into it is not reusable; it is a copy waiting to be wrong.
• There is a promotion path from live work. The moment you improve a sentence while editing a real deliverable is the only moment you will ever bother to capture it. If promoting that edit into the library takes a separate task and a different tool, it will not happen, and the improvement stays in one client's file.
• Every clause has an owner, a date and a reason for its last change. Otherwise nobody dares delete anything, and the library accretes into a second problem.

Tables are not wording and must never be authored as prose. Subprocessor lists, records of processing, retention schedules and system inventories are assembled from records — the vendor register, the client's confirmed facts — every time the document is produced. The moment somebody types one by hand it is stale, and there is no mechanism by which anyone will notice.

Finally, keep revision history per document with the origin of each change: initial production, manual edit, clause-library update, rollback. When a client asks whether the policy always said that, "I believe so" is not an answer you want to give, and a list of revisions with authors is cheap to keep and impossible to reconstruct afterwards.

Portfolio view: what needs attention this week

One screen. One row per client. Sorted by what needs you, not alphabetically.

The columns that earn their place are: regimes in scope, intake completeness, documents current versus stale, open gaps, owner, last touched — and next action. Next action is the one that changes how the week runs, and it has to be a computed sentence rather than a status chip:

• Intake not started.
• Twelve required answers outstanding.
• Three documents stale after a vendor change.
• Questionnaire received, not yet processed.
• Nothing outstanding; next review in four months.

A red dot tells you something is wrong. A sentence tells you what the work is, roughly how long it takes, and therefore who can be handed it. That difference is what lets a second person work the portfolio without a handover meeting.

Staleness needs a cause attached, and there are only two. A fact passed its review date, or something outside changed: a vendor updated its processing terms, changed contracting entity, moved a transfer mechanism, added a subprocessor in a jurisdiction without an adequacy finding, or quietly took a page down. The second kind is the work nobody does by hand, and the honest reason is arithmetic rather than diligence — checking every vendor page for every client every month is not a task a person completes.

Two rules about handling those changes:

Fan out explicitly. A detected change resolves to a list of affected clients and a list of affected documents. Not a notification that a vendor "has updates" — that is a research task dressed up as an alert.

Keep a human between detection and consequence. A page re-rendered with a new timestamp looks exactly like a substantive change to a differ. Publish that automatically and you regenerate documents across the portfolio on a false premise, or worse, tell clients something about their vendor that is not true. Review, then fan out.

Batch the reporting. A weekly digest naming the changes, the affected clients and the affected documents gets read; an email per event gets a filter rule within a month. Reserve immediate notice for the small set of changes that alter the answer rather than the wording.

And keep a per-client activity log — what was produced, edited, answered and exported, with dates. Not for its own sake: retainer renewals are lost by practices that did good work invisibly, and a log covering the period is the cheapest renewal document you will ever write.

Pricing retainers that include questionnaires

Questionnaires are the only major component of the engagement whose volume neither you nor your client controls. They are generated by your client's customers, on their procurement calendar. A client selling into regulated enterprises will send you one with every significant deal; a client selling to small businesses may send none for a year. Company size does not predict this. Who they sell to does.

So "vendor security questionnaires included" in a flat retainer is the sale of an unbounded quantity at a fixed price, and the variance between two superficially similar clients is not small. There are three honest structures:

1. Meter it. An included allowance per period, a named rate beyond it. This requires that you count, which means counting from the first month — retroactive counting is not possible, and without a baseline you cannot set the allowance.
2. Tier on buyer profile. Put clients who sell into enterprise or the public sector on a different band. This prices the actual driver instead of a proxy.
3. Exclude and quote per questionnaire. Defensible, and it loses you the reason the retainer was sticky.

Whichever you choose, make the billable unit a question, not a questionnaire. An eighty-row spreadsheet and a three-hundred-row one are different jobs that happen to arrive as the same kind of attachment.

The structural fix, independent of pricing, is that your marginal cost per questionnaire must fall over time. It falls when answers accumulate as a firm-level library keyed by question pattern, with the answer text and the source it came from, so that the second questionnaire for a client is mostly review rather than drafting. That library belongs to the firm, not to the consultant who happened to answer first — the version of it that lives in individual mailboxes is worth nothing at renewal.

One discipline makes the library safe to reuse: never collapse the three answer states. An answer is either supported by a confirmed fact with a citation into the client's own documentation; drafted from general wording and awaiting your review; or not true of this client. The third state is the one under pressure, and it must produce a plain sentence about what is not in place and what is planned — never a blank cell, never an accommodating "yes". An unearned "yes" is a representation that a procurement team will rely on, and it is your client's exposure and your name on the covering email.

What to keep bespoke

Standardising everything is as bad as standardising nothing; it just fails later and in front of a regulator instead of in front of your own staff. Draw the line explicitly.

Standardise: the slot list and its wording, document structure and section order, the clause library, all generated tables, the questionnaire answer library, review cadences, the next-action rules, branding and export.

Keep bespoke:

• Scope and qualification. Which regimes apply, controller or processor, risk categorisation, whether the entity is in scope. Proposed by a rule, explained, and then decided and recorded by a person.
• The facts themselves. A jurisdiction-typical default is a suggestion. An unaccepted default is not a fact, and it must not silently become one.
• Prioritisation. What this client should fix first, given its resources and what it is actually exposed to. No rule produces this.
• Anything a regulator or a customer could read as a commitment. Notification undertakings, retention rationales where the client deviates for a real business reason, transfer justifications.

A workable test for any piece of the work: if two competent consultants in your firm, given the same confirmed facts, would produce materially the same output, it should be produced once and reused everywhere. If they would disagree, and the disagreement matters, it is yours and it should cost what your judgement costs.

Clausebench is built along that line: a structured client interview that stores facts as slots with states and review dates, documents assembled from your firm's own wording with the tables generated from records, questionnaire answers drawn from your library, and a portfolio view that tells you which clients a vendor change has just made stale.

The limit on a privacy practice is rarely expertise. It is bookkeeping — knowing which facts are current, which wording is the good version, and which clients a change outside your walls has just affected. Those are all solvable, and they are solvable before you hire.