# Regulatory Change Management: Keeping Pace When DPDPA Rules, AI Guidelines, and Sectoral Circulars Drop Simultaneously

The DPDP Rules are notified and commencing in phases. The EU AI Act's high-risk obligations became applicable in August 2026. MeitY continues to issue advisories on AI. RBI, SEBI and IRDAI each publish technology and cyber directions on their own cycles. Standards bodies revise ISO 27001 and publish new AI management standards.

Your compliance calendar is a game of whack-a-mole, and the mole you miss is the one that becomes an audit finding.

## Why This Is Structurally Hard

The difficulty is not volume. It is that regulatory change arrives in a form no system can consume.

**It arrives as prose.** Gazette notifications, PDFs, press releases, FAQ pages, speeches by regulators that signal direction before any instrument exists. None of it is structured data. None of it comes with a machine-readable indication of which of your controls it affects.

**Sources are fragmented.** There is no single feed. Central government ministries, sectoral regulators, standards bodies, foreign regulators with extraterritorial reach, and industry bodies all publish independently on independent schedules.

**Effective dates are staggered and conditional.** The DPDP framework alone commences across three phases spanning eighteen months. The EU AI Act staggers across four. A single change may have different dates for different provisions, different entity classes, and different transition arrangements.

**Impact is not obvious from the text.** A change to a breach notification timeline touches your incident response runbook, your vendor contracts, your SOAR playbooks, your training material and your board reporting. Nothing in the instrument says so.

**Ownership is ambiguous.** A change affecting AI systems used in credit decisions touches the DPO, the CISO, the model risk function and the business line. Where everyone is partly responsible, nobody is accountable, and this is where changes are most often dropped.

![Regulatory change arrives as prose and PDFs, never as structured data a system can consume](/assets/blog-images/regulatory-change-management-grc/regulatory-change-dashboard.jpg)

## The Pipeline

Treat regulatory change as a pipeline with defined stages, entry and exit criteria, and an owner per stage. Anything less specific degrades into a mailing list nobody reads.

### Stage 1: Source identification and monitoring

Maintain an explicit register of sources, each with a named owner and a monitoring method.

| Source category | Examples | Method |
|---|---|---|
| Primary legislation and rules | Gazette of India, ministry notifications | Automated monitoring plus legal counsel |
| Sectoral regulators | RBI, SEBI, IRDAI, TRAI as applicable | Site monitoring, regulator mailing lists |
| Government advisories | MeitY advisories and guidance | Site monitoring, industry body alerts |
| Foreign regulators with reach | EU AI Act implementing acts, EDPB guidance | Specialist feed or external counsel |
| Standards bodies | ISO, NIST, sector standards | Membership, publication alerts |
| Enforcement signals | Board and regulator orders, penalties, supervisory findings | Legal monitoring, industry networks |
| Contractual | Customer requirement changes, industry frameworks | Account and procurement teams |

The last two rows are frequently omitted and both matter. Enforcement action tells you how a regulator interprets an obligation, which is often more actionable than the text of the obligation itself. And customer contractual requirements function as regulation in practice: a large customer mandating a control gives you no more choice than a regulator does.

### Stage 2: Triage and impact assessment

Every identified change gets a rapid triage within a defined SLA - 48 hours is a workable target.

Triage answers four questions:

1. **Does it apply to us?** Entity type, sector, jurisdiction, thresholds.
2. **What is the effective date**, and is there a transition period?
3. **What is the magnitude?** New obligation, changed obligation, clarification of an existing one, or purely informational.
4. **Which domains does it touch?** Privacy, security, AI, financial, operational.

Route by outcome: not applicable is logged and closed with the reasoning recorded, because you will be asked why you did not act; informational is logged and monitored; applicable proceeds to full impact assessment.

The full assessment identifies the specific controls, policies, processes, systems and contracts affected. This is where a mapped control library changes the economics entirely - with one, you query which controls reference the affected clause and get the answer in minutes; without one, you convene a working group and take three weeks.

### Stage 3: Control mapping and gap analysis

For each affected control: does it already satisfy the new requirement, does it partially satisfy it, or is it absent?

The most common and most dangerous outcome is partial satisfaction. A control that mostly addresses a changed requirement rarely gets flagged, because the control status remains green and nothing looks broken. Explicitly record partial coverage as a gap, or it will be discovered by an auditor rather than by you.

### Stage 4: Task assignment

Convert gaps to tasks with a named individual owner, a due date derived from the effective date rather than from convenience, and a defined evidence requirement.

Two rules that determine whether this stage works. Owners are individuals, never teams - a task assigned to "Engineering" is a task assigned to nobody. And due dates work backwards from the effective date with buffer, so that the plan reveals infeasibility early rather than in the final week.

### Stage 5: Evidence of implementation

The stage most often skipped. A completed task without evidence is an assertion. Each task closes with an artefact: the updated policy version, the configuration change record, the test result, the signed contract amendment, the training completion record.

