Resilience as a business continuity mindset

By Gary Hinson and Dejan Kosutic.

Executive summary

Most business continuity experts from an IT background are primarily, if not exclusively, concerned with establishing the ability to recover failed IT services after a serious incident or disaster. While disaster recovery is a necessary part of business continuity, this article promotes the strategic business value of resilience: a more proactive and holistic approach for preparing not only IT services, but also other business processes before an incident in order that an organization will survive incidents that would otherwise have taken it down, and so keep the business operating in some form during and following an incident. 

Introduction

According to the BSI Standard 100-4 (2009), “Business continuity management consists of a planned and organized procedure for sustainably increasing the resilience of (time-)critical business processes of an organization, reacting appropriately to events resulting in damages, and enabling the resumption of business activities as quickly as possible. The goal of business continuity management is to ensure that important business processes are only interrupted temporarily or not interrupted at all, even in critical situations, and to ensure the economic existence of the organization even after incurring serious damage.”

Is business continuity important enough to invest time, effort, and money into achieving it? Given that the alternative implies accepting the risk that the business will quite likely fold in a crisis, few in management would seriously argue against business continuity, but that still leaves the questions of how much to invest, and how to invest wisely. These are strategic issues: business continuity is a strategic concern.

Strategic approaches to business continuity

Information security is largely concerned with avoiding or preventing incidents, primarily through preventive controls. As a strategy, it clearly makes sense to invest in avoiding or preventing incidents wherever possible. In practice, however, we know only too well that despite our best intentions, incidents are inevitable due to errors in the risk management (risk assessment and risk treatment) processes. “Avoid/prevent information security incidents,” per se, is therefore a relatively risky or fragile strategy.

Incident management is normally an integral part of information security risk management, and with good reason: proactively managing the identification/notification, containment and resolution of incidents makes the associated processes more effective and efficient, and most organizations “learn the lessons” from incidents by improving their information security arrangements. (The truly clever ones don’t merely learn from their own incidents, but from those affecting others: gain without the pain!)

A resilience strategy takes the approach a step further by deliberately engineering the organization (its operations, workforce, IT systems, networks, business relationships and so on) to be inherently strong and reliable: dependable, even. A resilient organization can shrug off various incidents that might otherwise have interfered with or interrupted vital business activities, keeping operations running without a noticeable break in service. 

Failover, load-sharing, dual-live and mirroring arrangements in general illustrate the resilience concept in action. A well-engineered, high-volume retail website, for instance, will be configured to maintain 24x7 service even though the individual systems and network components may be overloaded, attacked, fail, or be taken out of service for backups, maintenance, and upgrades. Distributing the web traffic across physically diverse data centers that share the front-end load and synchronize the back-end database reduces the reliance on the component parts and increases resilience.

Note the implications of a strong resilience strategy that (a) incidents will indeed occur, despite the avoidance and preventive actions (we still need those!), but (b) they should have a negligible or limited effect on operations due to the resilience measures: a significant and potentially mistaken presumption. What if an information security incident turns out to be unexpectedly serious, perhaps catching us at a really bad time, coming at us from an unanticipated angle, or being far more severe than we thought? We cannot totally guarantee that we are sufficiently resilient to negate all possible incidents. A resilience strategy therefore also implies (c) a level of assurance or confidence that the resilience arrangements are sound, implying the need for checks and tests under the umbrella of suitable governance, and (d) we will still need business resumption and contingency arrangements just in case incidents push our resilience past its breaking point.

Crisis and disaster management involve someone suitable taking charge of things during a crisis, serious incident, or disaster, bringing order to chaos and initiating the recovery activities in particular. In such a high-pressure situation, the crisis/incident/disaster managers are anticipated to take stock of what has happened, marshal the available resources, and lead the activities necessary to recover or resume business operations. Crisis and disaster management can be viewed as extensions of incident management. However, conventional incident management activities are designed to deal with individual, relatively small-scale incidents, and are well-practiced due to the routine nature of incidents. A major incident involving multiple, very serious events requires a step change in the management processes, better coordination, and strong leadership. The infrequency of major incidents also means that the associated management activities are not routinely practiced; hence, additional planning and exercises are needed.

Disaster Recovery (DR) or business resumption planning (BRP) starts with the presumption that business processes and systems have somehow been disrupted. Perhaps the organization was not sufficiently resilient to escape the specific situation that occurred (for instance, a supply chain failure that was totally out of its control and for which there were no viable alternative sources of supply), or maybe the resilience measures turned out to be inadequate in practice (perhaps the incident was more severe than anticipated, or perhaps the resilience measures simply failed when called upon: it happens!). It could also be that the incident was totally unexpected and caught the organization unprepared: in other words, the risk analysis did not identify the possibility.

