How do you identify your critical business services?
The short answer
Identify critical business services by starting from who you serve and how fast a disruption harms them, then following the dependencies. A service is critical when its disruption causes intolerable harm to customers, the market or the organization within a short time. Shared dependencies show where one failure hits several critical services at once.
Why asking everyone doesn't work
A few years ago we were building business continuity for a hospital. In the first week, the client stopped us: "You can't run around asking everyone what's important. We need to find the truly critical things faster."
He was right. Every ward could argue that people die if it stops. Interviews produce opinions, and every opinion says "critical." The classic business impact analysis has the same problem at scale. Questionnaires go out to every department, come back weeks later, and rate most activities as critical.
So we changed the approach. We read criticality from structure: what each service runs on, where dependencies concentrate, and where one failure travels furthest. The ranked list came fast. It also left us with one thought: there must be a better way to do this.
Start from the people you serve
Criticality is judged from the outside in. Write down who you serve, in your own words: customers, patients, policyholders, members, partners. Then pick one or two impact dimensions that matter most to your organization, such as patient safety, customer payments, financial stability or reputation.
For each service that delivers to those people, ask three questions:
- Who stops being served if it goes down?
- How quickly does that harm become intolerable?
- Which obligations start: contracts, SLAs, reporting to a regulator?
Regulators use their own labels for the result. The UK rules talk about important business services, DORA about critical or important functions, NIS2 sorts organizations into essential and important entities. The method behind all of them is the same.
Let dependencies do the ranking
Follow each service down to what it runs on: applications, infrastructure, people, sites, suppliers and data. Two signals matter most. Speed: how fast harm builds once the service stops. Concentration: how many critical services share the same dependency.
Here is a simplified example from a hospital:
The patient record and the identity service sit under almost everything. That is where one failure does the most damage, and where preparation pays off first.
Use the data you already have
You don't need a new questionnaire. Application lists, CMDB exports, process maps, supplier lists and earlier business impact analyses already hold most of the picture. We have even used tax reports as a source.
Some of it will be incomplete or out of date. Record assumptions as gaps instead of treating them as facts. Then put a drafted picture in front of the people who run each service. They correct a draft in minutes. A blank form takes them weeks.
Keep the list current
Criticality changes with the business. A new product, a new major supplier or a cloud migration moves the picture. Review the list whenever one of those happens, and do a full review once a year.
A practical way to begin
- Write down who you serve, in your own words.
- Pick one or two impact dimensions that matter most, such as patient safety or customer payments.
- List the services that deliver to those people, and estimate how fast harm becomes intolerable for each.
- Map the main dependencies from the records you already have, and mark where they overlap.
- Validate the top of the list with the people who run those services, and record what is still unknown.
The first version will be rough. It will still be more useful than a questionnaire nobody returns.
How we do this in resimate
This is the work that started resimate. resimate imports your application lists, CMDB exports and process maps, links them into one connected view, and ranks services by impact. Labels such as "critical" or a regulation inherit down the chain, so every asset behind a critical service is visible, including the ones nobody listed. Acorn Life had its first dependency map in two weeks. Teams go live in 4 to 6 weeks.