Die wichtigsten Erkenntnisse

• Bei der „Minimum Viable Sovereignty“ (MVS) geht es darum, für die jeweiligen Workloads das richtige Maß an Kontrolle anzuwenden.
• Die Gleichbehandlung aller Workloads kann zu unnötiger Komplexität und Kosten oder zu unzureichendem Schutz führen.
• Unternehmen lassen sich in der Regel in drei Souveränitätsprofile einteilen: „True Sovereign“, „Regulated Enterprise“ und „Hybrid Multi-Cloud“.
• Eine einheitliche Governance über gemischte Umgebungen hinweg ist eine der größten betrieblichen Herausforderungen.

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.

Nicht alle Workloads sind gleich

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

Regulierte Unternehmen lassen sich in drei erkennbare Profile einteilen, die jeweils unterschiedliche Hauptantriebsfaktoren und Investitionsprioritäten aufweisen.

• 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.

Die Kosten einer falschen Kalibrierung

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 vierten Beitrags dieser Reihe) umfasst.

Ein praktischer Ausgangspunkt

Ein MVS-Ansatz umfasst drei Schritte:

1. Classify workloads by their actual sovereignty requirements across each pillar – don’t start with deployment models.
2. Ordnen Sie jede Workload-Klasse der Bereitstellungsstufe zu, die diese Anforderungen erfüllt, und zwar über das gesamte Spektrum hinweg – von Regionen öffentlicher Hyperscaler über souveräne Public Clouds bis hin zu lokal verwalteten Umgebungen.
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 – dem Thema des dritten Beitrags dieser Reihe, der Säule, die in den meisten Strategien erst nachträglich berücksichtigt wird.

Nutzen Sie die Selbsteinschätzung im„„Digital Sovereignty Readiness Report“““, um Ihre aktuelle Situation in allen vier Säulen zu ermitteln.

FAQs

F: Was ist „Minimum Viable Sovereignty“ (MVS)?

A: MVS bezeichnet die Praxis, Souveränitätskontrollen auf der Grundlage tatsächlicher geschäftlicher und regulatorischer Anforderungen anzuwenden. Damit soll sowohl eine übermäßige Komplexität als auch ein unzureichender Schutz vermieden werden.

F: Warum ist die Einstufung der Arbeitsbelastung wichtig?

A: Verschiedene Workloads sind mit unterschiedlichen regulatorischen und betrieblichen Verpflichtungen verbunden. Die Klassifizierung von Workloads hilft Unternehmen dabei, die angemessenen Souveränitätskontrollen anzuwenden.

F: Welche drei gängigen Souveränitätsprofile gibt es?

A: Die drei Profile sind eigenständige Organisationen, regulierte Organisationen und hybride Multi-Cloud-Organisationen. Jede davon unterliegt spezifischen betrieblichen und Compliance-Anforderungen.

F: Welche Risiken ergeben sich aus einer übermäßigen Regulierung der Souveränität?

A: Übermäßige Kontrollen können die Komplexität der Geschäftsabläufe und die Kosten erhöhen, ohne dass dadurch ein nennenswerter Nutzen in Bezug auf die Einhaltung von Vorschriften oder den Geschäftswert entsteht.

F: Warum stellen gemischte Umgebungen eine Herausforderung für die Governance dar?

A: Unternehmen nutzen häufig mehrere Cloud- und Infrastrukturmodelle. Es ist schwierig, in allen Umgebungen einheitliche Kontrollmaßnahmen, Prüfungsnachweise und Recovery-Standards aufrechtzuerhalten.

Ruben Renders ist Solutions Director, MSP, bei Commvault.

Die wichtigsten Erkenntnisse

• 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.

Die wichtigsten Erkenntnisse

• Vishing-Angriffe haben dramatisch zugenommen, wobei organisierte Gruppen Social-Engineering-Methoden systematisch einsetzen, um sich über Helpdesks einen ersten Zugang zu verschaffen.
• Angreifer wechseln schnell von kompromittierten Benutzerkonten zu dauerhaften Maschinenidentitäten wie OAuth-Tokens und Dienstkonten.
• Den meisten Organisationen mangelt es an Kontrollmechanismen und Transparenz in Bezug auf nicht-menschliche Identitäten (NHI), was einen erheblichen Sicherheitsblindfleck darstellt.
• Effective Readiness depends on linking identity signals and treating machine identities as risky resources.
• Echte Resilienz setzt die Fähigkeit voraus, unbefugte Änderungen an Berechtigungen zu erkennen und rückgängig zu machen, bevor Angreifer eine dauerhafte Präsenz aufbauen können.

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 im Jahr 2025 um 449 %.. Kriminelle Gruppen haben Social Engineering zu einem skalierbaren Geschäftsmodell gemacht: Sie rekrutieren Anrufer, erstellen Skripte und500 bis 1.000 Dollar zahlen 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.

