How to turn regulatory requirements into product requirements

One sentence of the European Union’s General Data Protection Regulation (GDPR) shapes how people withdraw consent on websites.

Article 7(3) gives a person the right to withdraw consent at any time and requires that withdrawing it be as easy as giving it. That provision has no technical details and no mention of an interface.

Read that as a product manager and you are looking at a control, a state change, and a set of test cases.

Most requirements advice assumes a requirement starts with a user, a stakeholder, or a hypothesis. A second kind arrives already written, in someone else’s language, from a party you can’t negotiate with.

I work on public sector products, where the rules are drafted before the service exists and users have no alternative provider. Translating binding text into buildable requirements is a core element of the job. That skill transfers to fintech, health tech, HR tech, and any team handed a 60-page contract and a delivery date.

Legal and compliance own the interpretation, with product helping frame the question. Once they agree on an interpretation, you have to turn it into something the team can build and test. In this article, I will show you the chain that runs from there: source clause, agreed interpretation, product obligation, requirement, and acceptance criteria, each linked back to its source.

Why regulatory requirements behave differently

Binding external requirements behave differently from other items in your backlog, in ways that change what you can plan around.

• You can’t simply descope an applicable obligation — You can sequence the work, but it still has to meet the applicable compliance deadline
• The text was drafted for enforceability — Legal text tends to be precise about outcomes and quiet about methods. Prescribing a method can tie a rule to the technology of the drafting year, and that silence is the source of much of the product work below
• It’s versioned outside your control — The text you built against can change without a ticket or any signal at all inside your own systems

Those properties change who decides what. Legal and compliance own the legal interpretation and advise on the risk that remains after safeguards are in place. The accountable business owner decides whether to accept that risk within the organization’s governance process. Product owns what the product must do and works with engineering and design to choose the mechanism that delivers it. Assign these responsibilities before the first requirement is written.

A product manager who interprets regulation independently has produced an unreviewed legal position and attached a delivery date to it. Ultimately, that’s what the rest of this process exists to prevent.

The translation chain: From regulatory clause to acceptance criteria

Each of the five stages below answers a different question and leaves behind a different artifact.

Stage	Question it answers	Owner	Artifact
Source clause	What exactly binds us, and which version applies?	Legal or compliance	A citation, with a version and date
Agreed interpretation	What does this text mean for our product and our users?	Legal or compliance, with product input	An entry in the interpretation register
Product obligation	What must the product be able to do as a result?	Product	An outcome statement
Requirement	How will this product do it?	Product, with engineering and design	A backlog item
Acceptance criteria and traceability	How do we prove it, and how do we find it again?	Product, with quality assurance (QA)	Testable criteria linked back to the clause and agreed interpretation

An interpretation register is a shared record of the questions you raise, the agreed answers, and who approved them and when.

Taking Article 7(3) through each stage in turn:

Source clause

Article 7(3) of the GDPR, applicable since May 25, 2018, read together with the definition of consent in Article 4(11) and Recital 32. The latter explains that silence, prechecked boxes, and inactivity don’t constitute consent.

Agreed interpretation

In this example, two questions went to compliance: whether equal ease means the same number of interactions or comparable effort, and whether the withdrawal path has to be available through the interface that collected the consent.

The European Data Protection Board (EDPB) guidelines on consent, adopted in May 2020, address both. They don’t require giving and withdrawing consent to involve the same action, but withdrawal must be equally easy and available through the same electronic interface.

---

---

The position recorded was that consent given by a single click has to be withdrawable with comparable ease on that same interface.

Product obligation

A person who has consented can withdraw at any time, through the same interface, with comparable ease. The product stops processing data for the purposes covered by the withdrawn consent. Features that don’t require that consent remain available.

Requirement

For this website, a persistent preferences control on every page opens the consent panel, with a clearly labeled withdrawal option at the top level.

Withdrawal writes a new consent record with a timestamp and the categories affected. The consent controls stop further data collection and transmission for those categories, including from scripts already running. The tag manager checks the updated record before loading any script that requires that consent.

This is one implementation of the obligation. Its ease of use still needs to be tested against the original consent flow.

Acceptance criteria and traceability

