Verified against ChatGPT · 2026-08-11
Turn a regulation you name into a working checklist your team can actually run against
Converts a compliance requirement you specify into a structured, assignable checklist with owners and evidence needed — built to organize what your team already knows applies, not to determine what the law requires.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a working compliance checklist for the requirement I name below. I will tell you what the requirement is; your job is to structure it into an actionable checklist, not to determine or verify what the law itself requires. THE REQUIREMENT (as I understand it — verify independently) Our state's data breach notification law requires notifying affected individuals within 30 days of discovering a breach involving personal information. OUR ORGANIZATION 50-person SaaS company, stores customer names/emails/payment info, no dedicated compliance team. WHAT WE ALREADY HAVE IN PLACE We have an incident response doc but it doesn't specify a notification timeline. WHO WILL OWN THIS IT Lead, Head of Ops, outside counsel on retainer. CHECKLIST-BUILDING RULES Break the requirement as I've described it into discrete, assignable action items — each one a specific thing a specific role does, not a restated summary of the requirement itself. For each item, note what evidence or documentation would demonstrate it's been done, since a compliance checklist without an evidence trail is just a to-do list that can't survive an audit. Cross-reference against what I said we already have in place, and mark each item Done, Partial, or Not Started rather than assuming everything starts from zero. Assign each item to a role from the team structure I gave you, not a named individual, so the checklist survives personnel changes. Flag any item where you genuinely don't have enough information from what I described to know what "done" would look like, rather than guessing at a specific action to fill the gap. WHAT NOT TO DO Do not add requirements beyond what I described, even if they sound like things that regulation commonly requires — you were not given the actual regulatory text and should not assume you know its full scope from the name alone. Do not state a specific penalty, fine amount, or enforcement consequence for non-compliance unless I gave you that figure; if it matters, mark it as something to confirm from the actual regulatory source. OUTPUT FORMAT 1. Checklist table: Action item | Owner role | Evidence needed | Status (Done/Partial/Not Started). 2. A short list of items flagged as needing more information. 3. A closing note stating this checklist organizes the requirement as described into an actionable structure — it is not a determination of full legal compliance, and the underlying requirement's actual scope, applicability to this organization, and completeness of this checklist should be confirmed by a qualified compliance lawyer before relying on it.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The most dangerous failure mode in this task isn't a badly organized checklist, it's a confidently expanded one — a model asked to build a compliance checklist around a named regulation will often fill in plausible-sounding additional requirements from its general training data about what that category of law "usually" includes, which is exactly backwards when the user hasn't provided the actual regulatory text; explicitly restricting the model to the requirement as described, and forbidding it from adding requirements it merely suspects apply, keeps the output scoped to what was actually verified rather than what sounds right. Requiring an evidence-needed column for every item is what separates a compliance checklist from a generic to-do list — a checklist that just says "notify affected individuals" without specifying what documentation proves that happened (dated notification letters, a log of who was contacted and when) is useless in front of an actual auditor or regulator, and a model not explicitly told to think about evidence will produce action items without their proof trail. Cross-referencing against existing measures before assigning status matters because organizations rarely start from zero, and a checklist that ignores what's already in place either duplicates existing work or, worse, gets treated as the full task list when half of it was already handled — an inaccurate Done/Not Started read is arguably worse than no checklist at all because it creates false confidence. The instruction to flag insufficient information rather than guess directly targets the model's tendency to fill any gap with a specific, invented detail rather than an honest "I don't have enough to specify this" — which matters enormously here because a specific action item that isn't actually what the regulation requires is worse than an acknowledged gap, since the gap at least prompts someone to go check.
What you get back
1. Draft breach notification letter template — Owner: outside counsel — Evidence: signed-off template on file — Status: Not Started. 2. Define internal escalation path for suspected breaches — Owner: IT Lead — Evidence: documented escalation procedure — Status: Partial (incident response doc exists, lacks timeline). Flagged: unclear from your description whether the 30-day clock starts at discovery or confirmation — confirm with counsel. This checklist organizes the requirement as described; it is not a determination of full compliance — confirm scope and completeness with a qualified compliance lawyer.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