Weniger als 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 zu 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.

Wie Readiness aussieht

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 Resilienceunterstützt die schnelle Erkennung, Rücknahme und Recovery Ihrer Identitätsumgebung.

FAQs

F: Was ist ein Vishing-Angriff im Zusammenhang mit der Unternehmenssicherheit?

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.

F: Warum wenden sich Angreifer nach einem Vishing-Angriff auf Maschinenidentitäten zu?

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 ist Field CTO bei Commvault.

Die wichtigsten Erkenntnisse

• Social-Engineering-Angriffe auf den Helpdesk sind mittlerweile ein Hauptangriffspunkt, wobei Vishing-Angriffe (Voice-Phishing) rapide zunehmen und zum Diebstahl von Zugangsdaten führen.
• Nicht-menschliche Identitäten wie Dienstkonten und Tokens stellen einen erheblichen Sicherheitsblindfleck dar; sie werden oft nicht verwaltet und in großem Umfang für laterale Bewegungen ausgenutzt.
• Active Directory (AD) ist aufgrund seiner zentralisierten Steuerung und möglicher Fehlkonfigurationen ein besonders attraktives Angriffsziel.
• Prävention allein reicht nicht aus; Unternehmen benötigen leistungsfähige Erkennungs- und schnelle Wiederherstellungsfunktionen, um den Schaden zu begrenzen.
• Immediate operational actions – like auditing accounts and correlating help desk activity with identity changes – can significantly reduce risk.

AD ist nach wie vor ein Hauptziel für Angreifer, da es das Herzstück der Identitätsverwaltung in Unternehmen bildet.Jüngste Untersuchungen zeigen, dass67 % der Vorfälle stehen mittlerweile im Zusammenhang mit Identitätsmissbrauch, 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 thier – and why the path is so much shorter than security teams might expect.

3 Schritte zu einem umfassenden Kompromiss

Angreifergruppen wie ShinyHunters und Scattered Spider haben Social Engineering zu einem industriellen Geschäft gemacht.Voice phishing – vishing – jumped 449% in 2025.Die Anrufer werden rekrutiert, erhalten ein Skript undbis zu 1.000 Dollar gezahlt 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.Die Ausdehnung und der operative Aufwand erschweren die Rotation und die Prüfung. Diese seitliche Bewegung hat ein Ziel: Active Directory.

AD ist das Ziel

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.

Prävention ist notwendig, aber nicht ausreichend

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.

Was Sie jetzt tun können, um Ihre Identitätsresilienz zu stärken

The gap between whier most organizations are and whier 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. Stellen Sie einen Zusammenhang zwischen den Helpdesk-Aktivitäten und den Ereignissen zur Erstellung von Tokens und Konten her.

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. 

Erfahren Sie, wie Commvault Cloud umfassenden Schutz für Active Directory bietet – 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 hier.And be sure to read Vidya’s blog, Der blinde Fleck bei der Maschinenidentität ist mittlerweile eine der wichtigsten Angriffsflächen.

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 ist leitender Technologe und Field CTO bei Commvault.

Die wichtigsten Erkenntnisse

• Die Migration von VMs zu Red Hat OpenShift Virtualization ist ein schrittweiser Prozess, der einen durchgängigen Schutz über hybride Umgebungen hinweg erfordert.
• Eine einheitliche, Kubernetes-native platform , die Komplexität zu verringern und den Einsatz separater Tools oder Prozesse überflüssig zu machen.
• Reliable resilience – including immutable backups and threat detection – is critical during migration, when risks are highest.
• Dank flexibler Wiederherstellungsoptionen können Unternehmen schnell reagieren, falls Migrationsschritte fehlschlagen oder sich Zeitpläne verschieben.
• Die Konsolidierung der Sicherheitsmaßnahmen für VMs und Container trägt dazu bei, die Vielzahl an Tools zu reduzieren und eine einheitliche Governance zu gewährleisten.

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 ist eine Reise, kein einmaliges Ereignis

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-basierte virtuelle Maschinen unterstützen weiterhin die Kerngeschäftsprozesse.
• VMs, die nun auf Red Hat OpenShift Virtualization laufen.
• Containerisierte Anwendungen, die dieselben Red Hat OpenShift-Cluster gemeinsam nutzen.

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.

