For years, recovery planning followed a familiar pattern. Build the plan, document the steps, and assume it will work when needed. For a long time, that approach held up. Hardware failures, isolated outages, even natural disasters – these were scenarios organizations could anticipate and plan for with some level of confidence.

But the equation has changed.

In this episode of STRIVE, I sat down with Commvault’s Jason Cray, Principal Product Experience, to explore a reality we continue to see across organizations of all sizes: Most don’t fail because they lack a recovery plan. They fail because they’ve never proven that plan will hold up under real pressure.

Watch the full episode.

Key Takeaways: Why Recovery Plans Break Down

• A documented plan isn’t the same as a proven one. If it hasn’t been tested in realistic conditions, it’s still an assumption.
• Recovery is a team sport. Security, infrastructure, and operations must align – or recovery slows down.
• Most investment still happens “left of boom.” Prevention matters, but recovery readiness often gets overlooked.
• Testing exposes gaps and builds confidence. Without it, organizations default to hope.
• Resilience is an operational discipline. It requires iteration, communication, and continuous improvement.

The Problem With ‘It Should Work’

On paper, recovery looks straightforward. You define when to recover to, what needs to come back, and where it should be restored. The process appears logical, structured, and manageable.

But as Jason points out, that simplicity rarely survives real-world conditions.

Plans are written in controlled environments, but they’re executed in chaos. When an incident hits, teams aren’t calmly stepping through documentation – they’re reacting, troubleshooting, and trying to align in real time. That’s where the gap emerges. Not between tools and technology, but between expectation and execution.

Sneak Peek: Why Plans Fail Under Pressure

In this moment from the conversation, Jason and I break down why having a plan isn’t enough – and what it actually takes to know a plan will work when it matters.

We’ve Seen This Before

What’s interesting is that this isn’t a new problem; it’s a familiar one, just in a different context.

If you go back to the early days of disaster recovery, organizations followed a similar pattern. Plans existed, but testing was inconsistent at best. Jason shared an example of spending an entire night helping a client pass a disaster recovery test they thought they were ready for. The plan looked solid. The execution told a different story.

Over time, organizations adapted. They tested more frequently, introduced failover exercises and, in some cases even ran production from secondary environments to prove readiness. That shift from assumption to validation is exactly what cyber resilience now requires.

The First Breakdown: Communication

If there’s one issue that consistently surfaces, it’s communication.

In many organizations, responsibilities are clearly defined – security handles prevention, infrastructure manages systems, and operations owns recovery. Individually, each team may be doing exactly what they’re supposed to do.

But recovery doesn’t happen in isolation. It depends on how well those teams work together when something goes wrong.

As Jason describes, too often it becomes a handoff model: “We’ve done our part, now it’s someone else’s turn.” That approach introduces delays, confusion, and ultimately risk. During a cyber event, coordination matters more than ownership.

The ‘Left of Boom’ Problem

Another pattern we continue to see is the imbalance in where organizations focus their efforts.

There’s significant investment in prevention – security tools, detection platforms, and defensive strategies designed to stop an attack before it happens. That investment is necessary, and it plays a critical role.

But far less attention is given to what happens after the event.

The assumption is that if enough effort is spent on prevention, recovery becomes a secondary concern. In reality, the opposite is true. At some point, something gets through. And when it does, recovery becomes the defining factor in how an organization responds.

From Hope to Evidence

This is where the mindset needs to shift.

It’s not about adding more tools or rewriting documentation. It’s about moving from a model based on hope to one grounded in evidence.

Jason highlights a key observation: The organizations that handle disruption well aren’t the ones that avoid incidents – they’re the ones that experience less impact when those incidents occur. They’ve tested their processes. They’ve validated their assumptions. They understand where their gaps are.

Most importantly, they’ve built confidence – not by believing the plan will work, but by proving it.

Start Small, Build Momentum

For many teams, the challenge isn’t understanding the problem – it’s knowing where to begin.

The answer isn’t to overhaul everything at once. It’s to start small and build from there.

Focus on one or two critical services. Understand what’s required to recover them. Bring together the teams responsible for those systems and test the process end-to-end. From there, expand the scope and continue refining.

This approach does more than improve recovery – it builds alignment, reinforces communication, and creates the foundation for broader resilience.

The Reality: No Plan Survives First Contact

One of the most honest moments in our discussion was this: Even the best plan won’t work exactly as written.

That’s not a failure – it’s expected.

Jason puts it simply: If you don’t have a plan, you will fail. But even if you do have one, it won’t unfold perfectly in the moment.

What matters is how prepared to adapt your teams are. Testing creates that adaptability. It builds the muscle memory needed to respond effectively when conditions don’t match expectations.

Watch the Full Episode

There’s much more we cover in this STRIVE conversation, including:

• Why recovery plans often fail despite being well-documented.
• What differentiates organizations that recover effectively.
• How communication gaps impact execution.
• Where to start when improving recovery readiness.
• Why testing is the foundation of resilience.

Watch now.

If you’ve ever questioned whether your recovery plan would actually work, this is a conversation worth your time.

FAQs

Q: Why isn’t having a recovery plan enough?

A: Because most plans are never validated under real-world conditions. Without testing, they remain assumptions rather than proven strategies.

Q: What causes recovery plans to fail?

A: The most common issues in recovery plans are lack of testing, poor cross-team communication, and gaps between documented processes and real execution.

Q: What does “left of boom” mean?

A: Left of boom refers to the focus on preventing incidents before they occur. Many organizations invest heavily here but underinvest in recovery capabilities.

Q: How often should recovery plans be tested?

A: Recovery plans should be tested regularly and under varied conditions. Testing should simulate realistic scenarios, not just controlled exercises.

Q: Where should organizations start?

A: Start with a small set of critical services, align the responsible teams, and test recovery end-to-end before expanding.

Q: What is the key mindset shift?

A: Moving from hope-based planning to evidence-based validation.

Chris Mierzwa is Senior Director, Portfolio Marketing, at Commvault.

We’ve spent years focusing on identity security in the context of people – who have access, what they can do, and how to control it. That model made sense when most activity in the environment was driven by human users.

But that’s no longer the case.

Machine identities – applications, services, APIs, and automated workloads – now play a central role in how modern systems operate. They authenticate, communicate, and execute tasks, often without direct oversight. And in many environments, they already outnumber human identities by a wide margin.

In this episode of STRIVE, I sit down with Dan Conrad, Principal Technologist and a fellow Field CTO at Commvault. We take a closer look at what that shift means – not just from a security perspective, but also from a governance standpoint. And we explore why so many organizations are still treating this as a secondary concern.

Watch the full episode.

Key Takeaways: Where the Risk Is Shifting

• Machine identities are growing faster than human identities, often by orders of magnitude.
• Governance models haven’t kept pace, creating blind spots in access and control.
• Visibility is the core challenge. Many teams don’t fully understand how machine identities behave.
• Privilege sprawl extends beyond users, with machine identities often holding persistent access.
• Resilience depends on understanding and managing the remit of these machine identities before they become a problem.

The Identity Model Has Changed

For a long time, identity management was relatively straightforward. You could map users to roles, define access policies, and build controls around predictable behavior. Even with complexity, the model was still anchored in human activity.

Machine identities have broken that model.

They’re created dynamically, often as part of development or deployment processes. They interact across systems in ways that aren’t always visible or well-documented or audited. And unlike human users, they don’t follow a clean lifecycle – they aren’t onboarded and offboarded in the same structured way.

