Application Criticality from a BIA Guide 2026

Application criticality is a rating of how much the organization depends on a given system, expressed in terms of the business activities it supports and the impact of losing it. IT teams are often asked to recover systems in priority order, but without a clear rating, the order is decided by whoever shouts loudest during an outage. A business impact analysis provides the evidence to set it properly.

This guide explains how to derive application criticality from a business impact analysis, how to build tiers, how to set recovery targets for each, how to handle shared platforms and hidden dependencies, and how to keep the ratings current.

Why application criticality should come from the business

IT departments tend to rate systems by technical factors: size, cost, number of users or the seniority of the sponsor. None of these tells you what the business loses when a system stops. A small application used once a month for regulatory filing may matter more than a large one that supports an internal newsletter. Ratings should reflect the impact of disruption on prioritized business activities, which is exactly what the business impact analysis measures.

ISO 22301:2019 requires the analysis to identify dependencies and supporting resources for prioritized activities, and applications are among the most important of them. You can view the standard at ISO 22301:2019 on iso.org. Our guide to the ISO 22301 business impact analysis explains the full method.

From activities to applications

Start with the prioritized activities and their tolerable periods of disruption. For each, list the applications that must be available, and how much of the activity would stop if each were unavailable. The result is a mapping from activities to applications, and the application inherits the most demanding requirement of any activity that depends on it. Our guide to business impact analysis dependencies shows how to collect this mapping.

1. List prioritized activities with their maximum tolerable period of disruption.
2. Identify supporting applications for each, including databases, middleware, identity and network services.
3. Record the degree of dependence. Is the activity impossible, degraded or merely slower without the application?
4. Take the strictest requirement across the activities each application supports.
5. Assign a criticality tier using agreed rules.

Include the invisible supporting services

Most outages of critical business activities are caused not by the main application but by something beneath it: an authentication service, a message queue, a shared database, a certificate, a network link or a third-party interface. Include these in the mapping and give them a criticality at least as high as the highest application that depends on them. Our guide to single point of failure analysis explains how to find the shared elements that concentrate risk.

Building criticality tiers

Three to five tiers are enough for most organizations. Define each by the tolerable period of the activities supported and by other impact criteria, and attach recovery targets.

Tier	Definition	Typical recovery approach
Tier 1: mission critical	Supports activities whose disruption becomes unacceptable within hours	Redundancy, replication, automatic failover, frequent testing
Tier 2: business critical	Tolerable period of about a day	Warm standby, rapid restore, tested runbooks
Tier 3: important	Tolerable period of several days	Restore from backup to alternative infrastructure
Tier 4: deferrable	Can wait a week or more	Rebuild as capacity allows

The examples of time in the table are illustrative, so set boundaries that fit your own activities and agree them with the business. Give each tier a recovery time objective and a recovery point objective, following the guidance in our article on RTO and RPO, and remember that each objective must be shorter than the period the business can tolerate. The article on the maximum tolerable period of disruption covers how that limit is derived.

Handling shared platforms and hidden dependencies

Modern estates share infrastructure: virtualization clusters, container platforms, cloud accounts, storage arrays and networks. A shared platform inherits the highest tier of anything running on it, which can make it expensive to protect. Consider separating the highest-tier applications onto their own infrastructure, or investing in the platform to the standard the most critical application demands. Record the shared platforms in your mapping so that no one assumes they are protected to a lower level than the applications above them.

Suppliers and SaaS applications

Applications hosted by suppliers still have a criticality, and the same tier rules apply. Compare the supplier’s stated recovery capability and contractual commitments with the tier’s targets. If a critical software-as-a-service application has no recovery commitment, the gap should be visible in your records, and treated through contract negotiation, a fallback process or an alternative. Our guide to supplier business continuity assessment explains how to gather assurance.

Using criticality to guide investment and testing

The tier tells you how much to spend and how often to test. Tier 1 applications warrant the strongest resilience and at least annual failover tests. Lower tiers can rely on simpler approaches and less frequent testing. Use the ratings to prioritize projects, decide where to add redundancy, plan the order of recovery in a major event and brief the incident team on what comes back first.

Data and interfaces: the overlooked part of application criticality

Applications rarely operate alone. Data feeds, file transfers, application programming interfaces and batch jobs connect them, and a failure in one interface can stop a critical activity even when every application is up. Include interfaces in the mapping, and rate them alongside the applications at either end. Check also the recovery point objective across connected systems: if one application restores to midnight and its partner to noon, the two will be inconsistent, and the recovery may be unusable until data is reconciled.

Record reference data and master data in the same way. A customer or product master that feeds many systems is often more critical than any single consumer. Where such data is held in spreadsheets or in end-user tools, note it and decide whether it deserves the same protection as a formal application, since the activity depends on it all the same.

Test against the rating

Once tiers are set, test that recovery meets each one. A rating supported by no test is an assumption, and a failed test is the best possible evidence for funding a fix.

A short worked example

A utility company maps its activities to applications. Outage reporting, with a tolerable period of four hours, depends on a geographic information system, a call center platform and an identity service. All three inherit tier 1. The identity service was previously rated tier 3 because it had few direct users, but the mapping shows that eleven higher-tier applications depend on it. The rating is corrected, a standby is funded and a failover test is added to the annual plan. Billing, tolerable for three days, is rated tier 3 and remains on backup and restore.

Keeping application criticality ratings current

Applications and activities change, so ratings decay. Review them at least annually, and whenever a new application goes live, an old one is retired, a supplier changes, a business process is redesigned or an exercise or incident shows a mismatch. Make criticality a required field in your configuration management database and change process, so that every change request states the rating of the systems it affects. Assign a named owner in the business to each rating, and have them confirm it at the annual review.

Common mistakes with application criticality

Organizations rate by technical size or by sponsor seniority, mark everything as critical, ignore supporting services, fail to record shared platforms, leave supplier applications out of scope and never review the ratings. Another mistake is setting the tier without checking that current capability meets its targets. A tier 1 rating on a system that takes two days to restore is a documented gap, and it should be reported to management with a plan to close it.

Using a ready structure

If you want to avoid building the working files from scratch, the Business Impact Analysis Report and Workbook provides a structured report with impact ratings, tolerable periods and supporting resources in a working register. You can see how a completed analysis looks in our business impact analysis example. Whichever tool you use, base application criticality on business impact and review it regularly.

Application criticality FAQ

What is application criticality?

It is a rating of how much the organization depends on an application, based on the business activities it supports and the impact if it becomes unavailable.

How is it different from IT priority?

IT priority often reflects technical factors or sponsorship. Application criticality comes from business impact analysis and reflects the tolerable disruption of the activities supported.

How many tiers should I have?

Three to five tiers are enough for most organizations. Define each by the tolerable period and impact criteria, and attach recovery targets to each tier.

Do SaaS applications need a rating?

Yes. Rate them using the same rules, and compare the supplier’s recovery commitments with the tier’s targets to expose gaps.

How often should ratings be reviewed?

At least annually and after changes to systems, suppliers or business processes, or after an exercise or incident reveals a mismatch.