White-labelling compliance documentation for clients

What white label should and should not mean

Two claims travel under the same phrase, and only one of them is yours to make.

The first is: this is my firm's work product. Your name is on the cover, your reasoning shaped the document, and if a reviewer at your client's largest customer disputes a line in it, someone at your firm answers. That is what the client is buying, and your brand on the file is the plainest way of saying so.

The second is: nobody helped me produce this. Nobody is asking you to make that claim, and white-labelling does not require it. No one expects a firm to name its word processor on the signature page, or its research database. What a recipient cares about is not which tools were involved but who is answerable.

Answerability does not transfer to software. A drafting tool can produce a section that is well-formed and wrong — a supplier name carried forward after it changed, a retention period from a template that never fitted this client. The firm named on the document explains it. That is the correct allocation; it is why the engagement exists. Two things follow.

Every statement of fact should be one you can source — traceable to the client's own answers, a document they supplied, or published vendor documentation, rather than to a sentence that merely reads plausibly. A fabricated subprocessor in a pack sent to your client's enterprise customer costs them that relationship and costs you the client.

The legal qualifications stay with you. Whether a regime applies, whether the client acts as controller or processor for a given activity, whether an entity falls in scope of a sectoral regime — a tool can propose one and explain the trigger it matched, but the decision is professional judgement. A product that quietly makes it for you has handed you a liability, not a convenience.

Now the negative case, which is the reason this guide exists. A tooling vendor's name in the properties of a file you delivered is not admirable transparency about method. It is a third party appearing inside a bilateral engagement, in a document the client forwards to people who have no idea who that party is. It discloses nothing useful, raises a question your client cannot answer — usually mid-way through someone else's security review — and advertises a route around you.

One boundary, because the argument can be stretched too far. White-labelling concerns authorship, not concealment of a processing relationship. If the tooling you use processes personal data on your behalf, that belongs in your engagement terms, your records of processing and whatever subprocessor disclosure you owe the client — in full. Not in the footer of a policy your client's customer will read.

Document headers, footers and metadata

There are two layers to a branded file, and firms reliably get the first right and the second wrong.

The visible layer

• Header: your logo, or your firm's name in your brand colour if you have no usable logo file. One line, the same across every document type.
• Footer: your firm's name or a short custom line, the date, page numbers.
• Title block: the document title and the client's full legal entity name, not their trading name. This is the line a reviewer checks against a contract.
• Draft marking: mark an unfinished document. A diagonal DRAFT on every page and a footer reading Draft — <your firm> — <date> says exactly what the reader has. A draft marker should say "draft" and name you, and advertise nothing else.

The metadata layer

This is the part that catches people, and it is worth your attention once.

A .docx is a ZIP archive. Inside it, docProps/core.xml carries creator, lastModifiedBy, title and description; docProps/app.xml carries the producing application. Anyone can read these from File → Properties, and anyone technical can unzip the file and read the raw XML. Tracked changes and comments carry author names too, and they survive a careless "accept all".

A PDF carries an info dictionary with Title, Author, Subject, Keywords, Creator and Producer, often with an XMP stream repeating the same values. Producer is the field that gets people: it is written by whatever library rendered the file, it defaults to that library's own name, and almost nobody looks at it. A firm can brand the header, footer, colours and cover page perfectly and still ship a file whose properties name a rendering library and a vendor the client never engaged.

A ZIP bundle has its own envelope: entry names and an archive comment field some tools populate automatically.

The check takes a minute:

unzip -o deliverable.docx -d out && grep -ril "<vendor name>" out
strings deliverable.pdf | grep -i "<vendor name>"

The first covers headers, footers, comments, custom properties and embedded objects in one pass, because they are all just files in the archive; the second covers the info dictionary and any uncompressed metadata stream. Run both against a real export.

A clean export has creator and lastModifiedBy set to your firm's name; title set to the document title and the client name; description, subject and keywords deliberately emptied rather than left at whatever a template inherited; and producer overwritten rather than left at the library default.

Two further sources of contamination: a firm template built from a downloaded sample keeps the sample author's name and passes it on, and exporting to PDF through an application you did not draft in re-stamps Producer.

Make this a check with an objective result rather than a habit you trust yourself to remember. In the product this site belongs to, the equivalent check runs in CI on every build and on every plan, including the free trial — because the earliest export is the one a consultant is likeliest to show a client while still deciding whether to buy.

Placeholders

If you keep firm wording as templates with fields — client legal name, jurisdiction, a generated subprocessor table — have them substituted mechanically rather than by hand. An unresolved {{client.legal_name}} in a delivered file is the most visible error it is possible to make. The same goes for any gap marker your process uses: it exists so that it cannot be missed, and nothing carrying one should leave your office.

Trust pages on the client's domain

A trust page is the natural end point of the documentation you produce: one public page your client sends to a prospect's security reviewer instead of a ZIP of policies. It answers the routine questions — subprocessors, retention, security posture, contact — and makes the documents available on request.

The brand on the page is the client's, not yours and not your tooling's. Their name, their logo, their colour. The reviewer is evaluating the client, and a page that looks like a consultant's deliverable invites the wrong question.

Your credit belongs at the foot, once. A single line — "Data protection programme supported by [your firm]" — linking to your own site. That is the right amount of marketing and it is well placed: trust pages are read by procurement and security people at companies that buy from your client. Let the client switch it off.