That creates a different kind of challenge. It’s not just about controlling access anymore. It’s about understanding how that access is being used, how it evolves, and how it connects across the environment.

Sneak Peek: You Can’t Phish a Non-Human Identity

In this moment from the STRIVE discussion, Dan describes how attackers aren’t targeting non-human identities directly through phishing – they’re malicious actors using compromised human accounts through social engineering, as a steppingstone to escalate privileges and impersonate powerful machine identities. Once inside, techniques like pass-the-hash and overprivileged service accounts allow attackers to move laterally and vertically, even after passwords are reset.

The Governance Gap

The real issue isn’t that machine identities exist , it’s how they’re governed.

In most organizations, there’s a clear process for managing human access:

• Requests are approved.
• Permissions are reviewed.
• Changes are tracked.

There’s a level of discipline that comes from years of focus on user identity. However, machine identities often fall outside of that structure. They’re created quickly to support applications or automation. They’re granted the permissions needed to function, sometimes more than necessary. And over time, those permissions persist. These overprovisioned accesses are rarely audited, reviewed, and more importantly rarely reduced.

That’s where the gap forms.

It becomes difficult to answer basic questions about access. Not because the information doesn’t exist, but because it hasn’t been organized or managed in a way that makes it usable.

Visibility Before Control

When organizations start to address this problem, the instinct is often to tighten controls.

• Limit permissions
• Restrict access
• Apply new policies

But control without visibility doesn’t solve much.

If you don’t understand how identities are being used, the business context of it in terms of  where they connect, what they interact with, and how they move across systems, then any attempt to restrict them becomes reactive and could result in slowing down business operations.

That’s why visibility needs to come first.

Once you can see how machine identities behave, patterns start to emerge. You can begin to understand where access is excessive, where dependencies exist, and where risk is concentrated. From there, governance can become more precise and more effective.

A Different Kind of Privilege Problem

Privilege sprawl isn’t new. Most organizations have spent years trying to manage excessive access among human users.

Machine identities introduce a similar issue, but with a different dynamic. Their access is often embedded into systems. It’s persistent, automated, and rarely questioned once it’s in place. That makes it harder to detect and easier to overlook.

And when something goes wrong, those identities can become a pathway for malicious actors to exploit

Where to Begin

For most organizations, the challenge isn’t awareness, it’s knowing where to start.

The first step isn’t a major transformation. It’s building clarity. Understanding how many machine identities exist. Where they’re being created. What permissions they have. How they’re used. And most importantly, confirming that a human user is mapped to a collection of non-human identities for the purposes of auditability and accountability.

Those questions sound simple, but they’re often difficult to answer. And that’s exactly why they matter. Because once you can answer them, you’re no longer operating in the dark.

Watch the Full Episode

In this installment of STRIVE, we go deeper into how machine identities are changing the way organizations should think about access, governance, and resilience. It’s a practical conversation about what’s happening now – and what needs to change moving forward.

Watch now.

Resource

If you’re interested in learning more about this topic, check out this e-book on non-human identities.

FAQs

Q: What is a machine identity?

A: A machine identity is a non-human identity used by applications, services, or systems to authenticate and interact with other resources.

Q: Why are machine identities becoming a bigger risk?

A: Because they are increasing in number, often have persistent access, and are not always governed as strictly as human users.

Q: How are they different from user identities?

A: They operate continuously, are embedded in automated workflows, and often lack structured lifecycle management.

Q: What is the biggest challenge organizations face in governing non-human identities?

A: Visibility. Many teams don’t have a clear understanding of how many machine identities are created, used, or interconnected.

Q: How does this impact resilience?

A: If compromised, machine identities can enable a malicious actor’s rapid movement across systems, making incidents harder to contain and recover from.

Q: Where should organizations start?

A: By identifying machine identities, understanding their permissions, and building governance practices that match their scale and complexity. And most importantly, confirming that a human user is mapped to a collection of non-human identities for the purposes of auditability and accountability

Vidya Shankaran is Field CTO at Commvault.

For decades, IT operations focused on uptime:

• Keep the infrastructure running.
• Hit your recovery time objective (RTO).
• Meet your recovery point objective (RPO).

But modern cyber threats don’t respect infrastructure boundaries – and recovery isn’t just about restoring systems anymore. It’s about restoring clean, trusted data – across teams, under pressure.

In this episode of STRIVE, I sat down with Stephen Foskett, founder and president of the Futurum Group’s Tech Field Day, to discuss an emerging discipline: resilience operations – or ResOps.

And it’s more than a buzzword. It’s a shift in how organizations think about recovery intelligence.

Watch the full episode.

Key Takeaways: What ResOps Changes

• ResOps moves recovery from infrastructure-focused to business-focused. It’s not just about bringing systems back online – it’s about restoring trusted, usable data.
• Traditional RTO and RPO metrics aren’t enough anymore. Mean Time to Clean Recovery (MTCR) is emerging as a more meaningful way to measure resilience.
• Breaking down silos is foundational to cyber readiness. Security, infrastructure, and DevOps must operate in sync – not in parallel.
• Resilience is an operational discipline, not a tool. Culture, communication, and coordination matter as much as technology.
• Recovery intelligence is becoming a competitive differentiator. Organizations that recover cleanly and quickly protect revenue, reputation, and trust. 

From IT Ops to ResOps: What’s Changed?

Stephen reflects on an earlier era of IT where teams often supported systems without fully understanding the business applications they powered. Recovery meant restoring infrastructure. Today, that model falls short. Modern environments are:

• Distributed
• Cloud-based
• DevOps-driven
• Security-sensitive
• Deeply integrated with revenue streams

ResOps acknowledges that recovery is no longer an isolated IT function. It’s a cross-functional discipline that helps connect infrastructure, software development, and security with real business outcomes.

Why Traditional Metrics Don’t Tell the Whole Story

RTO. RPO. These metrics have guided disaster recovery planning for years. But as Stephen explains, restoring quickly isn’t enough if the data you restore isn’t clean.

Enter a more meaningful metric: MTCR. It’s not just how fast you recover; it’s how fast you can recover to a verified, trusted state.

In a ransomware event, that difference matters enormously. Restoring compromised data can restart an attack cycle. ResOps focuses on restoring operational integrity – not just functionality.

Sneak Peek: Why Clean Recovery Matters

In this moment from STRIVE, Stephen explains why traditional recovery metrics miss the mark – and why recovery is a cross-functional discipline.

The Real Barrier: Organizational Silos

Technology isn’t usually the biggest blocker to resilience. Structure is. Security teams often report to one executive. Infrastructure teams to another. Application teams to yet another. Each with different priorities, different incentives, and different definitions of success.

ResOps challenges that fragmentation.

Stephen discusses how collaborative workshops and cross-functional alignment are helping break down those silos. Because during a cyber event, organizational misalignment slows recovery more than tooling gaps ever will.

Why Commvault Is Leaning Into This Conversation

STRIVE isn’t about product features. It’s about how recovery thinking is evolving. ResOps aligns closely with what we see in the field:

• Customers struggling with coordination during incidents.
• Organizations restoring infrastructure but questioning data integrity.
• Leadership asking for metrics that reflect real business impact.

The concept of MTCR reframes recovery intelligence around business trust – and that’s where the industry is heading. Recovery is no longer a back-office process. It’s an executive concern.

The Future of Recovery Intelligence

Looking ahead, ResOps is likely to mature rapidly. Over the next 12–18 months, organizations are expected to:

