You found the backup wrap up your go-to podcast for all things

backup recovery and cyber recovery.

In this episode, we tackled the critical topic of incident response plans.

Once again, we've brought our resident cyber expert, Dr.

Mike Saylor from Black Swan Security, who starts by defining what an IR plan is and

how it's different from DR and BC plans.

We then talk about how you need different kind of response plans

for different kinds of incidents.

Like a cyber attack versus a failed RAID array.

We also delve into RACI diagrams and how they define who is

responsible, accountable, consulted and informed on any incidents.

Then we dig into where this plan should live and how you should make sure you

have access to it and the bad guys don't.

This is a packed episode I think you're gonna really like.

By the way, if you don't know who I am, I'm w Curtis Preston, AKA, Mr.

Backup, and I've been passionate about this topic for over 30 years.

Ever since I had to tell my boss that our production database was toast

and there were no backups of it.

I don't want that to happen to you or anybody, and that's why I do this.

On this podcast, we turn unappreciated backup admins into Cyber Recovery Heroes.

This is the backup wrap up.

Welcome to the show.

If I can ask you for just a quick second to go, press, subscribe or

follow so that you'll always be able to get our content, that would be great.

I am w Curtis Preston, AKA, Mr.

Backup, and I have with me a guy who keeps trying to get me to watch

this weird new version of the Lord of the Rings Prasanna Malaiyandi

ah, yes.

And you still have not seen it, although I did.

So my parents, so what I'm referring to is there's this new, it's not

even a Bollywood movie, I think it's technically a Telugu movie.

It's so tollywood, but it is called ky, A 2398 or something like that.

So it's supposed to be Yes, very.

Fantasy oriented.

Supposed to be really good shot in the modern day era or actually in the future.

And it has some pretty famous actors.

So from both the Telegu scene and the Thumb, and also from Hindi cinema.

So pretty much star in all star cast.

But I've been asking you, my parents actually went and saw it.

They said it was like three and a half hours and it was really long, but.

That might be like a.

couple naps.

Yeah, but it might be a couple naps.

for you, But it's only one episode or one movie.

I've been also trying to get you to watch Bahoo Bali one and two or the beginning

yeah.

That's the Lord of the Rings.

When I was talking about though, isn't it?

Oh, that's y.

Oh, you're right.

That is the Lord of the Rings

and that's like seven hours.

That's like seven hours long.

that's six hours.

But, uh, my wife and I, we did watch it y or over the weekend and so it's fine.

And it's really good though, Curtis, you should watch it.

You have until August 6th.

Uh, okay.

So as of this recording, I have one week to watch it.

Yes.

All right, well, we have with us again, our, um, can, can we call you our,

our resident cybersecurity expert?

Can

I feel like I've, I, I, I feel like I do reside here now.

I think so we've done enough episodes.

Um, so, uh, the CEO of Black Swan Security, Mike Sailor,

welcome to the show once again.

Thanks guys.

Great to be here.

So this week we want to talk about, we talk a lot about this.

It comes up a lot, uh, you know, in shows.

And everybody says you need a response plan, right?

And, uh, you know, an incident response plan.

And we talk, some people talk about a ransomware response plan, a cybersecurity

response plan, an incident response plan.

Can you just help?

Define all of those, like what, you know, do they, do they fit?

And, and of course I talk about a disaster recovery, uh, plan.

Where do all are, are these like Russian nesting dolls?

Well, and what's an incident response plan to start with?

Yeah.

are Russian nesting dolls.

Uh, so an incident response plan is what are you gonna do in the event that an

event, in the event that an event occurs?

you then classify as an incident.

And so first part of an incident response plan is, how do I do that?

You can't, you, you gotta define the difference then if

you're gonna use that event

That's where I'm, that's where I'm going.

Oh.

part is, the first part of, of your incident response plan is how do

I, how do I intake an event report?

Uh, could be smoke, it could be, uh, my computer's acting weird.

