In regulated industries, a bad epic is worse than a missing one. A missing epic surfaces during discovery; a bad epic clears the refinement gate, gets estimated on false premises, and detonates in UAT when an auditor asks where the data-retention rule lives. The cost of fixing a vague epic late in a programme is measured in months, not story points. This guide is about preventing that.
Why do epics fail compliance reviews?
Most epics that fail a compliance review don't fail because the team ignored the regulation. They fail because the regulation is implicit — known to the people in the room, assumed by the solution architect, glossed over in the acceptance criteria. An auditor who reads the epic three months later can't see any of that context. What they see is a description that could apply to any CRUD feature in any industry.
The three patterns I see most often:
- Vague acceptance criteria. "The system should handle consent appropriately" is not testable. "On revocation of GDPR consent, all processing of the affected data subject's records stops within 24 hours, verified by a daily audit report" is testable. The difference isn't effort — it's discipline.
- Missing regulatory anchor. The epic mentions "retention rules" or "KYC requirements" without naming the regulation. When the rule changes — and it will — nobody can find the affected epics to re-scope. Grep becomes archeology.
- Mixed concerns. A single epic covers "new onboarding flow + GDPR consent + KYC integration + audit logging." All four are load-bearing. Estimation becomes guesswork because the four parts have different risk profiles and different stakeholders.
What does a well-structured epic look like?
A good epic for regulated work has five elements, each deliberate and separable.
1. A title that names the user outcome. Not "Implement consent module." "Customers can withdraw marketing consent from their profile page." The title is the fastest way to tell whether the epic is about a user-visible change or a back-office plumbing change. Mix those and you lose the reader in the first line.
2. A user story that makes the value explicit. "As a {user}, I want to {action}, so that {outcome}." The "so that" clause is the one most people skip. It's also the one that tells an estimator whether the epic is shallow (one screen) or deep (workflow across three systems). Write it.
3. AS-IS and TO-BE descriptions. Two paragraphs. What does the current process look like, and what should it look like after this epic ships. In regulated work, the AS-IS matters more than in any other domain because the regulator cares about the transition path, not just the end state. If you can't describe the AS-IS, you don't understand the system well enough to change it.
4. Acceptance criteria as verifiable statements. Each criterion is a testable claim. Given/When/Then helps. More on this in the next section.
5. A regulatory context block as a first-class section. Not a buzzword in the description. A named paragraph that says: which regulation applies, which article or section, which specific requirement the epic satisfies, and what happens if that requirement is misread. This block is the one the auditor will read first. Treat it that way.
How do you write acceptance criteria that auditors accept?
The difference between a criterion an auditor rejects and one they approve is almost entirely about falsifiability. An auditor's job is to ask: can I verify that this is true or false by inspection? If the answer is "it depends on interpretation," the criterion fails. Here are four comparisons.
Bad. "The system should correctly handle data retention."
Good. "Given a customer record older than 7 years and not subject to an active litigation hold, when the nightly retention job runs, then the record is moved to the archive bucket and the retention_status field is set to archived."
Bad. "Users should be informed of their data rights." Good. "Given a user on the account settings page, when they click 'My Data Rights', then a page loads that lists the rights under GDPR Art. 15-22 with a link to exercise each, and the page load is logged in the audit table with the user ID and timestamp."
Bad. "The report must be generated quickly."
Good. "Given a user with the compliance_officer role, when they request the monthly retention report, then the report is delivered as a PDF within 60 seconds under the median load profile of 250 concurrent users."
Bad. "Access should be restricted to authorised users."
Good. "Given a user without the read:customer_pii permission, when they attempt to access the customer detail page, then the request returns 403 and is logged in the security audit table. Given a user with the permission, the request returns 200 and is also logged."
Notice what changes. The good versions name the actor, the trigger, the observable outcome, and the verification point. The bad versions name an intent. Intents aren't testable. Outcomes are.
How do you connect the epic to the regulation?
The regulatory context block is not legal advice and it's not for the legal team. It's for the engineering team and the auditor. It has three fields: the source, the constraint, and the consequence.
Source. The named regulation and the specific clause. GDPR Art. 17 (right to erasure). HIPAA §164.312(a)(2)(iv) (encryption and decryption). Solvency II Art. 41 (governance system). If you can't name the clause, you haven't read the regulation — find someone who has.
Constraint. What the clause actually requires, in plain language, translated into a system behaviour. "On a valid erasure request, the personal data of the data subject must be deleted or anonymised within 30 days across all downstream systems" is a system behaviour. "GDPR-compliant" is a sticker.
Consequence. What happens if the constraint is violated — both technically and legally. Technical: which downstream system starts serving stale data, which audit report starts failing. Legal: which supervisory authority is the point of contact, and what's the realistic exposure. You don't need to be a lawyer for this. You need to have asked your compliance officer once and written down their answer.
The consequence field is what turns an epic from a spec into a decision framework. When the team hits a trade-off during implementation, the consequence is what tells them which option is acceptable.
Frequently asked questions
Should every epic reference a regulation?
No. Only the ones where regulation drives a specific requirement. A "redesign the dashboard" epic in a regulated industry is still just a dashboard epic. A "add a consent banner" epic is not — it's a GDPR epic. The test is simple: if you removed the regulation from the problem statement, does the epic still make sense? If yes, it's not a regulatory epic. If no, name the regulation.
How long should an epic be?
Long enough that the reader — a developer, an estimator, or an auditor — has everything they need and nothing they don't. For most teams that's around 300 to 600 words across all sections combined. If it's under 150 words, it's probably a user story, not an epic. If it's over 1,000 words, it's probably two epics glued together. Split it.
What's the difference between an epic and a user story?
An epic is a coherent chunk of work that typically spans a sprint or more and delivers a measurable outcome to a defined user or stakeholder. A user story is one specific behaviour within that outcome, small enough to build and test in a day or two. The epic is the container; user stories are the content. If your "epic" can be implemented in a single story, you've named it wrong.