• Integrate security and recovery workflows more tightly.
• Adopt new recovery-focused metrics.
• Operationalize resilience earlier in application lifecycles.
• Invest in intelligence that distinguishes clean data from compromised data.

Cyber threats are accelerating. Recovery strategies must evolve at the same pace. ResOps helps provide a framework for doing that.

Watch the Full Episode

In this episode, we discuss:

• How ResOps differs from traditional IT operations.
• Why MTCR is helping to reshape recovery metrics.
• What organizational alignment looks like in practice.
• How DevOps culture influences resilience.
• Where recovery intelligence is expected to head next.

Watch now.

If you’re responsible for cyber readiness, continuity, or recovery strategy, this is a must-watch discussion.

FAQs

Q: What is ResOps?

A: ResOps (Resilience Operations) is an emerging discipline that integrates IT operations, security, DevOps, and business stakeholders to help improve recovery intelligence and organizational resilience.

Q: How is ResOps different from traditional IT operations?

A: Traditional IT ops focuses primarily on infrastructure uptime. ResOps expands that focus to include clean data recovery, cross-functional coordination, and business alignment.

Q: What is Mean Time to Clean Recovery (MTCR)?

A: MTCR measures how quickly an organization can restore verified, clean data and resume safe operations after a cyber event – not just how quickly systems are brought back online.

Q: Why are metrics like RTO and RPO insufficient in modern environments?

A: They measure speed and data currency, but not data integrity. In ransomware scenarios, restoring compromised data can extend disruption.

Q: How can organizations start implementing ResOps?

A: Begin by:

• • Aligning security, infrastructure, and DevOps teams.
  • Evaluating recovery metrics beyond RTO/RPO.
  • Testing clean recovery processes.
  • Breaking down operational silos.
  • Incorporating resilience thinking earlier in system design.

Q: Why is recovery intelligence becoming more important?

A: As cyber threats grow more sophisticated, the ability to recover cleanly, quickly, and confidently directly impacts revenue, customer trust, and regulatory posture.

Darren Thomson is a Field CTO at Commvault.

Scaling a data-driven company is hard. Scaling one while meeting GDPR requirements, managing thousands of customers, enabling analytics teams, and standing up new infrastructure in under two weeks? That’s a different level of complexity.

In a recent episode of STRIVE, I sat down with Asif Dromi of monday.com and Ben Herzberg of Commvault to unpack what it really takes to operationalize data security at scale – not in theory, but in practice. This isn’t a high-level conversation about best practices. It’s a real-world look at how security, compliance, automation, and infrastructure decisions intersect when the clock is ticking.

Watch the full episode.

If you’re a CISO, data leader, architect, or compliance owner, this episode gives you something more valuable than theory. It shows how:

• A fast-growing enterprise handled GDPR pressure without stalling innovation.
• Infrastructure as code can simplify audits.
• Automation reduces risk instead of increasing complexity.
• Security and business agility don’t have to compete.

It’s rare to hear directly from operators who’ve done this under real constraints. That’s what makes this STRIVE conversation different.

Key Takeaways: Operationalizing Data Security at Scale

• Compliance and growth don’t have to compete. Monday.com demonstrates how GDPR requirements and rapid expansion can coexist when security is built into architecture from the start.
• Manual permissions don’t scale. Automation does. Infrastructure as code and API-driven access controls can turn governance from a bottleneck into a force multiplier.
• Role-based access must evolve with data usage. As more teams depend on analytics, visibility and fine-grained controls become important to help prevent permission sprawl.
• Operationalized security means visibility. It’s not just about setting policies – it’s about monitoring, auditing, and adapting controls dynamically as environments change.
• Speed is possible when architecture is intentional. A compliant European data warehouse stood up in under two weeks because governance, automation, and tooling were designed to scale.
• Security maturity enables innovation. When permissions, infrastructure, and compliance are programmable, organizations can move faster.

The Real Challenge: Growth + Compliance + Speed

For monday.com, the challenge wasn’t just storing European data in Europe. It was:

• Enabling GDPR compliance and regional data residency.
• Making sure employees only accessed relevant data.
• Maintaining visibility and auditability.
• Supporting analysts and developers who needed fast access.
• Doing it all under intense business timelines.

As Asif explains in the episode, becoming a data-driven organization means internal access expands rapidly. The more teams rely on analytics, the more complex permissions become.

And that’s where many organizations hit a wall. Security becomes manual, permissions become fragile, and compliance becomes reactive. That’s not operationalized security. That’s a house of cards.

Designing Security into the Architecture from Day One 

One of the most compelling parts of the episode is how monday.com approached the problem architecturally. Instead of retrofitting compliance, it built:

• A dedicated European data warehouse.
• Clear role-based access controls.
• Fine-grained permission models.
• Automated governance layers.

Ben describes what happens in many large organizations: Over time, permissions accumulate in layers, often without central visibility. Eventually, no one is confident about who can access what. Operationalizing security means avoiding that drift. It means building systems where governance scales automatically as usage grows.

Automation Is the Force Multiplier

If there’s one theme that runs through this episode, it’s automation. Instead of treating permissions as tickets and manual updates, monday.com wrapped their infrastructure in code. Databases, roles, and access policies could be created and modified programmatically.

The result? A compliant, scalable environment stood up in less than two weeks. That’s not luck. That’s architecture. And it’s a powerful reminder that security doesn’t slow you down when it’s built correctly. It enables speed.

What Operationalizing Data Security Really Means

“Operationalizing” gets used a lot. In this episode, it’s defined as:

• Continuous visibility into sensitive data.
• Centralized and automated permission management.
• Access tracking.
• Integration with collaboration tools.
• Policies that adapt as users and data grow.

Static controls don’t scale. Manual workflows don’t scale. Security must become dynamic – part of the operating fabric of the organization. And that shift is where many enterprises struggle today.

Watch the Full STRIVE Episode

In the discussion, you’ll hear more about:

• How monday.com structured its European data warehouse.
• The biggest lessons learned during rapid implementation.
• Why automation was non-negotiable.
• What companies often underestimate about permission sprawl.
• How to think about operationalizing governance before AI initiatives expand.

Watch now.

FAQs 

Q: How can small teams implement scalable data security?

A: Start with a clear permissions model and infrastructure-as-code tools. Automate permission management early to help avoid manual bottlenecks as you grow.

Q: What role does automation play in compliance?

A: Automation helps enable consistency, reduce errors, and simplify audits. Using APIs and scripts, you can monitor and adjust permissions dynamically.

Q: How long does it typically take to set up a compliant, scalable data environment?

A: With the right planning and tools, organizations like monday.com have achieved this in less than two weeks. Speed depends on scope and existing infrastructure.

Q: What are best practices for operationalizing data security?

A: Implement role-based access controls, automate permission management, monitor access logs regularly, and integrate security tools with collaboration platforms for real-time oversight.

Chris Mierzwa is Senior Director, Portfolio Marketing, at Commvault.

Key Takeaways

• Compliance frameworks codify lessons learned from real-world failures and help organizations strengthen resilience, governance, and operational stability.
• Organizations that approach compliance as a trust-building initiative can help strengthen customer confidence, partner relationships, and brand credibility.
• Regulatory alignment and strong risk controls can help improve insurance outcomes by demonstrating a mature and resilient security posture.
• Mapping compliance requirements to measurable business outcomes enables organizations to connect resilience investments directly to revenue protection and continuity.
• Cyber resilience capabilities such as immutable backups, rapid recovery, and governance frameworks help organizations turn compliance into a competitive advantage.

