Skip to content

Key Takeaways

  • Mythos will likely accelerate vulnerability discovery to a scale and speed that outpaces traditional, human-driven remediation workflows.
  • Core security fundamentals like patching, air-gapped backups, and disciplined vulnerability management remain critical but may no longer be sufficient on their own.
  • The primary challenge is shifting from detection to the capacity to act as vulnerability volumes surge beyond current operational limits.
  • AI resilience depends on the ability to recover coherent systems – not just data – across models, pipelines, and permissions.
  • Organizations that proactively adapt during this early window are likely to be significantly better positioned than those that delay action.

A few weeks ago, I was in a room with a group of CIOs and CISOs when the conversation turned to Mythos and Project Glasswing. The energy was immediate – these are people who have lived through a lot of hype cycles, and this commanded their attention.

The reactions landed in two camps. One: The threat categories aren’t new – organizations with solid vulnerability management and trusted air-gapped backups will be better positioned than those without. Two: The velocity is different – not just what Mythos can find, but how fast, how fast bad actors could leverage AI for machine-speed attacks, and what that does to the math that most vulnerability management programs are built on.

Both were right. That’s what made the conversation worth writing about.

What Mythos Changes – And What It Doesn’t

Mythos is Anthropic’s AI model for autonomous vulnerability discovery. It can find and chain critical exploits across major operating systems at a success rate that is believed to have no real precedent in this domain.

Project Glasswing – the consortium of companies brought in to test and harden their systems before Mythos or similar capabilities reach adversaries – is the signal that this is real, it is here, and the window for getting ahead of it is short.

The fundamentals-first view holds: patching matters, virtually air-gapped backups matter, vulnerability management discipline matters. None of that changes with Mythos. What changes is the production rate on the other side of those programs.

The question after Glasswing isn’t whether you have a vulnerability management program. It’s whether it was built for findings that arrive in a trickle – or a tsunami.

Most programs were built for the trickle. Periodic assessments, CVSS-based prioritization queues, patch and testing cycles measured in weeks. That cadence made sense when the pace of discovery matched the pace of human-led processes. Mythos-class capability breaks that assumption – the volume of exploitable findings may exceed what most organizations can process through the workflows they have today.

The issue isn’t detection. It’s capacity to act – and what happens when the gap between discovery and remediation widens faster than you can close it.

When Prevention Gets Compressed, Resilience Moves Forward

When prevention timelines are compressed, the resilience question moves to the front of the line. If you can’t guarantee you’ll patch everything before something is exploited – and increasingly, you can’t – the questions that matter shift: How fast do you detect? How do you contain? And when you recover, what exactly are you recovering to?

That last question is harder than it sounds, especially for organizations with progressive agentic interactions. An AI system isn’t just data. It’s a model version, a training pipeline, a vector database, a set of agent identities and permissions – all of which need to reflect the same operational state to constitute something you can actually trust.

Most organizations can restore individual components. Very few can prove that what they’ve restored is coherent.

Recovering an AI system isn’t a data restoration problem. It’s a coherence problem – and the gap between those two things is where most enterprises are currently exposed.

This is the thread that connects Mythos to the broader AI resilience conversation. It isn’t that Mythos introduces a new type of risk that requires a new framework.

It’s that Mythos compresses the timeline in a way that surfaces existing gaps faster, with less runway to close them before something goes wrong, thereby increasing the change that something will go wrong before an organization can properly remediate vulnerabilities.

The Window Is Open. It Won’t Stay That Way.

Glasswing was designed to give defenders a head start. The organizations that use this window deliberately – stress-testing their vulnerability programs for volume, getting AI resilience infrastructure to a state they can defend, and treating recovery as something that has to be provable before an incident, not assembled during one – will be in a materially better position than those that wait.

The fundamentals still apply. The urgency is new.

The Agentic Enterprise: Why AI Resilience Demands a System of Record – Commvault’s latest Readiness Report – examines the AI resilience infrastructure gaps that determine whether organizations can answer the hard recovery questions when the pace of threats demands it.

FAQs

Q: What is Mythos and why is it significant?

A: Mythos is an AI model designed for autonomous vulnerability discovery, capable of identifying and chaining exploits across systems at unprecedented speed. Its significance lies in how it compresses the timeline between vulnerability discovery and potential exploitation, raising the stakes for defenders.

Q: Does Mythos change the fundamentals of cybersecurity?

A: No, core practices like patching, backups, and vulnerability management still matter. What is changing is the volume and velocity of threats, which puts pressure on existing processes that were designed for slower, more predictable workflows.

Q: Why may current vulnerability management programs struggle?

A: Many programs were built for a steady flow of findings, not the surge enabled by AI-driven discovery. As a result, organizations face a growing gap between identifying vulnerabilities and actually remediating them.

Q: What does “resilience” mean in the context of AI systems?

A: Resilience goes beyond restoring data – it involves recovering an entire AI system in a coherent, trustworthy state. This includes models, training pipelines, vector databases, and access controls all aligning correctly.

Q: Why is recovery becoming more important than prevention?

A: As prevention timelines shrink due to faster exploitation, it is becoming unrealistic to patch everything in time. This shifts focus to how quickly organizations can detect, contain, and recover from incidents.

Q: How can organizations start preparing?

A: Organizations can stress-test their vulnerability management processes, modernize resilience infrastructure, and validate recovery capabilities. Acting during this early window provides a meaningful strategic advantage.

Tim Zonca is Vice President, Portfolio Management, at Commvault.

More related posts

Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more

Key Takeaways

  • Agentic AI introduces new security risks because it plans, remembers, and acts across systems instead of stopping after a single prompt-response cycle.
  • Poisoned training data can quietly influence model behavior at scale, even when the model still appears to perform normally in standard testing.
  • Compromised vector databases can steer agent decisions by corrupting the context the model relies on, making bad behavior look legitimate.
  • Ungoverned agent identity creates a machine-speed access-control problem that traditional human-centric identity systems are not built to handle.
  • Cascading decisions built on bad state can spread corruption across multiple agents and workflows, making rollback and recovery much harder.

The tools, controls, and governance policies most enterprises have in place were designed for systems that answer questions – retrieval tools, copilots, generative assistants. Systems that respond to a prompt and stop. When something went wrong, the failure was discrete. Fix the prompt, adjust the configuration, move on.

Agentic AI doesn’t work that way. These systems plan, remember, and execute across the enterprise without step-by-step human instruction. They maintain state. They coordinate with other agents. They act on production systems – writing to databases, triggering workflows, making decisions at machine speed.

That architectural shift introduces four threat vectors that existing security frameworks were never designed to address. If your AI governance strategy doesn’t account for them, you likely have exposure you probably can’t see.

1. Poisoned Training Data

An AI system is only as trustworthy as the data it was trained on. That statement has always been true. What’s changed is the attack surface.

In agentic AI deployments, training pipelines are larger, more complex, and frequently assembled from multiple sources – internal data, third-party feeds, vendor-provided datasets. Each dependency in that chain is a potential injection point. An adversarial actor who can influence training data – through supply chain compromise, insider access, or contamination of a shared data source – can shape model behavior at scale.

What makes this particularly dangerous is that poisoned models often perform normally on standard benchmarks. The manipulation may be surgical: designed to produce specific outputs in specific contexts while behaving correctly everywhere else.

By the time the effect surfaces in production, the model has been in use for weeks or months, and tracing the contamination back to its source requires exactly the kind of relational data provenance most organizations don’t have.

The question to ask: Can you produce a complete, verifiable record of what data your models were trained on – at a specific point in time?

2. Compromised Vector Databases

Vector databases are the memory layer of agentic systems. Before an agent acts, it queries a vector store to retrieve relevant context – past interactions, domain knowledge, reference data – that shapes what it does next.

Most security teams aren’t thinking about vector databases the way they think about other sensitive data stores. They should be.

A compromised vector database doesn’t just return wrong answers. It shapes the decisions that follow. Injected embeddings – malicious content inserted into the vector store – can redirect agent behavior in ways that appear completely legitimate from the outside.

An agent asked to approve a transaction retrieves context that subtly reframes the approval criteria. An agent managing customer communications pulls context that steers responses in an attacker’s preferred direction. The action looks correct. The reasoning looks sound. But the underlying context has been manipulated.

This attack vector is particularly hard to detect because it operates below the model layer. Standard model monitoring won’t catch it. The model is behaving exactly as trained – it’s the context it’s reasoning from that’s been corrupted.

The question to ask: Is your vector database treated as a sensitive, governed data asset – with access controls, integrity monitoring, and audit logging comparable to your most critical production databases?