Contingency management works on the assumption that “something else happens”; in other words, for some reason the controls have failed to avoid or prevent an incident, and the resilience and recovery measures have not catered adequately for the specific circumstances, perhaps because:

• the situation genuinely could not have been predicted: it is so novel that nobody could possibly have known it was coming;
• the situation was predictable, but for some reason we failed to predict it (maybe we just missed the signs of impending doom, or we each thought someone else was dealing with it);
• the situation was predicted, but we failed to control adequately against it (the control measures didn’t go far enough); or
• we had “bad luck”; in other words, we suffered an unfortunate coincidence involving one or more causes, happening at the worst possible time.

Whereas actual planning may not be sensible given the literally infinite array of possible situations, achieving a general state of readiness is a different matter. Workers’ willingness and latitude to “just get on with it,” even without precise instructions and a direct command, is at least as valuable as the detailed plans, particularly, of course, in situations that were not anticipated. Well-managed organizations (by which we mean those whose managers have the right mindset to take information security, business continuity, and resilience seriously) are capable of reacting efficiently and effectively to more or less any situation that occurs. Since there are simply too many possibilities to plan and prepare for them all individually, it may be better to build a more generalized capability sometimes known as survivability. The capability, willingness and determination, flexibility, and resourcefulness to deal with virtually any challenge could itself convey competitive advantage, and not only under disaster conditions, since challenges and surprises are an inherent part of business life. It might even be considered a strategic goal in its own right… and of course it implies the need for management to assign sufficient resources and direct them appropriately. A flexible, can-do attitude might conceivably become part of the boilerplate text on corporate vacancy notices.

Practical advice on resilience from ISO 22301

ISO 22301:2012, the leading business continuity management standard, stresses both the strategic importance of business continuity, and resilience as a key lever to ensure the continuity of operations under adverse conditions (Kosutic, 2013). The standard puts great emphasis on participation of top management in managing business continuity: from defining the general objectives, assigning the required roles and responsibilities, and providing required financial, human, technical and other resources, all the way to making crucial decisions and handling the stakeholders.

But one requirement of the standard stands out: top management has to ensure that the business continuity management system “...is compatible with the strategic direction of the organization” (ISO 22301:2012, clause 5.2). This means that business continuity cannot exist as an isolated practice within the organization, totally divorced from its business; quite the contrary, business continuity must support the achievement of business goals. For example, in companies whose success depends on their availability (e.g., cloud service providers), business continuity has to be an integral part of both the strategic direction and the routine operations.

The plans and arrangements will be wasted if the strategic approach is not taken to heart. For example: business impact analysis may be superficial, perhaps only covering particular business or support functions, or inconsistent; risks may be deliberately underplayed and ignored (inappropriately accepted) simply in order to avoid investing in the corresponding controls; investment in high-availability systems, redundant sources of critical supplies, etc. may be unduly limited or deferred indefinitely; lacking adequate resources and prioritization, plans may be unworkable; and, if management is so inclined, it is easy for them to pay lip service to testing and exercising, such as insisting that very limited tests are performed, at off-peak times, with barely a token effort to confirm that recovered systems are fully functional. This is why ISO 22301 goes further still:

• Top management must undertake a very active role – not only by conducting the activities already mentioned, but also by communicating the purpose and importance of business continuity. Unless they do so, the old paradigm “We can’t do anything if some big disaster occurs” will never change.
• The organization must figure out who are the interested parties related to business continuity, and what is expected by them and of them. For instance, if top management knew their legal obligations better, they might invest more willingly in business continuity, while if employees knew how their local communities depended on them, their response to incidents might be more effective.
• The organization must develop a comprehensive business continuity strategy based on the results of business impact analysis in order to (a) select appropriate continuity options (for example, recovering failed systems within their recovery time objectives RTOs), (b) secure the necessary resources, and (c) implement suitable preventive and other risk mitigation approaches to minimize the possibility and/or severity of incidents. For instance, if a particular business process has an RTO of four hours, the associated IT infrastructure, data, applications, employees, and supporting third parties all need to be prepared in advance to enable the process to be recovered to operational status within four hours: none of the supporting parts can exceed four hours, setting a clear goal.
• The organization must implement a continuous awareness program, systematically explaining how business continuity can help both the organization and its employees, motivating them to behave accordingly and thereby gradually changing corporate culture toward the resilience mindset.