In boardrooms across Europe and beyond, compliance has become a loaded word. It conjures images of endless documentation, mounting regulatory pressure, and the looming threat of fines.

GDPR. NIS2. DORA. The acronyms keep coming, and for many organizations, it can feel like they are choking on regulation.

But what if we’ve been looking at compliance the wrong way? What if compliance isn’t just about avoiding penalties – but about building a better, stronger, more resilient business?

The Insurance Analogy: Rules That Exist for a Reason

There’s a useful parallel between compliance and insurance.

When you insure your car, the insurer sets certain conditions. Your brakes must work. Your tires shouldn’t be bald. An alarm system might be required. You can argue about the inconvenience, or the cost – but fundamentally, those rules exist because they help reduce risk. They help make accidents less likely. They help protect both you and others.

And here’s the key point: Those requirements are usually a good idea, whether you buy the insurance or not.

Regulation works in much the same way. Governments and regulators don’t create frameworks because they enjoy it. Regulations are responses to real-world failures – data breaches, operational disruptions, systemic risk. They codify lessons learned the hard way.

You may object to the burden. You may find it frustrating. But when you look closely at what these frameworks require, it’s hard to argue that the core principles are unsound.

• Protect customer data.
• Enable operational resilience.
• Know your supply chain risk.
• Be able to recover from cyber incidents.
• Demonstrate governance and accountability.

None of that is a bad idea.

From Avoiding Fines to Enabling Trust

Too often, compliance is framed defensively: “Do this so you don’t get fined.” “Do this so you don’t go to jail.”

That’s a low bar. And it’s a missed opportunity. When we shift the perspective, compliance becomes something much more powerful. It becomes a driver of trust.

Take GDPR as an example. At its heart, it’s about protecting personal data. If your organization implements strong data protection practices – not just to tick a box, but because your systems genuinely safeguard customer information – that builds trust. Customers are more confident doing business with you. Partners are more willing to integrate with you. Regulators view you as lower risk.

Trust is not a regulatory outcome. It’s a commercial advantage.

The same applies to the Digital Operational Resilience Act. It’s not just about reporting incidents; it’s about being able to withstand and recover from disruption. In a world where cyberattacks are inevitable, resilience is not optional. It’s foundational to continuity, reputation, and long-term value.

When compliance drives resilience, resilience drives business stability – and stability drives growth.

Regulation and Insurance: A Feedback Loop

There’s also a natural alignment between regulation and insurance markets. When regulators mandate certain standards, insurers quickly follow. Organizations that demonstrate compliance and strong risk controls are more attractive to underwriters. They may benefit from better terms, broader coverage, or more favorable premiums.

This creates a reinforcing cycle:

• Regulation sets minimum standards.
• Organizations strengthen their controls.
• Insurers reward stronger risk postures.
• Markets become more stable and resilient.

Compliance, in this context, becomes a signal to the market: We take risk seriously.

The Missing Link: Mapping Compliance to Business Outcomes

One of the most important opportunities for organizations – particularly technology providers – is to make the “line of sight” between compliance and business value explicit.

For example:

• If a product creates immutable backups, that helps support regulatory requirements around data integrity.
• If it enables rapid recovery from cyber incidents, that helps align with operational resilience mandates.
• If it provides clear audit trails and reporting, that helps support governance and oversight requirements.

But it shouldn’t stop there. The next step is to articulate the business benefit:

• Immutable backups help reduce the impact of ransomware – and protect revenue.
• Faster recovery helps minimize downtime – and preserves customer confidence.
• Strong governance helps reduce regulatory scrutiny – and enhances brand credibility.

This mapping is critical. Compliance is not the end goal; it’s the mechanism that enables the outcomes that businesses care about: continuity, reputation, customer trust, and competitive differentiation.

Compliance as Innovation, Not Obligation

There’s a tendency to treat compliance as a “get-it-done” exercise. A cost center. A necessary evil.

But if we look at history, many best practices that are now considered fundamental to modern IT and security originated in regulatory or insurance requirements. Over time, they became embedded in how well-run organizations operate.

Encryption. Access controls. Incident response planning. Business continuity testing. Third-party risk management.

At one time, these may have been viewed as regulatory burdens. Today, they are table stakes for any serious enterprise.

The organizations that treat compliance as an innovation catalyst – rather than a checkbox exercise – are often the ones that pull ahead. They embed resilience into their architecture. They design with governance in mind. They turn regulatory requirements into product capabilities and customer value propositions.

Cyber Resilience: Where Compliance and Strategy Converge

This is where cyber resilience becomes central.

Modern regulations increasingly recognize a simple truth: Prevention is not enough. Incidents will happen. The differentiator is how well an organization can respond and recover.

Cyber resilience – the ability to withstand, recover from, and adapt to cyber disruption – is no longer just a security concern. It’s a strategic imperative. It supports regulatory compliance, yes. But more importantly, it underpins operational continuity and business confidence.

When organizations invest in resilient architectures, immutable data, rapid recovery capabilities, and robust governance frameworks, they are not merely satisfying regulators. They are building durable enterprises.

A Different Conversation About Compliance

Perhaps it’s time to change the narrative.

Instead of asking, “What’s the minimum we need to do to comply?” we should be asking:

• How does this regulation make us stronger?
• What good practice is being codified here?
• How can we use this to enhance trust with customers and partners?
• Where does this create a competitive advantage?

Compliance done well is not about fear. It’s about foresight.

It reflects lessons learned across industries. It embeds best practice into everyday operations. And when connected clearly to product capabilities and business outcomes, it becomes a powerful commercial story.

Yes, regulation can feel burdensome. Yes, the acronyms keep coming. But underneath the paperwork lies something far more valuable: a framework for running a better business.

Compliance isn’t just about avoiding penalties. It’s about enabling resilience. And resilience, ultimately, is what drives sustainable success. Learn more about how Commvault enables data protection to help your organization meet compliance requirements here.

FAQs

Q: Why should organizations view compliance as more than a regulatory obligation?

A: Compliance frameworks often reflect best practices developed in response to real-world cyber incidents, operational failures, and governance challenges. Organizations that embrace compliance strategically can help strengthen resilience, improve trust, and create long-term business value.

Q: How does compliance contribute to customer trust?

A: Strong compliance practices demonstrate that an organization takes data protection, governance, and operational continuity seriously. This can help increase customer confidence, strengthen partner relationships, and position the organization as a lower-risk business.

Q: What is the connection between compliance and cyber resilience?

A: Modern regulations increasingly focus on an organization’s ability to recover from disruptions rather than solely preventing them. Investments in resilient infrastructure, immutable backups, and rapid recovery capabilities can help organizations maintain continuity during cyber incidents.

Q: How can compliance positively impact insurance and risk management?

A: Organizations with mature compliance programs and strong security controls are often viewed more favorably by insurers. This can lead to better coverage options, improved policy terms, and potentially lower premiums.

Q: Why is it important to connect compliance initiatives to business outcomes?

A: Compliance efforts are most effective when organizations clearly demonstrate how controls support broader goals such as protecting revenue, reducing downtime, and preserving customer trust. This helps leadership view compliance as a strategic investment rather than a cost center.

Q6: How can organizations turn compliance into a competitive advantage?

A: Businesses that embed resilience, governance, and security into their products and operations can differentiate themselves in the market. By proactively aligning with regulatory expectations, organizations can strengthen their reputation and create greater confidence among customers and stakeholders.

Darren Thomson is Field CTO at Commvault.

Key Takeaways

