Business Continuity: The Automation Survival Guide Part 4

[Alizee]

• Defining Business Continuity Priorities
• Accessing Artifacts
• Ensuring Systems Access
• Granting Data Access
• Wrap Up

Business continuity might kick off when you have one process going down, which could be easy to manage, all the way to all automated processes and the larger IT estate being impacted. What's applicable will vary based on the scope of the disruption you are facing.

Let’s explore the four areas inherent to successfully enacting the plan. Throughout this blog, we’ll use data protection-related processes as example scenarios, since even though details vary by country, every organization can recognize themselves in such a process.

Example scenarios:

Scenario A (right to deletion): When changing mobile providers, a data subject may want their personal data transferred in a machine-readable format to a new provider.

Scenario B (right to portability):A data subject who receives too many marketing emails without being a customer of the company may want their data deleted from the company’s systems.

Defining Business Continuity Priorities

Every process has some form of SLA attached to it, and the non-compliance to that SLA has a varying impact. It could be internal, commercial or regulatory. And not all those SLAs are of equal importance to the business.

Being Aware of Applicable SLAs

We need to understand if there’s an applicable SLA for that process.

Example Scenario A & B:

There are several SLAs which apply to our data subject requests process:

• We are an EU-based company, and the regulatory SLA is 30 days.

• We also have an internal SLA of 10 days as we want to deliver an exceptional experience, including when data subjects exercise their rights.

• (Scenario A only) We have internal constraints linked to systems and data processes which means that “purging” a person’s data from all systems and ongoing email lists takes a minimum of 5 days.

These SLAs and regulatory requirements need to be considered to determine whether you need to accelerate the resolution for that process.

Understanding the Impact of a Failure To Comply

Once you have considered the SLA, you need to consider the business impact – in other words, the “cost” – of that failure.

The bigger the business impact, the higher the priority. And the impact is usually at its highest when the “hiccup” ends up being visible or palpable externally, be it by customers, suppliers or administrations.

Example Scenario A & B:

The impact will vary depending on our organization and the frequency at which we receive data subject requests. The data subject may complain to the data protection authority (DPA) in the region if we don’t meet the regulatory SLA, and the DPA can blame and fine us for non-compliance. However, the data subjects will have little to no grounds to hold you accountable if internal SLAs aren’t complied with.

• Impact of not complying with internal SLA: low

• Impact of not complying with regulatory SLA: high

• Maximum inferred acceptable no. days to resume processing: circa 22 days (accounting for the minimum of 5 days required to purge systems in scenario A)

If only the GDPR process is down and we have 10 days to restore it within a 30-day SLA, we might not need to kick off the business continuity plan at all.

However, if other processes, such as invoicing, are also affected, they might take priority due to their financial impact and the business continuity plan may need to be invoked anyway.

Accessing Artifacts

In our world of business continuity, an artifact is something that’s needed to resume execution in an alternate way.

It’s knowing where instructions to resume manual processing are stored, or being sure that everyone who needs access to the information does really have access.

Example Scenario A & B:

When notified to resume executing data subject requests manually, the responsible people must know where to find the manual processing instructions.

And always remember that the process executed manually likely differs from the process executed digitally, as it’s been optimized specifically for automation.

Ensuring Systems Access

With an automation being down, the root causes can be multiple and to enact your plan, you need to understand whether access to source and target systems is possible at all and by the right people. That’s the first step towards resuming processing.

In an automated process world, you have likely reviewed credentials to different systems (and reduced permission levels within each system) and your business continuity plan will require you to rethink permissions levels so that, when you need to break the glass in case of an emergency, you have access to the hammer.

Example Scenarios A & B:

In your data subject request process, permissions may have naturally been revoked or reduced for many people. However, some degree of permission needs to be maintained for the purpose of business continuity.

• Are the systems in your systems’ data map accessible?

• Do key stakeholders in the legal department have credentials to access those systems at the right level, including the permissions to delete data if necessary?

• Are they technically able to communicate instructions with application owners?

Granting Data Access

Finally, resuming the execution of your process will require more than just systems access: you also need access to the data.

Beyond permissions only and depending on the outage you’re facing (i.e., a system being down), you may not have access to the data, especially if stored digitally.

If the data is accessed via API, for example, there needs to be an alternative way of accessing it.

If some data is on paper, you’ll need access to the filing cabinet (and building) where it’s stored.

Example Scenario B:

To process the data portability request, you will need to give the means to generate a machine-readable file to a human colleague.

Wrap Up

Now that we’ve prepared our plan and have gone through how to enact it, we’ll wrap up our business continuity series with some last pieces of advice around mindset, frequency of invocation and more.

Stay tuned!