Regulatory Obligation Register Design Guide

Definitions

Practical workflow

1. Set the register purpose and legal perimeter

   State which compliance decisions the register must support, such as regulatory change assessment, control testing, filing readiness, audit response, board reporting, or issue remediation. Name the accountable compliance owner, qualified interpretation roles, covered business lines, record retention rule, access model, and escalation path. Define what the register does not decide.

2. Collect authoritative sources

   Start with official legislation, regulations, regulator rules, licenses, orders, supervisory publications, binding decisions, and other sources that actually govern the declared population. Record the issuing authority, source type, jurisdiction, language, publication or version date, effective date, repeal or expiry information, and retrieval date. Treat standards, guidance, industry codes, contracts, and internal policies as separate source classes unless the applicable authority makes them binding.

3. Create a reproducible citation record

   Capture the stable source title, official URL or repository identifier, article, section, rule, paragraph, schedule, page, or control reference, source version, relevant text location, publication date, effective date, and retrieved date. Preserve a copy or approved archival reference where policy permits. A search result, vendor summary, or undated screenshot is not a sufficient authoritative citation.

4. Preserve obligation text separately

   Store the relevant source wording or a controlled excerpt with its citation and version. Keep internal notes, plain-language summaries, assumptions, translations, and implementation advice in separate fields or sections. Mark paraphrases as interpretations and preserve enough context to avoid changing a conditional, exception, actor, threshold, time period, jurisdiction, or defined term.

5. Assess applicability with qualified review

   Evaluate the obligation against the declared entity, legal form, license, jurisdiction, product, service, process, technology, data, customer, transaction, and effective period. Record applicable, not applicable, pending, or disputed with the facts and source reasoning. Route ambiguous terms, conflicts between sources, extraterritorial reach, exemptions, thresholds, privilege, or legal effect to a qualified reviewer; do not infer applicability from a keyword match.

6. Define scope and relationships

   Record the exact in-scope and out-of-scope entities, jurisdictions, branches, products, services, processes, systems, locations, data classes, roles, and transaction types. Link parent instruments, amendments, implementing rules, related obligations, licenses, policies, risks, issues, controls, tasks, filings, and evidence. Keep source scope distinct from the organization’s implementation scope.

7. Write the operational interpretation

   Translate the applicable text into a concise operational statement that names the actor, required outcome, trigger, conditions, timing, exceptions, and evidence expectation. Identify assumptions, unresolved questions, local procedures, and interpretation boundaries. Require a named qualified reviewer and review date; an AI extraction or compliance summary may propose text but must not silently become the approved interpretation.

8. Map obligations to controls

   Link each obligation to one or more controls and record the relationship type, such as prevents, detects, responds, documents, or monitors. Describe the control objective, owner, population, frequency, design evidence, operating evidence, test method, and failure route separately. Avoid claiming that a control mapping proves compliance or that one control satisfies every condition in a source.

9. Create tasks and accountable owners

   Assign obligation owners, control owners, task executors, approvers, evidence custodians, and qualified reviewers explicitly. Create tasks for implementation, recurring performance, filings, attestations, training, testing, remediation, source review, and change assessment. Require a due date or trigger, priority, dependency, status, escalation, completion evidence, and reassignment rule for each task.

10. Model dates, frequency, and status

    Store source effective date, compliance start date, due date, event trigger, notice window, recurring frequency, time zone, business-calendar rule, next review date, and date-calculation method separately. Keep obligation status, control status, task status, evidence status, and issue status distinct. Do not replace a rule-based deadline with a reminder date without preserving the source rule and qualified calculation.

11. Define evidence and testing expectations

    Specify what evidence is expected, for which population and period, in what format, with which owner, retention class, access restriction, source link, timestamp, version, approval, and integrity check. Distinguish evidence that an activity occurred from evidence that the activity was designed or effective. Define sampling, exceptions, test results, reviewer, conclusion, and retest without treating a stored file as proof by itself.

12. Handle exceptions and residual risk

    Record the affected obligation, scope, reason, decision authority, compensating control, interim task, start date, expiry or review date, owner, notification, residual risk, and closure evidence. Separate an approved exception from a breach, overdue task, failed control, disputed applicability decision, and missing evidence. Escalate expired or repeated exceptions and prevent them from silently becoming the baseline.

13. Control regulatory and register change

    When a source changes, compare prior and new text, applicability, scope, interpretation, control links, tasks, evidence, dates, frequency, status, exceptions, and reporting. Record who detected, reviewed, approved, implemented, and verified the change, with effective and communication dates. Version the record rather than overwriting history, and preserve superseded citations and decisions.

14. Review, report, and improve

    Review each record on its scheduled cadence and when a trigger occurs, including new or amended law, regulator communication, product change, entity change, incident, audit finding, enforcement action, control failure, or business expansion. Report coverage, pending interpretation, overdue review, evidence gaps, exceptions, breaches, and control-test results by scope and risk. Use qualified review to correct the register and document the decision.

Comparison

Limitations and exceptions

