A compliance obligations register lists what each rule requires, of whom and by when, one row per obligation. Each row rests on a reading of the text: whether a sentence obliges, permits or forbids, whom it binds, what sets it off, what excuses it, whether it binds at all and from which date. Published standards and drafting guides give each of those choices a fixed field. This note applies them to two breach-notice duties, GDPR Article 33 and the SEC's customer-notice rule in 17 CFR 248.30.
Careful readers can fill different rows from the same text. When the U.S. federal court rules were restyled, "No preliminary injunction shall be issued without notice" became "The court may issue a preliminary injunction only on notice": one rule, read once as a prohibition with an exception and once as a conditional permission [20]. In a 2025 study, the authors counted 69 terms and 52 rules in three subsections of an Australian consumer code, where an earlier study had counted 65 terms and 36 rules [12]. Written reading rules let a second reader reproduce a row and a reviewer check it.
What a compliance obligations register row holds
LegalRuleML, an OASIS standard from 2021, gives the vocabulary [1]. An obligation is an act or state a party is legally bound to achieve, and failing it is a violation. A prohibition reverses that: doing it is the violation. A permission means the party has no duty to the contrary, and a right gives one party a permission while implying duties for others [1]. The party a rule is directed at is its bearer, and a party it involves is an auxiliary party [1].
Modality belongs to a party. Researchers have annotated English contracts with modality "expressed with respect to a contracting party or agent" [30], and GDPR Article 33 shows why it matters. Paragraph 1 obliges the controller to notify the supervisory authority. Paragraph 2 obliges the processor to notify the controller [2]. Those are two rows with different bearers. Paragraph 4 is a permission that relaxes the content duty in paragraph 3: information "may be provided in phases" [2].
Modality words need a stated convention
Engineers settled this for protocol documents. RFC 2119 defines MUST and SHALL as absolute requirements and MAY as "truly optional" [18]. RFC 8174 later clarified that only the uppercase forms carry those meanings, and that "a lot of normative text does not use them and is still normative" [19]. These are engineering conventions with no legal authority. The lesson carries over: a register states its convention, and a provision with no key word can still bind.
Legislatures use different conventions. In English, the enacting terms of binding EU acts generally use "shall" [3]. The UK's Office of the Parliamentary Counsel avoids the legislative "shall" [4]. U.S. House drafting reads "shall" as required and "may" as permitted, and prefers "may not" for denying a right, power or privilege, so a keyword list that maps "may" to permission misreads it [5]. Garner and Kimble read "may ... only" as a conditional permission [20].
The GDPR states the same duty twice. Recital 85 says the controller "should notify" within 72 hours unless it "is able to demonstrate" that the breach is unlikely to result in a risk. Article 33(1) says "shall ... notify", with a bare exception [2]. The EU's drafting guide says recitals give reasons and must not contain normative provisions [3], so the register reads the article and links the recital as context.
Binding status is its own field
Modality says what a provision asks. Status says whether it binds. The UK Financial Conduct Authority's Reader's Guide, dated January 2019, gives each Handbook provision a status icon. Four of them matter most for a register [6]:
| Icon | Status | Effect, as the guide states it |
|---|---|---|
| R | Rule | Creates binding obligations on firms in most cases |
| E | Evidential provision | Not binding in its own right and tied to a binding rule. Compliance with it can tend to establish compliance with that rule, and breach can tend to establish contravention |
| G | Guidance | Not binding, though acting in line with it in the circumstances it contemplates counts as compliance |
| D | Direction | Binding on the persons it is addressed to |
Guidance attaches to a row without merging into it. The European Data Protection Board's Guidelines 9/2022 explain when a controller becomes "aware": when it has "a reasonable degree of certainty" that an incident has compromised personal data [22]. The register links that passage to the trigger field as a separate source with its own status and version.
Exceptions, overrides and dates
LegalRuleML treats legal conditionals as defeasible: a more specific rule can block a general one, and an override records which rule takes precedence [1]. Article 33(1) has one exception, "unless the personal data breach is unlikely to result in a risk" [2]. 17 CFR 248.30 has a chain. A covered institution gives notice as soon as practicable, and not later than 30 days after becoming aware of unauthorized access to or use of customer information, unless the Attorney General finds a substantial risk to national security or public safety and notifies the Commission in writing. That permits a delay of up to 30 days, then a further delay of up to 30, and in extraordinary circumstances a final one of up to 60, for national security only [7]. Beyond that, the Commission may grant more delay by exemptive order [7]. Each delay is a permission row with its own condition and any limit, linked to the duty it overrides.
A permission found alone points to a missing parent rule. In the 2025 study, an example formalization of a consumer code listed four permissions to close a complaint and missed the rule that a complaint must not otherwise be closed [12].
A row also needs more than one date. LegalRuleML separates when a norm comes into force, when it has efficacy and when it applies [1]. The GDPR entered into force on 24 May 2016, the twentieth day after its publication on 4 May 2016 (derived), and applies from 25 May 2018 [2]. U.S. rules separate the effective date, when the CFR changes, from the compliance date, when the affected parties must comply [21]. The 2024 Regulation S-P amendments took effect on 2 August 2024, with compliance dates of 3 December 2025 for larger entities and 3 June 2026 for smaller ones (derived) [8].
A worked row: GDPR Article 33(1)
| Field | Value |
|---|---|
| Citation | Regulation (EU) 2016/679, Article 33(1), first sentence [2] |
| Binding status | Enacting term of a regulation, binding and directly applicable [2] |
| Bearer | Controller [2] |
| Auxiliary party | Supervisory authority competent under Article 55 [2] |
| Modality | Obligation ("shall") [2, 3] |
| Trigger | A personal data breach, as defined in Article 4(12), and the controller becoming aware of it [2, 22] |
| Action | Notify the breach to the supervisory authority [2] |
| Deadline | Without undue delay and, where feasible, within 72 hours of becoming aware [2] |
| Exception | The breach is unlikely to result in a risk to the rights and freedoms of natural persons [2] |
| Linked rows | 33(1) second sentence, 33(2), 33(3), 33(4), 33(5) [2] |
| In force, applies | 24 May 2016 (derived), 25 May 2018 [2] |
| Proposed change | Council mandate of 21 October 2026, procedure 2025/0360(COD) [10, 11] |
The approach matches the Rule 201 worked example, where every field is tied to the phrase it came from and checked against a stated property.
Cite a version and track proposed changes
Akoma Ntoso, the OASIS vocabulary for legal documents, separates the work, the act itself, from each expression, a version of its text [16]. A row cites the expression it was read from. The eCFR lists four versions of 17 CFR 248.30, from 31 December 2016 to 2 August 2024 [9], and the section as it stood on 1 August 2024 had no 30-day notice paragraph [23].
Proposed changes sit beside the row. The Council's negotiating mandate on the Digital Omnibus, agreed on 21 October 2026, would limit Article 33(1) to breaches "likely to result in a high risk" and set a limit of 96 hours [10]. On 7 November 2026 the European Parliament's procedure file read "Awaiting committee decision" [11]. The row keeps the text in force and links the change by its procedure reference.
Checking LLM-extracted obligations
In the 2025 study, modality labels were the easier part: every element's modality label came out right, while recall of rules peaked at 82.69% across model families and settings [12]. RePASs, a metric that scores answers on covering every relevant obligation without contradiction, gave gold answers 0.8101 and a baseline built on a commercial LLM 0.466 to 0.470 [25]. In a shared task built on it, one team showed that answers copied from the retrieved passages scored 0.947, against 0.639 for its readable generated answers [13].
Two checks follow. Measure recall against a labeled list of the obligations in a sample of provisions, as in testing document extraction accuracy before you buy. Then confirm that each field's phrase appears in the cited version of the passage, the method behind checking LLM citations against their sources. In Rillor's document and regulation intelligence work, an obligations register is read from the regulation text, one row per obligation, and every row links to the passage it came from.
Read the full report
The full report gives each field's definition from its standard, the modality and status tables, the 248.30 delay chain row by row, the date fields for both provisions, the research on finding and checking obligations, a register template in field order and the complete source list.