Perhaps the best feature of ISO 22301 is that it expresses all of this by recommending a single, comprehensive, and easy-to-understand management system.

The IT perspective on resilience

The systems engineering approach is ideally suited to highly resilient IT systems:

• Specification involves analyzing and clarifying the functional and technical requirements relating to availability of the organization’s IT systems and infrastructure, alongside other requirements. Business impact analysis, for instance, is a risk management technique for drawing out, prioritizing, and evaluating the organization’s resilience and recovery objectives in functional/business terms, which in turn can be used to drive the technical design.
• Designing for resilience is part of the normal systems architecture and design processes, but can be improved significantly through the application of specialized knowledge and skills. The design of so-called safety-critical systems, whose reliable operation is essential to the protection of life and limb, should clearly not be left to junior systems architects without sufficient expertise in this area. Similarly, think twice before letting fresh-from-college designers loose on business-critical systems!
• Development processes need to be rigorously controlled to produce inherently resilient and reliable systems. Aspects such as formal methods, detailed documentation, failure mode effects analysis (FMEA), and strict change controls can all help, provided they are brought into a coherent whole by effective project management...
• Management of the development project, plus the broader business integration, implementation, and operations aspects, is a higher-level control ensuring that structured processes are followed appropriately. While it is seldom feasible to eliminate all risks, sound management practices will at least ensure that they are duly identified, considered, and mitigated as far as practicable. Parallel development of both continuity and recovery arrangements, for example, could be an explicit part of the risk mitigation plan.
• Maintenance of the business continuity arrangements requires an ongoing commitment to good practices, ensuring that the inevitable changes to the technologies, processes, people, and other aspects are reflected by corresponding changes to the resilience and recovery arrangements. In the case of safety- or business-critical systems, the linkage itself is critically important: retrospective changes may not be adequate, even if fast-tracked.

Given their criticality, recovery of failed IT systems (computers, networks, peripherals, and data) supporting business processes can be essential for the organization’s survival: but which ones are critical, and just how critical are they? Mapping between critical business processes or activities and IT systems, networks, services, etc. tends to focus on highly visible elements. However, organizations typically depend on routine office services (such as telephones and email) plus bespoke, stand-alone applications to carry out key processes upon which the headline systems rely for key data. Failure to include these in the continuity and disaster recovery plans will impair the efficiency of the organization’s recovery, and may jeopardize its effectiveness.

If the organization relies upon third parties to provide essential IT systems and services (e.g., cloud computing), or for ICT DR, there should be a documented Service Level Agreement or contract in place that makes explicit the expected performance levels of the suppliers, plus realistic penalties, metrics, and assurance measures (such as the right to audit or exercise and so prove the arrangements at least once a year) to ensure compliance. Assurance is necessary, because discovering in a disaster situation that critical third parties have been somewhat “economical with the truth,” or that your organization’s business continuity requirements have materially changed since the contracts and service levels were agreed upon, is clearly too late.   

Business continuity maturity

An organization’s approach to business continuity matures as management appreciates and deals with the associated risks, investing in a variety of measures to ensure that the business will survive almost any challenge thrown at it. While the nature and order of the steps varies in practice, the sequence represented on the diagram indicates how each additional layer typically builds on those beneath. 

