A regulatory obligation register should answer a hard operational question: which current source requires this organisation to do what, where, when, under whose ownership, and with what evidence? A spreadsheet that lists circular titles cannot do that reliably. A policy inventory cannot either. The register needs a traceable chain from official text to day-to-day control.
Use authoritative sources such as the eGazette of India, India Code, the Reserve Bank of India's notifications and master directions, and SEBI's legal materials. Add sector and state sources relevant to the organisation. Aggregators can help discovery, but the register should point to the official item and preserve the version reviewed.
What belongs in a regulatory source inventory?
Start above the obligation level. Catalogue Acts, rules, regulations, notifications, directions, circulars, master directions or circulars, orders, official FAQs or guidance, and relevant licence conditions. Record the issuing authority, official URL, identifier, publication date, stated effective or transitional information, language, territorial and entity scope, amendments, supersession status, and retrieval date.
Treat the official document and internal interpretation as separate records. That avoids a common failure where a lawyer's summary replaces the underlying source. Preserve the source file or a controlled reference according to the organisation's policy, especially when official pages may later move.
| Source field | Review question |
|---|---|
| Authority and instrument type | Does this body and instrument apply to the entity? |
| Official identifier and link | Can a reviewer locate the same text? |
| Version and amendment chain | Is this the operative wording for the period? |
| Applicability dimensions | Which entity, product, activity, place, or customer is covered? |
| Effective and transition information | What must be ready, and when? |
| Interpretation owner | Who approved the operational reading? |
Do not update the old source record in place when text changes. Close its applicability period and link the successor.
How should a source become a usable obligation?
Break the source into atomic obligations that can be assigned and tested. One row should not say “comply with KYC requirements.” It should describe a single action or constraint in operational language, while retaining the exact source reference and any relevant defined terms.
Use a drafting pattern:
Applicability condition → accountable subject → required or prohibited action → trigger or frequency → timing → required recipient or channel → evidence → exception or dependency
The operational statement is a controlled interpretation, not a quotation unless marked as one. Record its author, reviewer, approval date, assumptions, and open question. Where qualified counsel concludes that a source does not apply, preserve the scope analysis and review trigger rather than deleting the candidate item.
Assign a stable obligation ID. Policies, controls, tests, issues, and evidence should refer to that ID so a wording change does not break history.
The ID also makes review conversations more precise. A policy owner can ask which obligation changed, a tester can identify the exact requirement sampled, and an auditor can follow prior versions without relying on row numbers that shift after sorting. Keep the identifier stable when wording is clarified. Create a new linked record only when the underlying duty, scope, timing, or accountable subject changes enough to require a separate implementation decision.
How can applicability be decided consistently across a group?
Build a legal-entity and activity profile before applying sources. Capture licences, registrations, products, services, customer types, locations, delivery models, outsourcing, data flows, listed status, group relationships, and other approved dimensions. The register should state which profile facts caused an obligation to apply.
For a group, avoid copying the same obligation into disconnected spreadsheets. Maintain one source and obligation model, then create entity-specific applicability records with local owners and controls. This preserves common interpretation while allowing genuine differences.
Escalate ambiguity through a documented route:
- unclear entity or activity coverage;
- competing instruments or regulator materials;
- amendment without clear transition treatment;
- cross-border or state-law interaction;
- product change that does not fit the existing profile; or
- an exception that depends on changing facts.
“Not applicable” should require a reason, approver, evidence, and next review event.
How should obligations connect to controls and proof?
An obligation describes what is required. A control describes how the organisation addresses it. Evidence shows whether the control operated. Keep those layers distinct and allow many-to-many links.
| Layer | Example record content | Common mistake |
|---|---|---|
| Obligation | Source, applicability, action, timing | Restating a policy title |
| Control | Owner, procedure, systems, frequency | Claiming a document is a control |
| Evidence | Period, source, result, reviewer | Uploading a screenshot without context |
| Test | Method, population, sample, finding | Marking “tested” without criteria |
| Issue | Gap, impact, action, due owner | Closing when a task is created |
Create the traceability chain:
Official source → approved obligation → applicable entity or activity → control → evidence → test → finding → remediation → retest
Evidence links should specify what period and system they cover. Keep secrets and unnecessary personal data out of general compliance repositories. Review Gotham's security information and privacy approach during platform diligence, then test the actual deployment and access model.
What workflow turns a legal update into controlled change?
Monitor official publication routes using named owners and backup owners. When a candidate update appears, capture it before deciding relevance. Compare it to the prior version, identify affected obligations, assess entities and activities, obtain the required interpretation, and create implementation actions with accountable owners.
Use explicit gates:
Detected → official source verified → relevance screened → legal analysis approved → obligation changes mapped → control impact assigned → implementation evidenced → readiness reviewed → register released → post-change test scheduled
Keep publication date, effective date, internal target, and completion date as separate fields. Do not infer a universal implementation date from a headline. If an instrument is clarified or corrected, link that event to the original and reassess open work.
A change packet should show affected obligations, old and new wording, interpretation, affected policies and controls, technology or vendor dependency, communications, training, approvals, residual issue, and validation plan.
How should ownership and assurance work?
Give every applicable obligation an accountable business or functional owner and an interpretation owner. Add control operators, evidence providers, testers, and issue owners without confusing responsibility. A committee cannot substitute for a named person who must act.
Record temporary ownership changes too. Leave, restructuring, outsourcing, and acquisitions can strand an obligation even when the register still displays a familiar team name.
Review the register through risk-based samples and thematic sweeps. Ask whether the official source is current, applicability facts remain true, interpretation is approved, control design matches the obligation, evidence covers the stated period, and open findings are visible. Test superseded requirements too, because historical reviews may depend on the rule then in force.
Use a practical health checklist:
- Every active obligation links to an official source and version.
- Applicability identifies the entity, activity, and supporting facts.
- Effective and internal target dates are not conflated.
- Control and evidence links identify scope and period.
- Amendments preserve the historical chain.
- “Not applicable” and exceptions have review triggers.
- Failed controls create owned remediation and retesting.
- Access, approvals, and changes are auditable.
For a sector-specific application, read the RBI outsourcing compliance workflow. Explore Gotham workflows, review security and compliance information, or contact Gotham about source-linked compliance operations. A register can make responsibilities visible. Qualified professionals still need to interpret each source and the organisation's facts.