3. Ungoverned Agent Identity

In a multi-agent architecture, agents don’t just interact with data – they interact with each other. They spawn subagents, delegate tasks, request outputs, and synthesize results from agents they’ve never been explicitly connected to. To do this, they authenticate, present credentials, and establish trust.

Agent identity is the access control layer for the autonomous enterprise – and it’s a gap that identity security vendors and identity providers (IDPs) don’t close. Their governance frameworks are built for human identity.

Agent identities created within those same rules appear completely legitimate: They were provisioned correctly, they followed policy. The IDP isn’t failing – it simply has no framework for determining whether an agent is acting outside the context it was created for, has been quietly escalated, or is coordinating where it shouldn’t be.

The exposure is qualitatively different from traditional credential compromise. When a human user’s credentials are stolen, the attacker operates within that user’s permissions, at human speed.

When an agent’s identity is compromised, the attacker gains access to the autonomous decision-making layer – the ability to trigger workflows, approve actions, coordinate with other agents, and exfiltrate data at machine speed, at scale, through channels that appear entirely normal.

Identity-layer failures are also among the hardest to detect after the fact. Agent actions taken under a compromised identity don’t look anomalous – they look like legitimate agent behavior. And because they’re generated by a system rather than a human, the volume can be enormous before anyone notices.

Recovery compounds the problem. Most AI recovery playbooks focus on restoring data: training sets, model weights, pipeline configurations. Identity is rarely on the list. A system recovered with clean data but misaligned identity configurations isn’t actually recovered. It’s a clean system with a poisoned access layer.

The question to ask: Is agent identity managed with the same rigor as human identity – with lifecycle management, least-privilege access, and inclusion in recovery playbooks?

4. Cascading Decisions Built on Bad State

The first three attack vectors are discrete. This one is systemic – and in many ways it can be the most difficult to contain.

Multi-agent architectures are designed for coordination. Agents share context, pass outputs to one another, and build on each other’s work. That coordination is what makes them powerful. It’s also what makes failures propagate.

An agent operating on corrupted memory doesn’t fail cleanly. It produces outputs – decisions, actions, data – that other agents consume. Those agents produce their own outputs. By the time the original corruption surfaces as something observable, bad state may have touched dozens of downstream processes, across multiple agents, with no clean rollback path.

This is what makes the context gap so significant. At any given moment, your AI system consists of a model version, a set of training data, an artifact store, a pipeline configuration, and a set of active agent interactions – all of which need to reflect the same operational state to constitute a trustworthy, recoverable system. When they don’t, you don’t just have an error. You have a system that is coherent in pieces and incoherent as a whole.

Point tools can each confirm their own slice. None can confirm the pieces belong together. That’s not a monitoring problem you can solve by adding another tool. It’s a structural gap – and the only way to close it is with a system that captures AI state relationally: what was running, against what data, with what configuration, at what moment.

The question to ask: If your AI infrastructure were compromised today, could you identify exactly what state every component was in before the incident – and prove it?

What This Means for Your Security Strategy

Each of these four vectors requires a different defensive response. But they share a common implication: The governance and resilience frameworks designed for the previous era of AI don’t cover the failure modes of the agentic era.

Securing agentic AI requires extending your framework in three directions:

  • Deeper, into the data and identity layers that sit below the model.
  • Broader, to cover agent-to-agent interactions that existing monitoring doesn’t observe.
  • Relationally, to capture not just the state of individual components, but how they fit together at any point in time.

That last requirement is the one most organizations haven’t yet confronted. And it’s the one that will determine whether, when something goes wrong, you have a recoverable system or a collection of accurate-looking reports describing something that no longer exists.

Read The Agentic Blind Spot: Why AI Resilience Demands a System of Record to learn why you need an SOR to help protect the consistency and accuracy of your AI data.

FAQs

Q: Why are agentic AI systems riskier than traditional generative AI tools?

A: Agentic systems do more than answer prompts. They maintain state, coordinate with other agents, and take actions in production environments, which expands the attack surface far beyond simple prompt manipulation.

Q: What makes poisoned training data so difficult to detect?

A: The manipulation can be highly targeted, affecting only specific situations while leaving normal benchmarks intact. That means a model may look healthy until the poisoned behavior appears in real use.

Q: How can a vector database become a security problem?

A: A vector database shapes the context an agent uses before acting. If that context is altered, the agent may make decisions that seem reasonable on the surface but are really being guided by malicious data.

Q: Why is agent identity different from human identity?

A: Agent identity is tied to autonomous actions, delegation, and machine-speed execution. Traditional identity governance is designed for people, so it often misses whether an agent is acting outside its intended context.

Q: Why is cascading bad state such a serious issue in multi-agent systems?

A: Once one agent consumes corrupted output, that error can spread to downstream agents and workflows. The result is not just one bad decision, but a chain of connected failures.

Q: How can organizations improve AI security?

A: Extend governance deeper into data and identity layers, monitor agent-to-agent interactions, and track AI state relationally to enable them to reconstruct what happened during an incident.

Michael Thelander is Senior Director, Product Marketing, at Commvault.

Related Blogs

More related posts

Thumbnail_Blog-Data-Access-Governance-2026

Securing AI with Unified Data Access Governance

Read more
Thumbnail_Blog-Environmental-Footprint-AI-2026

Smarter Data, Greener AI

Read more
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more
Thumbnail_Blog-AI-Agents-2026

AI Agents Are Everywhere. Do You Know What They’re Doing?

Read more
Thumbnail_Blog-Building-AI-Agents-2026

From Experimentation to Operation: Building AI Agents You Can Actually Trust

Read more

Key Takeaways

  • Agentic AI systems are stateful and continuously operating, making traditional recovery models insufficient.
  • The memory layer (vector databases and context storage) is a critical yet under-monitored attack surface.
  • Runtime decision-making workflows can be manipulated without triggering traditional security alerts.
  • Observability gaps in agent-to-agent interactions leave most organizations with incomplete visibility into risks.
  • True recovery requires a unified, time-aligned record of all system layers to restore a trustworthy state.

Most enterprises entering the agentic AI era are managing resilience with the wrong mental model – and the data backs it up: Only 1 in 5 companies has a mature model for governing autonomous AI agents. They’re thinking about AI the way they think about applications: discrete, stateless, recoverable by restoring clean data to a clean environment.

Agentic AI doesn’t work that way. These systems are stateful, continuously operating, and architecturally layered in ways that create failure modes most security and resilience frameworks weren’t designed to address. The gap isn’t in tooling. It’s in understanding what’s actually running – and what “recovery” has to mean for systems built this way.

There are four architectural layers that define the problem. Each one is distinct. Each one is underprotected. And together, they explain why an agentic AI system can appear recoverable while remaining fundamentally compromised.

Layer 1: Agent Memory – The Attack Surface You’re Not Watching

Traditional enterprise applications don’t remember anything between sessions. Agentic AI does. The memory layer – primarily vector databases storing embeddings, but also session state and retrieved context – is what gives agents continuity across interactions. It’s what allows an agent to pick up where it left off, to draw on prior context, to build a coherent picture of a complex workflow over time.

It is also one of the most consequential attack surfaces in the modern enterprise stack – and one of the least monitored.

The attack vector is subtle enough to evade most conventional security tooling. An adversary who can influence what gets written to a vector database can shape what the agent believes to be true. Injected or manipulated embeddings don’t need to look malicious – they need to look authoritative.

A compromised memory store can redirect agent behavior, exfiltrate data through agent actions, or cause an agent to make decisions that appear legitimate but serve an attacker’s objectives. None of this requires touching the model itself.

The detection problem is compounded by the volume and velocity of vector database writes in active agentic deployments. Anomaly detection tools built for structured data don’t translate well to embedding space. The signal is there – but most organizations aren’t equipped to read it.

What resilience requires here: continuous integrity monitoring of vector databases, not just backup. Version-controlled embeddings with a provable chain of custody. The ability to identify, at any point in time, exactly what the memory layer contained – and to restore to a verified clean state, not just a recent one.

Layer 2: Runtime Control – When the Workflow Is the Threat

Agentic AI doesn’t execute fixed scripts. It plans. At runtime, an agent receives a goal, determines the steps required to achieve it, selects the tools it needs, and executes – often spawning subagents to handle parallel workstreams. The workflow is dynamic, constructed in the moment, and frequently long-running.

This is what makes agentic AI genuinely useful. It’s also what makes it genuinely difficult to protect.

In a conventional automation environment, a compromised workflow is bounded. It does what it was configured to do, and it stops. A compromised agentic workflow is different: It adapts.

