Organisations rarely fail a regulation because they disagree with it; they fail because nobody noticed the change in time, nobody owned it, or nobody could prove the control was in place on the date it applied. Security and compliance teams now face a steady flow of new and amended obligations: DORA, NIS2 and its national laws, the PCI DSS v4.0.1 requirements that became mandatory on 31 March 2025, AI regulation, disclosure rules and sector guidance. Regulatory change management is the repeatable process that turns that flow into owned, tested and evidenced controls. This guide sets out a vendor-neutral operating model: horizon scanning, an obligations register, impact assessment, ownership, implementation and evidence, with metrics and failure patterns. It is written for GRC leads, CISOs and compliance officers, and it describes process, not the content of any particular law.
Key takeaways
- Treat change as a pipeline, not an inbox. Every regulatory item should move through the same stages, from detection to evidenced closure, with a status and an owner at every step.
- The obligations register is the system of record. Break each law or standard into individual, testable obligations and map each one to a control, a policy and an owner.
- Impact assessment decides effort. A quick triage within days, followed by a structured assessment for anything material, stops teams either ignoring change or over-reacting to consultations.
- Effective dates are deadlines for evidence, not for starting work. Controls must be operating, and producing records, on the day an obligation applies.
- Regulators expect demonstrable process. The FCA requires policies and procedures sufficient to ensure compliance, and DORA requires the ICT risk management framework to be reviewed at least yearly and after major incidents. A register with audit trails is how you show it.
What regulatory change management covers
Regulatory change management (RCM) sits between legal, compliance, risk, security and the business. Legal interprets; RCM makes sure the interpretation becomes work that is done and proven. In scope are laws and regulations, supervisory guidance and statements, industry standards that are contractually mandatory (PCI DSS is the usual example), and changes to existing obligations such as revised technical standards or a new SAQ version. Contractual security clauses from major customers are often run through the same process because they behave like regulation.
| Stage | Question answered | Output | Typical owner |
|---|---|---|---|
| 1. Horizon scanning | What is changing, and when? | Logged change item with source and dates | Compliance or GRC team |
| 2. Triage | Does it apply to us at all? | Applicable, not applicable (with reason) or monitor | Compliance with legal input |
| 3. Interpretation | What exactly must we do? | Discrete obligations in the register | Legal and compliance |
| 4. Impact assessment | What changes in our controls, systems, policies and contracts? | Gap list, effort estimate, risk rating | Accountable business and control owners |
| 5. Implementation | Who builds what, by when? | Funded plan, tickets, policy updates | Control owners, change management |
| 6. Evidence and attestation | Can we prove it on the effective date? | Test results, records, sign-off | Control owners, second line review |
| 7. Monitoring | Is it still working, and has anything changed again? | Control test schedule, register updates | Second and third line |
Horizon scanning: sources and triage
Horizon scanning is the detection control of RCM. It fails quietly: the cost of a missed change appears months later in an audit or a supervisory letter. Build it from named sources with named owners rather than relying on newsletters.
| Source type | Examples | What it gives you | Check frequency |
|---|---|---|---|
| Official journals and legislation databases | EUR-Lex, legislation.gov.uk, Federal Register | Final legal text, publication and application dates | Weekly |
| Regulator pipelines | UK Regulatory Initiatives Grid (published twice a year by the Financial Services Regulatory Initiatives Forum, covering a 24-month pipeline) | Planned initiatives with lead authority, milestones and indicative impact | Each edition |
| Regulator publications | Consultation papers, policy statements, supervisory statements, "Dear CEO" letters, regulator newsletters such as the FCA Regulation Round-up | Proposals before they are final, and how supervisors read existing rules | Weekly |
| Standards bodies | PCI SSC document library, ISO, NIST, ENISA | New versions, retirement dates, FAQs that change interpretation | Monthly |
| Enforcement and case outcomes | Final notices, fines, court rulings | Where regulators are focusing, and what "adequate" means in practice | Monthly |
| Commercial and peer channels | Regulatory intelligence feeds, law firm briefings, industry associations | Summaries and early warning; always confirm against the official text | Continuous |
Triage each item within a fixed service level, for example five working days, into one of three outcomes:
- Applicable: the change applies to a legal entity, product, jurisdiction or service you operate. It goes to interpretation.
- Monitor: a consultation or proposal that may apply. Record the expected next milestone and set a review date. The FCA notes that Grid timings can change, which is exactly why "monitor" items need dates.
- Not applicable: record the reason. An auditor or regulator may later ask why you decided a rule did not apply, and "we didn't look" is not an answer.
Watch for changes that alter dates or status rather than content. NIS2 had a transposition deadline of 17 October 2024 and repealed NIS1 from 18 October 2024, but national laws arrived at different times, and the European Commission's NIS2 page now also refers to targeted amendments in 2026. PCI DSS v4.0 was retired on 31 December 2024 in favour of v4.0.1, a limited revision that did not move the 31 March 2025 effective date. Each of these is a register update even when your controls do not change. See the NIS2 Directive Guide and the PCI DSS 4.0 Guide.
The obligations register
The register turns long legal texts into units that can be owned and tested. One article of a regulation may produce several obligations; one control may satisfy obligations from several regulations. That many-to-many relationship is the reason spreadsheets break down once you cover more than a handful of regimes.
| Field | Purpose | Example |
|---|---|---|
| Obligation ID and source citation | Traceability to the exact clause | DORA Art. 6(5); PCI DSS 8.4.2; FCA SYSC 6.1.1R |
| Plain-language statement | What must be true, in testable terms | "ICT risk framework is documented and reviewed at least once a year" |
| Applicability | Entities, products, jurisdictions in scope | EU-regulated subsidiaries only |
| Key dates | Publication, entry into force, application, transition end | Applies from [date]; transition ends [date] |
| Accountable owner | One named executive | [Chief Risk Officer] |
| Mapped controls and policies | Links to the control library and policy set | Control GOV-07; Information Security Policy section 4 |
| Evidence required | What proves it, how often | Signed annual review minutes; review report available on request |
| Status and residual risk | Compliant, gap, in remediation, risk accepted | Gap: due [date]; risk ID R-112 |
| Change history | Who changed what, when and why | Version, approver, date |
- Link to a common control set: map obligations to your own control library rather than to each other. A control such as "MFA for administrative and remote access" can then satisfy PCI DSS, NIS2 measures and customer contracts at once. See the Control Mapping Guide.
- Keep interpretation separate from text: store the legal text, the interpretation and who approved the interpretation. When a regulator later clarifies a rule, you can see which decisions to revisit.
- Record overlaps deliberately: where two regimes apply to the same entity, as DORA and NIS2 can, record which is treated as the lead. See the DORA and NIS2 Overlap Mapping Guide.
Impact assessment and ownership
Impact assessment answers "what changes for us?" across five dimensions. Score each one so that effort and priority are comparable across items.
- Controls and technology: new or changed technical controls, for example extending MFA from administrators to all access into a cardholder data environment, or adding payment page script monitoring.
- Policies and procedures: documents to update and re-approve. See the Policy Lifecycle Management Guide.
- Third parties and contracts: clauses, assessments and exit plans that need changing. DORA-style ICT third-party requirements frequently land here. See the Third-Party Risk Management Guide.
- Reporting and governance: new board reporting, regulatory returns or incident notification timelines.
- People: training, new roles and changes to accountability.
Ownership needs three distinct roles per item, recorded in the register:
| Role | Responsibility | Common mistake |
|---|---|---|
| Accountable executive | Owns the outcome and signs off readiness | Assigning a committee instead of a person |
| Change lead | Runs the plan, chases dependencies, reports status | Leaving it with compliance, who cannot change systems |
| Control owners | Implement and operate each mapped control and produce evidence | Not told until weeks before the effective date |
| Second line (compliance, risk) | Challenges interpretation and verifies evidence | Marking its own homework by also implementing |
Escalate when an item is rated high impact, when the effective date is less than [six] months away and the plan is not funded, or when the business wants to accept non-compliance. Risk acceptance for a legal obligation should be rare, approved at executive level and recorded in the risk register. See the Risk Register Template.
Implementation and evidence
Run material changes as projects with a dated plan working backwards from the effective date.
- Confirm the final text and dates from the official source, not a summary. Record publication, entry into force and application dates separately; they are often different.
- Write the obligations into the register with interpretations approved by legal or compliance.
- Run the gap assessment against mapped controls and agree the plan, budget and owners.
- Pilot technical changes in audit or alert-only mode first, for example log-only enforcement of a new access policy, with a documented rollback, before enforcing across production.
- Update policies and procedures and train the people affected.
- Produce evidence before the deadline: aim for controls operating at least one reporting cycle before the effective date, so the first evidence set exists on day one. Requirements that need a period of records (quarterly scans, six-monthly reviews) need the longest lead time.
- Second-line verification samples the evidence and records the result, then the accountable executive signs off.
- Move to business as usual: add the controls to the testing calendar and close the change item. See the Audit Evidence and Continuous Controls Monitoring Guide and the Compliance Calendar Template.
Evidence should be dated, attributable and reproducible: system exports with timestamps, signed review minutes, ticket histories and test results. Screenshots taken on the day of an audit prove little about the period before it. DORA, for example, expects the ICT risk management framework to be reviewed at least once a year and after major ICT-related incidents, and a report on that review to be available to the competent authority on request; that is an evidence obligation as much as a control obligation.
Where identity fits
Many recent obligations are, in practice, identity controls: MFA scope in PCI DSS 8.4.2, protection of system and application account credentials in PCI DSS 8.6, and access control and authentication measures in NIS2 and DORA. When these change, the work lands on IAM and PAM teams and often on non-human identities such as service accounts and API keys that were never in a review cycle. Include the IAM owner in impact assessments by default. See the Identity Security Regulatory Map.
Choosing an operating model
| Approach | Fits | Trade-offs |
|---|---|---|
| Spreadsheet register with manual scanning | Single jurisdiction, few regimes, small team | Cheap and quick; weak audit trail, breaks with many-to-many mappings and staff turnover |
| GRC platform register with manual scanning | Mid-sized, several regimes, existing control library | Good traceability and workflow; scanning quality still depends on people |
| GRC platform plus regulatory intelligence feed | Multi-jurisdiction, regulated financial services | Broad coverage and early warning; feed summaries must still be checked against official text, and volume needs strict triage |
| Outsourced monitoring with internal ownership | Lean teams in heavily regulated niches | Expert coverage; accountability cannot be outsourced, and the provider becomes a third-party risk |
- Small organisations: a named owner, a short list of official sources checked on a calendar, and a register with the core fields above is enough. The discipline matters more than the tool.
- Large or multi-entity organisations: need a common control library, entity-level applicability, workflow with service levels, and reporting to a risk or compliance committee. See the GRC Platform Buyer's Guide and the Compliance Automation Guide.
- Regulated financial firms: expect supervisors to ask how change is identified and governed. Under FCA SYSC 6.1.3R, firms in scope must have a permanent and effective compliance function that monitors and regularly assesses whether their compliance measures work and advises those carrying out regulated activities.
Detection and measurement
Log every register change, triage decision and approval with user and timestamp. Report these metrics monthly to the owning committee:
- Triage time: median days from publication to triage decision; target within your service level, for example five working days.
- Overdue items: number of applicable items past an internal milestone, by impact rating.
- Ready by effective date: percentage of obligations with controls operating and evidence verified on or before the application date; target 100%.
- Unowned obligations: register entries without a named accountable owner or mapped control; target zero.
- Late discoveries: changes first identified less than [three] months before application, or by an auditor or regulator rather than by scanning. Each one is a scanning failure to review.
- Risk acceptances: open acceptances against legal obligations and their expiry dates.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Legal, regulatory and contractual cybersecurity requirements are understood and managed |
| NIST CSF 2.0 | GV.PO-02 | Policy is reviewed and updated to reflect changes in requirements |
| NIST CSF 2.0 | GV.OV-02, ID.IM-01 | Strategy adjusted for new requirements; improvements identified from evaluations |
| NIST SP 800-53 Rev. 5 | PL-1, PM-9, PM-28, CA-7 | Policy and procedures, risk management strategy, risk framing, continuous monitoring |
| ISO/IEC 27001:2022 Annex A | 5.31, 5.36 | Identification of legal, statutory, regulatory and contractual requirements; compliance with policies and standards |
| ISO 37301:2021 | Compliance management system | Whole-system standard for managing compliance obligations; replaced ISO 19600:2014 |
| DORA (Regulation (EU) 2022/2554) | Art. 6(5) | Annual and event-driven review of the ICT risk management framework |
| FCA Handbook | SYSC 6.1.1R to 6.1.3R | Adequate compliance policies and procedures; compliance function duties |
Common failure patterns
- Scanning without triage: a feed produces hundreds of items a month, nobody records decisions, and the material change is lost in the noise. Fix with a triage service level and mandatory outcome.
- Waiting for final text: teams ignore consultations, then have months rather than years to implement. Use the "monitor" status and regulator pipelines such as the Regulatory Initiatives Grid to start sizing work early.
- Compliance owns delivery: the compliance team logs the change but cannot change systems or budgets, so nothing moves. Name an accountable business executive and control owners for every applicable item.
- Effective date treated as start date: the PCI DSS requirements that became mandatory on 31 March 2025 were best practice for years beforehand, yet many entities still lacked a full period of evidence, for example for payment page script monitoring under 11.6.1.
- Register drifts from reality: controls change, owners leave, and the register is updated only before audits. Review owner assignments quarterly and link the register to the control testing calendar.
- Relying on summaries: a secondary article or feed misstates a date or scope, and the organisation plans against it. Every obligation should cite the official text that was read.
Practitioner checklist
- Name an accountable owner for the RCM process and publish the procedure.
- List the official sources for every jurisdiction and regime you operate in, each with a reviewer and frequency.
- Set a triage service level and record a reasoned outcome for every item, including "not applicable".
- Build or clean the obligations register with clause citations, applicability, dates, owners, mapped controls and evidence.
- Map obligations to a common control library, not to each other.
- Include IAM, third-party risk and legal in every material impact assessment.
- Plan backwards from the application date so controls produce evidence before it.
- Have the second line verify evidence and the accountable executive sign off readiness.
- Report triage time, overdue items, readiness by effective date and late discoveries monthly.
- Review the process itself at least annually and after any late discovery.
Standards and references
- FCA Handbook: SYSC 6.1 Compliance
- FCA: Regulatory Initiatives Grid
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- European Commission: NIS2 Directive
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- ISO: ISO 37301:2021 Compliance management systems
- PCI SSC: Just Published, PCI DSS v4.0.1
This guide summarises regulatory expectations for managing regulatory change and is not legal advice. Related NHI Mgmt Group resources: Policy Lifecycle Management Guide · Compliance Automation Guide · Global Cybersecurity Regulatory Map · DORA Guide · PCI DSS Readiness Checklist