Regulatory Change Impact Assessment Template (With a Worked DORA Example)

A regulatory change impact assessment is the document a compliance team produces when a specific new rule lands: what the instrument is, whether it applies to you (with written reasoning either way), which functions and contracts it touches, and which owned, deadlined obligations fall out of it. Below is the full six-section template, ungated and in the page body, followed by the same template filled in end to end for Commission Delegated Regulation (EU) 2025/532, the DORA subcontracting RTS that entered into force on 22 July 2025. The discipline matters because implementation is slow: CUBE's Cost of Compliance Report 2025 (2,000+ senior compliance, risk and legal leaders, published 4 November 2025) found that 74% of firms take more than a year to implement new regulations.

The most valuable field in an impact assessment is the one templates rarely ship, the documented "no material impact" decision with written reasoning. When a supervisor asks "did you consider this instrument?", a dated out-of-scope decision with two sentences of reasoning is a defensible answer. A blank row is not.

This template lives in our trackers and templates library alongside the regulatory change tracker spreadsheet, which is the register this assessment feeds.

A regulatory impact assessment is what the regulator writes; this template is what you write when the rule lands

If you searched "how to write a regulatory impact assessment" and landed on OMB and OECD documents, you found sound guidance for a different document. A regulatory impact assessment (RIA) is a systematic appraisal a rule-maker performs before regulating: the costs and benefits of a proposed rule, per the OECD's RIA guidance and OMB Circular A-4 (the 2003 version, reinstated in February 2025 when OMB revoked the 2023 revision; OIRA summarizes its method in a primer). The European Commission's impact assessment guidance asks the same kind of questions: who is affected, how, at what cost and benefit, and whether the response is proportionate. Governments write RIAs so they regulate carefully.

A regulatory change impact assessment is the mirror-image document written by the regulated firm after a change is detected. The question is not "should this rule exist?" but "this rule exists, so what do we do about it, by when, and who owns it?" It sits between two disciplines it is often confused with: monitoring (detecting the change, covered in how compliance teams track regulatory changes) and regulatory change management, the end-to-end process this assessment is one stage of.

A complete assessment answers five questions:

1. What changed, and what is the legal status of the source?
2. Which entities, jurisdictions, products, services and activities are in scope?
3. What changes for policies, controls, systems, people and third parties?
4. Which actions are required, who owns them, and by when?
5. What evidence supports the conclusion, and what will prove the implementation was completed?

The depth should match the organization's size, complexity and risk profile. The OCC's Comptroller's Handbook on compliance management systems makes the same point about change management: its formality should be commensurate with those factors, and changes should be evaluated across every affected line of business.

Everything below is the firm-side document.

The template has six sections, and every field carries a one-line instruction

Copy the tables below into a document or spreadsheet and start filling them in this afternoon, or use the free Excel workbook (one tab per section, each holding the blank fields alongside the completed 2025/532 example). Each field carries a one-line instruction; that is the field-by-field annotation, so the worked example that follows can stand on its own.

Section 0: Document control

Section 1: Change identification

This is the section gated templates tend to skip, and it is where assessments go wrong before they start.

If the change statement cannot be completed yet, the development needs more legal research before it can be assessed.

The level and type field earns its row. Under DORA, the Level 1 obligation to manage subcontracting risk applied from 17 January 2025, while the Level 2 detail specifying how landed in July 2025 and was rejected by the Commission once in between. A template without a level field cannot represent that reality, and most of DORA's operational substance lives in Level 2. The incident-reporting clocks are one example: the initial report within four hours of classifying an incident as major and no later than 24 hours from awareness, the intermediate report within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report sit in Delegated Regulation (EU) 2025/301 of 23 October 2024, not in DORA itself. (The Commission's November 2025 Digital Omnibus proposes routing DORA incident reports through a single entry point; as of 30 September 2026 that is still a proposal in a Parliament committee.)

Section 2: Applicability screen

That last pair of fields is the defensibility artifact. Write the reasoning at the moment of decision, date it, and never delete it; dismissed changes with documented reasoning are what distinguish a triage process from a guess. "Not applicable" is not self-proving, so cite the business fact that makes it true. Use "Unknown" when a material fact is missing, and assign an owner and a date to resolve it rather than forcing a premature yes or no.