If an attacker can influence the planning layer – through a poisoned prompt, a manipulated tool response, or a corrupted planning model – the agent will pursue the attacker’s objective using whatever legitimate tools and access it has. It will look like normal operation. The logs, to the extent they exist, will show authorized tool calls.

Consider a procurement agent tasked with validating vendor invoices against contract terms. Under normal operation, it checks invoice amounts, cross-references approval thresholds, and flags exceptions for human review.

An attacker who can influence the planning layer – through a manipulated tool response from the contract database – doesn’t need to touch the approval logic directly. They simply give the agent a contract record with altered thresholds.

The agent plans correctly against corrupted inputs. Every tool call it makes is legitimate. Every decision it reaches is wrong. By the time the anomaly surfaces in a finance reconciliation, the workflow has processed weeks of invoices and the audit trail shows nothing but authorized actions.

The window between compromise and detection in these scenarios is not measured in seconds. Agentic workflows operate continuously. By the time anomalous outcomes surface, the workflow may have touched dozens of systems, made hundreds of decisions, and left changes across production environments that are difficult to enumerate and harder to reverse.

What resilience requires here: runtime monitoring that watches what agents are deciding, not just what they’re doing. Intervention mechanisms that can halt a running workflow cleanly without cascading failures. Recovery playbooks built for long-running agentic processes – not just for discrete transactions.

Layer 3: Agentic Observability – The Logging Gap at Machine Speed

Enterprise logging infrastructure was built for human-scale operations. It captures what systems do, at a granularity and latency designed for human review. Agentic AI operates at a different speed entirely.

In an active multi-agent deployment, agents are spawning subagents, passing context between one another, making tool calls, and synthesizing outputs – continuously, in parallel, faster than conventional logging pipelines were designed to capture.

The interactions that matter most for security – agent-to-agent communications, context handoffs, tool invocations that cross trust boundaries – are exactly the interactions that existing monitoring frameworks leave most underobserved.

Today, only 17% of continuously monitor agent-to-agent interactions. The other 83% are governing agentic AI based on a partial picture – one that captures what individual agents do in isolation but misses the interaction layer where the most consequential security events occur.

This isn’t a gap that more logging volume solves. The problem isn’t the quantity of data being captured – it’s that the data structures and latency requirements of agentic interactions don’t fit well into observability frameworks designed for slower, more structured systems. Closing this gap requires purpose-built agentic observability tooling, or significant adaptation of existing infrastructure.

What resilience requires here: end-to-end visibility into agent-to-agent interactions, not just individual agent outputs. Logging architectures that can operate at agentic speed without dropping events. The ability to reconstruct, after the fact, the full sequence of agent decisions and interactions for any given workflow.

Layer 4: Multi-Agent Coordination – Where Emergent Failures Hide

The most architecturally novel risk in agentic AI doesn’t come from any single compromised agent. It comes from how agents depend on one another – and how failures propagate across those dependencies before anyone realizes something is wrong.

In a multi-agent architecture, agents share context. An orchestrator agent passes a task brief to a subagent; the subagent returns a result that the orchestrator incorporates into its next decision.

If the subagent’s output is corrupted – through a compromised memory layer, a manipulated tool response, or a poisoned planning model – the orchestrator has no native way to detect it. It treats the output as authoritative. It incorporates it. It acts on it. And it passes its own now-compromised output downstream.

This is the emergent failure mode: a corruption that originates in one layer, propagates through agent interactions, and surfaces as an anomalous outcome in a system several steps removed from the original compromise. By the time it’s visible, the causal chain is long and the blast radius is significant.

Consider a threat intelligence pipeline where a data-gathering agent ingests feeds from external sources, a classification agent categorizes and scores them, and an orchestrator incorporates the scored intelligence into security posture recommendations pushed to downstream teams.

If the data-gathering agent’s memory layer is compromised – subtly, through injected embeddings that cause it to weight certain threat actors as low-risk – the classification agent receives inputs it has no reason to question. It classifies accurately against what it’s given.

The orchestrator incorporates the results confidently. Security teams downstream deprioritize the relevant threat category based on what looks like a coherent, multi-source consensus. The failure originated in Layer 1. It expressed itself in Layer 4. Nothing in between flagged an anomaly because nothing in between had visibility across the full chain.

The governance frameworks most enterprises apply to AI were designed for model outputs – what the AI says. Multi-agent coordination failures are not model output failures. They are systems failures, arising from the interaction layer between models, and they require a different kind of governance: one that monitors and controls not just individual agent behavior but the trust relationships between agents, the integrity of context as it passes between them, and the access rights that govern what any agent can request of any other.

What resilience requires here: agent identity management that treats inter-agent trust as a first-class security concern. Integrity verification for context as it moves across agent boundaries. Governance policies that cover autonomous agent behavior – not just the outputs of individual models.

The Relational Problem That Ties All Four Together

These four layers are distinct in their failure modes, but they share a common vulnerability: none of them has a shared record of how they relate to each other at a specific point in time.

The model registry knows what version is running. The vector database knows what’s in memory. The orchestration layer knows what workflow is active. The identity system knows what agents have what access. Each can confirm its own slice of the picture. None can confirm whether those slices belong together – whether they reflect the same operational state, the same moment, the same trustworthy configuration.

That’s the context gap. And it’s why recovery from an agentic AI compromise isn’t a data restoration problem. It’s a coherence problem – one that requires a unified record of the relationships between layers, not just the components themselves.

Close this gap before an incident, or spend an incident trying to close it.

The architecture challenges covered here are only part of what security and resilience leaders need to understand about agentic AI risk. The Agentic Blind Spot: Why AI Resilience Demands a System of Record goes further, examining where most enterprises actually stand on AI resilience readiness, what the governance gaps look like in practice, and what it takes to make “our AI is trustworthy” a provable claim, not just an assertion.

FAQs

Q: Why doesn’t traditional disaster recovery work for agentic AI?

A: Traditional recovery assumes systems are stateless and can be restored from clean backups. Agentic AI systems retain memory, evolve over time, and depend on layered interactions, making simple restoration insufficient to regain trust.

Q: What makes the memory layer in agentic AI vulnerable?

A: The memory layer stores embeddings and contextual data that influence agent decisions. If compromised, attackers can subtly manipulate what the agent “believes,” leading to incorrect but seemingly legitimate actions.

Q: How can attackers exploit runtime workflows in agentic AI?

A: Attackers can influence planning inputs, prompts, or tool responses, causing agents to execute harmful actions using legitimate processes. These actions often appear normal in logs, making detection difficult.

Q: Why is observability a challenge in multi-agent systems?

A: Agentic systems operate at machine speed with continuous interactions between agents. Traditional logging systems are not designed to capture or process this level of dynamic, high-frequency activity.

Q: What are emergent failures in multi-agent environments?

A: Emergent failures occur when a small compromise in one agent or layer propagates across interconnected agents, resulting in large-scale issues that are difficult to trace back to the original source.

Q: What does effective recovery look like for agentic AI?

A: Effective recovery requires more than restoring data – it demands a coherent snapshot of all system layers, including memory, workflows, identities, and interactions, aligned to a verified trustworthy state.

Tim Zonca is Vice President, Portfolio Management, at Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

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.

More related posts

Thumbnail_Blog-GoogleWorkspace-2026

Expanding Google Workspace Protection with Commvault eDiscovery

Read more
Thumbnail_Blog-Data-Leakage-Loops-2026

Are You Ready for Data Leakage Loops?

Read more
Thumbnail_Blog-Tornado-2025-Linkedin

The Trust Tightrope: Why New Yorkers Demand More from Businesses Than They Do from Themselves

Read more
Thumbnail_Blog_FinServ-Cybersecurity-2025

Modernizing Financial Cybersecurity: From Reactive to Resilient

Read more

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.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more

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.

More related posts

Thumbnail_Blog-Identity-Resilience-MachineID-2026-Linkedin

The Machine Identity Blind Spot Is Now a Primary Attack Surface

Read more
Thumbnail_Blog-Help-Desk-2026-Linkedin

When the Help Desk Becomes the Front Door to Your Entire Network

Read more
Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

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.

More related posts

Thumbnail_Blog-Okta-Early-Access-2026

Commvault® Extends Identity Resilience to Okta

Read more
Thumbnail_Blog-Lateral-Access-2026

Staying Resilient Against Lateral Access Exploits

Read more
Thumbnail_3_AD_Blogs_2025

Active Directory Forest Recovery: Why Manual Methods Are No Longer Viable

Read more
Thumbnail_6_AD_Blogs_2025