• The starting point is a purely reactive approach to incidents. As with the “fight or flight” instinct, there are situations where speed of response is even more important than the precise nature of the reaction, provided those involved in the process are sufficiently competent and capable of handling things on the fly. Notice that this foundation layer persists even in a highly mature organization: highly resourceful and resilient people come into their own in crises and disasters, bringing calmness and order to the chaos and boot-strapping the recovery processes. Being petrified with fear is seldom an effective response!
• Some would argue that the true foundation for effective business continuity is a reasonably comprehensive approach to information security management, such that information assets are valued and protected, and most incidents are avoided or prevented. Two characteristics of this stage are systematic processes for assessing and treating information security risks (possibly in the form of an information security management system), and the division of roles and responsibilities among suitable people and functions… however, mature organizations generally have those building blocks for business continuity in place even if they don’t actually have an information security management function, as such.
• As the incident response process matures, it typically broadens from a reactive to a more proactive and professional approach, systematically preparing to deal with incidents and learning from incidents and near-misses, including those that affect similar organizations (an important point, since major incidents or disasters are so rare that we may not have the luxury – or misfortune – of learning through our own experiences). The introduction of forensic methods is characteristic of a relatively mature incident management process, along with a structured way to capture knowledge and use it systematically to improve the organization’s capabilities.
• Disaster recovery arrangements are developed for business-critical core IT systems and necessary parts of the supporting infrastructure (e.g., networks and facilities). At this stage of maturity, business continuity testing tends to be limited both in scope and in the kinds of disaster scenarios envisaged, giving limited assurance.
• A more advanced approach to business continuity management broadens the perspective beyond IT to the business as a whole, for instance, making arrangements to handle the loss of key people and key suppliers or markets, and appreciating which business activities are truly critical. Business continuity testing tends to be supplemented in Stage 5 by business continuity exercises involving and training a broader cadre of people on a wider range of potential disaster scenarios. Practicing or rehearsing business continuity and disaster recovery activities helps because, as noted earlier, serious events are so rare that people are unlikely to experience them often enough to learn the ropes by doing.
• True contingency preparations help the organization deal with unanticipated incidents and disasters that, for some reason, other business continuity arrangements do not address and cannot resolve. Here, we are referring to contingency in the broad sense that what needs to be done is contingent on, or depends on, the particular circumstances as incidents unfold. Building the capability to deal positively with whatever life throws our way – to pick ourselves up and get on with stuff – is subtly different to more conventional business continuity management. Stage 6 develops people’s capacity for evaluating and responding to indeterminate situations, and their resolve to make the best of things, rather than a planned response to a specific scenario.  
• In addition to engineering critical business processes plus the associated systems, people, supplies, etc. for robustness and high availability, this stage is characterized by the emergence of a deep-rooted and widespread corporate culture of resilience. Through preparations, exercises, and tests, coupled with experience and learning from actual incidents and near-misses both within and outside the corporation, the organization is increasingly capable not merely of surviving serious incidents, but of thriving when their less-capable peers and competitors struggle. Stage 7 adds assurance to the previous layers: stakeholders are confident that the organization is robust, capable of withstanding almost any challenge. More than just a feel-good factor, assurance enables management to take on more risky approaches, safe in the knowledge that things will almost certainly work out. Therein lie genuine business benefits, above and beyond those secured in previous stages.

The maturation process may take several years, and in fact is never ending in the sense that, in order to remain effective, business continuity arrangements must evolve in line with changes to the business, technologies, relationships, and risks. Progress may occasionally falter due to supportive senior managers moving on or a lack of resources; conversely, progress may be boosted by a change of attitudes, perhaps triggered by a compliance obligation or an incident that, for some reason, resonates with management. A relatively minor incident within the organization, or a major incident suffered by others, could be the wake-up call that leads to a step change in capabilities: this illustrates the value of raising management’s awareness of business continuity and other information security matters through sharing information about incidents and near-misses.

ISO/IEC 27001 and ISO 22301 management systems both stress the concept of continuous improvement. Compliant organizations actively and systematically seek out and exploit improvement opportunities through corrective actions. Corrective actions respond to identified current issues such as noncompliance with the standards or with some other requirement. 

Many organizations are not so systematic about things, maturing naturally through a serendipitous process more akin to trial and error, and that’s fine – up to a point. Using structured management systems to drive continuous improvement and adopt good practices is generally held to be a more efficient and effective process, although (as with ISO 9001 quality assurance) rampant bureaucracy and inflexibility are genuine concerns – in other words, management needs to apply the standards wisely.

Business continuity metrics

Goal-question-metric (GQM) is an effective way of identifying metrics (Hayden, 2010). In the present context, the approach involves clarifying the goals and objectives of business continuity, elaborating on the questions that naturally arise in relation to whether those goals and objectives are being or will be met, and finally deriving suitable metrics that will provide the information necessary to address the questions.

Robustness metric

Focusing in on the resilience aspect, one objective of resilience is to make the organization inherently robust and able to stand up to serious challenges, begging questions such as “How robust are we?” and “Are we sufficiently robust to cope with the kinds of incidents that might occur?” Various metrics might answer those questions, for example measuring the organization’s ability to withstand different kinds of potential incidents (e.g., physical disasters, logical disasters, supply chain disasters, personnel disasters, and so on), using a simple scoring scale and assessment based on past experience, moderated perhaps to account for the organization’s current efforts to improve its robustness. A maturity metric is another possibility, measuring the maturity and quality of the organization’s resilience, robustness, and other business continuity arrangements against a notional range based on standards such as ISO 22301, plus good practices and experience.

Resilience metric

