Acceptable Use Policy Generator

What is Acceptable Use?

An acceptable use policy generator. It is the document that tells a customer what they may not do with a service, and what the provider will do about it. For anything with shared infrastructure it is the clause that decides whether abuse can be shut down quickly or has to be argued about first.

How it works

Each prohibited use you select becomes a bullet in the policy, and the response to resource abuse — throttle, suspend, or suspend and terminate — is written into the fair-use section. The monitoring clause states what is watched (traffic patterns and service health rather than content) and the narrow cases where content is inspected, which is the clarification customers ask about first.

1. Fill in the details the document needs. Business name, jurisdiction, dates, the clauses that apply to you. Nothing is uploaded and no account is created — the form is the only input, and the document is assembled in the page.
2. Watch the blanks, not just the text. Any field you leave empty appears in the document as [[a highlighted marker]], and the panel above the output lists exactly which blanks are left. A half-finished policy should never look finished.
3. Copy or download, then have it reviewed. Copy the document to the clipboard or download it as a .md file named for what it is. Every page states the same thing: this is a template, and it needs a qualified lawyer's eye before you publish or sign it.

Examples

A privacy policy for a side project

A solo developer shipping a newsletter signup needs a policy that says what is collected, why, and how to ask for deletion. Selecting the categories actually collected — rather than copying a competitor's list — takes two minutes and produces a document that is true.

Terms of service with a real liability cap

The liability clause is written from a number you supply instead of being left as "our total liability is limited to [amount]". A cap that is never filled in is a clause no one can rely on.

A DMCA notice a provider will actually action

A takedown that is missing the URL of the original work, or the statement under penalty of perjury, is one the service provider is entitled to ignore. Every required element appears in the generated letter, in the order the statute describes.

A DPA for a new vendor

Processors, security measures, breach notification window, transfers and audit rights as one document, with the subprocessor and SCC clauses switched on because this vendor uses both.

Common mistakes

Publishing a template without reading it

A policy that promises something you do not do — deleting data on request within 30 days, or never sharing data with third parties — is worse than no policy, because it is a documented misstatement. Read every clause against what actually happens and cut the ones that do not apply.

Assuming one document covers every jurisdiction

A privacy policy written for the UK does not automatically satisfy California, Brazil or Canada, and an employment clause that is standard in one country can be unenforceable in another. Name the jurisdiction you are actually writing for, and check the rules that follow from it.

Bundling consent and calling it consent

A single "I agree" covering marketing, analytics, photographs and treatment is not valid consent under most regimes, because consent has to be specific and separately given. Use one form per purpose, and never pre-tick the optional boxes.

Leaving the blanks in after generating

The marker can be more subtle to spot in a document than on the page — search the pasted text for the bracket characters before publishing, or use the missing-field list to confirm it is empty.

Frequently asked questions