In my early IT career, I worked technical support.
I took phone calls.
And the company I worked at, we made games.
Some of us came on a single floppy disk,
advanced Dungeons and Dragons as the case.
And we had someone, a repeat defender,
who would call a few times in a row.
Something wrong with the game.
I played it once, I put the disk back in,
and now I can't play anymore.
Okay, great. We'll send you another one.
Stick another disk in the mail, move on.
Well, a week or two later, we get another call.
Same thing.
The person who took the call didn't realize
that they had called in before, so sent another disk.
Now the person calls back in and says,
hey, I've been to this twice,
don't send me another disk.
I've got a bigger problem.
Okay, great. Describe to us what you do.
Put the game in, enter a few commands.
I save.
Great, now what happens?
Now I take the disk out, and I use a magnet
to stick it to my refrigerator.
And of course that renders a floppy disk
completely useless.
So there's my disaster recovery story.
Don't use magnets and floppy disks.
Oh no.
Or if you're Gen Z,
it's the thing that looks like the save icon.
Yeah.
That too.
Oh boy.
True story.
What was the recovery part of your story?
It was end user error.
Best practice.
That's a good one.
Best practice after this, right?
Avoid this, it's created disaster for yourself.
I was thinking, when you brought this up,
I'm like, do I have a good disaster story,
but it's a disaster for me.
I had my address book, like pen and paper written out,
all these names and phone numbers,
like my holy grail here.
And I put it down somewhere,
and I hit a cup of water,
and it just went all over my book.
And I was like, oh no.
So I got it, and I'm like trying to get all the water off
and everything.
Thankfully, recently I transitioned to
like these special Sharpie pens that don't bleed.
So like it was completely soaked,
but nothing was destroyed.
So, you know, my disaster recovery was a little bit
of like the forethought of changing the type of pens
that I use.
So it's like a total mess.
It's all warped, but all of it is readable.
So that is my disaster story.
That was a twist ending for me.
I thought for sure, I'd be like,
I transitioned using my phone.
And then you were like, no, it was the pen.
And I was like.
Well, the phone is not adverse
to being destroyed by water either,
but I did like that.
This is the fantastic transition, right?
So what's the real disaster?
Better planning, which just really leads really well
into a deep dive on backups and so forth.
There you go.
Ooh, segue.
Today we're talking about RTOs and RPOs.
Tara, Kelsey and myself are joined by Todd, our COO
and CISO, Scott, our manager of strategic engagement
and Matthew, our VISO.
And before we kind of dive in,
I'm gonna throw it to Scott to give us
a little bit of an overview.
What does someone need to kind of understand
to really listen to the rest of this podcast today?
Thanks for that intro, Ariel.
This is a topic I'm really passionate about.
If it's right into what I am talking about,
talking about to customers very often,
which is acronyms, fun, IT acronyms,
RPO and RTO.
So what are those two things?
Let's first explode the acronym and say,
RPO is recovery point objective.
And I'll talk about that one specifically.
Let's think about normal computer systems operation.
And then let's think about the time a disaster strikes.
RPO, recovery point objective,
is the amount of data, transactional data,
the organization is tolerant of losing
in that timeframe, right?
So let's say, for example,
we have a disaster at precisely noon on a Tuesday.
And you've been working up until that time throughout the day.
So say people started working at 8 a.m.
The last backup of your critical data occurred yesterday,
so on Monday.
So what that means is you would have lost any transactions
that would have occurred in that before that timeframe.
The last backup ended or was performed the night before,
you then were working and then there was a disaster
and you don't have backup of that transactional data.
So that's what RPO is.
It's our recovery point objective.
What we're trying to navigate there
is the time that backups occur
and when you're susceptible to have a disaster
and how much transactional data you are tolerant of losing.
Recovery time objective or the other acronym, RTO,
is simply the amount of time
that you're tolerant for experiencing downtime.
So again, let's think about normal operation,
same timeframe, we're operating normal from 8 a.m.
And then at noon, there's a disaster.
What's the amount of time
that the organization has expressed
it's willing to deal with in that outage.
Most organizations say, well, zero, Scott.
Well, that's fine.
That's the absolute tip of the cost pyramid,
but it's an important conversation to have.
So that's a brief overview of what RPO and what RTO are.
Again, I'm really passionate about these two topics.
I have this conversation very often,
which usually sounds like this.
Scott, what's our recovery time?
Well, I need the organization to communicate to me
what its recovery time goals are.
So often that's a two-way conversation.
The organization really needs to ask itself,
what's our tolerance for transactional data loss?
What's our tolerance for outage
in any one of the applications that we use every day?
And with that, I'll hand the mic over
to the rest of the group.
Pretty sick, huh?
All right, I'll go.
You're gonna be quiet, I'll go.
Yeah, so I agree everything that Scott said.
I typically have a smaller, shorter version
of both of those, but irrelevant.
I think you have a great intro
to what that conversation typically looks like
and what the next steps usually are
is it depends on who you talk to, right?
So if you talk to the CEO, the CFO,
their answer is going to be,
none, I have zero tolerance from downtime,
and you go, great, let's dig into that a little bit further.
If you talk to your IT manager,
they're gonna say, well, I don't really have any budget,
so we're looking at 24 hours, 48,
and you can see there's a fairly large gap into there.
One of the very first things that I would typically do
is start to ask the questions of,
have you gone through the process of identifying
what your various systems are
and putting a criticality on them, right?
So as I said, the CEO, CFO is gonna come in and say,
none, I wanted up all immediately,
I want you to tell me I can have it in five minutes,
and that's everything.
And that's super, that's great, that might be possible,
we can figure out what we can do about that,
but then we need to start digging into that
and saying, okay, well, let's look at that.
What are the critical things that you have
in your business?
Are do you make stamps?
Do you have strictly a technical deliverable?
What is that?
And if I didn't have it,
what does it take to get that back up, right?
So one of the things Scott kind of got into
is what is the physical cost of that downtime look like?
And we'll do a deeper dive on this,
but those would be various things like,
what is the reputational impact?
What does it look like if I can't do transactions?
Point of sale system is offline, you name it,
it's a variety of different things,
and you do need to look at those individually and say,
what does it mean to me if I don't have that?
Could I live without my accounting package for 24 hours?
Maybe.
Yeah, I agree with everything Todd and Scott have said.
There's most of the time when I see the confusion
around this as well,
just cause I don't wanna rehash anything guys have just said,
I'll move on.
When I see confusion around this,
it tends to be because there isn't that kind of breakdown
that's been mentioned,
you haven't gone through and defined everything,
or it's because everything is being done a specific way.
If you're running two servers in your system,
that do all of the things that your business requires,
the RTO and RPO for you is gonna be different
because you don't have to worry about the individual systems.
At the same time, if one thing goes down,
everything goes down.
Restarting one server requires restarting
every other process you're using.
Best practice says that every server should have
a single purpose for what it's running.
And when we think about it from that perspective,
the RTOs and RPOs become a lot clearer
because we have categorized everything we have in our system,
we've defined what everything is doing.
And so those machines are individual points
that can be restored.
Sorry, they have individual points where they can be restored,
they're all being backed up separately,
so that we know exactly how long that time is
from when, if there is that breakdown at say 12 o'clock.
If each of them has a different backup schedule,
we know how much data has been lost prior to that
for each service we're using,
whether that's accounting software,
whether that's your internal timekeeping software,
whatever it is, if they're properly segmented
and then organized and tracked this way with an RTO and RPO,
you'll be able to see exactly how critical each of these is
to you and instead of it being a chunk of change
to make sure no matter what,
everything's up 100% of the time,
maybe we can just focus on a couple of services
being up 100% of the time.
Or we can focus on getting certain items restored
far quicker than everything else.
Yeah, I guess one thing that I'd throw in
at the beginning of this is,
I think it's pretty safe to say in today's environment
you have backups of your core systems, everybody does.
And Matthew started to allude to this a little bit too,
is more than likely somebody at some point
has decided what the backup schedule is.
And Scott kind of alluded to this, it could be,
traditionally it used to be,
I'm gonna do an incremental backup,
which is anything that's changed over the last 24 hours.
And then at the end of the week,
you'd say I'm gonna grab everything
because nobody's working.
That has changed over the years, technology has changed,
the ability to do backups is significantly different
than it was even five, 10 years ago.
And so what's in place currently will vary,
but there is something currently in place.
What we typically find is that most organizations
have not got to a very mature process yet.
So when Scott's getting into, I'm passionate about this,
the reason why he's passionate about is,
you go into an organization, say,
what does your backup look like?
And they're like, well, if it fails, I just restore.
That's the end of the conversation.
So there is something there, there is something in place,
but digging in deeper is what the next steps are,
which is again, why we're here today.
Yeah.
And as part of that, I kind of feel like if,
like we're having this conversation,
and if it's something you haven't heard before,
know that this conversation, maybe not with this language,
but it's been made, this decision has been made.
Your restore times may be 24 hours,
it may be three to seven days,
but someone's made this decision,
maybe subconsciously or just on what's available
to allow these items to be brought back.
So even though you haven't defined it and said,
this is what we want it to be,
the resources that have been allocated to your IT,
define this already.
And it's about making sure that aligns
with what we actually want.
Right.
It so often becomes less of a technology conversation
and much more of a business risk discussion
in the same way that a business would analyze its risk
related to security of their building,
things like that, other insurance related risks
from a business perspective,
this becomes one of those things.
I would recommend that business owners, stakeholders,
don't wait for technology to drive this type
of a conversation.
They absolutely should be having this conversation
in within board and leadership type of meetings
to address, flush out and mitigate that risk.
An interesting dynamic to the way this has evolved,
even over the course of the last five years,
is that much more of our line of business
or critical applications have migrated
to a cloud type of an environment.
In that case, this changes a little bit.
In the past, where we might be concerned
about redundant physical servers, redundant storage arrays,
the redundancies associated with the capital,
the CAPEX infrastructure that an organization
has traditionally invested in changes when that workload,
let's call it Salesforce or an accounting application,
migrates to the cloud.
Now, the area of risk becomes your connection
to the internet, right?
And so things like firewalls,
things like internet connections,
those become the single point of failure.
That's where risk exists.
And so addressing the RTO component,
the recovery time objective,
if you have one firewall and one internet
and Comcast cuts the fiber out in the street,
who knows at that point in time,
we don't know how long the outage could occur for.
So that's kind of the nature of how some of that,
I've seen that changing.
Those are some of the conversations,
again, I've been having with our customers.
Yeah, I think that was really good stuff too.
We did talk about better planning
at the very beginning of the podcast
as we were doing our transition.
And cloud is an excellent conversation
and we've got had podcasts on them in the past.
One of the things I kind of wanted to drive
into a little bit more,
and I think this kind of helps expand
on what we're talking about is,
if you're looking at the cloud,
almost every cloud provider will tell you
that they have the three nines that are up 99.9, whatever,
percent of the time,
and kind of giving an idea of what that context is.
That sounds amazing, right?
But there is still downtime associated with that.
That does not mean it doesn't go offline during the year.
Yeah.
And I think part of this,
when we talk about something like the internet outage,
we're talking about that whole process, right?
So if you've got items in the cloud,
your internet goes down.
Hey, that's a different, that's a huge conversation
at that point.
Are you just gonna get a second internet line
that you only use when you need it?
Cool, there's that business conversation around it.
But when it comes to finding those items,
I tend to feel there's a significant amount of pushback
in the less mature organizations around simply
being aware of exactly what they have.
They either focus on the physical hardware only,
these are the machines we have,
this is the servers we have,
this is the stuff we have in the cloud,
or they focus really on the certain applications
that assist them in making money as an organization.
So they're very good at tracking what they use
for billing customers or tracking their services,
their time in billing,
but the apps that people use individually
to maybe mark up PDFs or maybe there's a unique system
that someone's using that is incredibly invaluable
and critical to their work style
that just isn't documented anywhere.
Starting there is, in my opinion,
the first thing you have to do
if you've done a risk assessment
or anything like that before,
you should have this list already,
but definitely take some time
and don't worry about it being perfect.
Focus more on getting as many things down as you can,
speaking with every team, making sure they're listed.
Right out the gate,
I just had a conversation last week
with someone who I'd spoken to about doing this
and they realized there was four different tools
that different individuals were using
that all did the exact same purpose
that they were paying for separately,
all of which could just be turned down
to one monthly charge for a single tool.
Right out the gate, we're saving some money.
Once you've done that,
that's when the categorization comes in,
defining how critical software is.
And it seems like a lot of the time
I'll see people do this hourly,
they'll do it by a minute to minute,
hour to hour, day to day standard.
You can categorize them further.
Once you've done that
and kind of gone through these applications,
said I need this service available to me
within X amount of time
or I start to see significant business losses,
you can then say,
well, if anything needs a less than three hour timeframe,
that is a critical software.
I need backups every three hours
and I wanna be able to restore it within four hours,
for instance, just as a general idea.
You can define these numbers yourself.
And then you can start categorizing everything you have
within whatever these limits are for you.
Then we start talking about how we can make sure
those items are available to you
within those timeframes as much as possible.
And you start looking at the cost analysis
of how much does it cost for us to be down
versus how much we have to spend to make it not be down
for extended periods of time.
These are where the conversations really get intense
because we give it that monetary value
that we've talked about.
And you start seeing,
I've worked with organizations
where an hour of downtime was a six figure sum loss.
Suddenly trying to build a system
that allows them to stay up to those three nines
seems less expensive when their previous RTO,
their previous RPO was close to six hours.
So we're talking seven figure sums
that they're losing over that six hour period.
Maybe an additional two, $300,000 in hardware in the office
isn't such a bad expenditure at that point.
Right, so I'm just kind of wrapping that up a little bit.
I mean, essentially it seems like it potentially
may be complicated to say, what is that asset?
How do I know what to put it as a criticality?
How do I set them on a downtime?
And you kind of alluded to it there.
And in simplest terms,
if I'm just gonna straight up boil that down is,
what is the actual cost to the organization to have that down?
And you can decide whether that metric is in minutes or hours.
Most people would typically do it in hours,
but what is the financial impact of having that?
Again, I had mentioned in some organizations,
a financial package may not be something that's huge.
They may not do a ton of transactions
and they can handle it outside the system for 24 hours.
You've suddenly come up with,
I know what my recovery point is.
Or by comparison, as Matthew just alluded to,
is in a system that he's talking about,
my recovery point is much,
and my time is much smaller than that.
So I can start to put dollar figures to it
exactly really quickly.
There are some other things I mentioned in earlier too
as reputational cost and so forth,
but you can quantify these items
by putting just together a handful of questions.
What is the financial impact per hour?
Is there a reputational hit?
What does that look like?
What does it cost us?
Do we lose customers?
Those kinds of the things that we should be focused on
as we start to dig into RTOs and RPOs going forward.
One thing I want to mention,
because I don't think we've defined this yet.
What is an asset?
What is something that we care about when we're doing this?
I heard a, for me at least,
new definition of this the other day
that has been breaking my brain,
which is an asset is anything of value to the organization.
So when we talk about this,
you think of hardware, you think of software,
you think of data, right?
But it also means things like your website URL.
We hear horror stories, right,
of organizations forgetting to renew their domain name
and suddenly someone else owns it
because they weren't quick enough to renew it.
We're talking about SSL certs
so that your servers correctly make the connections
in a secure way.
Listing everything that the organization provides,
organization considers to have value to its business
is what's important.
Where does this kind of separate things for me?
Maybe you have 10 to 15 keyboards out the back,
so you don't care about keyboards
as an asset of value to the organization.
Just don't track them.
That's fine.
That's the distinction you get to make with this
is are we going to worry about the cost of this product
or the cost of this item, this data,
this hardware long-term and track it within our system
that we define replacement costs for?
If it's in there, yes, you should be doing this for it.
You should have an RTO and RPO.
Some of them may be incredibly long lead times.
I'm not sure if, maybe webcams are on your list
but you don't need one to be replaced that same day.
It may be there's a six month lead time on that.
But we're trying to make sure
that you've defined what's important to the organization
first, those are your assets,
and then your RTO and RPO relate to how quickly you replace them
and how much of their data or their usage
is backed up and retrievable over that same time period
and prior.
That for a manufacturing organization
might be a machine on the floor.
Yeah.
Right?
I mean, there's lots of different ways to look at this
and the traditional 100 year old manufacturing organization
that spends millions and millions of dollars
per machine that makes their widgets
has parts for that machine.
They've got support and service for that machine.
They may even have an employee
who's a support service champion for that machine.
Those are the same kinds of lenses
we need to look through when we think about data
and applications.
That's a great point.
We sometimes forget the operational cost of it
when it comes to the individual, right?
Because you're probably, in some cases,
I'm thinking of medical labs coming to us
in medical labs coming to mind straight away.
There are individuals who are literally paid to sit there
and make sure everything's going according to plan
to be available if something goes wrong.
Sometimes there's more than one
and they're being paid completely valid amounts of money
for what the loss of what the value is
for what they're doing,
but they may not do anything throughout that day.
So that RTO and RPO has been assigned to the products
and the service that's being completed
and that individual has been put up as the solution to that,
to minimize those numbers.
It's not always just we need a secondary location
to go to if something happens to our primary location
or we need backup service in case that's necessary.
It's every tool you can come up with
to make those numbers as low as possible.
I'll shift a little bit.
When we think about what I was referring to earlier
and the internet being the single point of failure,
we only have one firewall,
we only have one internet connection.
Some organizations have been able to navigate
the remote work scenario very, very well due to the pandemic.
And that has added a component to this.
Well, if our internet goes down
and all of our applications live in the cloud,
there's an enormous amount of mobility
that comes into that scenario.
Well, our applications are in the cloud,
our people can be very mobile.
Everyone's got laptops.
We did away with the desktop long ago.
They can pick up their laptops, they can go home,
they can go to a coffee shop,
they can do some things from their phone.
Those present potential recovery scenarios
in the event that, again, we're talking about
an internet outage at the organization's location
where its people are.
However, I think to say that out loud is kind of one thing
and then to expect it to happen as another
should the fiber get cut underneath the ground
out beside the building and all of a sudden,
there's no internet to stop everybody from working,
get them up, instruct them to go home,
instruct them to go to another location.
Sounds good, but we all know that along the way,
on the way home, things may happen,
there's still a significant amount of disruption
in that process, right?
I certainly trust people to go home
and continue to their workday,
but some people may take an extended lunch.
Some people might not be as comfortable with
or make an easier transition from the office
to their home location to continue to work.
So, well, the idea that the cloud brings
that portability to the organization,
there still is some people process there to say,
okay, the internet's out, everybody go home and work.
How much do we trust that?
How well is that going to work for our organization?
It's not a bad idea to think about an exercise
that tests that.
What do we know about people's ability to work from home?
And so then that connects us back to,
is it just worth the investment in an additional firewall,
another internet connection to make up for an outage
in either one of those scenarios
where we're very dependent on the internet?
Yeah, and we have multiple scenarios obviously where,
I mean, right out the gate,
I've been called paranoid multiple times during this,
and not during this podcast, but others,
and part of that is preparing for those worst case scenarios,
is a large part of what this is.
No, we don't wanna think about it,
but hey, let's mitigate it just in case.
Natural disasters, someone cutting cables,
whatever it is, it may happen, right?
Because just someone working on the street outside
can have an impact to people getting into the building, right?
Work from home scenarios, test restores,
disaster recovery and business continuity plans
play into this very heavily,
but I talk about them enough.
So if you have more questions, let us know.
The thing for me that comes from that,
because Scott's right,
we should as much as you can test these policies,
test these plans you put in place,
figure out where there's deficits in what you're doing.
And right out the gate, first question you can ask is,
hey, if this goes down,
if this tool was unavailable because of any reason,
how long would it take to come back up?
Ask your internal IT.
I mean, ask CIT if we're your internal, if we're your IT.
Ask us, because we have numbers on what we believe
we can get that done to you,
we can how quickly we can do that for you.
If you have goals in mind,
then your internal IT or your external IT
will work with you to come up with what those numbers are now
and do what they kind of bridge that gap.
Oftentimes it is a budgetary item
where maybe it just needs a little bit more money thrown at it.
So by doing these RTOs and RPOs,
you can find out if that's beneficial to the organization.
Starting with, here's all the things that can go wrong,
is my favorite way to do it.
But that's not beneficial to a lot of people.
I know some people prefer to go the route of,
how important is this and then build down from that,
rather than being paranoid first,
which I'm sure is a valid way to do it.
I'm in security, so paranoid at the first is where we start.
Yeah.
As we dig into this, I know we kind of talked about
in a lot of ways there are various levels of risk,
right, and that will largely impact
how quickly we want to recover.
There are a lot of different ways you can go about that.
There's, and we can dig into this.
You guys can tell me whether it makes sense to do it or not,
but you can have like mirrored sites for an example,
you got a hot recovery,
so the intent of staying up for a while,
you can go to the website,
so the intent of staying up all the time,
it's essentially what we're doing
when we throw something into the cloud.
But those things that are not quite as critical,
you still have the ability to decide how you want to recover to them.
At one of the, at the beginning,
I kind of alluded to a lot of people will say,
well, we just want everything up all the time,
which I agree with me too,
that gets back to the paranoid thing.
But the reality is, if everything went down,
you will have to pick.
How do I decide what's the most important thing to do?
So, informally, every organization knows what that is,
because when push comes to shove, they'll go,
okay, well, if you made me pick, I would pick this,
although I'll resist you every step of the way,
but now that I have to, I can do that.
Eventually, you can get to a point where you say,
in this particular instance, all I really need is,
you can do whatever term you want to do,
is I just need a cold system I can restore to,
or spare, or whatever the case may be.
So the question for you guys is,
do you want to go down that path too
and talk about what that looks like?
You started to allude to the acceptable recovery.
There is a flat out cost where someone will eventually say,
nope, it's just way too much.
I will not pay that to get this email server back up and running.
Yeah.
Todd, I heard you say something that's important,
and I know we're coming up on time.
And that was everybody inherently kind of knows in their mind
what they think that recovery time objective is, right?
And I think you're right.
Overwhelmingly, I have sat in too many meetings
where there was an assumption that was made by the business,
right, by business leadership that said,
well, we just kind of thought IT had that figured out for us.
They just knew that, you know, we want zero downtime or whatever,
right?
And IT didn't know that because the conversation hadn't taken
place.
They hadn't sat together in a room,
and they had to get the technology and the business together
and said, this is our expectation for recovery times,
for outage, and then give technology an opportunity to say,
well, you know, I hear you say two hours, the reality is eight.
And so we then, the business, need to understand the investment
required to shore up that six hours and to get that truth out
of the world. So everybody, technology, up through business
unit leadership and senior leadership understand what the
realities of those things are.
Yeah, I think one of the other potential pitfalls there is,
is business and IT are not talking the same language.
IT may have felt like they communicated what that cost
would be to get a different setting, and vice versa,
right, the business is saying, well, you should have known
obviously this is the case, and you're not always in alignment.
So at a minimum, having the conversation and making sure
that you're aligned is definitely going to be the right step.
I know we talked about a risk assessment at the beginning,
and quite frankly, it is the beginning to most powerful
conversations. You got to understand where you are.
If you don't know where you are, you don't know where you're
going.
Yeah, I'll say this, and I've mentioned this previously,
but I think you've hit the nail on the head for how I think
about it, which is that Aoteo and Apio is a business conversation.
And at least in my experience as someone who didn't start out
with that business mindset, I distinctly remember that moment
where I started to think that way, because it was the moment
that I started getting senior leadership to listen and understand
what I was actually saying, because it wasn't just, hey,
here's this cool tool that's going to make my life easier.
It was, here's this cool tool that's going to save the
organization time and money, which is such an obvious
distinction now, but really took me a while to get there.
And oftentimes when you see that, when you see that or feel an
excessive amount of burnout from internal IT, I tend to think
it's because of that disconnect.
They're taking on things that they think are meant to be
completing these tasks or being told they can't do them
because of that. So, I completely agree that having that
communication open from the business side first with this
RTO and RPO can really change that conversation, open that
communication easier, and find where those gaps are that,
again, were maybe just assumptions that it would work a
certain way. And the explanation that came from someone else
trying to make it work better just maybe wasn't expressed in
the way that worked for the leadership team or vice versa.
Yeah, just to kind of summarize that is, I think the way that
I phrased it was you informally know what it is, right?
Push comes to show if you'll be able to figure it out.
This process takes it from informal to formal.
Yeah.
We've covered a lot today and I feel like there's so much more.
I just wanted to give you guys an opportunity if there's
anything we didn't cover that you really wanted to say here
in today's podcast.
I'm going to start with a question for you.
What's the RTO and RPO a fun?
This is fun to do.
We should have started there.
It's just fun.
Yeah, I mean, I would say it's critical, right?
If it isn't clear at the beginning of the meeting, by the time
we're done, you should hopefully have made the connection that
just assuming is insufficient, you do need to do the deep dive.
You do need to do the formal planning and you do need to write
that down and make sure that what you've got in place can meet
what your expectations are.
Otherwise, unfortunately, you're set up for a bad day.
Yeah, and we want only good days.
So assessment, planning, knowing what you have.
If you ever need help, you can always reach out to us.
Thank you, Todd, Scott and Matthew for joining us today.
If you enjoyed this podcast, please like and subscribe.
If you want to know how you're feeling about us and these subjects,
if you have a topic you'd like us to discuss,
reach out to us at info at cIT-net.com
or head out to our website, cIT-net.com, slash, podcast.
Thank you for joining us.