• Operational sovereignty focuses on who can access systems and under which jurisdictions they operate.
• Vendor access, telemetry flows, and support pathways can create hidden sovereignty gaps.
• Operational sovereignty is harder to certify because it requires continuous visibility and auditing.
• Organizations must be able to demonstrate and document every access pathway into sovereign environments.

Ask most organizations where their sovereignty program is strongest, and the answer is usually some version of the same two things: data locality and encryption. They know where their primary data lives. They’ve implemented bring-your-own-key or hold-your-own-key arrangements. They can point to certifications.

Ask them who accessed their sovereign environment in the last ninety days, from which countries, and under which legal jurisdictions – and the confidence tends to evaporate.

Operational sovereignty is the hardest pillar to audit, the most likely to be underestimated, and the most common place where a sovereignty posture that looks solid on paper breaks down in practice. The Digital Sovereignty Readiness Report names it as one of the four pillars – this post goes further.

The question most organizations can’t answer: ‘Who accessed your sovereign environment in the last 90 days, from which countries, and under which legal jurisdictions?’

What Operational Sovereignty Actually Means

Operational sovereignty is not about where data lives. It’s about who runs the environment – and who can reach it. It covers three things that most sovereignty programs treat as implementation details rather than first-class concerns:

• Personnel access and jurisdiction. Every person who can access your sovereign environment – for support, maintenance, monitoring, or incident response – operates under a defined legal jurisdiction. If a support engineer in a country subject to a foreign data access law can reach your systems, the sovereignty of your infrastructure is only as strong as that engineer’s legal exposure.

Most organizations, when they audit this for the first time, find at least one support pathway that crosses a jurisdiction boundary they hadn’t mapped.

• Third-party and vendor access. Your sovereignty boundary extends to every vendor, managed service provider, and software platform with access to your sovereign environment. ITSM platforms, monitoring tools, SIEM systems – if these sit outside your sovereignty boundary but have access to data or metadata within it, you have a gap that data locality controls cannot close.
• Telemetry, billing, and control-plane traffic. Data sovereignty programs focus on primary data. Operational sovereignty requires mapping where everything else goes: the telemetry your infrastructure generates, the metadata your monitoring systems collect, the billing data your provider processes. These flows can cross jurisdiction boundaries even when primary data doesn’t – and they are rarely mapped.

Why This Pillar Is Harder To Certify – and Why That Matters

Data locality is relatively straightforward to document. You can point to a storage region, a data residency agreement, a third-party audit. Operational sovereignty doesn’t have the same paper trail. There is no certification that guarantees the jurisdictional status of every support engineer who might access your environment.

This is precisely what makes it both the hardest pillar to audit and the most important to get right. It also connects directly to the minimum viable sovereignty challenge: applying the right operational controls to the right workloads requires knowing what those controls are – and operational sovereignty is where that knowledge is most commonly absent.

The Supply Chain Dimension

NIS2, which extends cybersecurity obligations across energy, transport, healthcare, and digital infrastructure sectors, now requires organizations to assess the cybersecurity practices of their technology suppliers. For sovereignty programs, this has a direct implication: vendor sovereignty posture is no longer a procurement nicety. It is an auditable requirement.

That means asking new questions of every provider in your sovereignty boundary: Where are your support personnel located? Under which legal jurisdiction do they operate? What happens to the access they have to my environment if your company is acquired by a non-EU entity?

What Good Looks Like

An operationally sovereign environment has four characteristics that can be demonstrated, not just documented:

• Every access pathway into the sovereign environment is mapped – not just primary access, but vendor access, support access, and monitoring system access.
• The jurisdictional status of every person or system with that access is documented and audited on a defined cadence.
• Telemetry, metadata, and control-plane traffic flows are inventoried and either contained within the sovereignty boundary or explicitly assessed and accepted as out-of-scope.
• The organization can answer the ninety-day access question – precisely, with evidence.

One more thing: Operational sovereignty doesn’t end at access control. If recovery requires personnel who operate outside your sovereignty boundary, the posture fails at the moment of an incident. That’s the subject of the fourth post in this series.

The Digital Sovereignty Readiness Report includes a direct assessment question on operational sovereignty.

FAQs

Q: What is operational sovereignty?

A: Operational sovereignty addresses who manages and accesses an environment, including personnel, vendors, and support systems. It extends beyond where data is stored.

Q: Why is operational sovereignty commonly overlooked?

A: Many organizations focus primarily on data location and encryption. Access pathways, support personnel, and telemetry flows are often not fully audited.

Q: How do vendors impact sovereignty posture?

A: Vendors and managed service providers may have access to sensitive systems or metadata. Their legal jurisdictions and operational practices can affect overall sovereignty compliance.

Q: Why are telemetry and metadata important?

A: Even if primary data remains local, telemetry and metadata may cross jurisdictional boundaries. These flows can create compliance risks if left unmanaged.

Q: What does a strong operational sovereignty model include?

A: It includes mapped access pathways, documented jurisdictional controls, audited vendor access, and visibility into all telemetry and metadata flows.

Alex Zinin is VP/GM, Managed Service Providers, at Commvault.

Key Takeaways

• Sovereign architectures often prioritize audits and access controls over recovery readiness.
• Recovery personnel, backup systems, and key custody models can create sovereignty gaps during incidents.
• Consistent controls across primary and recovery environments are essential.
• Sovereignty-ready resilience requires tested recovery procedures under realistic conditions.

Picture the moment. The attack has already happened. The incident response team is assembling. Someone must decide which systems come back first, in what order, using the correct recovery points.

And then someone realizes: The personnel with recovery system access are based in a different country. Worse, the recovery environment itself (hosted in a cloud region, a partner datacenter, or a secondary site) was never subject to the same sovereignty controls as the primary data.

The practice wasn’t subject to the same sovereignty controls as the primary data. The regulator is asking for status. The clock is running.

This is the scenario most sovereign architectures were not designed for – and the one the Digital Sovereignty Readiness Report calls out directly: most sovereign applications are designed for the audit, not the incident.

Most sovereign applications are designed for the audit, not the incident. The difference becomes visible at the worst possible moment.

The Recovery Blind Spot in Sovereign Architecture

Sovereignty programs are built around access control – who can reach the data, under what authority, through what pathway. That architecture is necessary. It is not sufficient. And it connects directly to the operational sovereignty gaps explored in the third post in this series: If the people who run your environment operate outside your sovereignty boundary, that problem doesn’t disappear during an incident. It becomes the problem.

What access control leaves unanswered is the harder question: What happens after an incident, when recovery is not just a technical operation but a legally constrained one?

A ransomware attack on a regulated European organization doesn’t simply create a recovery problem. It creates a recovery problem that must be solved within a jurisdiction, using personnel with appropriate authorizations, against recovery points that can be demonstrated to be clean and uncompromised.

The sovereign architecture designed to protect the data can make recovery harder if resilience wasn’t built into the original design.

The Specific Failure Modes

The ways sovereign recovery architectures fail are predictable – and common:

• Recovery personnel outside the sovereignty boundary. The engineers who know the recovery systems may operate in a different jurisdiction. Under pressure, using them is the path of least resistance. It is also a sovereignty violation at the moment it is least convenient to have one.
• Backup infrastructure without matching controls. Primary sovereign environments are carefully controlled. Backup infrastructure – particularly older or secondary environments – is frequently not subject to the same sovereignty requirements. If recovery points are stored or processed outside the boundary, compliant recovery is not available from compliant infrastructure.
• Key custody under crisis conditions. Hold-your-own-key arrangements are designed for normal operations. Under crisis conditions – with primary systems compromised and time pressure acute – the key custody model that works in a routine maintenance window may become an obstacle to recovery. If this hasn’t been tested, it’s an assumption, not a control.
• Cross-environment governance gaps. Organizations operating across multiple sovereign tiers – which is most of them – often have strong controls in primary environments and weaker controls in secondary environments that are also part of the recovery path. Consistency across the full estate is what auditors will look for. Gaps in secondary environments become visible exactly when consistency matters most.

Why Sovereignty Controls Can Complicate Recovery

The same controls that make a sovereign environment defensible to an auditor can make it harder to recover from. Data movement restrictions that prevent unauthorized exfiltration also constrain recovery orchestration. Key custody arrangements that ensure no provider can access your data without authorization also add friction when you need to restore quickly.

None of this means these controls are wrong. It means they have to be designed with recovery in mind from the start – not added to an architecture where recovery was an afterthought. This is the core of the minimum viable sovereignty principle: Calibrating controls to actual requirements includes recovery requirements, not just access control requirements.

What Sovereignty-Ready Resilience Requires

• Clean recovery validation. Proving that recovery points are free from compromise before restoring to production – not just recent, but uncompromised. In a ransomware scenario, a recent backup may itself be compromised. The ability to identify and restore from a known-clean recovery point, validated before it’s needed, is a sovereignty requirement, not just a disaster recovery requirement.
• Cross-environment governance. Consistent sovereignty controls and audit evidence across the full estate – not just the primary sovereign deployment. Every environment in the recovery path must meet the same requirements as the primary environment.
• Tested under realistic conditions. Regular exercises that validate recovery under the conditions that will actually exist during an incident: the legal constraints that apply, the personnel who are available, the recovery points that are clean. An annual disaster recovery test that doesn’t account for sovereignty constraints is not a sovereignty-ready exercise.

The Question To Add To Your Sovereignty Review

There is a direct way to assess whether your recovery architecture meets the same sovereignty requirements as your primary data environment: Ask it as a question and require an honest answer.

Can you recover your sovereign data, cleanly, within defined tolerances, using personnel operating within your sovereignty boundary, right now – under real conditions, not a controlled exercise?

For most organizations, the honest answer reveals a gap. The organizations that find it now – before the incident – will be best prepared with evidence when the regulator asks for it. The ones that don’t will be building it under pressure, in front of the people they least want to disappoint.

The Digital Sovereignty Readiness Report includes a direct recovery architecture assessment question.

FAQs

Q: Why is recovery important to digital sovereignty?

A: Sovereignty is incomplete if organizations cannot recover data within the same legal and operational boundaries used to protect it.

Q: What are common sovereign recovery failures?

A: Common failures include recovery personnel operating outside the sovereignty boundary, backup infrastructure lacking matching controls, and inconsistent governance across environments.

Q: How can key custody complicate recovery?

A: Hold-your-own-key models strengthen security during normal operations, but they can slow recovery efforts during incidents if not properly tested.

Q: What is clean recovery validation?

A: Clean recovery validation confirms that recovery points are free from compromise before systems are restored. This is especially important in ransomware scenarios.

Q: How should organizations test sovereignty-ready resilience?

A: They should conduct realistic exercises that account for legal constraints, operational availability, and validated recovery points – not just standard disaster recovery testing.

Alex Zinin is VP/GM, Managed Service Providers, at Commvault.

Key Takeaways

• Minimum viable sovereignty (MVS) focuses on applying the right level of control to the right workloads.
• Treating all workloads equally can lead to unnecessary complexity and costs or insufficient protection.
• Organizations typically fall into three sovereignty profiles: true sovereign, regulated enterprise, and hybrid multi-cloud.
• Consistent governance across mixed environments is one of the biggest operational challenges.

There is a version of the digital sovereignty conversation that leads organizations somewhere expensive, operationally burdensome, and – if they’re being honest – further than their actual obligations require. Maximum sovereignty sounds responsible. In practice, it’s often a miscalibration.

There is an equally common version that leads somewhere dangerously thin – controls that satisfy a checklist but wouldn’t survive an audit, an incident, or a regulator who has stopped accepting documented intent as proof of demonstrated control.

The organizations that get sovereignty right tend to do something more rigorous and more practical than either extreme: They ask what they actually owe, to whom, and for what. Then they build to that standard – no more, no less.

This is the discipline of MVS, introduced in the Digital Sovereignty Readiness Report  and developed in full here.

MVS isn’t a shortcut. It’s a recognition that the goal is the right level of control, applied consistently, across every workload that requires it.

Not All Workloads Are Equal

The starting point for an MVS approach is workload classification – and most organizations skip it entirely.

A trading system processing regulated financial data carries fundamentally different sovereignty obligations than an internal HR collaboration tool. A database holding personal data of EU citizens is subject to a different legal and regulatory regime than a development environment running anonymized test data.

Treating all of these identically – either by applying maximum sovereign controls across the board or by assuming a single deployment model covers everything – is how organizations end up either over-engineered or under-protected.

The right question before any deployment decision: What does this workload require across each of the four sovereignty pillars? The Readiness Report includes a self-assessment structured around exactly that question.

The Three Profiles – and What They Actually Need

Regulated enterprises fall into three recognizable profiles, each with different primary drivers and investment priorities.

• The True Sovereign. Government agencies, defense contractors, and critical national infrastructure operators. For these organizations, sovereignty is not a compliance requirement – it is an operational mandate. Maximum control over every dimension of the technology stack is often legally required, and the cost tradeoffs are accepted because the alternative is not.
• The Regulated Organization. Financial services firms, healthcare organizations, energy companies. These organizations face binding requirements from DORA, NIS2, GDPR, and sector-specific frameworks. Compliance obligations may also map to EU certification schemes – including EUCS, EUCC, BSI C5, and SecNumCloud – depending on sector and deployment context.

on-negotiable in certain areas – particularly around data residency, operational access controls, and recovery within jurisdictional boundaries. But not every workload carries the same obligation.

• The Hybrid Multi-Cloud Organization. Organizations with existing hyperscaler investments facing increasing sovereignty pressure from customers, regulators, or procurement requirements. Their challenge is not wholesale migration – it’s layering sovereign controls onto a mixed estate and maintaining consistent governance across it.

The Cost of Getting Calibration Wrong

Over-engineering sovereignty creates its own operational risks. Organizations that apply maximum sovereign controls to workloads that don’t require them absorb cost and complexity that serves no regulatory or business purpose.

Under-engineering is the more common failure mode, and the more dangerous one. It typically doesn’t show up until the audit arrives – or, more seriously, until an incident occurs and recovery becomes a legally constrained problem. (That failure mode is the subject of the fourth post in this series.)

A Practical Starting Point

An MVS approach follows three steps:

1. Classify workloads by their actual sovereignty requirements across each pillar – don’t start with deployment models.
2. Map each workload class to the deployment tier that meets those requirements, across the full spectrum from public hyperscaler regions to sovereign public cloud to on-premises managed environments.
3. Govern the resulting mixed estate consistently – controls, audit evidence, and recovery capabilities must be demonstrable across the full environment, not just the most-sovereign tier.

The third step is where most programs struggle. Maintaining consistent sovereignty controls across a mixed estate is an operational governance challenge – and specifically the domain of Operational Sovereignty – the subject of the third post in this series, the pillar most strategies treat as an afterthought.

