Hello and welcome back. Let’s now move onto incident response versus business continuity. When an incident actually happens, we've got to respond to it. Incident response actually falls into business continuity. Incident response is all about handling situations when they transpire, so security-related threats to systems, networks, data, data confidentiality, non-repudiable transactions. We haven't covered that term yet have we? Non repudiation. 

In case you’re unfamiliar with that last term, non-repudiation is the idea essentially that you can prove that something has taken place, or that you're unable to prove that it's not happened the way you say it's happened.

So, for example, if you have an Access server and it makes a record of each time someone logs in and out, you then have non-repudiable transactions. 

And you can build more systems in place to make that information even more water-tight. CCTV to prove someone was there at the desk. IP addresses to prove it was definitely not a remote login. Event logs and event status codes to further prove it was definitely not a remote login, it was a local login, it wasn't a system login - that's what the code says. 

So we can bring all that information together to say we have non-repudiable transactions. And we also use that term when we're talking about emails and digital certificates as well. 

So, going back to Business Continuity. We have business continuity, and inside that we have Disaster Recovery. And under Disaster Recovery we have IRT: Incident Response Planning. 

So, Incident Response Planning actually jumps in and out of both disaster recovery and business continuity as a whole. It has to. Because we have situations of general Business Continuity that we have to take care of, therefore we need Incident Response plans to take care of all of those different situations. For example, your network's gone down. What's the plan? Who do you call? How long should it take for you to get it back up?

What's acceptable in terms of the downtime that we're about to experience? And how long is that acceptable? What makes that acceptable? Those types of things.

And then we have Business Continuity Planning which looks at the larger, broader things for sustainability of the business overall. Business operations, things such as power, lights, people able to get in, succession planning, positions. All of the types of things that pertain to the organization and also systems as well. 

Disaster Recovery then comes in and looks at those core IT systems which without those the business wouldn't be able to make money.

Incident Response Planning builds playbooks for both of these situations. Whether it's business continuity or disaster recovery. So we build playbooks that take care of whether it's a volcano has kicked off and smoke is everywhere and our people can't get to work. Or it's snowed. They're snowed in. What do we do? What's the process? Do we expand the bandwidth for our remote servers until such a time. And those would be our incident response plans until we can return things to business as usual. 

Right, so incident response focuses on IT attacks and prevention. IT information security plays a big part in that. And also interfaces with legislation and environmental impact. All of those types of things that come into play as well.

So, we start with the planning phase. We plan for things before they happen. How do we do that? Normally by carrying out a risk evaluation and then planning for it. We'll identify any facts in the relation to an actual incident, when it does transpire. That's what that skull and crossbones represents - an incident that’s taken place. We’ll then find out any facts related to the actual incident, and we’ll implement our plan. This will reduce the damage and we’ll also ask ourselves the question: what types of things have happened to data security and do people need further support if there has been an incident? If it is the case, we need to notify victims. If there is a data breach, we need to establish contact and issue an official company response. And we need to identify and remove the root cause of the incident, and reduce its effects so that we can still continue business. 

We'll then restore the company to business as usual and at some point in time we need to discuss what it is that we learned. That is important because that helps us then go forward and create better plans or, if we successfully avoided any damage from the incident, to identify what we did well. Now let’s take a look at BIA: business impact analysis. Like risk assessments, this looks at and analyzes the impact of risks on the business being realized over time, and how that loss and disruption would hurt that business. It looks at critical systems so we would have business impact levels. This impact level is 5,000 dollars worth of impact. This is 10,000 dollars worth of impact. This is 50,000 dollars worth of impact, and so on. Then different incidents fall into these different impact levels, and their effects on the business over time. And depending on the time frame that we have, there will be different levels of financial impact.

So we still have the risk assessments and we’re looking at confidentiality and integrity, but it's based around availability of our systems. We have to ask ourselves the questions: If it lasted for this long, what would be the issue? If it lasted for this long, how much money was that we lost? If it lasted for this long, what's the financial impact? So it’s business continuity oriented but focused around availability.