It could be.

Um, the website's down, uh, and then how do I classify that event as a type of

incident and then as a type of incident, what, what level of incident is it?

1, 2, 3, or, or however your organization classifies things.

And so the first part is that that analysis and categorization of an

event into, uh, an incident and, uh, incident type and criticality.

Right, and, and then

go ahead.

So then you have an incident, and based on what that incident type is, you

would have what's called a playbook.

So that playbook could be ransomware, that playbook could be denial of service,

the website's down, uh, operational, you know, uh, outage type of playbook.

Uh, or it could be, uh, misconduct, uh, you know, employee, employee misconduct

or trying to access stuff that shouldn't, unauthorized access type playbook.

Um, and you would.

You, you would do an analysis of your organization's most likely threats

and build playbooks based on those.

And then playbooks are like we've talked about in the past, just

sort of everything documented.

Hey, if this happens, here's all the people involved.

Here's all the steps that everyone takes.

Here's who's responsible for what actions, here's who I have to

talk to, and all the rest of that.

Right.

And here's who needs to be informed.

Right.

At least an outline.

Uh,

something's better than nothing.

And then, and then back to Curtis's question about disaster recovery.

And how does incident response plan it?

It is nested because an event becomes an incident and an incident

can then become a disaster.

'cause essentially a.

The, you know, you have a Dr.

Runbook, right?

Or a play, you know, you're saying playbook, playbook,

runbook, same thing to you.

Yeah.

It is.

So, um, it, it's a, I I think of it a, a bit like programming where Dr.

Runbook is, you know, is a function, is a library that can

be called by the bigger program.

Right.

So that, that to me is like the.

The, the deepest, nested part, right, because only after we've had an

incident, we've classified an incident.

We've classified it as a cybersecurity incident.

We've classified it as a, it's a ransomware event, and it's a

ransomware event that needs restore.

Right now we, you know, and then we have done our preparatory steps that

we need to do because, you know, I talk about a lot about this a lot,

and that is one of the big differences between a disaster recovery response

and a, a ransomware response is that almost always the disaster is over.

Right.

The flood has receded.

Um, because you, you can't start, you can't start your recovery

until the flood has receded.

The winds have stopped, the earthquake is over, the fire has

been put out, whatever the disaster was, it's over call the DR person.

The, the big difference with a cyber event is that the attack is ongoing

and you've got to put that fire out.

Uh, to, to use that analogy before you can ever call the DR person, and that's why

I'm saying it's sort of the most nested within, within the, the nesting dolls.

What do you think of that comment?

Completely agree.

And, and just to add a level of complexity with regard to backups,

uh, during your incident response.

If it's a ransomware where there's some compromise that happened

that led to the ransomware, then you've gotta make sure then also

that the backups you're restoring don't also include the compromise.

That you're trying to,

to tie off?

Correct.

lot more, a lot more attention to detail and, and analysis, uh, during

an incident than for sure, than, than, uh, cleaning up after a disaster.

So you have these, so you said you take the event, you identify it,

you put it into the right bucket of incidences, and then you.

Put a severity alongside it, and then you just sort of execute

your incident response plan.

Now, are these like, I am sure it's hard to cover every single incident

and severity or priority, right?

That goes alongside it.

So how do you sort of decide like, which ones am I actually going to

create an incident response plan for?

Which ones do I not need to?

Because it all comes down to.

Like resources in the company, right?

It does.

And, and that's where you're gonna start.

So in, in your incident response plan, and this, this goes.

Kind of back to the left a little bit in understanding the business

and the, the way it operates and how technology supports the business and,

and all the critical components of, uh, where, where the, the business

revenue and, and, um, focus is.

Uh.

Create an inventory of, of your, of your resources, both on the IT side.

We should already have that, especially from a disaster recovery perspective.

And I'll add this comment too.

If you have a mature disaster recovery plan, then a lot of

the work that you're gonna.