AD Recovery Testing: How to Know Your Recovery Plan Will Actually Work

Read more

Key Takeaways

  • Non-human identities (NHIs) now vastly outnumber human users and are growing at a much faster rate, creating a significant and under-governed attack surface.
  • Attackers increasingly use social engineering, like voice phishing (vishing), to bypass human defenses and gain access to machine-layer credentials.
  • Most NHIs operate with excessive permissions and lack proper lifecycle management, contributing to accumulated “identity debt.”
  • Traditional security tools fail to detect threats in the machine layer because NHIs behave differently from human users.
  • Organizations must shift from prevention-first strategies to recovery-first approaches, prioritizing rapid detection and rollback of identity-based attacks.

For the past decade, enterprise security investment has followed the human. Better authentication. Stronger multi-factor authentication (MFA). Phishing simulation. Identity-centric architecture. These investments were the right response to the threat landscape at the time.

The threat landscape has moved.

Today’s most sophisticated adversaries aren’t trying to defeat your MFA. They’re using it as a door. A convincing phone call to your IT help desk, an MFA reset, and a compromised human account – that’s the entry. What they’re actually after is what’s behind it: the sprawling, under-governed layer of NHIs that connects every system in your environment.

The Scale of the Problem Is Staggering

Service accounts, API keys, OAuth tokens, AI agents – NHIs now outnumber human users by a ratio of 144 to 1, and they’re growing 4 to 10 times faster than human accounts. Yet fewer than 25% of organizations have formal policies governing their creation or decommissioning. Nearly all of them carry excessive permissions – rights that far exceed what their function requires.

This isn’t a new risk that suddenly appeared. It’s accumulated identity debt: years of provisioning without governance, automation without accountability, cloud expansion without visibility. And adversaries have noticed.

Vishing Is the Entry Point

Groups like ShinyHunters and Scattered Spider – operating under what researchers call the Scattered LAPSUS$ Hunters (SLH) cluster – have industrialized social engineering to exploit exactly this gap. Voice phishing rose 449% in 2025. These aren’t opportunistic calls. They’re coordinated operations: purpose-built scripts, recruited callers, financial incentives of up to $1,000 per successful help desk impersonation.

The call isn’t the attack. The call is the credential reset that gets an attacker past the human perimeter. The attack begins when they migrate to the machine layer – stealing OAuth tokens, creating administrative service accounts, embedding access into credentials that are rarely monitored and almost never rotated.

The human account gets remediated. The machine-layer access persists. The attacker has already moved on.

Three Vulnerabilities that Traditional Controls Can’t See

Standard security tools are designed around human behavior. They flag anomalous logins, unusual geolocation, suspicious email traffic. NHIs operate differently, and that difference is the blind spot.

OAuth abuse, for instance, looks like normal API traffic – even after a password reset. Thousands of undocumented service accounts operate in large enterprises with administrative privileges, often long after the projects that created them ended. Long-lived API keys embedded in DevOps pipelines carry broad access with no device context and no login alert.

MFA doesn’t cover them. Endpoint detection doesn’t see them. Email filtering is irrelevant to them.

The Framework Shift: From Prevention-First to Recovery-First

The logical response to a threat that often evades traditional detection is to stop assuming you can prevent every intrusion and start designing for rapid recovery from the ones that succeed.

That means treating NHIs as Tier 0 assets – with the same governance controls applied to domain administrators or cloud control planes managed with human identities. It means replacing static secrets with short-lived tokens and automatic rotation.

It also means correlating cross-domain signals: A help desk interaction followed by an MFA reset followed by a new token creation is a high-confidence indicator of compromise, and catching it early is the difference between containment and a prolonged breach. It means mapping NHIs to human identities for accountability.

Most importantly, it means having the capability to detect unauthorized privilege escalations and roll back malicious identity changes in real time – returning the environment to a known-trusted state before the damage extends.

Prevention still matters. But given the governance gap many organizations are carrying, recovery speed is becoming a primary resilience metric. Organizations should build identity programs designed for the attacks that are already happening, not the ones that were common five years ago.

Visit the Readiverse and check out our eBook The Non-Human Identity Crisis, which explores the full scope of the machine attack surface and the framework for identity resilience.

FAQs

Q1: What are non-human identities (NHIs)?

A: NHIs include service accounts, API keys, OAuth tokens, and AI agents that allow systems and applications to interact. Unlike human users, they often operate automatically and at scale, making them harder to monitor and control.

Q2: Why are NHIs considered a security risk?

A: NHIs often have excessive permissions and lack proper governance, making them attractive targets for attackers. Because they are rarely monitored or rotated, compromised credentials can persist undetected for long periods.

Q3: How do attackers exploit NHIs?

A: Attackers typically gain initial access through social engineering, such as voice phishing, then pivot to the machine layer. They steal tokens, create new service accounts, or embed persistent access in credentials that are not closely monitored.

Q4: Why don’t traditional security tools detect these threats?

A: Most security tools are designed to track human behavior, such as login anomalies or phishing attempts. NHIs generate normal-looking system traffic, which allows malicious activity to blend in with legitimate operations.

Q5: What is meant by a “recovery-first” security approach?

A: A recovery-first approach focuses on quickly detecting breaches and restoring systems to a trusted state rather than assuming all attacks can be prevented. This includes identifying unauthorized changes and rolling them back in real time.

Q6: How can organizations improve NHI security?

A: Organizations can treat NHIs as critical assets, implement strict governance policies, replace static credentials with short-lived tokens, and correlate signals across systems. Mapping NHIs to human owners also improves accountability and oversight.

Vidya Shankaran is Field CTO at Commvault.

More related posts

Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog-Unified-Resilience-2026

Why AI Is Breaking Your Resilience Strategy (And What to Do About It)

Read more
Thumbnail_Blog-SHIFT-Sanjay-2025-Linkedin

Re-envisioning Resilience for the Age of AI

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Organizations today are building applications faster, automating workflows at scale, and turning data into insights, powered by platforms like Microsoft Power Platform. What started as a low-code productivity layer has quickly become mission-critical, embedded in the processes that support revenue generation, day-to-day operations, and strategic decision-making.

But as the reliance on these business intelligence assets grows, so does the associated risk. The same platform accelerating innovation can also amplify the impact of operational errors, misconfigurations, and malicious actions.

A misconfigured workflow, a deleted report, or a broken application can disrupt business processes, compromise decision-making, and erode trust in the systems the business relies on. And when something goes wrong, recovery is rarely straightforward.

Commvault is helping address these challenges with enterprise-grade data protection and recovery for Microsoft Power Platform, starting with Power BI – allowing organizations to help keep the insights, workflows, and apps they build protected and rapidly recoverable. 

Power BI: The Gap Between Insight and Recovery

At the center of many Power Platform deployments is Microsoft Power BI, providing analytics and business intelligence, transforming data into reporting, forecasting, and operational visibility.

When Power BI assets are lost or compromised teams can quickly lose access to trusted insights, interrupting reporting cycles, and delaying business decision-making.

In practice, however, protection strategies lag behind the importance of these assets. Many organizations rely on manual file exports or limited native capabilities that weren’t designed for comprehensive recovery. When something breaks, teams are often forced to rebuild manually with no ability to restore exactly what’s needed. This makes recovery slow, error-prone, and difficult to scale.

Commvault Cloud Backup & Recovery for Microsoft Power Platform

Now generally available, Commvault Cloud Backup & Recovery for Microsoft Power Platform helps organizations protect and recover their business-critical assets, such as reports, from accidental deletion, corruption, and malicious activity.

  • Automated, policy-based protection: Apply policy-driven backups across Power BI workspace assets, enabling consistent, scalable coverage without manual intervention.
  • Rapid, granular recovery: Restore individual reports, folders to a specific point in time, avoiding manual rebuilds and helping minimize downtime and disruption.
  • Isolated, immutable backups: Help protect data from ransomware and unauthorized changes with backups designed to prevent unauthorized modification or deletion.
  • Simplified compliance: Maintain long-term retention (up to 10 years), centralized audit logs, and reporting to support regulatory and internal requirements.

Unified Platform for Resilience

Commvault Cloud offers a unified platform to protect SaaS, cloud, and on-premises workloads, including Microsoft 365, Dynamics 365, Salesforce, VMs, databases, and endpoints. With Microsoft Power Platform support, customers can streamline protection, recovery, and resilience for more workloads, helping reduce tool sprawl and simplify operations.

How to Get Started