This evidence is what allows you to answer the only question that matters at audit - not "were you aware of the change" but "what did you do about it, and when."

![A pen and papers on a desk, representing structured impact assessment](/assets/blog-images/regulatory-change-management-grc/regulatory-intelligence-pipeline.jpg)

## Regulatory Owners

Assign accountability by jurisdiction and sector rather than by topic. Topic-based assignment fragments a single instrument across several owners, and each assumes another is handling it.

| Domain | Regulatory owner | Accountable for |
|---|---|---|
| India - data protection | DPO | DPDP Act and Rules, Board guidance, enforcement signals |
| India - sectoral | Compliance head for the regulated entity | RBI, SEBI or IRDAI directions as applicable |
| India - technology and AI policy | CISO | MeitY advisories, CERT-In directions, national AI guidance |
| EU - data protection | DPO or EU representative | GDPR, EDPB guidance, supervisory decisions |
| EU - AI | CISO jointly with DPO | AI Act, implementing acts, harmonised standards |
| Standards | GRC lead | ISO, NIST, sector frameworks |
| Contractual | Head of Legal | Customer requirements functioning as obligations |

Each owner is accountable for monitoring their sources, completing triage within SLA, and ensuring assessment happens. They are not accountable for implementation - that belongs to the control owner. Conflating the two produces regulatory owners who avoid identifying changes because identification creates work they must personally perform.

## An SLA Framework

Without timing commitments, regulatory change management becomes best-effort and drifts.

| Stage | SLA | Escalation |
|---|---|---|
| Detection to logging | 5 working days from publication | Regulatory owner, then GRC lead |
| Logging to triage complete | 48 hours | GRC lead |
| Triage to full impact assessment | 10 working days for applicable changes | GRC lead, then CISO or DPO |
| Assessment to tasks assigned | 5 working days | Domain owner |
| Task completion | Risk-tiered: high 30 days, medium 60, low 90 - always capped by the effective date | Control owner, then executive sponsor |
| Evidence captured | 10 working days after task completion | GRC lead |

The risk tiering should reflect consequence, not effort. A small change with a large penalty exposure outranks a large change with none.

## Board Reporting

Four things belong on the board's regulatory page:

**Open changes by status.** How many identified, in assessment, in implementation, and closed this period. The trend matters more than the count.

**Overdue actions with owner and exposure.** Named, with what the exposure is if the effective date passes unremediated. This is the page's operative content.

**Horizon view.** Changes with effective dates in the next four quarters, plotted on a timeline. Boards plan on quarters, and a timeline lets them see resourcing conflicts before they arrive.

**Posture score.** A single composite of the proportion of applicable requirements with satisfying controls and current evidence, trended over time. It is a simplification, and its value is precisely that it is comparable across periods.

What to leave off: the text of the regulations, the full change log, and anything requiring the reader to have read the underlying instrument.

## The "We Did Not Know" Defence Is Gone

There is a broader shift worth naming for the executive audience. Regulators increasingly treat awareness of published requirements as a given, and treat failure to have a process for tracking them as itself a governance failure - separate from, and sometimes more serious than, the underlying non-compliance.

The practical consequence is that the process artefact matters independently of its output. An organisation that can show a source register, dated triage records, an impact assessment and a task list with evidence is in a materially different position from one that can only show that a particular requirement was met. The first has demonstrated a system; the second has demonstrated an outcome that may have been luck.

This is why the logged-and-closed-as-not-applicable records matter, and why they should never be deleted. A reasoned, dated decision that a requirement did not apply is a defence. Silence is not.

## Conclusion

Regulatory change management fails in predictable ways: sources monitored informally by whoever remembers, impact assessed by convening a meeting rather than by querying a mapping, tasks assigned to teams instead of people, and completion recorded without evidence.

Each of those failures is structural rather than a matter of diligence, and each has a specific fix. The pipeline above is not sophisticated. It is simply explicit, and explicit is what survives the quarter when three instruments land at once.

**Actionable recommendations:**

- **Build the source register first, with a named owner per source.** Informal monitoring works until the person doing it is on leave the week something lands.
- **Assign regulatory ownership by jurisdiction, not by topic.** Topic-based assignment splits a single instrument across owners who each assume someone else has it.
- **Record partial control coverage as a gap.** A control that mostly satisfies a changed requirement stays green and gets discovered by your auditor instead of by you.
- **Derive due dates from effective dates, backwards, with buffer.** This is what makes an infeasible plan visible in month one rather than in the final week.
- **Never delete a not-applicable decision.** A dated, reasoned record of why a requirement did not apply is a defence you will eventually need.

> **Get alerted when a regulation changes, with the impact already mapped.** Monitored sources, automated triage against your control library, tasks routed to named owners, and evidence tracked to closure - so the horizon view on your board page is always current. See how [Dedups.ai](https://dedups.ai) turns regulatory change into a managed pipeline.