Technology

What is Business Resiliency?

David Edborg By David Edborg Portfolio Manager, Business Resiliency December 8, 2014

This is the first blog in a series supporting EMC’s Business Resiliency eBook. Use the menu to the right to explore the rest of the series. 

In my last blog, I introduced the framework  of a new security standard.  To be fair, I’m not simply trolling for this standard on a whim as we already have a semi-effective variation of that in ISO 27000 that’s a great first cut at the mass consumerization of a series of complex technical topics.   EMC’s Data Protection Index dives deeper into some of the major issues firms are facing.

I’m proposing a broader and more practically applicable standard that moves away from  reducing organizational risks into a series of one-dimensional focal points to a unified platform that proactively addresses enterprise-wide liabilities en masse.  Instead, we should formally address the cornucopia of organizational risks via a single function… and NO, it’s not ERM.

The stories associated with the development of different security standards or “best practices” are pretty interesting, but there’s a disturbing truth to each one – they were all preceded by a major data protection collapse that caused the public to collectively demand a better way.  Honestly, I don’t think we’ve had our catastrophe when it comes to IT failure.  But the big meltdown is fermenting.  With every “We are writing to verify whether the transaction below…” letter we get, we inch closer to the abyss that will trigger the herd to bolt for the exits.  The problem is that we’re conditioned to the noise now.  For us to notice, the scale of the next epic fail will have to exceed  our current point of reference by huge orders of magnitude.

busresiliency1Keep in mind the aforementioned next epic fail won’t be security alone.  The problem is much bigger, broader and scarier.  The root cause, we’ll discover, won’t be a single security issue, but rather a series of seemingly separate issues. No single standard exists that even comes close to helping us address these ‘separate issues’.  While the ISO series does give systemic structure and technical definition to the individual IT security, continuity and stability topics – it tends to focus only on the parameters and commonality of terms and processes.

So it’s time for a “more than just security” standard.  It’s time for a resiliency standard.  So where to begin?  Let’s start by defining business resiliency.  Business resiliency is an organization’s ability to consistently, systemically and flexibly anticipate significant interruptions and failures while fulfilling all business commitments and requirements without exception.  The primary objective: provide a systemic approach to more effective management of the cross-enterprise risks, liabilities and exposures associated with IT infrastructure.  The effort should co-opt the management of security, backup, recovery, continuity AND compliance.  It should also force us to unify our view of all the major categories of risk within the IT infrastructure domain and stop thinking about the one-off issues as minor inconveniences that both have no relationship to each other andhave no impact on the organization.  Done correctly, the standard will give us the ability to integrate all the elements that are squarely in the traditional view of risk management with those that are not, but still have the characteristics of exposure / liability that require attention.

What exactly are we currently missing?

    • The idea that security is simply one of many liability management terms centralized around IT infrastructure (think – loss elimination versus loss control)
    • The size, scale, scope and the very nature of the risks, exposures and related liabilities that exist for every organization
    • An operational connection with the control framework that is more than just a “tick the box” exercise at the end of every quarter
    • The activities needed to ensure that data protection moves from the current overly technical, jargon-filled state to a more formal, credible, business consumable discipline.

The focus needs to be simple – the resiliency standard will be built on an integrated framework, consolidated processes and decision-making support.

1) An Integrated Framework (IF)

busresiliency6The Integrated Framework is the logical relationship and conceptual requirements associated with all the moving parts in the processes, activities, reporting, communications, escalations, governance, roles and responsibilities that make up the total standard.  It should provide a simple view into how the high-level components work together – the relative relationship of the concepts.  Put simply, the framework is the pipes, wires, chassis and exoskeleton that, together, are the standard.  This part of the standard is hard to build consensus around, especially if you’re starting from scratch.  The good news is we have several different related standards that we can “barrow” from to provide the majority of the framework needed.  Let’s make sure, however, that it addresses the following:

    • It needs to tackle the intersection of centrally managed IT versus business unit ownership, the relationships of the Board of Directors with the senior leadership team(s), the relationships between the senior leadership team and middle management, and so on.
    • It should specifically require the use of an enabling technology that makes the process work more affordable and the analytics capabilities more realistic.
    • It should include a compliance and legal component that features a reporting relationship of those bodies into the owner of the framework.
    • It needs a clear, simple and easily communicated structure – conceptual parts that are designed to delineate the differences between process, activities, outcomes and function.  The structure also provides a logical view of the roles and responsibilities of the compliant organization and specifically identifies a single owner for specific activities and end products.
    • Most importantly, the structure must show, if not graphically demonstrate, the relationship between the Integrated Framework and the existing hierarchy of the organization.