Commvault Cloud Backup & Recovery for Power Platform is delivered as a SaaS solution, designed for fast deployment and minimal operational overhead. Organizations can connect their Power BI environment, apply policy-based protection, and begin backing up critical data in a matter of steps.

Automated discovery protects new reports and folders are included as environments evolve, while centralized management provides a single place to monitor, manage, and recover data at scale.

What’s Next: Expanding Across Power Platform

We intend to expand protection and resilience across Microsoft Power Platform to include Power Apps and Power Automate, extending coverage to the applications and workflows that power your business. Plans, timelines, and features are subject to change and should not be relied upon in making purchasing decisions.

Protect What Powers Your Business

As reliance on Microsoft Power Platform grows, so does the need for resilient, enterprise-grade protection. With Commvault Cloud, you can:

  • Protect critical assets against deletion, corruption, and attack
  • Rapidly recover exactly what you need – without rebuilding everything
  • Maintain trust in data, decisions, and automation
Ready to make your Microsoft Power BI investment resilient?

Learn more and see Commvault Cloud in action at commvault.com/platform/power-platform.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Key Takeaways

  • VM migration to Red Hat OpenShift Virtualization is a phased journey that requires consistent protection across hybrid environments.
  • A unified, Kubernetes-native data protection platform helps reduce complexity and eliminate the need for separate tools or processes.
  • Reliable resilience – including immutable backups and threat detection – is critical during migration, when risks are highest.
  • Flexible recovery options allow organizations to quickly adapt if migration steps fail or timelines shift.
  • Consolidating protection for VMs and containers helps reduce tool sprawl and maintain consistent governance.

If you’re an IT leader today, chances are your virtualization strategy is under active review.

Rising costs, licensing uncertainty, and long-term vendor lock-in have many organizations reassessing their reliance on traditional hypervisors. At the same time, Kubernetes has matured into the operational foundation for modern applications.

These two realities are converging – and for many enterprises, Red Hat OpenShift Virtualization is emerging as a preferred destination for running virtual machines within a Kubernetes-native operating model.

This transition is accelerating across industries. As organizations modernize infrastructure on their own terms, Red Hat OpenShift Virtualization is increasingly viewed as a way to modernize the platform without the need for application refactoring. With that momentum comes a critical question:

How do you migrate virtual machines while maintaining consistent protection, resilience, and recoverability throughout the process?

To answer it, you need to examine how most enterprise migrations actually unfold – and where protection and resilience become critical.

Migration Is a Journey, not a One-Time Event

Seasoned IT leaders know that infrastructure transitions rarely happen all at once.

For enterprises opting to move from hypervisors like VMware to Red Hat OpenShift Virtualization, the transition typically unfolds in phases. During this time, organizations inevitably operate in a mixed state:

  • VMware-based VMs continue to support core business operations.
  • VMs newly running on Red Hat OpenShift Virtualization.
  • Containerized applications sharing the same Red Hat OpenShift clusters.

This coexistence period introduces complexity and risk. Data is in motion, environments are changing, and protection gaps can appear if tooling and processes don’t evolve alongside workloads.

Maintaining Reliable Protection Is Essential

Commvault has long delivered data protection and recovery for both VMware environments and Kubernetes workloads running on Red Hat OpenShift. That same Kubernetes-native, policy-driven protection model now extends to VMs running on Red Hat OpenShift Virtualization.

What really resonates with customers is the consistency:

  • A single platform for protection and recovery.
  • Policy-based operations applied uniformly across workloads.
  • Designed to work with your existing tools and processes as environments evolve.

VMs running on Red Hat OpenShift Virtualization are protected using the same workflows and governance constructs as containerized applications. This unified approach is being embraced by organizations standardizing on Red Hat OpenShift that want a simpler, more consistent way to manage data across environments.

This capability is available today. Commvault Cloud supports protection for Red Hat OpenShift Virtualization environments aligned with Long-Term Support Release 11.40 and Innovation Release 11.42, meaning customers can put these capabilities into production now.

You Shouldn’t Need to Manage Protection Differently

Once VMs move to Red Hat OpenShift Virtualization, they shouldn’t require special handling from a protection standpoint.

Commvault Cloud discovers and protects Red Hat OpenShift Virtualization VMs alongside containerized applications, helping give teams centralized visibility, consistent policy enforcement, and simplified recovery operations. Virtualized and containerized workloads are managed together – without introducing operational silos.

For organizations managing diverse application portfolios, this treatment of VMs inside Kubernetes helps reduce operational friction while maintaining enterprise-grade controls.

Cyber Resilience Is Key When Migration Increases Risk.

Migration periods represent a uniquely vulnerable window. Change creates complexity, and complexity increases exposure to data loss and ransomware.

Commvault Cloud helps maintain resilience throughout this phase with:

  • Air-gapped and immutable backups for Red Hat OpenShift Virtualization workloads.
  • Backup data that supports threat hunting and forensic analysis, helping teams validate recovery readiness before restoring workloads.
  • Advanced recovery capabilities designed to help organizations minimize operational disruption.

Whether workloads are pre-migration, mid-transition, or fully operating on Red Hat OpenShift Virtualization, the resilience posture remains intact.

Recovery Flexibility Provides Confidence

Every modernization initiative needs room for adjustment.

Commvault supports both in-place and out-of-place recovery for Red Hat OpenShift Virtualization virtual machines, including full VM context and configuration. If a migration step doesn’t go as planned – or timelines need to shift – teams may recover quickly and move forward without compromising availability or data integrity.

Kubernetes-Native Protection Beyond VMs

For many enterprises, virtualization is only one piece of a broader application modernization strategy.

Commvault Cloud also provides application-centric, Kubernetes-native protection for containerized workloads, including persistent volumes and application metadata, across all CNCF-certified Kubernetes distributions. This enables mobility and recovery for cloud-native applications while helping maintain operational consistency across environments.

Reducing Tool Sprawl as Infrastructure Evolves

Platform transitions often introduce new tools, new processes – and new complexity.

By using Commvault Cloud as a unified protection platform for:

  • VMware VMs.
  • Red Hat OpenShift Virtualization VMs.
  • Containerized applications.

Organizations can help reduce tool sprawl, simplify administration, and maintain consistent governance even as infrastructure strategies evolve.

How it all Comes Together

During any migration, it helps to understand how the pieces work together. Red Hat’s Migration Toolkit for Virtualization takes care of moving VMs from VMware into Red Hat OpenShift Virtualization.

Commvault Cloud helps provide the protection and resilience that stays with your workloads throughout the process, so data can remain protected before, during, and after migration. This can help keep recoverability from falling behind as workloads move.

Continuing the Conversation at Red Hat Summit

We’re already working with customers that are actively moving virtual machines onto OpenShift Virtualization – and we’re continuing these discussions at Red Hat Summit, May 11–14 in Atlanta.

At the Commvault booth, we’ll be:

  • Talking with IT leaders about real-world resilience challenges.
  • Sharing practical guidance on migrating with confidence.
  • Demonstrating Commvault Cloud protection for Red Hat OpenShift Virtualization.

If maintaining resilience and recoverability throughout your virtualization strategy is a priority, we’d welcome the opportunity to connect.

Moving Forward with Confidence

Red Hat OpenShift Virtualization is becoming a foundational component of modern enterprise infrastructure. But you can’t rush migration at any cost; you must build protection, resilience, and recovery into the process from the beginning.

With Commvault Cloud, protecting Red Hat OpenShift Virtualization workloads isn’t a future aspiration. It’s something customers already are doing – using a unified platform to modernize confidently while staying resilient and recoverable.

“Red Hat OpenShift Virtualization delivers a reliable, consistent foundation for organizations to support their entire virtualized estate,” says Steve Gordon, Senior Director, Product Management, Hybrid Cloud Platforms, at Red Hat. “By leveraging an optimized integration like Commvault Cloud with Red Hat OpenShift Virtualization, our customers can move forward with greater confidence, knowing their workloads are protected consistently before, during, and after migration.”

FAQs

Q: Why is VM migration considered a multi-phase process?

A: Most enterprises cannot migrate all workloads at once, so they operate in a hybrid state with legacy and new environments running simultaneously. This phased approach introduces complexity, making consistent protection and visibility essential throughout the transition.

Q: What role does resilience play during VM migration?

A: Resilience enables organizations to maintain data protection, recover quickly from failures, and defend against threats like ransomware. During migration, when systems are in flux, strong resilience measures can help prevent data loss and operational disruption.

Q: How does Commvault Cloud simplify protection across environments?

A: Commvault Cloud provides a single platform with policy-driven protection for VMware VMs, OpenShift Virtualization VMs, and containerized applications. This unified approach enables consistent operations without introducing new tools or workflows.