Applicability and materiality are separate decisions. A rule can legally apply and need little work because existing controls already satisfy it. Another development can impose no direct obligation and still change supervisory expectations, enforcement exposure or contract terms.

Section 3: Impact analysis

Run a functions-affected matrix, with a row for each function and columns for affected? / what changes / current-state reference:

Then check the change against eight domains, so nothing is missed: obligations and controls (created, amended, clarified or removed), products and customers, processes and operations, data and technology, policies and governance, people and training, contracts and third parties, and financial or strategic effects. Then rate the whole change:

Materiality is judged on consistent dimensions: severity if the requirement is not met, reach across entities and markets, harm to customers or the market, time available, complexity and reversibility, and the strength of existing controls. Do not let a single score replace the analysis. A High, Medium or Low label is only useful when its rationale is visible.

Section 4: Obligation breakdown

One row per discrete obligation. This is the section that turns analysis into work, and it feeds your obligations register directly (the template for that is the regulatory obligations register template).

The evidence column is the field templates most often omit. Decide at assessment time what artifact will prove each obligation is met (a revised policy, an amended contract, a filed report), or the obligation will be "done" in a status column and unprovable in an audit. The validation column names how someone other than the owner will test that the change worked, whether by sample, walk-through or control test.

Section 5: Implementation plan

The OCC handbook expects examiners to ask whether an organization reviews a change after it is implemented and whether project records, committee minutes, adopted procedures and monitoring show that the process worked as intended. The last row of that table is how you have an answer.

Section 6: Sign-off and changelog

A visible change log (date, change, source) for the assessment itself. Instruments move; the January 2025 rejection in the worked example below invalidated part of an assessment written in August 2024, and the changelog is how that shows. Keep three more things with it. Separate facts, assumptions and professional judgments, and record contrary views that shaped the decision. Add a review trigger whenever a conclusion depends on guidance that may change. And list the events that reopen the assessment: an amendment, a correction, a final text, an interpretation by a regulator or court, local implementation, a new product, a new jurisdiction, a supplier change, an acquisition, or an assumption that turns out to be wrong.

Before approval, ask eight questions. Is the source authoritative and current? Is its legal status described correctly? Have all relevant entities, jurisdictions, products and third parties been considered? Are the business facts confirmed by the people who own the activity? Does every significant conclusion have evidence? Are actions specific, owned and timed against the compliance date? Is validation defined? Are uncertainties and escalations visible?

The worked example assesses Delegated Regulation (EU) 2025/532 from an EU payment institution's compliance seat