Put into creating your incident response plan should have already been done.

I've got an inventory of all our, our IT assets and where our data is

and the SLAs for, you know, if this machine's offline for an hour, we, we

lost a million dollars type of thing.

Well then, and the, and the, the resources we need to address those

disaster recovery activities.

Who's the sy?

Who owns that system?

Who's our network administrator?

Who's our active directory?

Who's who?

Who's our website?

You should, you should know who.

All those subject matter experts and stakeholders and owners are both on

the IT side and the business side.

Right?

So understanding that, um.

That environment of resources is critical to being successful in incident response.

All right, well then to your question about do we, you know, we can't possibly

have a playbook for everything, but what, what you'll learn, especially

after you, you do your first playbook and your first tabletop exercise,

is that there are very common

elements of every incident response.

You've got a leader.

That knows how to, that understands the environment and knows how to

categorize an event appropriately.

And then from that categorization of incident and priority can assemble

the right people from this inventory of resources to be effective

at responding to that incident.

You know, if it's ransomware, it's kind of an all hands on deck thing,

but if the website's down, I, I already know, I, I can look up who to call.

I need our

ISP, our host, our hosting site, the the person that wrote the website,

the person that knows all the backend systems that support the website.

I've got all that hammered out, and we'll get on a call and I've got their phone

number and their email and where they live and account numbers and all that stuff.

So you don't have to basically cry wolf every single time.

You don't, and you, and you should not.

Uh, so you know when, when an incident happens and, and or an event happens and

you're like, this is a true incident.

You don't go push the button.

You, you, you call the next person and get some, some, some feedback and

some collaboration, uh, and then you start to expand the team as necessary.

You don't, you don't call everybody to the table for every answer.

and, and I think you, I think you.

You mentioned this a little bit earlier, but I just want to, um, you know,

when you, when you said that a lot of the work would've already been done,

if you have a DR plan, that's great.

If you don't have one, uh, that's not good.

But, but I want to say that if this is the first time you're

doing any of this kind of work, the really key first thing is the BIA.

Right?

It's like.

Because, you know, as nerds as it people, we, we, we very often, we, we

focus immediately on the, you know, the cyber aspect or the recovery aspect

or the backup aspect and you know, how are we gonna get our network up?

Okay, okay.

We need to figure out what actually matters, right?

What makes the company money?

What's going to cost the company money when it's down?

Right.

What are things that we can do without and, and how long and

how long can we do without them?

Uh, how much money are we losing when this part of the company is down?

Right?

Um, and when this part of the company is down, is there something else that

the people that work on that part of the company can do to continue

to make money for the company?

Uh, or do we just send them home?

Um, you know, so they're not twiddling their thumbs.

and Curtis, when you said BIA, you meant business impact assessment, correct.

you.

Thank you.

What do you, what do you think, Mike?

Any, any additional.

Absolutely.

And so the BIA is valuable in so many ways.

BIA will help you on your insurance.

It helps you on your business continuity, your disaster recovery, your incident

response, all your risk assessments.

It's, it's very critical.

And any, any due diligence for like acquisitions and mergers and all

that stuff, it's, it's very critical.

It's also a good, uh, it's also a good tool for process.

Uh, improvement and overhead analysis.

Uh, it, it's, it's, it's really good.

Well then, uh, to touch on something you mentioned, uh, you know, if,

if this incident, or if this event happens and people can't do their

work and you send them home, or what else could they be doing?

Uh, that also touches on business continuity.

So how do we keep running the business without technology, which is really

what disaster recovery focuses on.

Business continuity is that.

that.

that contingency plan for, you know, I can't use the phone anymore or, or

that system's down and, and now we've gotta revert to pen and paper and,

uh, how do I, how do I keep taking orders or scheduling

repairs or whatever the case might

Somebody go find a big box of carbon paper.

Yeah, like Curtis's, uh, doctor's office or

that direct show that happened in the Midwest summer.

Remember that episode Curtis?