• Given a user who accepted all optional categories, when they open the preferences panel, then they can withdraw consent for all those categories without navigating into individual category settings
• Given a user who withdraws consent, when they select the withdrawal option, then scripts in the affected categories stop collecting and transmitting data without requiring a page reload
• Given a user who has withdrawn consent, when they navigate to another page or reload, then scripts requiring that consent don’t load
• Given a user who withdraws consent, when the choice is saved, then the consent record shows the withdrawal, its timestamp, and the categories affected
• Given a user who withdraws consent, when they continue using the service, then the parts that never depended on that consent remain available

Each criterion carries the clause citation and the interpretation reference. The team also checks the complete withdrawal journey against the consent journey, including how easily users can find and operate the controls.

Obligation and requirement might sound like one artifact under two names, but they do different jobs: the obligation says what has to be true for the user, and the requirement says what this product does about it. A team that merges them locks in one implementation of a rule that permitted several.

Every requirement also carries its source and interpretation references. Adding those links pays for itself the first time the rule moves.

How to handle ambiguity in regulatory requirements

Legal text leaves gaps, and the gaps are the interesting part of the job. Three common kinds involve terms, thresholds, and methods. Asking who is in a position to close each gap tells you which move to make.

The undefined term

The text uses a term whose application to your product isn’t immediately clear. The Americans with Disabilities Act (ADA) Title II web accessibility rule covers content a public entity provides or makes available, including through contractual and licensing arrangements. What does this mean for the third-party scheduling widget embedded in your service?

Someone outside your organization may have answered this already, so the move is a search before it’s a decision: regulator guidance, published questions and answers, and enforcement actions involving comparable organizations. In this case, Department of Justice guidance explicitly identifies scheduling tools provided by outside companies as content that generally doesn’t qualify for the third-party content exception.

Product frames the question, legal or compliance confirms how the guidance applies, and the answer gets cited on the requirement. The failure mode is a team that quietly invents a definition and carries an unreviewed legal position for years.

The undefined threshold

The text sets a deadline but doesn’t specify every internal target needed to meet it. Article 33 of the GDPR requires notifying the relevant supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to pose a risk to people’s rights and freedoms.

That doesn’t give your team a detection or triage target, nor does it make 72 hours an acceptable default waiting period. External guidance can inform those targets, but your team still has to account for its architecture, staffing, and escalation process.

Legal states the notification requirements. Product works with security and operations to set internal targets that leave time for assessment and notification and records the reasoning behind them. The failure mode is a requirement sitting exactly on the deadline, with nothing left for the week a queue backs up.

The undefined method

The text names what must be true without prescribing your implementation. That same ADA Title II rule generally requires web content and mobile apps to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. However, it doesn’t choose your components, vendors, or remediation plan.

The work takes the form of a proposal. Product puts forward a mechanism with engineering, design, and accessibility specialists, stating its limits and how the team will verify the outcome. Legal or compliance reviews whether the approach addresses the agreed obligation, and the decision carries a date.

Remember that approval doesn’t replace testing. The failure mode is adopting whatever a competitor shipped and inheriting their exposure with it.

Keeping requirements current when the rule moves

A requirement can need review even when the underlying regulation hasn’t changed. Four common triggers tell you where to start.

Change type	What triggers it	What you rerun
New text	An amendment, a new instrument, or a new version of a standard	The full chain, from the source clause, for affected organizations
New deadline	A compliance date extended or brought forward	Delivery dates, sequencing, and dependencies. Confirm whether the substantive requirements also changed
New interpretation	Regulator guidance, a published answer, or an enforcement action that clarifies an obligation	The interpretation register first, then every requirement citing the affected entry
New enforcement posture	A shift in enforcement priorities or decisions involving comparable organizations	Your risk assessment, evidence, and traceability. Revisit requirements if the review exposes a gap

These categories can overlap. An enforcement decision can both clarify an obligation and signal that a regulator is paying closer attention to it.

The third row is where the traceability model earns its keep, so it’s worth following one through. In January 2023, the EDPB’s Cookie Banner Taskforce published findings on consent-banner practices, including how users withdraw consent. The report called for easily accessible withdrawal controls, such as a persistent icon or link in a visible, standard location. It didn’t prescribe one design: each implementation still needed assessment.