Ein zuverlässiger Schutz ist unerlässlich

Commvault bietet seit langem Lösungen für die Datensicherung und -wiederherstellung sowohl für VMware-Umgebungen als auch für Kubernetes-Workloads, die auf Red Hat OpenShift ausgeführt werden. Dasselbe Kubernetes-native, richtliniengesteuerte Schutzmodell gilt nun auch für VMs, die auf Red Hat OpenShift Virtualization ausgeführt werden. Was bei den Kunden wirklich Anklang findet, ist die Beständigkeit:

• Eine einzige platform Schutz und Wiederherstellung.
• Richtlinienbasierte Abläufe, die einheitlich auf alle Workloads angewendet werden.
• Entwickelt, um mit Ihren bestehenden Tools und Prozessen zu harmonieren, während sich die Umgebungen weiterentwickeln.

VMs, die auf Red Hat OpenShift Virtualization ausgeführt werden, werden mithilfe derselben Workflows und Governance-Strukturen geschützt wie containerisierte Anwendungen. Dieser einheitliche Ansatz wird von Unternehmen genutzt, die auf Red Hat OpenShift standardisieren und eine einfachere, einheitlichere Methode zur Verwaltung von Daten über verschiedene Umgebungen hinweg anstreben. Diese Funktion ist ab sofort verfügbar.Cloudunterstützt die Sicherung von Red Hat OpenShift Virtualization-Umgebungen, die auf die Long-Term-Support-Version 11.40 und die Innovation-Version 11.42 abgestimmt sind. Das bedeutet, dass Kunden diese Funktionen bereits jetzt in der Produktion einsetzen können.

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.

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-Resilienz ist entscheidend, wenn die Migration das Risiko erhöht.

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

Cloud helps maintain resilience throughout this phase with:

• Air-Gapped- und unveränderliche Backups für Workloads unter Red Hat OpenShift Virtualization.
• Sicherungsdaten, die die Bedrohungssuche und forensische Analysen unterstützen und den Teams dabei helfen, die Wiederherstellungsbereitschaft vor der Wiederherstellung von Workloads zu überprüfen.
• Advanced recovery capabilities designed to help organizations minimize operational disruption.

Unabhängig davon, ob sich die Workloads in der Vorbereitungsphase der Migration, mitten in der Umstellung oder bereits voll im Betrieb auf Red Hat OpenShift Virtualization befinden, bleibt die Ausfallsicherheit gewährleistet.

Flexibilität bei der Genesung schafft Vertrauen

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-nativer Schutz über VMs hinaus

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

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.

Eindämmung der Tool-Flut im Zuge der Weiterentwicklung der Infrastruktur

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

By using Cloud as a unified protection platform for:

• VMware-VMs.
• Red Hat OpenShift Virtualization-VMs.
• Containerisierte Anwendungen.

Unternehmen können dazu beitragen, die Vielzahl an Tools zu reduzieren, die Verwaltung zu vereinfachen und eine einheitliche Governance aufrechtzuerhalten, auch wenn sich die Infrastrukturstrategien weiterentwickeln.

Wie alles zusammenkommt

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.

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:

• Gespräche mit IT-Führungskräften über praktische Herausforderungen im Bereich der Ausfallsicherheit.
• Praktische Tipps für eine reibungslose Migration.
• Demonstrating 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.

Mit Zuversicht in die Zukunft

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 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 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

F: Warum wird die VM-Migration als mehrstufiger Prozess betrachtet?

A: Die meisten Unternehmen können nicht alle Workloads auf einmal migrieren, sodass sie in einem Hybridzustand arbeiten, in dem alte und neue Umgebungen gleichzeitig betrieben werden. Dieser schrittweise Ansatz bringt Komplexität mit sich, weshalb ein einheitlicher Schutz und eine durchgängige Transparenz während des gesamten Übergangs unerlässlich sind.

F: Welche Rolle spielt die Ausfallsicherheit bei der VM-Migration?

A: Dank Ausfallsicherheit können Unternehmen den Datenschutz gewährleisten, sich schnell von Ausfällen erholen und sich gegen Bedrohungen wie Ransomware schützen. Während der Migration, wenn sich die Systeme im Umbruch befinden, können wirksame Maßnahmen zur Ausfallsicherheit dazu beitragen, Datenverluste und Betriebsstörungen zu verhindern.

