Establishing Minimum Viability Featuring Constellation Energy

Minimum viability refers to the smallest set of essential capabilities—including people, processes, and technology—required to keep a business operational during a major disruption or cyberattack. It focuses on ensuring continuity when resources and systems are limited.

Minimum viability extends beyond infrastructure readiness. It requires leadership decision-making, cross-functional alignment, and clear prioritization of business outcomes. It is a strategic framework that helps organizations determine what truly matters when recovering from a cyber event.

With industry downtime averages reaching up to 24 days, most organizations cannot absorb the financial, operational, or reputational damage from prolonged outages. Minimum viability ensures the fastest path to restoring essential operations and reducing business impact.

Determining minimum viability involves cross-functional analysis of dependencies, business processes, identity systems, and operational workflows. Often, overlooked systems—such as identity management or jump services—are identified as essential for early-stage recovery.

Minimum viability requires shared ownership across IT, security, risk, operations, finance, and executive leadership. It is a collaborative “team sport” where recovery decisions and trade-offs must be aligned across the entire business to ensure resilience.

Please view video here for a time-stamped transcript

Hello and welcome to this episode of SHIFT Podcast.

That’s focused on establishing minimum viability, making minimum viability the most
valuable player for your business.

Hi everyone, I’m Vidya Shankaran, Field CTO at Commvault and I’m joined here today by Ha
Hoang CIO Commvault Technologies and Jay, CIO Constellation Energy.

Thank you for joining us here today.

Thanks for having us.

Thanks for having us.

Of course.

Typically, when we talk about minimum viability, the average downtime that’s recorded
across the industry, the optimistic industry stats as 24 days.

But for most businesses, that is too long to sustain.

It’s not only that, but also the dollar impact in revenue that it can have on businesses,
not to mention the reputational damage that the business sustains during the 24 days of

downtime.

So today, the industry defines minimum viability as a minimum set of capabilities that
includes the people, process, and of course the technology stack that make up that minimum

viable business.

And bringing up that minimum viability becomes the defining moment whether the business
can survive and thrive after a cyber attack.

So given the MV is the topic of our discussion here today, I have Ha.

and Jay joining us.

And my first question to Ha would be, how would you go about defining minimum viability
beyond what industry probably has a misconception around that it is just an IT checklist?

How do you lead it with a leadership mindset?

So for me, minimum viability is less tech stack and more decision clarity.

So it’s asking what are the smallest set of capabilities that we need to keep the business
moving while everything else is down, right?

So it’s a mindset that forces discipline, which is to prioritize outcome and not just
infrastructure, right?

So I think when you apply that lens, then recovery planning becomes a leadership
conversation about trade-offs and that it’s not just a technical exercise, right?

And then that also helps build shared accountability across the business units, risk and
um IT.

Makes perfect sense.

Now, since we have the pleasure of you joining us here today, Jay, what does minimum
viability mean for a critical infrastructure company like Constellation Energy, where

definitely downtime isn’t an option?

Well, I think I’d probably chime on a little bit with what you were talking about.

It’s the ultimate team sport.

Right?

I mean, it is not an IT only discussion.

It is not a discussion with individual business units.

It’s not a discussion with security, a discussion with IT.

It really is a discussion with everybody.

Because really what minimal viable company means is just that, right?

What does it mean for me to keep functioning my core business?

Right?

And what does that look like?

So to me, I think the most important message is being a team sport, because it’s not an
individual

It’s no one group can do it on their own.

I love that.

And I must ask both of you this.

I’d probably defer to Ha first.

Were there any gotchas or surprises that caught you off guard as you were drawing up the
list for minimum viable critical assets?

Yeah, absolutely.

There were a few.

Some of the foundational systems or applications

that we thought were kind of table stakes, you know, were certainly not there, right?

Or didn’t make it to our list.

And then I think just systems like identity that I think is more of an afterthought was
one where it’s pretty critical.

And at times um we’re focusing mainly on what the customer sees, which are the
applications, right?

But if you’re thinking about whether it’s a jump service, whether it’s identity, whether
it’s just base kind of interdependency systems,

Those are the ones that I think are critical.

Love it.

I would chime in that the whole thing’s got you.

And if they say that somebody tells you it’s not, then they’re making it up.

nobody’s done it before, right?

It the first time we’ve really started thinking about that, where we’ve talked about
minimal viable products forever, but not minimal viable company.

I think the biggest one for me is we had a very traditional view of the world where we had
high business value apps, medium business value apps, and low business value apps.

And we said, well, this is easy.

We’ll just recover the high business value apps and be done.

What we learned was that a whole bunch of those low business value apps probably did
something to feed or to provide something for the high business value app.