Q: What makes Kubernetes-native protection important?

A: Kubernetes-native protection aligns with how modern applications are deployed and managed, covering both containers and virtual machines. It enables simple data management, mobility, and recovery within cloud-native environments.

Q: How does recovery flexibility improve migration confidence?

A: Flexible recovery options, such as in-place and out-of-place restores, can help teams quickly recover workloads if something goes wrong. This adaptability helps reduce downtime and enables organizations to adjust migration plans without risking data integrity.

Q: How can organizations reduce complexity during infrastructure transitions?

A: By adopting a unified data protection platform, organizations can manage all workloads – virtualized and containerized – through a single interface. This approach helps reduce tool sprawl, simplify administration, and maintain consistent governance across evolving environments.

Jason Giza is Senior Manager, Global Content Partner Marketing, at Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Key Takeaways

  • The Readiverse Academy has introduced a structured, tiered certification path from foundational knowledge to advanced cloud engineering expertise.
  • Certifications are aligned to real-world roles, helping enable learners to build skills relevant to their responsibilities in Commvault Cloud environments.
  • The program includes four tiers – Practitioner, Specialist, Professional, and Expert – each increasing in depth and operational capability.
  • Learning is built across three core pillars: platform skills, cyber resilience, and workload expertise.
  • Flexible learning options, including self-paced and instructor-led formats, allow professionals to progress based on their schedules and goals.

The environments you protect with Commvault® Cloud are increasingly complex, and the expectations on your teams that run them are higher than ever. It’s no longer just about knowing the platform. It’s about being able to operate, protect, and recover, often under pressure.

If you’ve already started your learning journey in the Readiverse Academy, welcome back. And if you’re new here, you’re joining at the right time.

Today, we’re introducing a structured, tiered certification approach that gives learners a clear, skill‑based path from foundational platform knowledge to advanced cloud engineering expertise.

We Build Content for You

Commvault Cloud environments demand expertise across multiple responsibilities, often within the same role. Administrators, security specialists, cloud engineers, and workload owners require different depths and breadths of knowledge. And not everyone needs to learn the same things, in the same order, to be effective.

The new Readiverse Academy certification tiers reflect that reality. Learners progress through clearly defined levels that build on one another so that your certification aligns to what you actually do and validates those capabilities to the teams you work with.

  • Commvault Cloud Practitioner – foundational platform and resilience knowledge.
  • Commvault Cloud Specialist – expanded operational and security depth.
  • Commvault Cloud Professional – advanced recovery and workload expertise.
  • Commvault Cloud Expert – full cloud engineering and resilience leadership.

Each tier is earned through a combination of coursework, hands‑on lab activities, and validated assessments. As learners progress, the scope and depth of operational capability demonstrated increases accordingly.

A Clear Path Practitioner to Expert

The certification program is built around three core skill pillars that run through every level:

  • Foundational platform skills
  • Cyber resilience concepts
  • Workload and feature expertise

Each tier adds focused requirements across those pillars. Learners can complete individual courses or combine designated requirements to reach certification goals.

Already in Readiverse Academy? What this Means for You.

With a new structure like this, the most important question is what it means for the progress you’ve already made. If you’ve already completed courses or earned certifications in the Readiverse Academy, congratulations! Your investment matters, and we want to be clear about what happens next.

Those certifications represent your history and accomplishments with Commvault. The new program is aligned to our expanded portfolio of cyber resilience features for Commvault Software, Commvault SaaS, and hybrid environments. As your needs grow to require more from Commvault, these courses and certifications will help you configure, manage, and optimize Commvault to meet your organization’s unique needs.

There is no direct progression from the previous certification tracks to the new program, but your existing certifications validate your expertise on the former product releases. As those releases are retired, those certifications will reach end of life as well. Learners who are already invested in the Readiverse Academy are well positioned to progress quickly.

Who Should Take Readiverse Academy Courses and Certifications

Readiverse Academy certifications are designed for professionals working across Commvault SaaS, Commvault Software, and hybrid environments.

  • Platform administrators managing day‑to‑day operations.
  • Security specialists focused on protecting data and hardening environments.
  • Cloud engineers responsible for control plane configuration and advanced resilience.
  • Workload owners needing proficiency in specific data domains.

All training is available for self‑paced learning, with select courses also offered in instructor‑led formats, so learners can progress in a way that fits their role and schedule.

How To Get Started or Continue Your Learning Journey

Whether you’re starting fresh or continuing your journey, the next step is simple and designed to meet you where you are.

  • Login or register at commvault.com.
  • New to Commvault? Start with the Commvault Cloud Administrator course.
  • Responsible for workload support? Check out our catalog of courses covering just about everything.
  • Looking for strategies to support recovery from a cyberattack? The Cyber Resilience course is your first stop.

What Is Coming Next

Our goal is to make advancement predictable, transparent, and aligned to real‑world roles to help learners know what’s next and how to prepare for it.

We are committed to giving every Commvault Cloud user the knowledge to operate, protect, and recover their environment with confidence. Because when it matters most, certification isn’t about credentials. It’s about being resilient and ready to recover.

FAQs

Q: What is the purpose of the Readiverse Academy certification program?

A: The program provides a structured, skill-based learning path that helps professionals progress from basic platform knowledge to advanced cloud engineering expertise. It aligns training with real-world responsibilities to enable learners to apply their knowledge effectively in complex environments.

Q: What are the different certification tiers available?

A: There are four tiers: Commvault Cloud Practitioner, Specialist, Professional, and Expert. Each level builds on the previous one, increasing in technical depth, operational scope, and leadership capability.

Q: Who should enroll in Readiverse Academy courses?

A: The courses are designed for platform administrators, security specialists, cloud engineers, and workload owners working across SaaS, software, and hybrid environments. Each role can follow a tailored learning path based on their responsibilities.

Q: How are the certifications earned?

A: Certifications are achieved through a combination of coursework, hands-on labs, and validated assessments. As learners progress, they demonstrate increasing levels of expertise across platform, security, and workload domains.

Q: What happens to existing Readiverse Academy certifications?

A: Existing certifications remain valid as proof of past expertise but are tied to earlier product releases. As those releases are retired, the certifications will reach end of life, encouraging learners to transition to the new program.

Q: How can someone get started with the new program?

A: New learners can begin with the Commvault Cloud Administrator course, while existing users can log in to continue their progress. Additional courses are available based on specific goals, such as workload management or cyber resilience strategies.

Suzanne Klausner is Director, Customer Enablement Strategy, at Commvault.

More related posts

Thumbnail_Blog-Ready-or-Not-2026

Why Every CIO Needs a ‘Ready. Or Not.’ Mindset

Read more
Thumbnail_Blog_Readiness-Update-2024

Boost Your Cyber Resilience and Readiness

Read more
Social_Readiverse_Blog_LinkedIn-1

The Readiverse: Your Go-To Learning Resource for Cyber Resilience and Readiness

Read more

Key Takeaways

  • Traditional restore workflows can create infrastructure drift in Terraform-managed environments by provisioning new resources outside of state.
  • Clumio Backtrack is designed to restore data directly into existing S3 buckets and DynamoDB tables, helping preserve resource identity.
  • In-place recovery helps reduce the need for manual Terraform imports, endpoint rewiring, and state reconciliation during incidents.
  • Aligning recovery workflows with Infrastructure as Code (IaC) principles helps maintain configuration integrity and operational predictability.
  • Recovery design is as critical as backup design for teams operating production environments through Terraform.

IaC brings consistency, repeatability, and version control to cloud environments. Terraform becomes the source of truth for what exists, how it is configured, and how it should behave. Recovery introduces a new challenge.

Traditional restore operations often create new resources – new S3 buckets, new DynamoDB tables, new endpoints. From Terraform’s perspective, those resources were not defined in code. They do not exist in state.

That creates drift. In routine operations, drift is manageable. During an incident, it compounds. This is where recovery design matters as much as backup design.

The IaC Drift Problem

In a typical restore model:

  • A protected resource is restored as a new resource.
  • The original resource remains in a corrupted, overwritten, or failed state.
  • Terraform state does not recognize the new resource.
  • Teams must manually import resources into state.
  • Application configurations may need updates.

For platform teams managing production infrastructure through Terraform, this introduces friction at exactly the wrong moment. The challenge isn’t backup reliability itself, but how restore workflows integrate with infrastructure-as-code practices.

Introducing In-Place Recovery with Clumio Backtrack