Q: How does Cloud simplify protection across environments?

A: 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.

F: Warum ist ein Kubernetes-nativer Schutz so wichtig?

A: Der Kubernetes-native Schutz ist auf die Art und Weise abgestimmt, wie moderne Anwendungen bereitgestellt und verwaltet werden, und deckt sowohl Container als auch virtuelle Maschinen ab. Er ermöglicht eine einfache Datenverwaltung, Mobilität und Wiederherstellung in cloud Umgebungen.

F: Inwiefern trägt die Flexibilität bei der Wiederherstellung dazu bei, das Vertrauen in die Migration zu stärken?

A: Flexible Wiederherstellungsoptionen, wie beispielsweise In-Place- und Out-of-Place-Wiederherstellungen, können Teams dabei helfen, Workloads schnell wiederherzustellen, falls etwas schiefgeht. Diese Flexibilität trägt dazu bei, Ausfallzeiten zu reduzieren, und ermöglicht es Unternehmen, ihre Migrationspläne anzupassen, ohne die Datenintegrität zu gefährden.

F: Wie können Unternehmen die Komplexität bei Infrastrukturumstellungen reduzieren?

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 Gizaist Senior Manager im Bereich „Global Content Partner Marketing“ bei Commvault.

Die wichtigsten Erkenntnisse

• Die Readiverse-Akademie hat einen strukturierten, mehrstufigen Zertifizierungspfad eingeführt, der von den Grundlagen bis hin zu fortgeschrittenen Fachkenntnissen cloud reicht.
• Die Zertifizierungen sind auf reale Aufgabenbereiche abgestimmt und helfen den Lernenden dabei, Fähigkeiten zu erwerben, die für ihre Aufgaben in Cloud relevant sind.
• The program includes four tiers – Practitioner, Specialist, Professional, and Expert – each increasing in depth and operational capability.
• Das Lernen stützt sich auf drei Kernsäulen: platform , Cyber-Resilienz und Fachwissen im Bereich Workloads.
• Flexible Lernmöglichkeiten, darunter sowohl selbstbestimmte als auch von Lehrkräften geleitete Formate, ermöglichen es Berufstätigen, entsprechend ihrem Zeitplan und ihren Zielen Fortschritte zu erzielen.

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-Akademie, 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.

Wir erstellen Inhalte für Sie

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-Akademie 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.

„Clear Path“ – Vom Anfänger zum Experten

Das Zertifizierungsprogramm basiert auf drei Kernkompetenzen, die sich durch alle Stufen ziehen:

• Grundlegende platform
• Konzepte zur Cyber-Resilienz
• Arbeitsaufwand und Fachkenntnisse

Jede Stufe umfasst spezifische Anforderungen, die sich auf diese Säulen beziehen. Die Lernenden können einzelne Kurse absolvieren oder bestimmte Anforderungen kombinieren, um ihre Zertifizierungsziele zu erreichen.

Already in Readiverse-Akademie? 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-Akademie, 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-Akademie are well positioned to progress quickly.

Who Should Take Readiverse-Akademie Courses and Certifications

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

• Platform administrators managing day‑to‑day operations.
• Sicherheitsexperten, die sich auf den Schutz von Daten und die Absicherung von Systemumgebungen konzentrieren.
• Cloud , die für die Konfiguration der Steuerungsebene und für erweiterte Ausfallsicherheit zuständig sind.
• Verantwortliche für Arbeitsabläufe, die über Fachkenntnisse in bestimmten Datenbereichen verfügen müssen.

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.

So beginnen Sie Ihre Lernreise oder setzen sie fort

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

• Melden Sie sich beiCommvault.com.
• Sind Sie neu bei Commvault? Beginnen Sie mit dem Kurs „Commvault Cloud “.
• Sind Sie für die Unterstützung bei der Arbeitsbelastung zuständig? Dann schauen Sie sich unseren Kurskatalog an, der so gut wie alle Themen abdeckt.
• Suchen Sie nach Strategien zur Unterstützung der Wiederherstellung nach einem Cyberangriff? Dann ist der Kurs „Cyber Resilience“ genau das Richtige für Sie.

Was kommt als Nächstes?

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-Akademie certification program?