• There is no universal obligation-register schema, applicability test, evidence standard, status vocabulary, frequency, or severity threshold. Tailor the register to the organization, sources, jurisdictions, entities, products, processes, and risk decisions that actually apply.
• A register does not create a legal obligation and cannot determine the meaning, enforceability, scope, exemption, or conflict of a source without qualified interpretation. Record uncertainty instead of presenting a confident summary as a legal conclusion.
• A source citation can be accurate while the implementation scope is incomplete. Entity structures, licenses, locations, data flows, products, outsourced activities, and customer commitments can change the applicable population.
• Control mapping is not a compliance guarantee. A control may be poorly designed, inconsistently operated, too narrow for the source, or supported by evidence that is incomplete, stale, fabricated, inaccessible, or unrelated to the relevant population.
• Automated extraction and change detection can improve triage but can miss definitions, cross-references, exceptions, tables, jurisdictional qualifiers, scanned text, amendments, translations, and effective-date logic. Require human review for material interpretations and changes.
• A recurring due date is not necessarily the source deadline. Calendar conventions, business days, event triggers, time zones, notice mechanics, extensions, holidays, and regulator-specific filing methods require source-based calculation and appropriate review.
• A complete register can still fail operationally if owners do not act, evidence is not retained, access is too broad, exceptions expire, controls are not tested, or changes are not communicated. Measure use and outcomes in addition to record completeness.

Primary sources

Methodology

Use a versioned obligation record with these standard design fields: obligation_id; source_authority; source_title; source_type; official_source_url; citation; source_version; publication_date; effective_date; repeal_or_expiry_date; retrieved_at; language; obligation_text; defined_terms; applicability_status; applicability_reason; qualified_reviewer; interpretation_status; operational_interpretation; interpretation_assumptions; affected_entities; affected_jurisdictions; affected_products; affected_services; affected_processes; affected_systems; affected_locations; affected_data_or_transaction_scope; in_scope_statement; out_of_scope_statement; obligation_owner; accountable_function; qualified_review_role; control_links; control_relationship; task_links; evidence_requirements; evidence_owner; evidence_location; evidence_period; evidence_status; due_date_or_trigger; date_calculation_rule; frequency; calendar_and_time_zone; obligation_status; control_status; task_status; evidence_status; exception_links; exception_reason; compensating_treatment; residual_risk; exception_owner; exception_expiry_or_review_date; change_history; source_change_detected_at; change_summary; prior_record_version; change_approved_by; change_effective_at; last_reviewed_at; next_review_at; review_trigger; review_result; and record_access_class. Use one stable obligation_id across versions and a separate record_version for each approved change. The source_authority, official_source_url, citation, source_version, obligation_text, publication date, effective date, and retrieved_at make the source reproducible. The applicability fields state the facts and qualified decision, while the operational_interpretation translates the source into local action without replacing it. Scope fields must identify entities, jurisdictions, products, services, processes, systems, locations, data, and transactions; avoid a generic label such as enterprise-wide when a narrower population is intended. Keep obligations, controls, tasks, and evidence as separate linked records. A control has an objective, owner, population, design, frequency, operating procedure, test method, and failure path. A task has an assignee, trigger, due date, dependencies, status, escalation, and completion result. Evidence has a source, period, scope, timestamp, version, custodian, access restriction, integrity or approval context, and conclusion. Calculate register coverage = obligations with a current citation, qualified applicability decision, owner, scope, review date, and at least one stated control or documented not-applicable rationale / obligations in the declared population x 100. Calculate qualified-review coverage = obligations due for qualified review in the observation period with completed review and decision date / obligations due for qualified review in that period x 100; exclude only records explicitly outside the declared scope or canceled under a documented rule, keep pending, disputed, unknown, and late items in the denominator, and report the numerator, denominator, period, exclusions, unknown count, and unit (obligations and percent). Example: 18 completed reviews / 20 obligations due = 90%; 100 completed reviews cannot be divided by 20 due obligations because completed reviews must be a subset of the due population. Calculate evidence readiness = obligations due for evidence with an approved evidence requirement, current evidence location, and period-appropriate evidence status / obligations due for evidence x 100; report the period, exclusions, unknowns, numerator, denominator, and unit (obligations and percent). Calculate on-time review rate = records reviewed by the approved review point / records due for review in the observation period x 100. Calculate control mapping coverage = tested applicable obligations with every required condition mapped to a control, task, evidence expectation, or documented qualified decision that no control is required / tested applicable obligations x 100; exclude only records outside the declared test scope under a documented rule, keep incomplete, pending, disputed, and unknown mappings in the denominator, and report the period, exclusions, unknown count, numerator, denominator, and unit (obligations and percent). Example: 18 mapped / 20 tested = 90%; mappings from 100 obligations cannot be divided by 20 tested obligations because the numerator must come from that tested population. Publish counts and denominators, pending interpretations, not-applicable decisions, unknowns, overdue reviews, exceptions, breaches, and out-of-scope items separately; never convert missing, disputed, or pending values into compliance. Organization-designed starting statuses are proposed, source-confirmed, under interpretation, applicable, not applicable, pending evidence, implemented, monitored, breached, remediating, superseded, and retired. Organization-designed review triggers include a source amendment, new rule, regulator communication, enforcement or court development, entity or license change, new product or process, material incident, control failure, audit finding, expired exception, or scheduled review. Treat these labels, formulas, thresholds, and fields as a local operating framework to be approved and calibrated, not as universal legal requirements. Have qualified professionals validate source text, applicability, interpretation, scope, dates, exceptions, and changes before operational reliance.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Compliance management
• Case management
• Playbooks
• Contract lifecycle management