So thinking in what felt like very absolute terms doesn’t work when you’re talking about
minimal viable company, right?

Because you’re talking about a system, not individual applications.

And that was the biggest unlock for us.

And I would bet for a lot of folks.

I think that’s a fantastic

phrasing that he just used there, that it’s not minimum viable product, but it’s a minimum
viable business or minimum viable company.

So which brings me to the next point.

In all of this exercise, how much of a partnership have you enjoyed with your CISO and
especially in drafting some of those critical assets and who owns these recovery

decisions?

Yes, you called out the critical assets, but then who helps?

prioritize the recovery operations.

Yeah.

boy, as I said, there’s a team sport, but you also need a referee.

So I think in a lot of ways, the CIO and the CSO really acts a little bit like a referee
in that case, because when you start tabletopping it and look, we had a great partner that

helped us out in WWT and they really helped us kind of think through this and kind of go
through both the technical process, but also the

I’ll say procedural processes, because what you wound up learning is that everybody feels
their thing is the most important.

So I think the most important thing for the CIO and the CISO to focus on is how do you
play that judge and juror view, but also how do you make sure you focus on, you mentioned

some really core foundational technologies, identity, network, right?

Without that, nothing works.

So it’s also about helping people understand

that piece of the puzzle.

So that’s the way I think their role is, right?

Love that.

Back to you, Ha.

In all of this, back to Jay’s point around how this is a team sport, did you run into any
challenges in building the business case as you were presenting to probably the finance

team, the risk team, the compliance team?

And what were some of the misconceptions that were already seeped into those

lines of businesses that you had to dispel before you could sell the use case around
minimum viability?

Bringing those teams together, obviously, I think the framing of minimum viability had to
be different, right?

Had to be in business terms and not in kind of backup and recovery jargon, right?

So like for finance, it’s about, you know, protecting revenue continuity.

For the risk teams, it’s about limiting exposure.

And then for operations teams, it’s all about keeping the customers whole.

And so I think when the teams and the functions see their reflection in the minimal
viability strategy, that’s when alignment happens.

And then in terms of misconception, I think the biggest misconception is that minimum
viability is minimum effort.

As if it’s like lowering standards or accepting partial recovery.

That’s a great point.

The reality is it’s the opposite, right?

uh It’s really about discipline and uh focusing on what truly uh drives continuity and
resilience when every minute counts, right?

And then I think the other misconception is that it’s a pure technology play, right?

So boards and CIOs like us are expecting a checklist or an architectural diagram, but in
reality, it’s a business strategy conversation, right?

On how companies actually prioritize value under pressure, what they decide to protect and
why.

I love that tag line that you just had there, which is how to prioritize business value
under pressure.

I would probably…

bold it, highlight it, and emphasize ad nauseum because that is the critical nature of the
very MVC definition.

So which brings me to the next point.

We talked about strategy.

We talked about how it is a team sport.

But what are the key KPIs?

How do you even quantify and measure?

This is not your quintessential tangible metrics, is it?

Or am I missing something?

Is it your RPO, RPTO that you drive off of?

What would be the units of measurement of success based off of MVC?

I think for me, I’ll start maybe less on the metric side, then maybe you hit metrics.

But for me, it’s about making sure that you’re not only using the system in a crisis.

I think that’s a common misconception to sit there and say, we’re going to drill this and
we’re going to have this thing.

For us, we pivoted

all our backup and recoveries to Commvault because we wanted folks in this system every
day.

So we wanted to make sure that they knew how to use the system, how to work the system,
how to do all the ins and outs because, you know, we talk about being under pressure,

right?

That is not when you want to try a new thing.

So that’s one of the things.

And I’ll tack on to the last point you were talking about, which was another about DR,
right?

think the other common misconception is we already have DR.

Why do I need this?

Right?

I mean, I already have it.

And I think

again if you think about DR, it’s somewhat of a legacy mindset, right?

It has a very, for lack of a better term, kind of hole in the ground thought, right?

If I don’t have this one thing, what happens?

Well, I don’t think any of our worlds exist in less than five other clouds or five other
worlds.

So I really think it becomes about, one, changing the mindset, and then, two, changing
your operations to not only be doing something in a crisis.

So that’s the way I think about it.

Love that.

Totally agree.

Yeah, obviously, you know, we look at quantitative and qualitative, you know, metrics,
right, indicators.

And, you know, technically, everyone’s going to measure RPO and RTOs, right, and
percentage of your, you know, clean backup data and such.

But I think the thing that I also focus and track is how fast we can make confident
decisions under pressure, right?