A: Das Programm bietet einen strukturierten, kompetenzorientierten Lernpfad, der Fachkräften dabei hilft, platform von den Grundlagen platform bis hin zu fortgeschrittenem Fachwissen cloud auszubauen. Es stimmt die Schulungen auf die Aufgaben in der Praxis ab, damit die Teilnehmer ihr Wissen in komplexen Umgebungen effektiv anwenden können.

F: Welche verschiedenen Zertifizierungsstufen gibt es?

A: Es gibt vier Stufen: Commvault Cloud , Specialist, Professional und Expert. Jede Stufe baut auf der vorherigen auf und zeichnet sich durch zunehmende technische Tiefe, einen größeren operativen Umfang sowie gestiegene Führungsfähigkeiten aus.

Q: Who should enroll in Readiverse-Akademie courses?

A: Die Kurse richten sich an platform , Sicherheitsspezialisten, cloud und Workload-Verantwortliche, die in SaaS, Software- und Hybridumgebungen tätig sind. Jede dieser Rollen kann einen auf ihre jeweiligen Aufgaben zugeschnittenen Lernpfad absolvieren.

F: Wie erlangt man die Zertifizierungen?

A: Die Zertifizierungen werden durch eine Kombination aus Kursarbeit, praktischen Übungen und validierten Prüfungen erworben. Im Laufe ihrer Ausbildung weisen die Lernenden ein zunehmend höheres Maß an Fachwissen in den Bereichen platform, Sicherheit und Workloads nach.

Q: What happens to existing Readiverse-Akademie certifications?

A: Bestehende Zertifizierungen behalten ihre Gültigkeit als Nachweis früherer Fachkenntnisse, sind jedoch an frühere Produktversionen gebunden. Wenn diese Versionen aus dem Verkehr gezogen werden, läuft die Gültigkeit der Zertifizierungen aus, was die Lernenden dazu anregen soll, auf das neue Programm umzusteigen.

F: Wie kann man mit dem neuen Programm beginnen?

A: Neue Teilnehmer können mit dem Kurs „Commvault Cloud beginnen, während sich bestehende Nutzer anmelden können, um ihre Fortschritte fortzusetzen. Je nach den jeweiligen Zielen stehen weitere Kurse zur Verfügung, beispielsweise zu den Themen Workload-Management oder Strategien zur Cyber-Resilienz.

Suzanne Klausner ist Leiter des Bereichs „Customer Enablement Strategy“ bei Commvault.

Die wichtigsten Erkenntnisse

• Die meisten Tabletop-Übungen dienen eher der Leistungsüberprüfung als der Aufdeckung tatsächlicher Lücken bei der Reaktion auf Vorfälle.
• Damit Übungen wirksam sind, müssen sie Reibungspunkte, Unklarheiten und Druck erzeugen, um reale Vorfälle widerzuspiegeln.
• Wenn man den Umfang der Übung auf einige wenige kritische Szenarien beschränkt und Erfolg nicht darin sieht, einen guten Eindruck zu hinterlassen, sondern vielmehr darin, Probleme aufzudecken, kann dies zu aussagekräftigeren und umsetzbareren Erkenntnissen führen.
• Eine funktionsübergreifende Beteiligung – nicht nur die der technischen Teams – ist unerlässlich, um die Reaktionsfähigkeit der Organisation genau zu testen.
• Echte Ausfallsicherheit zeigt sich erst in praktischen Wiederherstellungstests und nicht nur in theoretischen Szenarien.

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.

Die Leistungsfalle

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.

Was eine gute Übung tatsächlich testet

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.

Sagen Sie das gleich zu Beginn laut: Erfolg bedeutet heute, Probleme zu finden, und nicht, einen guten Eindruck zu machen. Dieser eine Satz verändert die Art und Weise, wie sich die Anwesenden äußern.

Das Problem mit den Menschen

Ein Tabletop-Übung, bei der es ausschließlich um Sicherheit und IT geht, ist eine technische Diskussion und keine Übung zur Krisenbewältigung. Wenn die Rechtsabteilung nicht dabei ist, wenn die Kommunikationsabteilung nicht dabei ist, wenn die Geschäftsbereichsleiter und die Geschäftsleitung fehlen, testen Sie nicht, wie Ihre Organisation tatsächlich auf eine Krise reagiert. Sie testen lediglich, wie eine Gruppe kluger Köpfe ein hypothetisches Szenario durchspielt. Tatsächliche Vorfälle werden unternehmensweit bearbeitet. Die Übung sollte dies widerspiegeln.