The address bar is part of the brand. A page on the client's own domain or subdomain, pointed at your host by a CNAME, reads as the client's. A page on your firm's domain reads as yours, which suits some engagements. A page on a tooling vendor's domain reads as neither, and it is the part of a white-label arrangement a client objects to first, because it is the part they see first.

Nothing in the page source should name a tool either. Check view-source, not just the rendered page. A <meta name="generator"> tag is the trust-page equivalent of the PDF Producer field: invisible in normal use, trivially readable by exactly the audience likeliest to look. The same goes for favicon paths, asset URLs, analytics snippets and structured data. The only outbound link on a well-built trust page goes to your firm.

Drift is the real operational risk. The pack gets regenerated when the client adds a processor; the public page does not; six weeks later a reviewer compares the page's subprocessor list against the DPA and finds a contradiction. Build the page from the same source as the documents, and keep a visible signal in your workspace when a document has gone stale relative to the facts behind it.

Gate what should be gated. A DPA can sit behind a request form: the request reaches you, you approve it, the requester gets a link that expires. And keep the page unindexed until it is right.

Emails from your practice

The interview invitation, the reminder, the "your documentation is ready" note go from your practice to your client, and the From line is brand in the most literal sense.

• From display name: your firm. Not a product name, not a generic "notifications".
• Reply-to: a monitored address at your firm. The common failure here is not a visible vendor name but a reply that goes nowhere, because the field was left at the sending platform's default.
• Sending domain: ideally a subdomain of your own, authenticated with SPF, DKIM and DMARC before the first send. Until it is verified, mail leaves on the platform's domain, visible in the raw headers.
• Body and signature: your wording, your contact details, no third-party mention.

Two practical notes. Warm a new sending domain. A domain with no sending history goes to spam, and rebuilding reputation takes weeks. Start with low daily volume to recipients who will actually open, and increase gradually. A reminder that lands in spam is a deadline missed.

Separate your streams. Mail a client must receive — a portal invitation, a sign-in link — should not share a sending domain with digests. One complaint against a digest should not take down the mail that carries access links.

Disclaimers that protect you without undermining the work

Start with the sentence to stop using. "This document is provided for informational purposes only and does not constitute advice" is, on a deliverable the client paid you to produce, self-defeating three times over.

It contradicts the engagement: the client engaged you for professional judgement, and the sentence tells them in writing that they did not receive any. It devalues the artefact where it is meant to work — the eventual reader is often a reviewer at your client's customer, deciding whether the client has a real data protection programme, and a document that opens by disclaiming its own content hands them a reason to discount it. And it does not do the job you want done. What you sensibly want to limit is the input you relied on, the scope you covered and the period over which the document holds. A blanket "not advice" addresses none of the three.

What a scope-and-basis note should say

Keep it short, put it on the inside front page or before the annexes, and write it in the same plain register as the rest of the document.

Element	What it states
Parties	Your firm, the client's full legal entity, an engagement reference
Date and version	The document's date and version number
Basis	The facts it rests on: the client's responses of a stated date, documents they supplied, vendor documentation as published
Verification	Whether the client's factual statements were independently verified, and where they were, what was checked
Scope	Which regimes, entities and processing activities are covered — and briefly, what is not
Open items	Anything still unconfirmed, with an owner and a date
Validity	That it describes the position as at the date, and what kind of change calls for review
Contact	A named person at your firm

That note limits what should be limited and asserts what should be asserted.

Confirmed by the client versus assessed by you

This is the most useful discipline here and it costs nothing but attention to grammar. Every statement falls into one of three categories, and the sentence should say which.

• Facts the client confirmed. Attribute them. "The client reports that customer data is stored in the EU region of its hosting provider." You are recording, not certifying.
• Your assessment. Own it and show the reasoning. "In our assessment the client acts as a controller for the marketing activity in Annex 2, because it determines both the purpose and the means of that processing."
• Drafting convention. Wording you used because it is standard. Where it matters — a retention period from a policy default rather than a decision — say so.

Mixing the categories is what creates exposure. A client fact dressed up as your conclusion means you own an error you never made. Your conclusion dressed up as a client fact means that when it is challenged, the client finds nobody stood behind it.

Negative findings and open items

If an expected control is not in place, write it. "Independent penetration testing has not been carried out to date. It is planned before [date]." That is stronger than omitting the section: a reviewer who finds a gap in the coverage assumes the worst, while one who finds a stated gap with a date sees a programme being managed. It also keeps the document true, which is what matters when someone returns to it a year later.

And never let an unresolved placeholder reach the client. If a fact is not available at delivery, make it a named open item in the scope note. A plausible-sounding sentence covering a fact you do not have is the one failure from which the branding on the cover gives you no protection at all.

Words to leave out

Any verb that promises an outcome — that a document ensures, guarantees or certifies a state of compliance — should come out, and so should claims that the wording was approved or verified by someone the reader cannot identify. Set aside how such a sentence would be read if anyone tested it; it is bad for you on its own terms, because it sets an absolute standard against which any later finding is a shortfall. "Prepares the documentation required by [regime]" describes what you did and is defensible.

None of this is in tension with white-labelling. Putting your firm's name on a document means your firm stands behind the content; a scope note says precisely what "the content" is. A tool — clausebench among them — should make both easier and appear in neither. If you take one thing from this guide, run the two commands above against your next real export: it is the cheapest check here and the likeliest to find something.