Yeah.

The derecho.

Yeah, that's a great episode.

We, we, we did have somebody on here who, who lived in a place,

um, and they experienced a derecho.

Have you ever even heard of a derecho?

I've heard the term, but I don't, I'm, I'm assuming It,

it's a,

it just means a, a hurricane that forms over land.

Um, don't have any idea why it's called what it's called,

but that's what it's called.

Um, so yeah, so we've done our, our business impact analysis.

We, you know, we, we, we know all the parts.

We know the.

We know where to focus our efforts.

And then we need to focus on the things that are likely to happen, the things that

are likely to give us the biggest impact.

And, you know, persona you talked about, you know, we can't do everything.

We talk a lot on here about good, better, best, right?

Good.

Is to have something, to have some kind of outline for anything.

If you have nothing, anything is better, is better than nothing.

On a back of an napkin is fine too.

Yeah.

Yeah.

Um, and the what if you've got nothing, once you've done the impact analysis and,

um, you've decided on, you know, we're gonna focus on, I, I think it wouldn't be,

it wouldn't be crazy to say we're gonna focus on a ransomware event that takes

out our, you know, priority one servers.

What would be your next step?

Well, I'll add some, I'll add some color to that scenario because part of

your analysis may, may indicate that in the event of an, of an incident like

that, you cannot reallocate people.

Those people have to keep doing whatever it is they're doing.

So your incident response plan should identify resources that you

can bring in to augment your staff.

And address the incident or vice versa.

Maybe it's your, your full-time, people addressing the incident, but

then you need to bring in staff, you know, some contractors to continue

daily operations or whatever that is.

Or that you've got zero capability of responding to that incident and

you've gotta bring in a third party, 100% to, to support and you're just

providing them guidance or oversight.

And I mean, it's, it's kind of like, uh.

The, the flood, the flood response, the blackman mooring or whoever it is

Yep.

where you've got a flood.

Nobody, I don't know how to clean up a flood or respond to a flood.

I know how to, I may know where the water shutoff valve is, but 100% of that

response is gonna be some third party.

And so that business impact analysis is gonna help you determine.

What proportion of inside, outside, you know, extra help you're gonna

need and who's gonna do what?

All right, so then, then the event happens, uh, and you're gonna, you're

gonna use that resource playbook depending on what that that event is,

um, to bring in the right, the right resources, the right people, and,

and start managing that response.

So.

If you'll have your playbook or your incident response

plan, you've executed on it.

You knew who the resources to pull in.

I'm sure along the way, as you're going through this actual event,

you probably see some gaps.

Maybe you're probably fine tuning, tweaking, adjusting, adding to

your incident response plan to update it so the next time it

happens, you're better prepared.

I guess the one question I have is.

Environments change.

We've always talked about it, right?

New systems come on board, new sites come up, new applications get deployed.

There are new threats out there.

What sort of frequency should people be thinking about going and revisiting

their incident response plans?

Because it's not helpful if, say, today, right?

You have an incident response plan for how to deal with telephone communications

from like 30 years ago, right?

So how do you make sure that your plans are also up to date as the

world changes, as your environment changes and as the people change too?

as a, as a good, as a good practice, good governance would be reviewing

all your policies, procedures, and plans at least once a year.

But I'll, I'll caveat that with any significant change to your personnel,

your environment, or the way your business operates should then dictate a

review of all the things that support.

And, uh, not only support all of those things, but also support the response

activity to any, any related incidents.

Uh, so as often as it makes sense, but at least once a year.

Okay.

And I'll, I'll add to that too, that there's often two types

of incident response plans.

There's the very technical one with the playbooks and the contact

information, the technical details.

That's for the.

The internal response team consumption.

And then there's kind of a general population incident response plan,

which is more like a guide to, well, how do I report stuff and what do

I expect?

And,

um, you know, some that, that same plan may also include a provision that says you

as an employee or contractor may be called upon as a subject matter expert to help.