Darüber zu reden reicht nicht aus

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.

Nach Beendigung der Übung

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 ein ausführliches Gespräch über Tabletop-Übungen.

FAQs

Frage: Warum bringen die meisten Tabletop-Übungen keinen wirklichen Nutzen?

A: Viele Übungen sind darauf ausgelegt, Teams als gut vorbereitet erscheinen zu lassen, anstatt Schwachstellen aufzudecken. Dies führt zu vorgefertigten Diskussionen, bei denen die Unvorhersehbarkeit und der Druck realer Vorfälle zu kurz kommen.

F: Was sollte das Ziel einer Tabletop-Übung sein?

A: Der Schwerpunkt sollte auf der Beantwortung einer kleinen Anzahl entscheidender Fragen liegen, wie beispielsweise der Geschwindigkeit der Entscheidungsfindung, der Klarheit hinsichtlich der Zuständigkeiten und der Wiederherstellungsfähigkeit. Dieser Fokus hilft den Teams dabei, wesentliche Lücken aufzudecken, anstatt sich mit oberflächlichen Erkenntnissen zu begnügen.

F: Wie können Organisationen Übungen realistischer gestalten?

A: Führen Sie im Verlauf des Szenarios Unsicherheiten, fehlende Informationen und unerwartete Störungen ein. Diese Elemente zwingen die Teams dazu, kritisch zu denken und unter Druck zu handeln – ähnlich wie unter realen Einsatzbedingungen.

F: Wer sollte an einer Tabletop-Übung teilnehmen?

A: Neben den Bereichen Sicherheit und IT sollten auch Teams wie die Rechtsabteilung und die Kommunikationsabteilung sowie Führungskräfte und leitende Angestellte einbezogen werden. So kann die Übung widerspiegeln, wie reale Vorfälle unternehmensweit bewältigt werden.

F: Warum reicht es nicht aus, über die Genesung zu sprechen?

A: Durch Diskussionen lassen sich zwar Pläne verdeutlichen, doch nur durch echte Tests lässt sich nachweisen, ob Systeme tatsächlich einwandfrei und schnell wiederhergestellt werden können. Eine praktische Überprüfung ist erforderlich, um die Wiederherstellungsbereitschaft zu bestätigen.

F: Was macht ein erfolgreiches Ergebnis einer Tabletop-Übung aus?

A: Eine gründliche Übung führt zu klaren Ergebnissen, festgelegten Verantwortlichen und definierten Zeitplänen für die Behebung der Mängel. Fehlen diese Elemente, hat die Übung das Team wahrscheinlich nicht ausreichend gefordert.

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

Every organization that has ever failed a recovery – and there are more than anyone publicly acknowledges – had one thing in common: They believed they could recover before they tried.

The belief came from somewhere. A completed tabletop exercise. A backup system that showed green. An annual disaster recovery test that passed. All of it documented. All of it, at some point, accurate. None of it current when the incident actually hit.

This is the confidence gap. And it is the gap that continuous recovery validation is designed to close.

What ‘Testing’ Actually Means in Most Organizations

Fragt man die meisten Sicherheits- oder IT-Verantwortlichen, wie oft sie ihre Wiederherstellungsfähigkeit testen, lautet die Antwort in der Regel „einmal jährlich“, manchmal „zweimal jährlich“. Der Test umfasst die Wiederherstellung eines Teils der Systeme aus dem Backup in eine Testumgebung, die Überprüfung, ob diese ordnungsgemäß hochfahren, und die Erstellung eines Berichts. Manchmal wird parallel dazu eine Tabletop-Übung durchgeführt. Was diese Art von Tests nicht leisten: zu überprüfen, ob die Backup-Daten frei von Malware sind. Zu bestätigen, dass die Recovery-Reihenfolge bei voneinander abhängigen Diensten funktioniert. Die Recovery von Identitäten wird nicht getestet, obwohl dies unerlässlich ist, wenn kompromittierte Anmeldedaten den Angriff erst ermöglicht haben. Es wird nicht überprüft, ob das Team, das die Recovery tatsächlich durchführen würde, die aktuellen Runbooks kennt. Und es werden keine aussagekräftigen Nachweise erbracht, die eine Aufsichtsbehörde, einen Wirtschaftsprüfer oder den Vorstand davon überzeugen könnten, dass die Recovery-Fähigkeit real und aktuell ist. Kurz gesagt: Es dient der Validierung eines bestimmten Zeitpunkts. Resilience Operations (ResOps) erfordern eine kontinuierliche Validierung.