Now the same template, completed. The scenario is hypothetical but the regulation is real: a mid-size EU payment institution (one of the 20 categories of financial entity listed in DORA Article 2(1); see EIOPA's DORA overview) whose card acquiring and processing run on ICT providers that subcontract. All regulatory facts below are as of 30 September 2026 and cite the final text on EUR-Lex: Commission Delegated Regulation (EU) 2025/532.

First, the lifecycle that makes this instrument such a good test of the template (documented on the EBA's Single Rulebook page for the RTS and, for the rejection episode, in PwC Legal's analysis):

Section 0: Document control (completed)

Section 1: Change identification (completed)

Section 2: Applicability screen (completed)

Section 3: Impact analysis (completed)

Section 4: Obligation breakdown (completed)

That last row is the knock-on most assessments miss. The register of information is already a live supervisory artifact, and your subcontracting data feeds it: the ESAs collected the first registers via competent authorities by 30 April 2025 and used them to designate the first 19 critical ICT third-party providers on 18 November 2025, including AWS, Microsoft and Google Cloud.

Section 5: Implementation plan (completed)

Section 6: Sign-off and changelog (completed)

The changelog shows that the rejected draft's Article 5 and the final regulation's Article 5 are different provisions that happen to share a number. A team working from a July 2024 summary would build a chain-monitoring program the final text does not require in that form, and might miss the notification protocol it does require, which is why the template always cites the final EUR-Lex text.

Start the assessment at final-report stage, because teams that waited for the Official Journal got 20 days

The timeline above settles the "when do we assess?" argument with arithmetic. A team that opened this assessment at the ESAs' final report (26 July 2024) had roughly twelve months of runway to the 22 July 2025 in-force date. A team that waited for OJ publication (2 July 2025) had 20 days, against a regulation with no transitional provision that requires contract changes. Set against the CUBE finding that 74% of firms take more than a year to implement a new regulation, twenty days is little more than notice.

The counterargument is "drafts change, so why assess early?" The same instrument answers it: the draft did change, materially, and the assessment survived because it carried lifecycle status and re-assessment triggers instead of pretending the rule was static. Early assessment plus a changelog beats late assessment every time; the January 2025 rejection cost the early team one paused workstream, while late teams lost the entire runway. The same logic applies to proposed rules generally. Assess a proposal when its likely effect or implementation effort justifies preparation, label it as proposed, record the uncertainty, separate preparatory actions from mandatory ones, and reassess when the final text is issued.

Catching instruments at final-report stage is a monitoring-design question. That is horizon scanning feeding change management, and the horizon scanning template covers the upstream half. For changes that span several jurisdictions, start from one common source record, then assess applicability, local implementation, deadlines and actions by jurisdiction and legal entity; one regional conclusion rarely carries over unchanged.

Five mistakes make an impact assessment worthless in front of a supervisor

1. No record of out-of-scope decisions. If your process only documents rules you act on, you cannot prove you considered the ones you dismissed. The Section 2 reasoning field is two sentences per instrument; write them.
2. Citing drafts, summaries or vendor blogs instead of the final text. The Article 5 renumbering above is the cautionary tale. Cite the CELEX number, link EUR-Lex (or the equivalent primary source), and re-base obligations when the final text lands.
3. Conflating publication, entry into force and application. DORA entered into force in January 2023 and applies from 17 January 2025; 2025/532 was published on 2 July 2025 and came into force on 22 July 2025, so each of the four date types needs its own field.
4. Inventing grace periods. 2025/532 has no transitional provision for existing contracts. The honest move is Section 5's documented interim-risk acceptance, a real decision with an owner and a review date, not an assumed one, and consistent with Article 4(2), which expects timely changes and a documented timeline.
5. Writing penalty folklore into the impact box. "DORA fines firms 1% of turnover" is wrong. DORA sets no EU-level fine tariff for financial entities, because sanctions are set at Member State level, and the periodic penalty payments in Article 35, of up to 1% of average daily worldwide turnover (Article 35(8)) for no more than six months (Article 35(7)), apply only to designated critical ICT third-party providers (as of 30 September 2026, per the DORA text).

A sixth mistake is structural: running assessments as unconnected documents. Each assessment should feed a register, the change tracker for status and the obligations register for the Section 4 rows, and your regulatory change management policy should name the assessment as a mandatory stage with the trigger defined.

The template works in a spreadsheet until volume outruns diligence

Everything above works in a spreadsheet, and if you run five assessments a year, a spreadsheet is the right tool. The template breaks down on volume: the detection lag in Section 1, the re-assessment triggers in Section 0 and the changelog discipline in Section 6 all depend on someone noticing every status change across every instrument you track, and that work does not scale by diligence.

RegWatch (my company) automates this part of the workflow, and its records line up with the template's sections. Section 1 starts from a Finding: the source URL, dates and a verbatim excerpt captured by a scheduled monitoring run. Section 2's applicability call maps to triage: each finding is scored against your company profile, accepted ones get a plain-language "Why this matters," and suppressed ones remain on the record, marked as suppressed. Each Section 4 row becomes an Obligation with an owner, an effective date and an evidence area, and the obligation's history and the audit log carry Section 6. The judgment stays human: whether a rule applies, how hard it hits, and whether the written reasoning holds.

Tooling or not, start by copying the template, picking the most recent instrument that landed on your desk, and filling in all six sections against the primary text. If Section 2's reasoning field or Section 4's evidence and validation columns feel unfamiliar, practice those first, because an examiner asks for them by name.

This article is general information, not legal advice.