Documenting a Service Inventory

A service inventory is the single record of which services a firm has identified as important, why each one counts, who owns it, and what it depends on. Its purpose is practical: when a disruption occurs, when a change is proposed, or when a new owner takes over, the inventory should answer the essential questions without a search through scattered documents, old emails, or individual memory. A useful inventory entry therefore contains the service name in user terms, the users and the harm reasoning, the boundary and any sub-services, the key dependencies including outsourced parts, the named owner, and a link to the tolerance, map, and test record for that service. An inventory that contains only names is a catalogue, not a working record, and it will not support decisions under pressure.

A good entry begins with a clear service name and a one paragraph description of the user outcome, written so that a reader outside the owning team can recognise it. It then states the users, segmented where their needs differ, and the harm that disruption would cause each group, in concrete terms. It records the boundary decision, including what was deliberately left out and why, and any sub-services or shared functions the service depends on. It lists dependencies by type, people, systems, data, premises, and third parties, with enough detail to show where a single failure could block the service. It names an owner and a deputy, and it links to the tolerance, the detailed map, and the most recent test or incident learning. Each field should have a last reviewed marker, so that staleness is visible rather than hidden.

Multiple lists drift apart. A programme list, a risk list, a supplier list, and a testing list may each contain a slightly different version of the same service, with different names, different boundaries, and different owners, and no one can say which version is current. A single inventory, maintained by a named custodian and referenced by other records rather than copied into them, prevents that drift. Other documents can link to inventory entries, but they should not restate service definitions in their own words, because restatement is where divergence begins. Where a firm genuinely needs different views, such as a view by owner or by supplier, those views should be generated from the same inventory, so that a correction in one place corrects every view.

Inconsistent naming is a quiet source of resilience failure. If one team calls a service account access, another calls it digital banking, and a third calls it core banking, a disruption report, a test plan, and a supplier contract may all appear to concern different services when they concern the same one. Consistent naming, agreed once and used everywhere, allows incidents, tests, changes, and supplier events to be filed against the correct service, so that patterns become visible over time. Naming should follow the user outcome, avoid internal system names as the primary label, and distinguish services that sound similar, such as payments from an account and access to that account.

Inventories decay when they are created for a project and then left unowned, when entries are written to satisfy a review rather than to support operations, and when updates are batched into occasional overhauls instead of made at the point of change. An entry that describes a service as it was before a migration, a supplier change, or a channel closure is worse than a missing entry, because it misleads with confidence. Decay also comes from excessive detail: an inventory that tries to record every system component becomes unmaintainable and is soon ignored. The balance is to record the service, its harm reasoning, its owner, and its key dependencies at a level that can be kept current, and to link to detailed maps and system records rather than duplicating them. Regular challenge, in which owners are asked to defend or revise their entries, keeps the inventory honest.

Test an inventory by giving it to someone unfamiliar with the services and asking them to find, for a named service, its users, its harm, its owner, its dependencies, and its tolerance link, and to explain what would happen if a named dependency failed. If they cannot do that quickly, the inventory is not yet fit for use during a disruption. Test it also by tracing a recent incident or change: does the inventory show the affected service, was the entry current before the event, and did the event lead to an update afterwards? If incidents and changes leave no trace in the inventory, the inventory is a static document rather than a living record. This guide is educational only.