Das Modell der kontinuierlichen Validierung

Continuous recovery validation is not a single test run more frequently. It is a set of integrated practices that produce ongoing, evidence-based proof of recoverability across critical services.

Automated backup integrity scanning. Every backup, continuously evaluated for anomalies, encryption patterns, and malware signatures. Not at restore time – before restore time. The goal is to know whether your recovery points are clean before you need them, not during an incident.

Scheduled Cleanroom Recovery drills. Bi-annual at minimum, restoring from immutable backup points into an isolated Cleanroom Recovery environment – not production, not a production-adjacent test environment, but a genuinely isolated space where forensic analysis can happen without risk of reinfection. These drills produce documented evidence of recoverability against defined impact tolerances.

Identity recovery validation. With der Missbrauch von Anmeldedaten der häufigste Angriffsvektor, Active Directory and Entra ID recovery must be tested alongside data recovery. Organizations that restore systems without restoring a verified-clean identity layer may find attackers re-enter through the same door.

Service Resilience Indicator (SRI) dashboards. SRIs – continuous signals drawn from backup telemetry, dependency mapping, and test results – that give CISOs, CIOs, and boards a live view of recoverability posture. Not a point-in-time report. An ongoing operational signal.

Each of these practices feeds what Deloitte and Commvault call the resilience backlog: a continuously updated, prioritized list of gaps identified through testing and tracked to resolution. It is the mechanism by which validation drives improvement rather than just producing reports.

Was bedeutet die mittlere Zeit bis zur Wiederherstellung nach einem Ausfall?

Traditional recovery metrics – recovery time objective (RTO) and recovery point objective (RPO) – measure speed and data recency. They say nothing about whether the data being restored can be trusted. Mean Time to Clean Recovery (MTCR) fills that gap: It measures the time required to restore data that is verifiably clean, not just technically available.

MTCR matters because in a ransomware incident, the adversary’s goal is often to corrupt recovery options, not just encrypt production systems. An organization that restores quickly but restores from a compromised backup has not recovered. It has re-infected itself.

Building MTCR into your resilience measurement framework, alongside RTO and RPO, changes what you optimize for and what you report to the board. Speed plus recency plus integrity: that is the complete picture of recovery readiness.

Nachweisbare Resilienz

The organizations that navigate cyber disruptions with the least damage share one characteristic: They treat recovery capability as something to be continuously demonstrated, not periodically asserted. They know their MTCR. Their SRIs are current. Their cleanroom recovery has been tested in the last 90 days.

That posture is not the result of better technology alone. It is the result of an operating discipline – ResOps – that makes resilience continuous, measurable, and governable. Commvault’s platform provides the technical foundation: clean recovery, automated validation, and the unified visibility across data, identity, and services that ResOps requires at scale.

For the organizational side of that equation – how to define impact tolerances, align executive leadership, and build the governance structure that sustains the discipline – see the Deloitte companion blog, „The Resilience Conversation Your Board Isn’t Having Yet. Das vollständige ResOps-Framework, einschließlich der sechs ResOps-Bereiche und des Bewertungsmodells, das die technische Wiederherstellbarkeit mit der Rechenschaftspflicht auf Vorstandsebene verknüpft, finden Sie im gemeinsamen Whitepaper:„From Minimum Viability to Operational Resilience: ResOps in Practice.Bill O’Connell ist Chief Security Officer bei Commvault.

Key Takeaways:

• Cyberattacks increasingly target both production and backup environments, making clean, verifiable recovery essential.
• Integrated anomaly and threat detection strengthen cyber resilience by identifying compromised data, validating trusted recovery points, and accelerating restoration.
• When embedded into data-protection workflows, anomaly and threat detection capabilities can help provide the evidence needed to recover quickly, safely, and confidently.

Why Cyber Resilience Hinges on Integrated Anomaly and Threat Detection

Anomaly detection identifies unusual behavior in backup data that may indicate compromise. Threat detection identifies known malicious activity using signatures, heuristic analysis, and scanning techniques. Together, they help validate recovery points and enable clean data recovery.

For years, security leaders focused on preventing breaches. In today’s era of persistent attacks and AI-driven threats, organizations increasingly assume compromise and design systems that can withstand disruption and recover safely when it occurs.