2) Process, Process, Process

If the IF is the sausage casing, the processes would be the sausage.  New processes are so important in the resiliency standard, that I would say there’s no standard without them.  In this instance however, it’s not one process – it’s many.  Let’s focus on the few that are absolutely critical – the big risk / threat items for now:

    1. Identification
    2. Prioritization
    3. Reporting
    4. Actions

ao2To a fault, I think it’s the risk / threat identification processes that are both missing and needed desperately by virtually every organization.  We need a process that combines data captured at the lowest and highest levels of the organization and every tier in between.  Ideally, there’s a step that includes the act of relating all the data points captured to one another. Plus, n turn outlines a series of steps that require the layering of additional data capture from outside the organization.  All the data then becomes both the mechanism that drives the process, but also acts as the basis for predictive modeling and ongoing loss elimination.

The best way to achieve spot-level readiness is to develop functionality that requires the ability to generate actionable data at any point in time – on demand.  Inother words, get out of the “one and done” effort that matches to the annual Financial Planning and Analysis (FP&A) calendar, by  demanding that identification, prioritization and reporting be possible at any time – on demand.  The ability to then meet the formal needs of an annual, quarterly, monthly and weekly set of timing requirements is simplified.

There’s also a clear need for the collection and ongoing use of valuable external data to supplement the internal information.  I very rarely see clients using external data in a way that gives me confidence that there’s an understanding of the value in being proactive.  Therefore, I naturally find it difficult to avoid the need for the standard to establish formal processes that identify qualitatively differentiated external data sources, establish the sustainable means of collecting data from them and then incorporating that data into the prioritization process.

There is no such far-reachcing use of risk or exposure oriented calculations.  It doesn’t have to be super complex, just universally understood.

3) Tolerances, Thresholds…. DECISION MAKING

The Enterprise Risk Management (ERM) and Governance, Risk and Compliance (GRC) hacks have confused us all when describing what a threshold is and how to establish tolerances.  The confusion is not in definitions of tolerance and / or thresholds, but rather in understanding the simple need to make decisions.  To be fair, it’s also about clearly understanding when decisions need to be made.  The new standard simply has to establish a clear set of requirements as it relates to when decisions need to be made, why they need to be made and what the expected effects of the decision should be.

We need to establish a formula for risk / threat oriented decision-making.  Think  investment decision-making terms – ROI, IRR, etc. are common measures of an investment performance and, because of the uniformity in use, there’s wide-spread understanding and application of those measures.  There is no such far-reachcing use of risk or exposure oriented calculations.  It doesn’t have to be super complex, just universally understood.

With the use of metrics comes a far better ability to push the actual act of making decisions.  What is more, metrics, or commonly used metrics, tend to standardize the views of different parties.  Like the investment reference above, common metrics give us all shared reference points that are better than just one for good, two for bad… they give us the ability to understand how bad, “bad” really is.  And, the good news is that it will do this without a laundry list of “it depends” qualifiers and consultant invoices.

For anyone who’s written, read or even heard the word standard, you’ll agree – what I’ve done in this entry is the equivalent of declaring that “the big yellow one is the sun”.  YES, it’s obvious and fairly hard to argue about at the same time.  The problem is both in the details and the fundamental inability to get the right people to pay attention long enough to do something about it.  So I’ve explained, what I think, is the obvious… which is a start.  I’ve also tried to get us moving into the specific topics that are the most critical building blocks.

The next step is to add the connective tissue and develop real detail in the moving parts.  To name names, call out functions, and establish timing.  If this were a movie, it’s where the viewer is pleased that the movie is being packaged with a bow and the thinking part starts…

David Edborg

About David Edborg


Portfolio Manager, Business Resiliency

David originally joined EMC (now Dell EMC) in 2005 and is currently the Portfolio Manager for Dell EMC Business Resiliency Services. Over his career at Dell EMC, David has served as a Global Practice Manager for Availability Technologies, as an Availability Services Solutions Principal, and as the Chief Architect for EMC’s Continuous Availability Services Line.

David has over thirty years in the computer security and disaster recovery industries. Out of college David worked as an IBM Assembler coder and wrote operating system mods for ACF2/VM; the first ever security product for IBM’s Virtual Machine OS. He has worked with other vendors and partners in the DR industry, including supporting recoveries from the 9/11 event. David has also worked in the packaged software industry as Director of Development and Support for a computer security product.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *