Privacy Compliance Documentation Template
Four documents and three sheets that give each rights request its real statutory deadline, computed from the regulation that actually governs it.
Free download · No account needed
Rights Request Log · Kestrel Metrics, Inc. · Q1 2026
One shared 30-day column can't time both clocks. Neither clock is actually 30 days.
Every row's due date is computed from the regulation that governs that specific requester, not from a single response-time field meant to serve both.
| Request | Regime | Received | Real due | Flat 30-day due | Off by |
|---|---|---|---|---|---|
| R-2601 | GDPR | Jan 9 | Feb 9 | Feb 8 | −1d |
| R-2647 | GDPR | Feb 17 | Mar 17 | Mar 19 | +2d |
| R-2609 | CCPA | Jan 14 | Feb 28 | Feb 13 | −15d |
34 of 34 requests this quarter disagree with a flat 30-day field. Only 7 are the dangerous kind.
R-2647's kind is the one that actually got missed. A February receipt's real GDPR deadline lands 2 days before a flat 30-day field says it will, so the tracker still shows time left after the legal deadline has already passed.
Most privacy compliance templates give you the same four documents: a Privacy Policy, Records of Processing, a DPIA Template, a Breach Response Plan. All standard, all correctly named, and none of them time a single actual rights request. The gap shows up the moment two regimes apply at once, because a shared spreadsheet with one response-due column has no way to be right for both, and most companies serving both the EU and California are already carrying both.
Article 12(3) of the GDPR gives a data subject one calendar month, extendable by two further months. A calendar month is not a fixed day count: it runs 28 to 31 real days depending on which month the request lands in. The CCPA, as amended by the CPRA, gives a California consumer 45 calendar days outright, extendable once by 45 more. Neither number is 30, and a flat 30-day field misdates a request under either regime, in opposite directions.
Applied to Kestrel Metrics' Q1 2026 volume, 19 GDPR requests and 15 CCPA requests, all 34 disagree with a flat 30-day field. The 7 received in February, a 28-day month, land 2 real days early, the dangerous direction; the other 27 land late by 1 to 15 days, safe but still wrong. The Breach Response Plan runs the same logic against notification. Regulatory change keeps either register current as a rule amends, and the same mapping habit is where a privacy obligation lands once it becomes one row in the wider program.
What's in the pack
Data Inventory
Every system that touches personal data, its specific elements, the regime it engages, and the retention period the rest of the pack traces back to.
Processor Register
Every vendor with access to personal data, whether a data processing agreement is signed, and the breach notice commitment its own contract actually states.
Privacy Policy
The public-facing statement, traceable to the Data Inventory row behind every category it names, with each regime's real response clock stated by name.
Records of Processing
One entry per system, eight fields every time, so a reviewer can move between entries without re-learning the shape each one takes.
DPIA Template
Necessity, risk identification and named mitigations run against a specific high-risk processing activity, not a generic privacy-by-design statement.
Rights Request Log
Every request's due date computed from the regulation that actually governs the requester, a calendar month for the GDPR or 45 days for the CCPA, never one shared field.
Breach Response Plan
Three separate notice clocks run in parallel from one awareness timestamp, so a regulator's 72 hours and a resident's 30 days never get merged into one number.
How to use it
- 1
Open in River, or take it blank
Open the pack in River and describe which systems hold personal data, or download the Word documents and CSV sheets from the template library and build the inventory yourself.
- 2
Build the Data Inventory before drafting anything else
Every system, its data categories, its regime, and its retention period, because the Privacy Policy and the Records of Processing both trace back to this list rather than to memory.
- 3
Log every rights request on its own regime's clock
A calendar month for a GDPR request, 45 calendar days for a CCPA request, computed on the row rather than read off one shared column.
- 4
Run the Breach Response Plan's three clocks in parallel
A supervisory authority's 72 hours, an individual's undue-delay judgment call, and a resident's flat 30-day count, each logged separately from one awareness timestamp.
Frequently asked questions
Is this template free?
Yes, no account or card required. The download is Word documents and CSV sheets in a zip. Edit with AI is the second half: the agent builds the Data Inventory from a description of what your systems actually hold, then computes every rights request's real deadline from it.
What am I actually downloading?
Four Word documents and three CSV sheets, zipped. The sheets open in Excel, Numbers or Google Sheets straight off the download, and the Privacy Policy, Records of Processing, DPIA Template and Breach Response Plan open in Word or Pages.
Why can't one response-deadline field cover both regimes?
Because neither regime's real deadline is 30 days, and they are not computed the same way. The GDPR's one calendar month runs 28 to 31 real days depending on the month; the CCPA's 45 days is a fixed count. A field built for one regime is wrong for the other, and wrong for its own once a request lands in a short month.
What happens when a request could plausibly be either regime?
The log records which regime's clock was applied and the specific fact that decided it, a stated residency or an account's billing address, rather than picking silently. Where it stays genuinely unclear, running the shorter of the two applicable clocks is the safer default until it is resolved.
Does the GDPR's 72-hour rule apply to notifying customers directly?
No, and treating it that way skips a required judgment call. The 72 hours in Article 33 is the deadline to notify the supervisory authority. Notifying the individual is a separate GDPR obligation, triggered only by a high-risk finding, with no fixed hour count at all.
How does this fit with the other legal packs?
Regulatory change keeps either register current as a rule amends, and the same mapping habit is where a privacy obligation lands once it becomes one row in the wider compliance program rather than a document tracked on its own.
Give every rights request its real statutory deadline
Take the Word documents and CSV sheets blank, or open this exact pack in River and describe which systems hold personal data.
Edit with AI