Modern adversaries don’t always hide their presence – they reveal it when it serves their objective. Attackers try to infiltrate environments quietly, observe systems over time, and position themselves inside critical infrastructure. The moment an attack becomes visible is rarely the moment it begins; it is the moment the attacker chooses to act.

By then, compromised data may already be woven into backup copies. Integrated anomaly and threat detection can help organizations identify compromised backup data, validate clean recovery points, and assist recovery after a cyberattack.

For security and IT teams, the challenge is no longer simply detecting an attack but predicting and managing an attacker’s possible impact. Understanding what was affected, what remains trustworthy, and how the organization can recover safely without escalating business disruption is the solution.

This is why cyber resilience benefits tremendously from integrated anomaly and threat detection. When detection capabilities are embedded into data protection and recovery workflows, they help provide the shared intelligence that teams need to identify compromised data, validate trusted recovery points, and guide response decisions with evidence rather than guesswork.

This approach aligns with the emerging ResOps™ operating model, where security, IT, and recovery teams work from shared visibility and validated recovery paths to respond to incidents together.

The New Reality: Recovery Requires Proof, Not Assumptions

Traditional threat detection tools focus on spotting threats along the perimeter. But once attackers are inside, visibility can become fragmented and determining which systems and data have been affected becomes a challenge.

Further, attackers increasingly target backup environments specifically to undermine recovery. And the moment organizations cannot confidently prove that backups remain untouched, suspicion becomes unavoidable. The result is uncertainty. Restore quickly and risk reinfection? Or delay recovery while investigating which copies remain trustworthy? IT teams are forced to guess which data is safe while downtime accumulates.

By building intelligence directly into data protection workflows, anomaly and threat detection helps transform recovery from a reactive guess into a disciplined, evidence-driven process. These capabilities can help organizations pinpoint tampered copies, validate data cleanliness, and assemble the most recent uncompromised recovery points – helping you accelerate cyber recovery and reduce operational impact.

Anomaly Detection: Your Early Signal of the Unknown

Anomaly detection acts as a sentinel, guarding your protected data integrity. It establishes a baseline of normal behavior – file sizes, growth patterns, deduplication changes, access attempts – and alerts teams when something deviates from that norm. These deviations can surface signs of silent tampering long before malware signatures do. In an era of novel and polymorphic threats, anomaly detection helps offer what static tools can’t: visibility into the unexpected.

Threat Detection: Targeted Defense Against Known Malicious Activity

While anomalies reveal what’s unusual, threat detection exposes what is malicious. By scanning protected data directly for ransomware, malware signatures, encryption patterns, and custom indicators of compromise (IoCs), threat detection helps validate that the data you protect is not already compromised.

Why a Combined Approach Matters

Neither anomaly nor threat detection alone provides the full picture. Together, they deliver a defense-in-depth strategy: Anomaly detection can highlight suspicious signals while threat detection can probe deeper to verify malicious intent. This combination helps organizations distinguish harmless anomalies from true compromises and maintain reliable, validated data for rapid recovery.

Meeting Today’s Challenges with Commvault® Cloud

Attackers increasingly target backup environments, and hidden malware within backup data can increase the risk of reinfection during recovery. Organizations need data-driven validation for their clean recovery with certainty.Cloud addresses this by combining data protection workflows with anomaly detection, threat intelligence, AI-enabled analytics, and isolated clean instances. With anomaly and threat insights applied before, during, and after backup operations, Commvault can help empower organizations to recover faster, cleaner, and confidently.

Read the full white paper, “Can You Prove You’re Recoverable Right Now?”.

FAQs

Q: What is anomaly detection in data protection?

A: Anomaly detection identifies unusual behaviors – such as unexpected backup size changes or abnormal file activity – that may signal tampering, ransomware, or emerging threats within protected data.

Q: Why do CISOs need threat detection in their backup workflows?

A: Backup environments are now prime attacker targets. Threat detection helps prevent organizations from storing or restoring compromised data, which helps reduce reinfection risk and improve chances for clean recovery.

Q: How does Commvault help enable clean data recovery?

A: Commvault uses AI-assisted threat scanning, encryption detection, custom IoC matching, and cyber deception to help validate backup integrity and assemble the most recent uncompromised data for rapid recovery.

Q: Why combine anomaly and threat detection?

A: Anomalies identify the unknown; threat detection validates the known. Together, they provide comprehensive visibility into suspicious activity, helping enable faster investigation and more confident data recovery.

Pauline Listis Product Marketing Manager at Commvault