Reviewing Important Services After Change

Reviewing important services after change means asking, whenever something material changes, whether the service list still describes the firm as it now operates. A new product can create a new service, a channel closure can remove the alternative that made a service less important, a migration can change dependencies, a supplier change can introduce a new point of failure, and an incident can reveal harm through a service that was not on the list at all. Review is therefore not a calendar exercise alone, although a periodic review has value as a backstop. It is a discipline tied to change: the service list, the harm reasoning, the boundaries, and the tolerances are revisited at the point where the change is planned, so that the revised understanding is in place before the change goes live, not reconstructed after a disruption exposes the gap.

Change that triggers review includes new or withdrawn products and channels, changes in customer groups or in how customers use a service, migrations to new platforms or data stores, supplier and outsourcing changes, reorganisations that move ownership, mergers and acquisitions, and changes in the wider environment, such as the closure of a widely used alternative or a shift in market structure. Incidents and tests are triggers too, and often the most informative ones, because they show how harm actually travelled rather than how it was predicted to travel. Cumulative change is a common blind spot: each step looks small, while the service at the end bears little resemblance to the service originally identified.

A review asks a short set of questions in order. Has a new service been created, or has an existing service split or merged? Have the users changed, or has their vulnerability, urgency, or ability to find an alternative changed? Has the harm profile changed, because the service is now used for a more critical purpose, at a more sensitive time, or by more people at once? Have dependencies changed, including new suppliers, new shared functions, or new concentrations of risk? Do the boundary, the owner, the tolerance, and the test plan still fit the service as it now stands? If any answer is yes, the inventory entry, the map, and where necessary the tolerance should be updated, with the change and its reason recorded. If every answer is no, that conclusion should also be recorded briefly, so that the review leaves evidence rather than merely a meeting note.

Review should happen early enough to influence the change, not after the change has been implemented and the old service picture has already become misleading. At the planning stage, the service owner and the change owner together can assess whether the change creates, removes, or reshapes a service, and can plan mapping, tolerance, and testing updates alongside the technical work. During implementation, the review should be revisited if the change evolves, since planned migrations and supplier transitions rarely proceed exactly as first described. After implementation, a short confirmation review checks that the service operates as expected, that the inventory reflects the new state, and that any temporary workarounds introduced during the change have been removed or properly recorded. Tying review to change governance in this way makes it part of ordinary delivery rather than an additional burden imposed afterwards.

Weak review produces a service list that describes a former firm. Tolerances are set for services that no longer exist in that form, maps trace dependencies that have been replaced, and tests rehearse scenarios for an architecture that has moved on. The firm may appear well prepared on paper while being unprepared for the services it actually operates. Another failure is review without decision: a change is noted, a workshop is held, and no entry is updated, no owner is changed, and no tolerance is revised, so the review leaves no trace in the record that matters. Good review is willing to conclude that a service is no longer important, with reasons, just as it is willing to add a service that has become important.

Evidence of review is found in the inventory itself: updated entries with reasons, dated decisions about services added, removed, split, or merged, revised harm reasoning where users or dependencies changed, and links to updated maps and test plans. A reviewer should be able to pick a material change from the recent past and trace it through to the service list, seeing what was considered, what was decided, and what changed as a result. If that trace cannot be made, review after change has not yet become a working discipline, whatever the policy says. This guide is educational only, and it does not advise any particular firm; DORA applies from 17 January 2025 in the EU, with the UK regime labelled separately.