The table below combines these approaches into one resilience metric. Using the criteria in the table, a competent and independent person (such as an IT auditor) can determine the percentage scores for each row, and then generate either a simple overall mean score for the final metric, or else a weighted average if some rows are considered more important than others. The level of analysis could be the entire organization, and/or significant parts such as its business units, sites, departments, or functions. More detailed analysis has the advantage of identifying under-performing parts that might learn from others that are doing better, and prompting local management to address the issues.

Breaking down the overall score to show the contributions of each row in the table will also indicate which aspects are considered the strongest or weakest, which in turn can help senior management push things along where necessary.
The PRAGMATIC method allows management to shortlist a small number of metrics from a much longer list of candidate metrics, comparing and contrasting them on a common basis using nine PRAGMATIC criteria (1) (Brotby & Hinson, 2013). Applying the PRAGMATIC method to the two metrics suggested above, management might, for instance, feel that the robustness metric is more predictive and more cost-effective than the maturity metric, but falls down on independence. Insights of this nature can be used in turn to select the most appropriate metrics, and to improve metrics systematically.

Conclusion

Throughout this paper, we have stressed the idea that business continuity needs to be business-driven. The clue is in the name! This is much more than just a matter of inviting a token business representative to a disaster recovery planning meeting in IT, or asking some tame IT users to confirm that they can login to a recovered application system. It starts right at the top of the tree with a clear appreciation of how business continuity, resilience, recovery, and contingency are of strategic value to the organization.
In particular, we have focused on resilience as a complementary approach to the more widely accepted concept of recovering failed IT systems and services. Keeping essential business processes running through disasters implies the need to engineer the associated systems, networks, etc. specifically for high availability. It doesn’t just naturally happen that way, at least not to the extent appropriate given the need for assurance. There should be no question of passing the ultimate availability test – a genuine disaster – which in turn imposes demands on the business continuity tests and exercises that are so often taken for granted. A further advantage of the approach is that, because they are designed to work routinely, resilience arrangements get exercised and/or tested much more frequently than disaster recovery arrangements.
Neither top management’s clear appreciation of the issues nor engineering systems and processes for high availability will guarantee the survival of an organization in a disaster. To achieve true resilience, the mindset needs to change at all levels of the organization from top to bottom. Unless every business process, every piece of equipment, every application system, every supply chain and so forth is known to be sufficiently resilient, business continuity is merely an illusion, wishful thinking.

Footnote

(1) P = Predictive; R = Relevant; A = Actionable; G = Genuine; M = Meaningful; A = Accurate; T = Timely; I = Independently measurable; and C = Cost-effective.

References and further reading

• Brotby, Krag, and Hinson, Gary (2013) “PRAGMATIC Security Metrics – Applying Metametrics to Information Security,” CRC Press, Boca Raton, Florida.
• BSI Standard 100-4 (2009) “Business Continuity Management,” Bundesamt für Sicherheit in der Informationstechnik (German Federal Office for Information Security).  Part of the IT Grundshutz suite.
• Bunkley, Nick (2011) “Japan’s Automakers Expect More Delays,” The New York Times, March 18th
• Business Continuity Institute (2013) “Good Practice Guidelines.”
• Hayden, Lance (2010) “IT Security Metrics – A Practical Framework for Measuring Security & Protecting Data,” McGraw Hill.
• Kosutic, Dejan (2013) “Becoming Resilient: the Definitive Guide to ISO 22301 Implementation,” EPPS Services Ltd, Zagreb.
• ISO 22301:2012, Societal security – Business continuity management systems – Requirements.
• ISO/IEC 27001:2013, Information technology – Security techniques – Information security management systems – Requirements.
• ISO/IEC 27002:2013, Information technology – Security techniques – Code of practice for information security controls.

About the authors

Dr. Gary Hinson, PhD, MBA, CISSP, started out in life as a research scientist studying genetics before moving into network/systems management for a pharmaceutical company in the ‘80s. Through the ‘90s he was doing and managing information security and IT audits for utilities, aerospace/defense, and technology companies. Since 2000, he has been consulting, training, and writing – mostly security awareness materials for NoticeBored www.NoticeBored.com and a book on security metrics www.SecurityMetametrics.com. Gary has been a using the ISO27k standards since the early ‘90s. He is a member of ISO/IEC committee JTC 1/SC 27 and runs the ISO27k Forum with ~3,000 members www.ISO27001security.com. He emigrated from the UK to New Zealand in 2005 for a better standard of living and more space to think.

Dejan Kosutic is one of the leading experts in ISO 22301 and ISO 27001, and has helped numerous companies worldwide to implement these business continuity and information security standards. To get deeper insight on how to implement business continuity, get his book Becoming Resilient.