Respond to an incident.

And

so putting all that, all that stuff out there as far as expectations

and guidance in a, in a, a shorter,

you know, kind of condensed manual,

similar disaster recovery, you know, there, there's like your evacuation plan

and then there's the tech, the, the, the true disaster recovery plan

that has a lot more detail on it.

I like the idea of, I, I think one of the most crucial elements, if not the very

first element that goes into an IR or DR plan, is the, the contact list, right?

Who do you call for?

What, who's responsible for what?

Um, what is Mike Sailor's cell phone number?

Um, you know, to, to call.

Because he's our guy to bring in, in the case of scenario, and again, you,

you, you have to update that information 'cause that stuff changes all the time.

Right.

Um, and

And, and don't.

Don't just Google Mike and his cell phone number and put it in your contact list.

Actually, you, you've gotta call these people and say

hello and

and you know, I'm, I'm, we need to, we need to establish a, a, a relationship or

a rapport so that you, you are, uh, you will answer the phone when I call you,

uh, and, and

know that it's important.

Yeah.

'cause I don't answer, I don't answer unknown, uh, phone numbers.

So, um, yeah.

Same.

Um, yeah, so we've got our contact list.

Uh, we've got our vendor list, right?

We've got our, um, all of tech, the technologies that are involved.

Um, and we've got an escalation list, right?

A list of what's go, who's going to be called when, and then also.

Who's going to be called when those people don't answer the phone?

Um, right, because I, I know that comes up in a, in a, um, like in a

tabletop, well, it comes up all the time.

Right.

Uh, Fred, who's the one that's responsible for A, B, C, uh, he's on vacation, right?

He, he's in Aruba.

Uh, good for Fred.

And he's taken an actual vacation and he is unplugged the cell phone.

And, uh, you know, and he's not taking our calls, so who's gonna take

Fred's call when Fred's not there?

That should be the case for every responsibility in the,

you know, in the company, right?

Uh, correct, and, and you should have a chart.

And, and if you remember from a previous episode, we call that a racy diagram.

That's right.

Yeah.

Uh, and spell that out again.

RACI,

responsible, accountable, consulted, and informed.

And so for everybody on your response team, you would, you would

indicate, and sometimes that changes based on what the playbook is.

Uh, but who's, who's, who are your primary responsible, uh, accountable

people for all the different types of incidents that you include, uh, in, in

your, in your, in your response plan.

Persona is the first person I call, uh, when I need to do something.

I don't know how to do, because I have this feeling that he

knows, he, he's watched a YouTube video about how to do it.

What does that seem, does that seem reasonable persona?

97% accurate, I would say.

he, he watches a lot of YouTube videos.

Um, all right.

So we have our, we have our, our list, our contact list, we have

the actual procedures, the actual runbooks that are, you know, the

different things that we're gonna do.

Uh, is there anything else that needs to go into response plan?

Yep.

So.

So at the, at the end of your response plan, you, you should

have as much reference material as you think is, uh, necessary.

So, you know, there's your, your instant response team contact list, but down at

the bottom, kind of to your point of, of third parties, but more than just

name and phone number, you may need an account number or a policy number

or, um, something specific, a pin.

Uh, you know, if there's, you know, multifactor, um, and then.

Something at the end.

Uh, towards the end, we have, I, I typically suggest appendices.

And so one of the escalation points of an incident is

whether or not it was a breach.

And the difference between incident and

breach can be significant

for a lot of different reasons.

What, you can get sued over a breach, right?

A breach might require that you, you

have, uh, reporting, reporting obligations to the state or.

What have you.

So then, so there's a, there's usually an appendix that helps you walk through

kind of a decision tree to determine if a, if an incident was a breach,

well then we've got all of this, you know, maybe, especially if you're a

publicly traded company, what are your reporting requirements, uh, by state,

by statute, and then some things that you want to pre, uh, pre-negotiate.