Use the self-assessment in the Digital Sovereignty Readiness Report to locate your current posture across all four pillars.

FAQs

Q: What is minimum viable sovereignty (MVS)?

A: MVS is the practice of applying sovereignty controls based on actual business and regulatory needs. It is intended to help avoid both over-engineering and under-protection.

Q: Why is workload classification important?

A: Different workloads carry different regulatory and operational obligations. Classifying workloads helps organizations apply the appropriate level of sovereignty controls.

Q: What are the three common sovereignty profiles?

A: The three profiles are true sovereign organizations, regulated organizations, and hybrid multi-cloud organizations. Each has distinct operational and compliance requirements.

Q: What risks come from over-engineering sovereignty?

A: Excessive controls can increase operational complexity and costs without delivering meaningful compliance or business value.

Q: Why do mixed environments create governance challenges?

A: Organizations often operate across multiple cloud and infrastructure models. Maintaining consistent controls, audit evidence, and recovery standards across all environments is difficult.

Ruben Renders is Solutions Director, MSP, at Commvault.

Key Takeaways

• Data residency addresses where data is stored, but digital sovereignty also requires control over access, operations, and proper understanding of jurisdictional implications.
• Operational sovereignty is often the weakest and least-audited part of most sovereignty programs.
• A complete sovereignty posture depends on four pillars: data locality, technological sovereignty, operational sovereignty, and jurisdictional sovereignty.
• Sovereignty is not binary; organizations must define a posture aligned to their regulatory and operational obligations.

Here is a question worth sitting with: When your organization made its sovereignty decision, what exactly did it decide?

For most, the answer is some version of the same thing. Pick a region. Move the workloads. Choose a cloud provider with data centers in-country. Check the box. The question of where data lives was answered, and the sovereignty conversation was considered closed.

But it wasn’t closed. It had barely started.

Data residency answers one question: Where? Digital sovereignty asks three more – who, how, and under what conditions?

The conflation of residency with sovereignty is understandable. Hyperscalers have made region selection feel like a sovereignty decision. Compliance checklists ask where data is stored. Regulatory guidance, at least in its earlier iterations, focused heavily on geography.

Choosing a sovereign cloud region is a real thing – it matters, it has operational implications, and it’s a necessary first step. But it is only a first step. And most organizations stopped there.

What Residency Doesn’t Answer

Think of it this way: Choosing a sovereign cloud region is like buying a safe. It tells you where your valuables are stored. It says nothing about who has a copy of the combination, who manufactured the safe, which country’s laws govern the manufacturer, or whether you can open it if compelled to.

Region selection answers one question. Three more remain entirely open – and these are the questions regulators, procurement committees, and auditors are now asking with increasing precision:

• Who can operate your environment, and from where? Whether your cloud provider’s support personnel are subject to foreign jurisdiction is a sovereignty question that data residency cannot resolve. A routine maintenance window performed by a support engineer in a different legal jurisdiction is an access pathway your residency policy doesn’t cover. This is the domain of Operational Sovereignty – the hardest pillar to audit and the most commonly overlooked.
• Under what legal regime can your data be accessed? A foreign technology provider operating infrastructure in-country does not automatically remove the reach of their home jurisdiction’s law. The extraterritorial reach of foreign legal regimes is a risk that geography alone cannot eliminate.
• Can you recover your data if something goes wrong? Most sovereignty programs are built around access control. Very few address recovery – whether your data can be restored cleanly, within defined tolerances, by personnel who operate within your sovereignty boundary. That gap is where sovereignty postures most commonly fail under real conditions.

The Framework that Fills the Gap

A complete sovereignty posture spans four interdependent pillars. The Digital Sovereignty Readiness Report – available at readiverse.com – walks through each in full. In brief:

• Data locality addresses where data and metadata actually travel.
• Technological sovereignty covers control over encryption, key custody, and architecture portability.
• Operational sovereignty covers who runs the environment and from where.
• Jurisdictional sovereignty establishes the legal framework governing and affecting all of the above.

No single pillar is sufficient. A strong data locality posture with weak operational controls is not sovereignty – it is residency with unexamined risk.

What makes the framework useful is not its complexity. It’s the questions it generates. When an organization maps its current posture against all four pillars for the first time, it almost always finds gaps it didn’t know were there – not because the controls are absent, but because the questions were never asked.

Sovereignty Is a Sliding Scale

One more thing worth naming: Sovereignty is not a binary state. There is no certification that grants it and no single deployment model that guarantees it. It is a posture – a set of deliberate, auditable decisions. And the right level of that posture varies by organization, by workload, and by what you actually owe regulators and customers.

That calibration is what minimum viable sovereignty is about – the subject of the second post in this series.

Regulatory confidence is built long before the audit itself – through clearly defined requirements, not assumptions tied to geography.

Download the Digital Sovereignty Readiness Report for the four-pillar framework and a practical self-assessment tool.

FAQs

Q: What is the difference between data residency and digital sovereignty?

A: Data residency focuses on where data is physically stored. Digital sovereignty goes further by addressing who can access the data, how systems are operated, and exposure to which jurisdictions may create legal risk.

Q: Why is region selection not enough for sovereignty?

A: Choosing a cloud region only addresses geography. It does not resolve issues related to operational access, legal risks exposure, or recovery capabilities.

Q: What are the four pillars of digital sovereignty?

A: The four pillars are data locality, technological sovereignty, operational sovereignty, and jurisdictional sovereignty. Together, they create, what we believe, is a more complete framework for assessing sovereign readiness.

Q: Why is operational sovereignty difficult to manage?

A: Operational sovereignty involves monitoring who can access systems, where they operate from, and under which legal regime. These controls are harder to audit than simple data location requirements.

Q: Is digital sovereignty a fixed certification?

A: No. Sovereignty is an ongoing posture based on deliberate, auditable decisions that vary by organization, workload, and regulatory environment.

Ruben Renders is Solutions Director, MSP, at Commvault.

Key Takeaways

• Vishing attacks have surged dramatically, with organized groups industrializing social engineering to gain initial access through help desks.
• Attackers quickly pivot from compromised human accounts to persistent machine identities like OAuth tokens and service accounts.
• Most organizations lack governance and visibility over non-human identities (NHI), creating a major security blind spot.
• Effective readiness depends on correlating identity signals and treating machine identities as high-risk assets.
• True resilience requires the ability to detect and roll back unauthorized privilege changes before attackers establish persistence.

Your help desk staff just got a phone call. The caller knew the employee’s name, their manager, and the last four digits of their badge number. They asked for a password reset. Standard procedure. The IT rep complied.

That call was a fraud. And the attacker is now inside.

Voice phishing – vishing – jumped 449% in 2025. Adversary groups have turned social engineering into a scalable operation: recruiting callers, writing scripts, and paying $500 to $1,000 per successful help desk impersonation. They’re not looking for your data. They’re looking for a foothold.

Once inside, attackers don’t linger on the human account. They move laterally – stealing OAuth tokens, creating new administrative service accounts, embedding access in machine-layer credentials that nobody watches. Unlike human passwords, those credentials are rarely rotated. They don’t trigger login alerts. They can survive a full remediation of the original compromised user.

By the time your security team closes the ticket on the help desk incident, the attacker may have been quietly persistent in your environment for weeks. The governance gap makes it worse.

Fewer than 25% of organizations have formal policies for creating or decommissioning NHIs – the service accounts, API keys, and OAuth tokens that now outnumber human users by 144 to 1. Nearly all of them carry permissions far beyond what their function requires.