Because I think readiness is not only about how fast we can recover or restore, but it’s
also how fast we can trust the data and the system that we’re restoring.

So how much of it actually boils down to operationalizing testing?

All of it.

A ton.

Yeah.

I mean, that’s what it always comes down to, right?

Preparedness, practice.

Look, in our world, we practice a lot.

We practice everything that we do.

because you want to make sure that when you really need it or when you’re under pressure,
you can execute it on it.

And I think this is no different.

Maybe the good news, the bad news is we’ve all had a lot of opportunities to practice this
recently, right?

Whether it’s been cloud outages or providers that do things, right?

We’ve had opportunities to practice this.

And that’s the other thing I would say is you have to take those opportunities to say,
don’t be afraid to leverage a system that you have, right?

You’ve built a system, you use this system.

How do I use it

to get myself back faster?

How do I use it to, whether it be a recovery of a particular cloud or an incident that’s
happening, right?

I think it’s about looking forward and using it and not keeping it off to this side like,
oh, do I have to do the DR thing?

Like, do I have to do that?

We all have this mindset.

Don’t set and forget.

Right, exactly.

Like just, it’s there, use it.

Yeah, and it’s definitely something that organizations need to iterate upon.

It’s not a

done and dusted with kind of an exercise.

It’s a living process that you need to continuously improve upon.

And let’s be honest, it’s also continually growing, right?

Data and everything is not slowing down.

most likely for probably everybody, the product you put in is a fraction of the size of
where you’re at now.

does change the game, right?

Exactly.

So which brings me to the next most pivotal question, which was harder.

Was it the technical execution or the cultural shift?

I’d say the cultural shift and the cultural change without question.

The technical work is complex, but it’s solvable.

You can automate and test your way through it.

But the hardest is the shift in mindset from, I think, where recovery is an IT task to
resilience is actually a shared

business capability.

Yeah.

Yeah.

I mean, I would agree.

I’ll say that the technical part’s easy because I have an amazing technical team and they
just make it look really easy.

But I do think the technology is solvable, right?

It’s ones and zeros and we can figure it all out.

The problem is this discussion was always, hey, IT, do your thing and let us know when
you’re done, right?

Which is not the conversation anymore.

And that to me is the biggest change when you now have to have all the business leaders in
a room that says, hey, we need to have a conversation about recovery.

And it’s not just, hey, let us know when you’re done, IT.

And that is the cultural shift.

I totally agree.

think, know, moving viability forces kind of uncomfortable conversations around
prioritization, right?

What really needs to happen in the first 24 hours versus what needs to wait.

And that’s where I think

we’re asking business leaders essentially to make trade-offs in real time, And those are
the tough conversations.

Yeah.

No, that makes perfect sense.

And especially to your point, where if you were to ask every business leader, they’re
going to come back saying, my AppStack is important.

Everything is important.

I’m most important.

Yeah, absolutely.

So having lived through

and exercise around building out your MVC, and of course it’s like we just discussed, this
is a living exercise.

But what are the key takeaways, battle scars that you would like to ensure that you would
love to share with your peers so that they don’t run into the same challenges as they are

building out their MVC?

I would say practice recovery, like it’s game day, right?

Because you can’t build resilience in a crisis.

It’s built in the reps that you take before.

Perfect.

I think for me, and you’ve mentioned it a couple of times and I can’t emphasize it enough,
is the core foundational layer.

I think traditionally we just don’t think about not having core foundational things such
as Active Directory, such as network, such as, all this stuff is now software defined more

so than it’s ever been.

And I think that is the biggest change to really respect and practice that

and understand, what’s it look like when I have to recover my core authentication before
any of my folks can do any work?

And that’s where we always forget.

The IT people can’t do any work without that.

And I think that is the ultimate battle scar.

And frankly, think it’s one of the things Commvault does better than anybody else, which
is kind of that Active Directory forest level recovery, which is so key and was one of the

main differentiators for us on why we selected the product.

Thank you.

Thanks for sharing that insight.

And before I let the two of you go, what are the one liners really hard hitting punchlines
that you would leave us with?

Gosh, I think I just said it.

Practice recovery like it’s game day.

Perfect.

Love that.

For me, it’s a team sport.

And you cannot just leave this to your IT team and say, hey, let me know when it’s done.

This is a team sport that you need everybody in the room to have the conversation.

Perfect.

Thank you so much for joining us here today and sharing your insights.

Very valuable.

And to all our viewers joining us virtually, if you’d like to take a deeper dive into
minimum viability concepts, please take a look at our Giga Om Analyst Report, which talks

more in depth around minimum viability, available on Commvault.com.

Thank you.