Is with, and this is with like management and legal or hr, how do

we communicate different types of incidents internally and externally?

And so having those predefined templates for emails or phone calls

already in your plan, so you're not on

the phone for an hour negotiating with internal audit or legal about,

all right, how are we gonna say this?

You've, you've got all that stuff outta the way.

So Mike.

So we have everything documented.

I think one thing we didn't cover is where does this document live?

Because right if, because if it's like on your normal internal systems

and you get hit with a ransomware attack, now your incident response

plans are also potentially gone.

If you get hit by a hurricane or a flood and you have it in

physical paper form in the site location, those are probably gone.

So.

How do people store these and make Sure.

it's still accessible?

I've seen a lot of variations of this.

I've seen the All right, who's, whose turn is it to take the metal

box home in the trunk of their car?

Uh, I've seen people store it with their tapes at Iron Mountain.

I've seen people, uh, uh, pay for a service where it's like a cloud-based

disaster recovery thing, where different stakeholders have the ability

to log in and update their stuff, and that's where the plan lives.

Uh, and then, uh, I've also seen some pretty creative, uh, approaches to this

with like $0 retainers with a, a law firm.

And so pre-negotiate, get all the paperwork outta the way.

And I would, I would suggest this with an instant response firm.

And, and even, uh, uh, you know, if, if, if your staff isn't capable of, of

quickly fixing or building or re-imaging stuff, then go find a, a firm that, that

can provide you those resources and, and get all the paperwork done today.

And, but to my point, uh, uh, or back to my point about the law firm.

So $0 retainer establishes and it gets all the deconfliction out of the way.

Uh, but send, give them your, your Dr and incident response plan.

And because you're gonna call them anyway,

uh, make sure that you've got their phone numbers, but you're, it's great.

Great point.

I've seen in a lot of cases where, you know, we're trying to, there's an

incident, we're trying to coordinate response and their networks, their

internet's down, their email's down and, and, you know, how do, how do we even

coordinate among their response team?

And so having a, having a relationship with someone that can.

That can provide you that, that communications medium, but also, uh, be

a, a good place to keep your, your plan.

Yeah, I, I, my personal preference is I like having an electronic version

because it's easier to maintain, but I also like having that paper version and

the way I like having the way I like.

Creating a paper version is in a loose leaf type of a notebook, so that allows

me, when I update a couple of pages, I can just rip out at those pages and

replace those pages so that I'm not printing an entire tree of documentation

every time I go to update the runbook.

Um, and I do like that idea of having it, having it stored somewhere else

other than the company, but close by.

Right.

If we're talking about actual paper.

It needs, you know, you talked about a law firm, you talked about an instant

response team somewhere that stuff is stored, that's accessible to us as a

company, but, uh, but not too accessible because it's in the data center that,

uh, that we're trying to recover.

Or at least a copy.

Right.

Store it somewhere

A copy.

Yeah.

Um, of course the more copies you have, the more trouble you

have maintaining those copies.

Right.

But the, the, um, the, uh, and I think the, the, the physical paper

issue is less of an issue during a cybersecurity event as it, than it is

in a, in a disaster where the, you know, the building blew up or was on fire.

But, I cannot overstate the value of, um, of a paper document, right?

In a, in an event that potentially takes out your, you know,

everything that you have, right?

I mean, I mean, I'm, you know, I'm a, I'm a huge fan of the

cloud putting stuff in the cloud.

Uh, what if you got no internet, right?

Cloud's, cloud's great, but you can't see the clouds anymore.

Yep.

Yep.

So off switching topics, so we have the cybersecurity incident

response plan, which for company documents, who all the people are,

how they respond, and all the rest.

I.

This is a goldmine for malicious actors, right?

So if they got their hands on this right, they know your entire playbook.

It's like if you got the military plans for like the nuclear weapons and

like how things will respond, right?

So how, like how should people go about protecting these from these bad actors?

So it should be considered or classified as a, a confidential or sensitive