Clumio Backtrack is a recovery capability that helps restore data directly into existing AWS resources rather than provisioning replacement infrastructure. When configured through the Clumio Terraform provider, Backtrack helps enable recovery workflows that align with infrastructure defined in code.

Clumio Backtrack supports both Amazon S3 and Amazon DynamoDB. For a deeper technical look at DynamoDB-specific recovery workflows, see our blog post about Clumio Backtrack for DynamoDB.

Instead of provisioning replacement resources, Backtrack helps restore:

  • S3 objects directly into the original bucket.
  • DynamoDB data directly into the original table.

From Terraform’s perspective, the infrastructure is intended to remain unchanged, with defined resources continuing to match the declared configuration. This helps reduce the need for manual resource imports, temporary restore tables, endpoint rewiring, and state reconciliation under pressure.

A Practical Example

Consider a production environment managed entirely through Terraform. A DynamoDB table tracks inventory; an S3 bucket stores application assets; identity and access management roles and policies are codified; and protection policies are defined via Terraform. If corruption occurs before a major traffic event, traditional restore approaches may create new resources that must be integrated back into Terraform.

With Backtrack, recovery is designed to occur within the existing resource boundary, helping keep the defined infrastructure intact and preserving resource identity. This approach is intended to eliminate the need to update Terraform to accommodate a newly created bucket or table, treating recovery as a data-layer operation rather than an infrastructure replacement exercise.

Why This Matters for Platform Teams

For teams committed to IaC, recovery workflows should preserve resource identity, state alignment, configuration integrity, and operational predictability. In-place restoration helps support those goals by limiting infrastructure changes during recovery events.

Recovery at Cloud Scale

Backtrack is designed to operate at cloud scale – whether restoring a small number of objects or large datasets. Recovery performance varies based on workload size and environment configuration, but the architectural objective remains consistent: restore data without introducing new infrastructure drift.

For Terraform-driven environments, that distinction matters.

Where This Approach Fits

In-place recovery is particularly relevant for:

  • High-throughput DynamoDB workloads
  • S3 buckets with large object counts
  • Production systems managed entirely through Terraform
  • omplex environments where redirecting application dependencies to new resources is difficult

When infrastructure is defined declaratively, recovery workflows should align with that same discipline.

Getting Started

To explore Clumio Backtrack and its integration with Terraform:

Defining protection as code is only part of the story. Designing recovery workflows that preserve infrastructure integrity completes the model.

FAQs

Q: What problem do traditional restores create in Terraform-managed environments?

A: Traditional restores often create new resources, such as replacement S3 buckets or DynamoDB tables, that are not defined in Terraform state. This can lead to infrastructure drift and force teams to manually import resources and reconcile configurations during high-pressure incidents.

Q: How does Clumio Backtrack differ from standard restore approaches?

A: Instead of provisioning new infrastructure, Clumio Backtrack is designed to restore data directly into the existing AWS resource. This approach helps preserve resource identity and keep Terraform state aligned with the declared configuration.

Q: Which AWS services are supported by Clumio Backtrack?

A: Clumio Backtrack supports Amazon S3 and Amazon DynamoDB. It is designed to restore S3 objects into the original bucket and DynamoDB data into the original table, helping maintain consistency with infrastructure defined in code.

Q: Why is in-place recovery important for platform teams?

A: Platform teams rely on infrastructure as code for consistency and control. In-place recovery helps maintain state alignment, configuration integrity, and operational predictability without introducing additional infrastructure changes during recovery events.

Q: When is in-place recovery particularly valuable?

A: It is especially useful for high-throughput DynamoDB workloads, S3 buckets with large object counts, and production systems fully managed through Terraform. It also can be beneficial in environments where redirecting application dependencies to newly created resources would be complex or risky.

Q: How can teams get started with Clumio Backtrack and Terraform integration?

A: Teams can review the Clumio Terraform provider documentation, explore the provider source code on GitHub, and watch the Backtrack demo video referenced in the blog to understand implementation and workflow details.

Lawrence Chang is Chief Engineering Officer of Clumio and Vir Choksi is Principal Product Marketing Manager at Commvault.

More related posts

Thumbnail_Blog-AWS-Data-Protection-Terraform-Clumio-2026

Automating AWS Data Protection with Terraform and Clumio

Read more
Thumbnail_Blog_Clumio-Tech-2025

Restore only what matters: Clumio Backtrack for DynamoDB

Read more
Thumbnail_Blog-GoogleWorkspace-2026

How the Move to Clumio Delivered 66.7% Savings on AWS Backups

Read more
Thumbnail_Blog_AWS-Marketplace-AI

Commvault Featured in New AI Agent Solutions in AWS Marketplace

Read more
Man-and-woman-working-on-laptops-profile-Crocus-Thumbnail

Protecting Your Amazon S3 Data with Clumio: A Comprehensive Solution

Read more

Clumio

Read more

Key Takeaways

  • Most tabletop exercises validate performance instead of exposing real gaps in incident response.
  • For exercises to be effective, they must introduce friction, ambiguity, and pressure to reflect real-world incidents.
  • Limiting the scope of the exercise to a few critical scenarios and defining success as finding problems rather than looking good can lead to more meaningful and actionable insights.
  • Cross-functional participation, not just that of technical teams, is essential to accurately test organizational response.
  • True resilience is proven through actual recovery testing, not just discussion-based scenarios.

There is a moment most security leaders recognize, even if they do not say it out loud. The tabletop just wrapped. The team is filing out. Everyone looks reasonably satisfied. And somewhere in the back of your mind, a quiet question surfaces: Did we actually learn anything?

If you are honest, the answer is often no.

That is not because tabletop exercises are a bad idea. They are one of the most valuable tools a security leader has. The problem is how most organizations run them – and what they are actually measuring when they do.

The Performance Trap

The most common mistake in tabletop exercises has nothing to do with the scenario. It has to do with the goal. Most teams, consciously or not, build exercises designed to demonstrate competence rather than discover gaps.

The scenario generally follows a clean arc. Information arrives in a logical sequence. The right people say the right things. Everyone feels prepared. And that feeling – confident, well-rehearsed, almost collegial – is exactly the problem.

Real incidents do not run on clean arcs. They arrive with incomplete information, conflicting signals, unavailable people, and a business demanding answers faster than the facts support. If your tabletop does not create that kind of friction, you have not tested incident response. You have practiced a conversation.

When the exercise is designed to validate rather than stress-test, a second problem follows: People stop being honest. Nobody says, “I don’t know who owns that decision” or “we have never actually tested that recovery path.” They say what sounds right. And the gaps that should surface in a controlled environment stay hidden until they surface in a real one.

What a Good Exercise Actually Tests

Before you build a scenario, you need to answer a simpler question: What do you actually want to learn? Not 20 things. Three or four.

Can your team make a shutdown decision fast enough, and does everyone know who has the authority to make it? When security, IT, legal, and communications are all in the room with conflicting priorities, can they actually reach decisions together? Can you explain the business impact of an incident clearly enough for leadership to act – not just understand? And if you had to restore a critical system in the next four hours, could you really do it?

Once you know what you are testing, build a scenario with real friction. Make a key person unavailable mid-exercise. Introduce a customer escalation. Have a regulator ask a question the team cannot answer from the runbook.

Give people incomplete information and see how they make decisions anyway. The value is not in watching people succeed under pressure. It is in finding the places where the process breaks down while the stakes are still low enough to fix it.

Say this out loud at the start: Success today means finding problems, not looking good. That one sentence changes what people are willing to say in the room.

The People Problem

A tabletop that only involves security and IT is a technical conversation, not an incident response exercise. If legal is not in the room, if communications is not in the room, if business owners and executive leadership are absent, you are not testing how your organization actually responds to a crisis. You are testing how a subset of smart people talk through a hypothetical.

Real incidents are handled across the business. The exercise should reflect that.

Talking Through It Is Not Enough

This is where most organizations stop short. A paper exercise is important – but it is not confidence.

Talking through a recovery scenario tells you something. Actually restoring a system tells you something different. Can you bring identity back to a clean point in time? Can you validate that what you are recovering is trustworthy? Can you restore a Tier 1 application and confirm it comes back cleanly, without carrying the infection with it?

Those are not questions you can answer in a conference room. At some point, the plan has to meet the environment – and you need to know whether they match.

After the Exercise Ends

The debrief tells you whether the exercise mattered. If the hot wash is quiet, vague, or full of “good reminders,” the exercise did not push hard enough. A well-run tabletop should leave you with a short list of real findings, clear owners, and deadlines. If you cannot answer what broke, who is fixing it, and by when, you ran an event, not an exercise.

