Business Criticality

[snowuser5]

Curious how others are defining Business Criticality, on the Business Application form, and each of the values: Critical, High, Medium, Low   Who typically owns that field and can provide the appropriate value?  How do they determine which value?

[Jeff Aldrich]

Following...as we are struggling with this as well.  I'm interested in how others are approaching this!

We have multiple definitions of "Business Criticality" in use, most defined from a particular, myopic perspective.  For instance, our Integrated Network Operations Center uses their own definition for setting priority on Incidents and defining response levels.  Our Disaster Recovery team uses a different definition for defining recovery objectives.  They don't align.

Ideally, I would like to see a common definition of Business Criticality that has encompasses various dimensions, including Availability targets, recoverability requirements, operational service levels and such.  I think the optimal solution is that the assignment of Business Criticality is based on Business Impact Analyses done by our Business Continuity team.  Once the BIA determines the criticality of Business Capabilities and/or Business Processes, we should, via relationships, be able to determine the criticality of the underlying Business Applications and other technology.  We are a long way from there...

[Zach Allen1]

We have recently had these discussions within the business in conjunction with our Cloud management team and Enterprise Architecture. Here is what we landed on:

Criticality definitions are based on an application's impact on revenue and two important parameters: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

• RTO stands for Recovery Time Objective and is a measure of how quickly after an outage an application must be available again.  

• RPO, or Recovery Point Objective, refers to how much data loss your application can tolerate.  

Criticality definitions: 

• Critical: Applications that have a DIRECT impact on revenue, where even a short outage or data loss can result in stoppage of manufacturing of products, and the ability to trade or deliver software. These applications have a short RTO (< 2 hours) and a near-zero RPO (< 0.5 hours). 

• High: Applications with an INDIRECT impact on revenue, where an outage or data loss can cause significant ability to make product(s). These applications typically have a relatively short RTO (< 8 hours) and RPO (4 hours). 

• Medium: Applications with a MODERATE impact on revenue, where an outage or data loss may affect organizational efficiency. These applications typically have a moderate RTO (< 4 days) and RPO (8 hours), allowing for a slightly longer recovery time. 

• Low: Applications with a MINOR impact on revenue, where an outage or data loss may affect individual performance. These applications typically have a longer RTO (best effort) and RPO (best effort), as the urgency of recovery is not as high as critical or high applications.

Hope this helps. Typically, we rely on our IT Application Owner to define the correct criticality based on the definitions above.