document, so password protected, you know, make sure it's stored

appropriately with restricted access.

Uh, but you're right.

In fact, uh.

We did a tabletop exercise on ransomware for a, an engineering company.

Uh, and then shortly after the tabletop, they actually had a ransomware attack.

Uh, come to find out the threat actors had been in that environment for six months

or actually privy to the tabletop exercise and had access to their instant

response plan and their insurance

policies and all these other things, which then help them better

strategize and facilitate the attack.

And.

Uh, which, and they got paid, you know, they, they made several million

dollars off of that deal because they were, they were informed, uh, and

they knew what the capabilities were.

They knew that they were gonna be, um, ineffective at responding

to a ransomware attack, um,

Yeah.

sure that you, you fix all the problems identified in a tabletop exercise,

and this organization did not.

Well, I, I think that's a great question.

P and I think it goes back to the same thing that we advise for

backup systems segregation, right?

Making sure that it's just not on the same systems with the same usernames

and passwords protected by active directory and an admin and an active

directory admin password, right?

It's gotta be more than that.

And, and that's, and I think that's where SaaS providers can be very helpful.

Right.

Uh, I like this idea, you know, um, that you talked about Mike, of having

a, you know, basically services that will, that they probably have, I.

Templates and things that you can use for an incident response

plan and help build it out.

It makes making that easier.

And then also it's, it's stored in a different environment than yours.

Uh, of course you gotta vet all their security because persona, you are 100%

right, that that would be a gold mine.

Just like backup systems are a gold mine.

You get, you get in charge of the backup system and you have, you know,

why, why hack all the servers when I can just restore the data that I want?

Right?

Um, any final thoughts, Mike?

Any final things we need to say about creating an an incident response plan?

Yes, the design of that plan will drive its effectiveness.

And so, uh, from an audit perspective, um, well, even more fundamentally

controls perspective, an incident response plan or program would be considered

a control, uh, that helps drive the effectiveness of your organization.

I.

There's two parts of a control.

There's the design of the control, and then there's the operational

effectiveness of a control.

And so we can put this plan together.

We can have all these whiteboarding sessions and phone

calls about who's doing what.

And we put it all in this document.

We feel great about it, but it doesn't mean a thing if you don't walk through

it to see how effective that design is.

And that's, you have to do table, you have to do an exercise to test

the effectiveness of your plan.

'cause like Mike Tyson said.

Yeah, everybody has a plan until I hit 'em.

And so your response plan is, that's all it is, is a plan until, until you get hit.

And if you don't, if you haven't, if you haven't walked through

it, you're not gonna know how well you, uh, respond to that.

That hit.

Yeah, I really thought you were gonna rhyme earlier.

You know, you something.

I forgot what you said.

It's, uh, you don't got that thing or something.

I thought you were gonna rhyme there, but, you know, uh, but I, yeah, I,

I, I thought exactly about that.

That Mike, that Mike Tyson comment.

You know, everybody, everybody got play until they get hit in the face.

Absolutely.

All right, well thanks again, Mike for uh, walking us through

and thanks again for some great questions this time.

Persona,

I, I think I'm starting to think more like a bad actor, which is kind of.

Fun.

that's what you gotta do, right?

Gotta think like a bad actor.

Absolutely.

All right, and thanks to our listeners, we do this for you.

Uh, reach out to us, say hi.

Go to backup wrap up.com and put in a comment.

I love getting comments from people.

Um, and, uh, you know, rate us go.

You know, if you love us, rate us.

If you hate us, don't.

Anyway.

Uh, that is a wrap.

The backup wrap up is written, recorded and produced by me w Curtis Preston.

If you need backup or Dr.

Consulting content generation or expert witness work,

check out backup central.com.

You can also find links from my O'Reilly Books on the same website.

Remember, this is an independent podcast and any opinions that you

hear are those of the speaker.

And not necessarily an employer.

Thanks for listening.