The part that makes the policy true

Lite is, and it is not a trial. Everything needed to answer a request lawfully is in it: intake, verification, the dossier across all fourteen sources, export, anonymise, erase, the consent ledger, the activity ledger, legal holds and the suppression list. Pro is $149 with a $119/year renewal and adds the recurring half — retention rules and their scheduling, the Article 30 register and its report, and deadline reminders. A site on Lite can comply in full; it does the repeating parts by hand.

No, and be suspicious of anything that says otherwise. Compliance is a set of decisions — what you collect, why you are allowed to, how long you keep it, who you share it with — and those are yours to make. What Lock does is carry them out and prove that it did: it finds the data, it does what you decided, and it keeps a record a regulator can read. The decisions still have to be made by somebody who knows the business.

Fourteen collectors ship, one per source, covering users and addresses, entries and their custom fields, Commerce orders and customers, Formie and Freeform submissions, Verbb Comments, Toss, sessions and authentication records, and the log files. Every integration is guarded by an availability check, so nothing is a hard dependency and anything absent is recorded as not searched rather than skipped in silence. For the source Lock cannot know about — an old import, a mailing list, a module's enquiry log — there is a screen for declaring it and an interface for writing a real collector.

Because an approval that does not bind is not an approval. Lock builds a plan of specific records with a decided action each, and running it walks that list — it never goes back and searches again. Re-searching would be shorter code and it is wrong twice over: rows created between the preview and the button would be deleted without anybody having seen them, and rows the preview listed might be gone, so the report would describe a different set from the one approved. The plan is fingerprinted, the fingerprint is posted back, and a mismatch throws.

Erase deletes the record. Anonymise keeps the record and destroys the person in it. Most of the time the second is the right answer, and not because it is gentler: a completed order is a financial record, six years in the UK and ten in Germany, and Article 17(3)(b) says the right to erasure does not override a legal obligation to keep something. But the order is what the obligation covers, not the customer's name inside it. So Lock empties the order and keeps it — the money, the tax, the line items, the country and the date stay; everything that says who does not.

Each record declares whether it is erasable, anonymisable, or neither, and the collector that owns the data gets the last word — the erasure screen cannot override it. Completed Commerce orders are not erasable and keep country and region when anonymised, because that is what a VAT return is built from. Consent records are never deleted at all. On top of that, a legal hold beats both a retention rule and an erasure request, and held records never reach a preview in the first place.

Not with admin changes turned off, and that is the intended trade. A rule that deletes personal data on a timer is a change to what the site does, so it lives in project config and arrives by deploy — reviewed, diffable, and the same in every environment. The alternative, an editable table on production, means the most destructive setting in the plugin is also the least reviewed one. The Article 30 register goes the other way and lives in the database, because it is a document a DPO maintains and nothing in it changes behaviour.

The other thirteen still run. collect() is final and the base class catches the error, records it against the bundle, and the dossier reports itself as partial with the source named. That honesty is the feature: a collector that threw and took the whole run with it would leave you with nothing, and one that failed quietly would leave you with a disclosure that looks complete and is not. Nine sources out of ten with no mention of the tenth is what turns a handled request into a complaint.

No. Every response the public intake gives is identical — a successful request, an address nobody has heard of, a rate-limited attempt, a tripped honeypot. Any difference between them, including a difference in timing or in the wording of an error, is an oracle a stranger can use to enumerate your users. Confirmation of whether anything was found happens after the address has been verified by email, to the person who holds it.

One month from the day the request arrives, and two more on top if the request is genuinely complex — but you must claim the extension within the first month and tell the subject why. lock/requests/deadlines on a daily cron sends the reminders and expires unconfirmed requests, and Pro adds escalating warnings as the date approaches. Deadlines are compared in days rather than seconds, because adding two months to a timezone-aware date across a DST boundary moves the answer by an hour and can cost you a day.