Consider a team whose withdrawal option sits inside account settings. Its obligation already says withdrawal must be as easy as giving consent, but its interpretation and tests have focused on whether the option exists. Reviewing the report prompts the team to examine whether people can actually find and use it.

The following example shows how that review could lead to the persistent preferences control described earlier.

Stage	Before the review	After the review	Why
Source clause	GDPR Article 7(3)	Unchanged	The review concerns guidance on the existing obligation
Agreed interpretation	INT-017: Withdrawal must be available through the same interface and equally easy	Clarified to address how users find and reach the withdrawal control	The review exposes a gap in how the team applied equal ease
Product obligation	Withdraw at any time, through the same interface, with comparable ease	Unchanged	The outcome already covers ease of withdrawal
Requirement	Withdrawal is available inside account settings	A persistent preferences control opens a panel with a clearly labeled withdrawal option	The team chooses a more accessible mechanism
Acceptance criteria	Confirm that withdrawal works once the user reaches account settings	Also test access from each page and compare the complete withdrawal journey with the consent journey	The tests now cover finding the safeguard as well as using it

The obligation holding still is the point of the exercise. It had been written as an outcome, so the review leaves it standing and the change lands on the mechanism and the tests. Traceability turns the report from an excavation into a query: every requirement citing INT-017 can be found in a single search.

Other changes travel differently. In April 2026, the Department of Justice extended the ADA Title II web accessibility compliance dates by a year, to April 26, 2027, for public entities with populations of 50,000 or more, and April 26, 2028, for smaller entities and special district governments. The extension changed the timetable, not the WCAG 2.1 Level AA standard. Teams gained delivery time, but the accessibility work remained.

Proposals need a different status again. As of October 2026, proposed changes to the Health Insurance Portability and Accountability Act (HIPAA) Security Rule remain pending, with the final action projected for July 2027. That is a planning estimate, not a compliance deadline.

---

---

Keep requirements based on existing rules separate from work proposed in anticipation of a change. Assign someone to monitor the proposal, record where it was last checked, and revisit the affected requirements when the final text and compliance dates are published.

Why compliance checklists don’t guarantee usability

The most common failure in this work is a team that treats a completed checklist as proof that the product serves the people the rule protects.

In April 2025, the Federal Trade Commission (FTC) finalized an order requiring accessiBe to pay $1 million to settle allegations that it misrepresented its automated accessibility tool’s ability to make any website conform to WCAG.

For product teams, the lesson is about what counts as done. A requirement written as an artifact to install can be closed without anybody verifying the outcome. The withdrawal example above exposes the same gap: a control can exist while remaining difficult for people to find or use.

The trap is set at the requirement stage, in the wording. A requirement that reads “display a consent banner” names an artifact. An obligation that reads “a user can withdraw consent with no more effort than giving it” names an outcome that can be tested. The implementation requirement and acceptance criteria need to preserve that outcome.

Before you call a compliance requirement done, put it through these checks:

1. People from the group the rule protects complete the real task end to end, using the tools they normally rely on. A checklist walkthrough doesn’t stand in for that experience
2. The failure path gets exercised alongside the happy path. Test what happens when a safeguard fails, such as a consent preference that can’t be saved
3. The safeguard can be found and used by a person who doesn’t already know it exists

These checks complement the legal and technical review. They show whether the safeguard works for the people it’s meant to protect.

Run one requirement through the chain this week

Pick a single item in your backlog that exists because an external rule says so.

1. Find its source clause and write down the citation, with the version and the date. If nobody can produce one, you have found something worth escalating
2. Ask legal or compliance the question you’ve been quietly guessing at. Record the answer in an interpretation register with a decider, a date, and any unresolved assumptions
3. Write the product obligation as an outcome, then revisit the implementation requirement, noting anything the old wording ruled out without anyone deciding to
4. Write acceptance criteria that cover the outcome, including the failure path and whether users can find and use the safeguard
5. Add the source and interpretation references as fields on the backlog item, so the next change begins with a search. Assign someone to monitor the source and record when it was last checked

None of this is going to make a regulation easier to read. What changes is where the interpretation sits: with the people accountable for it. The record it leaves can tell you a year from now why the product works the way it does.

Start with a citation field and one conversation you’ve been avoiding. Build from there toward requirements you can trace, test, and keep current, so the product serves the person the rule was written to protect.

Featured image source: IconScout