Privacy Policy Generator for agencies
Written for the agency’s own policy, the client sites it builds, and the processor role in between.
An agency needs two different privacy documents and most publish only one. This generator produces the agency’s own controller-facing policy - your site, your CRM, your recruitment, your client contacts - and points at the DPA for the client data you handle as a processor.
An agency has three privacy problems and usually documents only the first. There is the agency’s own site and CRM, where you are a controller. There is client data you hold to do the work - ad account access, analytics logins, CRM exports, customer lists for a campaign - where you are a processor. And there are the sites you build and hand over, where the tracking you installed becomes someone else’s legal exposure.
The middle one is where the contractual risk sits. If you touch client customer data, GDPR Article 28 requires a written processor agreement, and most agency master service agreements do not contain one. Without it, both sides are non-compliant, and the client finds out during their own audit rather than yours.
The third is where the reputational risk sits. An agency that installs GTM, a Meta pixel, a heatmap and a chat widget during a build, and hands over without documenting them, has left a client publishing a privacy policy that is inaccurate from day one. Increasingly, clients notice.
What a privacy policy for an agency has to cover
Your own controller processing: website, enquiry forms, CRM, recruitment and client contacts
A clear statement that client customer data is handled as a processor under a separate agreement
Your tooling as recipients: project management, storage, communication, analytics
Contractors and freelancers, disclosed as a category of recipient
Retention for client records after a project ends, and for prospect data that never converted
If you build sites for clients, the most valuable thing you can add to a hand-over is a list of every tag you installed and what it collects. It is the raw material for their policy, and producing it protects both sides.
How an agency actually moves personal data
Client customer lists for campaigns
Uploading a customer list to an ad platform for matching is processing on the client’s behalf, and it needs their basis, not yours.
Ad account and analytics access
Delegated access to a client’s Google Ads, Meta Business Manager or GA4 property gives you access to personal data under their control.
Creative assets containing personal data
Testimonials, case study material, customer photographs and user-generated content used in campaigns.
Your own project tooling
Notion, Slack, Figma, Asana and Drive all end up holding client personal data, which makes them sub-processors even though nobody thinks of them that way.
Freelance and offshore contractors
A common sub-processing relationship that most agency contracts do not disclose, and that transfer rules may also cover.
Tracking installed on client sites
Whatever you add during a build becomes a permanent part of the client’s processing, and it needs handing over in writing.
Third parties the draft will ask you about
Google Ads and GA4 · Meta Business Manager · HubSpot · Notion or Asana · Slack · Figma · Dropbox or Google Drive · freelance contractors
The rules that apply
Article 28 processor agreements
Required in writing wherever you process client personal data. It is the document clients now ask for at onboarding, not at renewal.
Sub-processor disclosure to clients
Your own tooling - project management, analytics, reporting, freelancers - are sub-processors from the client’s point of view.
Freelancers and contractors
Anyone outside your legal entity handling client data is a sub-processor needing a contract and, usually, client authorisation.
Marketing consent on behalf of clients
Running a client’s email or ads programme means operating on their consent records. If the records are weak, the exposure is theirs and the professional embarrassment is yours.
Hand-over documentation
Not a legal requirement, but the practical difference between a clean hand-over and a client publishing a policy that misdescribes their own site.
What the generated privacy policy contains
Identity and contact details of the controller
Your legal entity, trading name, registered address and a working contact route - plus a representative or DPO where one is required.
Categories of personal data and their sources
What you collect directly, what you observe automatically, and what you receive from third parties such as payment providers or ad platforms.
Purposes and lawful basis, purpose by purpose
A table that pairs each processing purpose with its lawful basis rather than listing all six bases and hoping one fits.
Recipients and sub-processors
The categories of recipient, and for the ones that matter to users - payment, hosting, analytics, support - the named provider.
International transfers and their safeguards
Where data leaves its home jurisdiction, and the mechanism relied on: adequacy, standard contractual clauses, the UK addendum or IDTA.
Retention periods per data category
Concrete periods or the criteria used to set them, which is what regulators ask for first when a complaint lands.
Rights and how to exercise them
Access, rectification, erasure, portability, objection and restriction, with the actual route to make a request and the deadline you work to.
Complaints and supervisory authority
The regulator a user can escalate to, named, with a link - not a generic "your local authority".
The agency compliance stack
Publish your own privacy policy as a controller
Covering your site, your CRM, your recruitment and your client contacts.
Add an Article 28 schedule to your MSA
One schedule, reusable across clients, covering instructions, confidentiality, security, sub-processors, assistance, deletion and audit.
Maintain a sub-processor list
Including your tooling and any contractors, ready to send when a client asks.
Standardise a hand-over pack
Every tag installed, what it collects, which policy sections it affects, and who now owns each one.
Set a client-data retention rule
Delete or return exports at project end, and actually run it.
Give each client site its own documents
Generated from that site’s actual stack rather than copied from the last build.
Where this usually goes wrong
No processor agreement with clients
The single most common agency gap. It surfaces when the client’s own compliance review asks for one and there is nothing to send.
Undisclosed sub-processors
Freelancers, offshore teams and the project tooling holding client data all count, and clients increasingly ask for the list.
Installing tracking without documenting it
Hand-over should include the exact list of tags, what each collects, and what the client now needs to disclose.
Reusing one privacy policy across every client site
Different sites, different tools, different processors, different markets. A shared template is inaccurate on most of them by definition.
Holding client data indefinitely after a project ends
Article 28 requires deletion or return at the end. Agency drives are full of exports from clients who left years ago.
Running email campaigns on consent nobody can evidence
If the client cannot produce the consent record, the campaign should not go out.
Frequently asked questions
Is my agency a controller or a processor?
A controller for your own business data - your site, your CRM, your staff - and a processor for client data you handle on their instructions. Most agencies need both a privacy policy and a processor agreement.
Do I need a DPA with my clients?
If you process personal data on their behalf, yes, and Article 28 requires it in writing. Adding it as a schedule to your standard contract is far easier than negotiating one per client.
Am I responsible for tracking I installed on a client site?
The client is the controller once they operate the site, but you carry professional responsibility for what you installed and for documenting it. Undocumented tracking is the source of most post-hand-over disputes.
Can I use one privacy policy across all my client sites?
Not accurately. Each site has a different toolset, different processors and often different markets, and an inaccurate transparency notice is itself a breach for the client.
Are my freelancers sub-processors?
If they handle client personal data, yes. That means a contract, and usually disclosure to and authorisation from the client.
Is a privacy policy legally required?
If you process personal data, in almost every market yes. GDPR and UK GDPR require the disclosure at the point of collection, CCPA/CPRA requires a notice at collection plus an annually reviewed policy, and app stores and payment processors require a public policy URL before they will list or onboard you.
Can I copy another company’s privacy policy?
It is both a copyright problem and a compliance problem. A copied policy describes someone else’s data flows, processors and retention periods, so it is inaccurate the moment you publish it - and an inaccurate transparency notice is itself a breach of GDPR Article 13.
How often does a privacy policy need updating?
Whenever your processing changes - a new analytics tool, a new payment provider, a new market - and as a backstop, review it annually. CPRA makes the twelve-month review explicit.
Does PolicifyAI give legal advice?
No. PolicifyAI is a technology provider, not a law firm. The output is a structured, jurisdiction-aware draft that a qualified adviser should review before you rely on it.
Privacy Policy Generator for agencies
Answer a short questionnaire and get a draft written for an agency. Free to start, no card required.
Generate your privacy policyOther documents an agency needs
Each one is written for the same context, not a generic template.
The same document, by business type
Go deeper
PolicifyAI is a technology provider, not a law firm, and this page is not legal advice. Generated documents are a structured starting point that a qualified adviser should review before you publish or rely on them.