The goal was never to pass the exercise. It was to learn something important while the cost of being wrong was still just time.

Watch our recent episode of the STRIVE podcast, where I join my colleague Chris Mierzwa, Senior Director, Portfolio Marketing, for an in-depth conversation about tabletop exercises.

FAQs

Q: Why do most tabletop exercises fail to deliver real value?

A: Many exercises are designed to make teams look prepared rather than uncover weaknesses. This leads to scripted discussions that miss the unpredictability and pressure of real incidents.

Q: What should a tabletop exercise aim to achieve?

A: It should focus on answering a small number of critical questions, such as decision-making speed, ownership clarity, and recovery capability. This focus helps teams uncover meaningful gaps instead of surface-level insights.

Q: How can organizations make exercises more realistic?

A: Introduce uncertainty, missing information, and unexpected disruptions during the scenario. These elements force teams to think critically and act under pressure, closer to real incident conditions.

Q: Who should be involved in a tabletop exercise?

A: Beyond security and IT, teams like legal and communications, business leaders, and executives should participate. This enables the exercise to reflect how real incidents are managed across the organization.

Q: Why is talking through recovery not enough?

A: Discussion can highlight plans, but only real testing proves whether systems actually can be restored cleanly and quickly. Practical validation is necessary to confirm recovery readiness.

Q: What defines a successful tabletop exercise outcome?

A: A strong exercise results in clear findings, assigned owners, and defined timelines for remediation. If these are missing, the exercise likely did not challenge the team enough.

Chris Bevil is Principal, Global Cyber Resilience & AI, at Commvault.

More related posts

Thumbnail_Blog-Commvault-Enhancements-Cyber-Recovery-2026

Commvault Enhancements in Cyber Recovery

Read more
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more
Thumbnail_5_MV_Blogs_2025

Recovery Testing: The Missing Piece in Most Cyber Resilience Programs

Read more
Urgent-Need-for-Cyber-Resilience

The Urgent Need for Cyber Resilience

Read more
Thumbnail_Blog_Modern-Playbook-2025

Your Modern Playbook for Rapid Response and Clean Recovery

Read more

Key Takeaways

  • Commvault’s data access governance, powered by Satori, unifies visibility, access control, and auditability across structured data, unstructured files, SaaS apps, and AI workloads.
  • A single, consistent access policy can govern both human users and AI models, helping reduce silos and limit overexposure of sensitive data.
  • Continuous discovery, classification, and risk scoring help provide prioritized insight into where sensitive data resides and where exposure risk is highest.
  • Policy-driven dynamic masking and redaction help enforce least-privilege access, allowing authorized use of data while helping protect sensitive fields.
  • Centralized, near-real-time audit trails deliver comprehensive visibility into user queries, AI prompts, and governed access events to help support compliance and accountability.

With AI now embedded in every workflow, from copilots and chat assistants to analytics tools, all these endpoints have become ravenous for data to ingest. Commvault’s data access governance capabilities, powered by Satori, are designed to make that data-hungry AI more by unifying visibility, access control, and auditability across your data landscape.

A Unified Foundation for AI-Era Data Governance

Commvault’s data access governance features bring structured databases, unstructured files in SaaS apps, and AI workloads under one governance model, instead of treating them as separate silos. Organizations now can apply a single access policy to both human users and AI models, so that the same rules determine who or what can see sensitive information, regardless of where it lives.

By integrating Satori into the Commvault Command Center, these capabilities extend Commvault’s traditional protection into live data and AI usage, not just backups and snapshots. This helps security and data protection teams move from reactive incident response to proactive control over how data is discovered, accessed, and used in real time.

Continuous Discovery, Classification, and Risk Scoring

A core pillar of our data governance capabilities is unified discovery and classification of data across clouds and SaaS platforms. As organizations connect to environments such as AWS, Azure, Google Cloud, Snowflake, Databricks, and others, Commvault automatically maps data stores and continuously classifies them, whether the data is structured or unstructured.

Each asset is assigned a risk score, giving teams a prioritized view of where sensitive information resides and where exposure is most likely. Instead of relying on periodic scans, the platform keeps pace with data movement, new stores, and classification changes, helping teams spot issues earlier and focus on the highest-risk areas first.

Least-Privilege Access with Dynamic Masking and Redaction

Traditional data protection often stops at knowing where sensitive data is; Commvault’s capabilities emphasize controlling how that data is revealed. Using policy-driven masking and redaction, organizations can enforce least-privilege access so that users, services, and AI models only see the specific information they are authorized to see, with sensitive fields anonymized or hidden as needed.

Because the same masking and redaction policies apply across all connected environments, organizations can consistently safeguard access instead of fragmented, application-by-application rules. This helps reduce the risk of data overexposure, where too many people or systems have access to more data than they legitimately need.

Security and Safe Prompt Handling

A standout capability is policy-driven AI security that operates at the prompt and response level. Before data is ever sent to an AI model, Commvault, powered by Satori, can intercept the interaction, detect sensitive fields (such as regulated personal details), and apply inline masking or redaction according to existing data access policies.

Unlike solutions that simply block entire prompts or rely solely on downstream data loss prevention (making security someone else’s concern), this approach allows employees to keep using AI assistants productively while keeping sensitive data under governance. Because redaction occurs before the model processes the data, it also helps prevent sensitive information from influencing or contaminating AI training datasets, protecting both the users and the broader AI environment.

Centralized Audit Trails Aids in Compliance

The final piece of our data access governance capabilities is comprehensive, centralized audit logging. Every interaction – whether a user query, an AI prompt, or a governed access event – is captured with details such as who accessed what, which policy was applied, and what redactions occurred, in near–real time.

This unified audit visibility spans live data, AI prompts, and access governance events, giving security, IT, and compliance leaders a single authoritative record rather than disparate logs from point tools. For CISOs and CIOs, this means faster compliance reviews and clear proof that governance is not just documented on paper but actively enforced across the environment.

Helping Organizations Adopt AI Securely

Taken together, these new features give organizations a cohesive way to govern data in an AI-enabled world: unified visibility across clouds, SaaS, and AI; one policy for users and models; dynamic masking and redaction for least-privilege access; and policy-aware AI prompt protection backed by complete audit trails. The result is a shift from reactive controls to proactive, AI-ready data access governance, helping teams embrace AI innovation while maintaining control of their most sensitive information.

FAQs

Q: What makes Commvault’s approach to AI data governance different from traditional data protection?

A: Traditional data protection often focuses on backups and incident response after exposure occurs. Commvault extends governance into live environments and AI interactions, helping enable proactive control over how data is discovered, accessed, and used in real time. This shift helps organizations manage risk before it becomes a breach.

Q: How does unified discovery and classification improve security?

A: Continuous discovery and classification automatically map and label structured and unstructured data across clouds and SaaS platforms. By assigning risk scores to each asset, teams gain a prioritized view of sensitive data exposure. This helps enable faster identification of high-risk areas and more focused remediation efforts.

Q: What is dynamic masking, and why is it important for AI workloads?

A: Dynamic masking and redaction limit what users, services, and AI models can see based on predefined policies. Sensitive fields can be anonymized or hidden while still allowing legitimate access to relevant data. This approach supports productivity while helping reduce the risk of overexposure.

Q: How does policy-aware AI prompt protection work?

A: Policy-aware AI security intercepts prompts and responses before data reaches the AI model. It helps detect sensitive information and apply inline masking or redaction according to existing policies. This helps employees continue using AI tools while helping keep regulated data under governance and out of training datasets.

Q: How do centralized audit trails support compliance efforts?

A: Comprehensive audit logging captures details about who accessed what data, which policies were applied, and what redactions occurred. This unified visibility spans live data and AI interactions, helping give security and compliance leaders a clear, authoritative record. It helps enable faster reviews and demonstrate that governance controls are actively enforced.

Q: How do these capabilities help organizations adopt AI safely?

A: By combining unified visibility, consistent policy enforcement, dynamic masking, and complete audit trails, Commvault’s data governance capabilities help give organizations a cohesive framework for governing AI-era data. These controls help enable innovation while helping maintain control over sensitive information. The result is a more confident and safe path to AI adoption.

Nico Guerrera is Senior Technical Marketing Manager at Commvault.

More related posts

Social_Blog_Satori_GigaOm_Leader_2026_Linkedin

Satori Named Leader in GigaOm’s Data Access Governance Radar Report

Read more
Thumbnail_Blog-Conversational-Resilience-2025-Linkedin

Conversational Resilience: The New Way to Manage and Protect Enterprise Data

Read more
Thumbnail_Blog_Satori-Acquisition-2025

Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more