Map business services and risk context

A risk analysis need not begin with a software inventory. Begin with the promise the organization makes to a customer and what must keep working to fulfill it. Suppose a delivery company promises a parcel status update within an hour. The service depends on the customer application, a carrier interface, an order database, and a messaging provider. A message outage may delay notice without stopping a parcel. Corruption of the order database may misdirect the parcel itself. “The system is critical” is too imprecise for a decision. Trace the service and distinguish loss of availability from loss of data integrity or confidentiality.

Ask the service owner to describe the business outcome to protect, not merely server names. Sketch a flow: customer order to order database to carrier interface to status update to customer notice. For each connection, record its owner, a way to verify it, and an alternative if one exists. Identify where data cross into another organization, who can alter them, and whether a shared component can interrupt several services at once. This map is a decision aid, not a claim that the asset inventory is complete. NIST CSF 2.0's Identify function helps an organization understand assets and risks, while Govern connects that understanding to objectives, roles, and risk strategy.

Agree on impact criteria before reading a colored risk matrix. For the hypothetical company, “high” impact might mean inability to route more than 20% of a working day's parcels or loss of delivery-address integrity. “Medium” might mean a status notice delayed over two hours without data loss. “Low” might mean an internal report that can be recovered the next day. These thresholds belong to the company in the case; NIST does not prescribe those numbers. Record their basis: transaction volumes, service commitments, the service owner's experience, and budget constraints. If marketing and operations disagree about the effect of a delay, retain the disagreement as uncertainty instead of hiding it in an average score.

The output is a service map with linked rows. “Status update” depends on the carrier interface and order database. “Reschedule delivery” depends on the customer notice and response channel. “Confirm delivery” depends on driver data and the carrier interface. Each row states availability and integrity consequences, evidence for the dependency, and the owner who can confirm it. Mark backup effectiveness unresolved until a current test exists. If switchover succeeds and customers can reschedule by email at an acceptable rate, investment in a second messaging provider becomes less urgent. If it fails, that investment rises in priority. Neither result changes the separate risk of address corruption in the order database. Separating the scenarios avoids treating the wrong problem.

A map used for analysis is not a permanent truth. A new feature or changed carrier interface can alter dependencies. Name who reviews the map after a significant architecture change. In interviews, establish the normal route and then break one assumption at a time: what happens if notices fail while orders remain intact? What happens if a valid notice reaches the wrong address? These questions reveal distinct consequences of confidentiality, integrity, and availability. They are not interchangeable components of a single “criticality” number. When several services share the same identity provider or database, show that common dependency explicitly, since separate service lists can conceal concentrated exposure.

Add an evidence-confidence column to the working map, but define its labels. High confidence might mean a route was observed in configuration, tested recently, and logged as working. Medium confidence might mean a recent design record without an operating test. Low confidence might mean a verbal account or an old document. These labels are not statistical probabilities. They describe how much the available evidence can support a provisional decision. If interruption would be severe but confidence in a backup is low, testing may be more valuable than buying another tool immediately. A cheap, short test might show that another provider is unnecessary. If the test cannot finish before a binding decision, write a conditional recommendation and contingency, and name who will reopen the decision when evidence arrives. Uncertainty then drives the next action rather than sitting as a vague disclaimer.