Most organizations have almost no confidence in their ability to detect an attack targeting this layer. That’s not a prevention failure. It’s a recovery planning failure.

What Readiness Looks Like

Prevention at the help desk matters – training, callback verification, out-of-band confirmation. But it isn’t enough on its own. Attackers are industrializing faster than awareness programs can keep pace.

Readiness means correlating the signals: A help desk interaction followed immediately by a multi-factor authentication (MFA) reset or a new token creation is a high-probability indicator of compromise.

It means treating machine identities as Tier 0 assets – governing their creation, scoping their permissions, and monitoring for unauthorized escalation. And it means having the ability to detect and roll back malicious privilege changes quickly, before they become the new normal.

Explore how Commvault identity resilience supports rapid detection, rollback, and recovery of your identity environment.

FAQs

Q: What is a vishing attack in the context of enterprise security?

A: Vishing (voice phishing) uses phone calls to impersonate employees and manipulate IT help desks into granting access – typically through password or MFA resets. It’s increasingly industrialized, with organized groups recruiting callers and using pre-written scripts to maximize success rates.

Q: Why do attackers pivot to machine identities after a vishing entry?

A: Human accounts get remediated. NHIs – OAuth tokens, service accounts, API keys – are more persistent and rarely rotated, often invisible to traditional monitoring. Migrating access to the machine layer allows attackers to maintain that persistence long after the original human credential breach is detected and closed.

Q: What does “identity resilience” mean in practice?

A: It means your organization can help detect unauthorized privilege changes in near real time and help restore the identity environment to a trusted state quickly. Detection alone isn’t sufficient – the ability to roll back malicious activity and verify that machine identities haven’t been tampered with (or if tampered with, to be rolled back to a prior good point in time) is what separates readiness from exposure.

Vidya Shankaran is Field CTO at Commvault.

Key Takeaways

• Help desk social engineering is now a primary entry point, with vishing (voice phishing) attacks rapidly increasing and leading to credential compromise.
• Non-human identities like service accounts and tokens are a major security blind spot, often unmanaged and heavily exploited for lateral movement.
• Active Directory (AD) is a high-value target because of its centralized control and potential misconfigurations.
• Prevention alone is insufficient; organizations need strong detection and rapid recovery capabilities to limit damage.
• Immediate operational actions – like auditing accounts and correlating help desk activity with identity changes – can significantly reduce risk.

AD remains a primary target for attackers because it sits at the center of enterprise identity. Recent research shows that 67% of incidents now involve identity-related compromise, with attackers going after critical systems like AD within hours of initial access. Once compromised, recovery can take days or weeks – causing significant business disruption.

The question worth asking isn’t whether AD is a target. It’s how attackers get there – and why the path is so much shorter than security teams might expect.

3 Steps to Full Compromise

Adversary groups like ShinyHunters and Scattered Spider have turned social engineering into a production operation. Voice phishing – vishing – jumped 449% in 2025. Callers are recruited, scripted, and paid up to $1,000 depending on success and hit rate.

That means, it’s possible to start an attack with one step: Get a password reset or multi-factor authentication (MFA) change. That’s it.

From that single credential, the attacker moves laterally into cloud and virtualized environments. They harvest OAuth tokens, create new administrative service accounts, and embed access in machine-layer credentials. These non-human identities – service accounts, API keys, tokens – now outnumber human users 144 to 1. Sprawl and operational overhead makes rotation and audit difficult.

That lateral movement has a destination: Active Directory.

AD Is the Target

AD is the central nervous system of enterprise identity. Control it and you control everything – user accounts, group policies, and access to every domain-joined system in the network. The reason it’s so attractive to attackers – and so difficult to defend – is structural. Any authenticated user can read the entire directory. Every domain-joined system inherits trust from it.

Group Policy Objects linked at the domain head can be weaponized to disable security controls outright. Legacy protocols left enabled for application compatibility provide straightforward access. Microsoft’s own documentation says that “most identity attacks utilize common misconfigurations in Active Directory.”

When an attacker reaches the AD, they don’t need to force entry. The door is usually open.

Prevention Is Necessary but Not Sufficient

The standard security stack – MFA, endpoint detection, email filtering – is built around human behavior. It wasn’t designed to govern the machine identity layer or to detect the kind of slow, legitimate-looking privilege escalation that characterizes modern AD attacks. An attacker that moves from a compromised human account to a service account to a domain administrator over 72 hours may never trigger a single alert.

This is why the conversation must shift from prevention-first to recovery-first.

Prevention still matters. Least-privilege access, auditing AD changes, hardening default configurations, disabling inactive accounts – these can help reduce the attack surface. But given that half of organizations have already experienced an AD attack, designing only for prevention means designing to fail.

True identity resilience requires the ability to detect unauthorized privilege escalations in near real time, roll back malicious changes before they propagate, and restore the identity environment to a known-trusted state quickly – not in days or weeks, but fast enough to contain the blast radius. That means treating AD and the non-human identity layer as Tier 0 assets, with the same governance and recovery investment you’d apply to any other mission-critical system.

What To Do Right Now for Identity Resilience

The gap between where most organizations are and where they need to be on identity resilience is real. But it’s closeable. The immediate priorities are unglamorous and operational:

1. Audit what’s in your AD.
2. Find the accounts that shouldn’t still exist.
3. Rotate the credentials that haven’t been touched in years.
4. Correlate help desk activity against token- and account-creation events.

A help desk interaction followed by an MFA reset followed by a new service account is a high-confidence attack signal – and it’s detectable if you’re looking for it.

The longer-term work is architectural: Build recovery capability into your identity program so that when an attack succeeds – and it’s usually when, not if – you can contain it, reverse it, and try to restore trust faster than the attacker can consolidate their position.

Attackers are counting on your AD being ungoverned, your machine identities being invisible, and your recovery plan being theoretical. Close one of those gaps this quarter. Close all three and you’ve fundamentally changed the math. 

Learn how Commvault Cloud delivers comprehensive AD protection – from vulnerability assessment to one-click rollback and full forest recovery.

I recently joined Vidya Shankaran on the STRIVE podcast to talk about the governance gap for non-human identities. Check out our episode here. And be sure to read Vidya’s blog, The Machine Identity Blind Spot Is Now a Primary Attack Surface.

FAQs

Q: Why are help desks becoming a major security risk?

A: Help desks are often trusted to reset passwords and modify MFA settings, making them attractive targets for social engineering. Attackers exploit this trust to gain initial access with minimal resistance.

Q: What role do non-human identities play in attacks?

A: Sprawl and operational overhead make rotation and audit of non-human identities, such as service accounts and API keys, difficult. Attackers use them to maintain persistence and move undetected across systems.

Q: Why is AD such a critical target?

A: AD controls authentication and access across the network. Gaining control of it allows attackers to manage users, policies, and systems at scale.

Q: Isn’t MFA and endpoint security enough to stop these attacks?

A: These tools focus on human behavior and may not detect slow, legitimate-looking privilege escalation. Attackers can operate within normal patterns and avoid triggering alerts.

Q: What does a recovery-first security approach mean?

A: It means preparing for the reality that breaches will happen and prioritizing the ability to detect, contain, and reverse them quickly. This approach helps reduce downtime and can help limit overall impact.

Q: What are the most important steps to take immediately?

A: Start by auditing your AD, removing unnecessary accounts, rotating old credentials, and monitoring for suspicious sequences of help desk and identity-related activities.

Dan Conrad is Principal Technologist and Field CTO at Commvault.