Die wichtigsten Erkenntnisse

• Replace subjective claims about “ease of use” with a measurable data protection gearing ratio: protected capacity divided by the number of full-time administrators.
• Die Messung der geschützten Kapazität pro Vollzeitäquivalent (FTE) liefert ein aussagekräftigeres Bild der betrieblichen Effizienz als herkömmliche Kennzahlen wie beispielsweise die Anzahl der Backup-Jobs pro Administrator.
• Die Datenschutz-Kennzahl sollte vor einer Plattformmigration als Ausgangsbasis herangezogen und anschließend erneut gemessen werden, um betriebliche Verbesserungen zu validieren.
• Faktoren wie Multi-Cloud-Umgebungen, Anforderungen an die Cyber-Recovery und Compliance-Verpflichtungen können die Kennzahl beeinflussen, daher sollte sie im Kontext der jeweiligen Umgebung bewertet werden.
• Unternehmen sollten von Anbietern verlangen, sich zu messbaren betrieblichen Ergebnissen zu verpflichten, anstatt sich auf qualitative Behauptungen über die Einfachheit zu verlassen.

Every vendor evaluation I have sat in eventually reaches the same dead end. One side says the platform is simple to run. The other side says their platform is simpler.

Nobody can prove either claim, so the conversation drifts to the demo, the reference call, the gut feeling in the room. That is not how you should be making a decision that determines how your team will spend the next five years.

I have run production data protection environments. I have watched teams get buried under fragmented tooling that promised automation and delivered tickets instead.

“Reduced complexity” is not a feeling you should have to take on faith. It is something you should be able to calculate.

Die Kennzahl, die der Branche bisher gefehlt hat

We have started using a simple ratio internally and with customers: total protected capacity divided by the number of full-time staff required to run it. We call it the data protection gearing ratio.

Protected Capacity (PB) / FTEs = Data Protection Gearing Ratio

That’s it. No survey questions about satisfaction. No adjectives. A number, calculated from data you already have.

Here is why it matters more than the metrics it replaces. Calculating the number of backup jobs per person made sense a decade ago, when a job represented a discrete unit of manual effort. It does not reflect how modern platforms operate today, where automation absorbs the routine work and a single administrator can be accountable for petabytes, not job counts.

Measuring jobs per person in an automated environment tells you nothing about whether the automation is actually working.

So sieht es in der Praxis aus

One clarification before the number, because it trips people up. Protected capacity means the full, uncompressed, undeduplicated size of the applications being protected, not the physical disk behind them.

That distinction matters because it is the whole point. Commvault’s own production environment protects 4.²,39 PB of application data on 9,.²6 PB of physical disk, an 81,91 % space savings from deduplication and compression.

The ratio is not just a measure of how many petabytes a person can watch over. It is a measure of how much architecture is doing the work before headcount ever enters the picture.

With that in mind: Commvault runs its own production backup environment on 4.²,39 PB of protected capacity with two FTEs. That is a gearing ratio of .²1..²0 PB per FTE. Industry benchmarks for modern platforms typically land between 5 and .²5 PB per FTE, depending on environment complexity, so that number sits at the high end of what is achievable today.

Data Protection Gearing Ratio = 4.²,39 PB / .² FTEs = .²1..²0 PB per FTE

I want to be direct about what this number does not do. It does not account for a multi-cloud footprint, cyber recovery requirements, or a compliance-heavy application mix, all of which will pull the ratio down for reasons that have nothing to do with how good the platform is.

A ratio in isolation is not a verdict. A ratio measured before and after a migration is.

That is the actual use case. Baseline your current environment on your current tools. Set a target ratio based on your growth projections and your team’s capacity. Then hold your vendor to it after the implementation is done, not just during the sales cycle.

Die Auswirkungen auf Vorstandsebene

If you are the one signing off on a platform migration, you are not just being asked to trust that a new platform is easier to run. You are being asked to fund a specific operational outcome. A data protection gearing ratio target gives you a way to write that outcome into the business case and check it 1.² months later.

This is the same discipline we apply to mean time to clean recovery (MTCR). Recovery capability is not something you claim, it is something you measure and re-measure until the number tells you the truth. Operational efficiency deserves the same standard.

Die Herausforderung

Ask your current vendor for the gearing ratio of your own environment today. If they cannot produce it, that tells you something about how well they understand what “simple to manage” means for your team.

And if you are evaluating a new platform, do not accept “easier to use” as an answer. Ask what ratio they will commit to, and ask again after year one.

FAQs

Q: What is the data protection gearing ratio?

A: The data protection gearing ratio measures the amount of protected data capacity managed by each full-time administrator. It provides an objective way to evaluate operational efficiency rather than relying on subjective impressions of platform usability.

Q: Why is this metric more useful than backup jobs per administrator?

A: Modern data protection platforms automate much of the routine work that previously required manual effort. As a result, counting backup jobs no longer reflects the true workload or efficiency of an operations team.

Q: What does “protected capacity” mean in this calculation?

A: Protected capacity refers to the full, uncompressed, and undeduplicated size of the application data being protected. This measurement reflects the actual workload managed by the platform rather than the physical storage consumed after optimization.

Q: Does a higher gearing ratio always indicate a better platform?

A: Not necessarily. Environmental complexity, including multi-cloud deployments, cyber resilience requirements, and regulatory obligations, can reduce the ratio even when the platform performs well. The metric is most valuable when comparing the same environment before and after a migration.

Q: How should organizations use the data protection gearing ratio during vendor evaluations?

A: Organizations should establish a baseline using their current environment, define a target ratio aligned with future growth, and ask vendors to commit to achieving measurable improvements after implementation. This approach shifts the conversation from marketing claims to verifiable business outcomes.

Q: What is the broader business value of this metric?

A: The data protection gearing ratio enables executives to quantify expected operational efficiency gains and include them in the business case for a platform investment. It also provides a benchmark that can be reviewed after deployment to confirm the promised results were achieved.

Rajiv Kottomtharayilist Chief Products Officer bei Commvault.

In thefirst episode of our STRIVE series on digital sovereignty, Commvault’s Alex Zinin and Osmium Data Group’s Max Mortillaro challenged one of the biggest misconceptions in the industry: Digital sovereignty isn’t a feature you buy – it’s a business problem you have to understand before you can solve.

This conversation picks up where that one left off. This time, I sat down with Thomas Maurer, EMEA Global Black Belt for Sovereign Cloud at Microsoft, to explore what happens after an organization decides sovereignty matters. How do executive teams move from broad concerns about regulation, jurisdiction, or geopolitical uncertainty into practical architectural decisions?

The answer, it turns out, is rarely as straightforward as choosing a cloud provider or selecting the right deployment model. It’s about asking better questions before making technical decisions.

Watch the full episode.

Die wichtigsten Erkenntnisse

• Every organization defines digital sovereignty differently – and that’s exactly where the conversation should begin.
• Sovereignty isn’t solved by technology alone. Legal, operational, architectural, and business considerations all shape the outcome.
• Cloud and on-premises aren’t competing strategies. For many organizations, the future is a carefully designed combination of both.
• Risk management – not fear – should drive sovereignty decisions.
• Good architecture starts with understanding business requirements, not choosing infrastructure.

Sovereignty Means Different Things to Different Organizations

One of the first observations Thomas made was also one of the most important.

There is no universal definition for digital sovereignty. For one organization, it may simply mean meeting regulatory requirements or keeping data within a specific geography. For another, it may involve operational independence, business continuity, or preparing for geopolitical disruption. That difference matters because it changes the conversation entirely.

Too often, organizations assume there’s a standard sovereignty blueprint waiting to be implemented. In reality, the first challenge isn’t selecting technology – it’s understanding what problem the organization is actually trying to solve.

Only then does architecture begin to make sense.

Technology Should Follow Strategy

One theme that kept surfacing throughout our discussion was the temptation to jump straight into technical design.

It’s understandable. Architects naturally think about infrastructure, workloads, connectivity, and deployment models. But Thomas emphasized that the most successful projects begin somewhere else.

They begin by listening.

What concerns are driving the initiative? Is the objective regulatory compliance? Business continuity? Data residency? Operational control? Protection against geopolitical disruption?

Different answers lead to different architectures.

That may sound obvious, but it’s surprising how often organizations begin evaluating solutions before they’ve aligned on the business outcome they’re trying to achieve.

Sneak Peek: Start With Risk, Not Assumptions

One of the most practical moments in our conversation comes when Thomas and I discuss why sovereignty initiatives should begin with a risk assessment – not an architectural diagram.

Every organization has a different risk appetite. A Formula 1 team, a government agency, and a global manufacturer won’t make the same decisions, nor should they. The key is understanding which risks matter most to your business, what trade-offs you’re willing to make, and then designing an architecture that supports those decisions.

As Thomas points out, there is no perfect solution – only informed trade-offs. The earlier organizations adopt that mindset, the stronger their sovereignty strategy will be.

‘Cloud or On-Premises?’ Is the Wrong Question to Ask

One of the more interesting parts of the conversation challenged another common assumption – that organizations must choose between public cloud and private infrastructure.

Thomas described a very different reality.

Many organizations aren’t replacing one with the other. They’re designing environments where workloads can move between them based on business need, regulatory requirements, or resilience considerations.

That flexibility changes how we should think about architecture. Instead of asking whether cloud or on-premises is better, the more useful question becomes:

“Where does this workload belong today – and could that answer change tomorrow?”

When sovereignty becomes part of the design process, workload mobility becomes just as important as workload placement.

Architecture Is Only Part of the Equation

Another takeaway I appreciate is Thomas’s reminder that architecture alone doesn’t solve sovereignty.

• Contracts matter.
• Legal frameworks matter.
• Operational processes matter.
• The people responsible for running the environment matter.

None of those disciplines can operate in isolation. Sovereignty requires legal, security, compliance, and infrastructure teams to work together from the beginning – not hand projects off to one another after decisions have already been made.

That’s a familiar pattern for anyone working in cyber resilience. The strongest outcomes rarely come from individual teams. They come from coordinated ones.

Risk Should Drive Every Decision

Toward the end of our discussion, the conversation naturally shifted toward risk. For me, this is where sovereignty starts to feel much more familiar. Every resilience project begins by asking what the organization is trying to protect, what threats matter most, and how much risk it’s willing to accept.

Digital sovereignty is no different.

Rather than searching for a perfect solution, organizations need to identify the specific sovereignty scenarios they’re concerned about and then determine which architectural, operational, or contractual controls best address those risks.

That shift – from feature comparison to risk management – is what ultimately leads to better decisions.

Why This Conversation Matters

Digital sovereignty continues to evolve rapidly. New regulations will emerge. Technology will change. Geopolitical realities will continue to shift.

That means sovereignty isn’t something organizations solve once. It’s something they regularly evaluate as business priorities and external risks evolve.

The organizations that succeed won’t necessarily have the most restrictive architectures. They’ll have the clearest understanding of their business objectives, the discipline to assess risk thoughtfully, and the flexibility to adapt as those risks change.

Ultimately, digital sovereignty isn’t something organizations can buy off a shelf. It’s an exercise in understanding risk, managing dependencies, and making informed trade-offs long before those decisions are tested.

Die ganze Folge ansehen

In this STRIVE episode, Thomas and I discuss:

• Why sovereignty means different things to different organizations.
• How executives should approach sovereignty strategy.
• Public cloud versus private cloud – and why it’s often not an either/or decision.
• Why risk management should guide architectural choices.
• The role of resilience in modern sovereignty planning.

Jetzt anschauen.

FAQs

Q: Does digital sovereignty mean keeping everything on-premises?

A: No. Many organizations adopt hybrid approaches that balance cloud capabilities with specific sovereignty requirements.

Q: Where should sovereignty projects begin?

A: Start by defining the business problem and understanding the risks you’re trying to mitigate before evaluating technology.

Q: Is sovereignty purely a technical issue?

A: No. It requires collaboration between legal, compliance, security, operations, and architecture teams.

Q: How does sovereignty relate to resilience?

A: Both disciplines focus on maintaining operational continuity by reducing exposure to risks that could disrupt the business.

Q: What’s one big mistake organizations make in regard to digital sovereignty?

A: Jumping into architectural decisions before agreeing on what sovereignty means for their organization.

Q: What should executives ask first in terms of planning for digital sovereignty?

A: “What problem are we trying to solve?” Everything else follows from that answer.

Darren Thomsonis Vice President and Chief Technology Officer, EMEA, at Commvault.

For years, cyber resilience has been defined by technology – security controls, sophisticated detection capabilities, and increasingly robust backup strategies designed to prevent attacks or recover more quickly. Those investments remain essential, but they are no longer enough. 

AI has fundamentally changed the nature of cyberattacks, which now move at a speed that challenges even mature organizations. As the window between compromise and business disruption continues to shrink, resilience is becoming less about preventing every attack and more about keeping the enterprise running when prevention inevitably falls short. 

That shift is at the heart of IDC’s new report, Resilience Operations: The Discipline that Makes Readiness Provable. Based on a survey of more than 500 North American organizations, the report argues that resilience is evolving into a cross-functional operating discipline that connects business priorities with cybersecurity, ITOps, and disaster recovery. More importantly, it reveals several gaps that suggest many organizations are still preparing for a threat landscape that no longer exists. 

Here are the insights that stood out. 

Recovery should begin with business outcomes – not technical ones.

Historically, recovery planning has focused on restoring infrastructure as quickly as possible, with success judged by recovery time objectives, backup completion rates, and application availability. While those measures remain valuable, they don’t necessarily answer the question executives care about most: When can we get the business back online? 

IDC argues that resilience should be anchored to business outcomes rather than technical milestones – restoring the capabilities that allow the organization to serve customers, generate revenue, and meet its obligations. That may sound like semantics, but it changes how recovery priorities are established. Technology becomes the means to an end rather than the end itself. 

Most organizations still haven’t defined what matters most.

Nearly 6 in 10 organizations have not fully defined their minimum viable business (MVB)gar nicht mehr gibt. Hier sind die wichtigsten Erkenntnisse. Die Wiederherstellung sollte bei den geschäftlichen Zielen ansetzen – nicht bei den technischen.– the smallest set of functions, systems, processes, and data required to continue operating after a disruption. 

Without a shared understanding of what the business truly depends on, every movement during recovery becomes reactive. By defining your MVB before a crisis, you’ll enable faster decisions, better coordination during recovery, and ultimately a more resilient organization. 

Automation is becoming the dividing line between resilience and recovery debt.

While attackers increasingly automate reconnaissance, exploitation, and lateral movement, many organizations still rely on manual recovery processes. 

That imbalance is becoming increasingly difficult to ignore. AI is compressing attack timelines, but recovery timelines have not kept pace. Organizations that fail to automate these recovery tasks may find themselves spending days assembling and executing plans while the damage has already been done. 

Automated recovery orchestration, clean recovery point identification, and coordinated validation are becoming foundational capabilities for recovering at the speed modern attacks demand. 

Technology isn’t the biggest resilience challenge – organizational alignment is.

Security teams focus on containment, infrastructure teams focus on restoration, business leaders focus on customer impact, and compliance teams focus on regulatory obligations. None of these priorities are inherently wrong, but when they evolve independently, organizations enter a crisis without a shared operating model. 

Enter ResOps. Rather than positioning resilience as an IT responsibility, the report frames it as a discipline that deliberately brings together business, security, infrastructure, and recovery planning. The message is clear: Resilience depends less on individual tools than on creating shared priorities before an incident forces you to make difficult decisions. 

Testing remains one of the strongest indicators of resilience.

IDC found that relatively few organizations conduct frequent tabletop exercises or cyber-range simulations, despite decades of evidence showing that rehearsal consistently improves performance during real incidents. 

Exercises reveal hidden dependencies, expose communication gaps, and allow teams to make decisions without the real consequences. Organizations that repeatedly validate their recovery processes develop a level of confidence beyond planning alone. 

Tomorrow’s resilience challenges are already taking shape.

Ransomware still dominates headlines, but the next resilience challenges have already emerged – from agentic AI and machine identities to post-quantum cryptography. 

These threats remind us that resilience planning can’t focus exclusively on today’s infrastructure. Recovery increasingly involves cloud services, SaaS applications, AI models, machine identities, third-party providers, and distributed digital ecosystems that didn’t exist a decade ago. 

Resilience is becoming measurable.

IDC’s ResOps Maturity Model is invaluable for assessing your organization’s current posture. Rather than treating resilience as something organizations either possess or lack, the framework describes a progression from reactive, siloed operations to mature, adaptive resilience built on governance, automation, and continuous improvement. 

To me, that progression acknowledges an important reality: Resilience is never finished. It’s not about purchasing a platform or completing a project. Organizations become resilient by continually improving how technology, people, and business processes work together under pressure. 

Viewed through that lens, resilience becomes less like insurance and more like operational excellence – a capability that can be assessed, strengthened, and demonstrated over time. 

We’re undergoing a broader shift in how organizations think about resilience.

Resilience conversations are evolving from protecting infrastructure to protecting the business itself. That means recovery planning starts with customers instead of servers, governance becomes as important as technology, and confidence comes from proving capabilities rather than documenting intentions. 

ResOps isn’t really a new framework; rather, it’s a broader recognition that cyber resilience has become an operational discipline. As attacks become faster and more complex, resilience will be measured not by the absence of incidents, but by an organization’s ability to continue serving customers, supporting employees, and maintaining trust despite disruption. 

That’s ultimately what ResOps is designed to prove. 

Rajiv Kottomtharayilist Chief Products Officer bei Commvault. 

Die wichtigsten Erkenntnisse

• Trust in the age of AI isn’t disappearing – it’s evolving.
• Organizations need to verify AI continuously rather than trust it by default.
• AI adoption should empower employees, not push them toward shadow AI.
• Zero trust isn’t about distrusting people. It’s about continuously validating identities, devices, and actions.
• Responsible AI adoption requires technology, governance, and people working together.

When we launched Ready. Or Not., we wanted to create a series that made some of today’s biggest AI conversations easier to understand. By pairing comedian Nathan Macintosh with industry experts, we’re exploring everything from agentic AI and cyber resilience to data management – and adding a little humor along the way.

If you caught our first episode on the opportunities and risks of agentic AI, I think you’ll enjoy this one as well. This time, we’re tackling a topic that’s at the center of every AI conversation: trust.

Nathan sits down with Diana Kelley, Chief Information Security Officer at Protect AI, for a conversation about what it means to trust technology when AI can generate convincing fake content, make decisions, and even imitate people. From deepfakes and hallucinations to zero trust and shadow AI, they explore how organizations can embrace AI without losing confidence in their people and systems.

Watch the full episode on Readiverse.I walked away from this episode feeling more optimistic than I expected. Not because AI is suddenly more trustworthy, but because Diana shows us that trust grows when organizations put the right policies, guardrails, and technology in place. Here are some themes from the conversation that put AI in a new perspective.

Trust and Technology Can Co-Exist

Diana believes trust is possible in the AI era, but it’s going to look different. We’ve always built trust through relationships with people. Now, we’re learning how to extend that trust to systems.

That doesn’t mean trusting technology blindly. It means understanding how AI works, recognizing its limitations, and putting the right safeguards in place so people and technology can work together with confidence.

“Trust has to evolve for the new world.”

– Diana Kelley

What resonated with me was the idea that trust and technology don’t have to be at odds with one another. With the right approach, they can strengthen each other.

We’re Getting Smarter About AI

Deepfakes have become one of the most talked about AI risks, and it’s easy to understand why. AI can now generate convincing voices, images, and videos that make us question what’s real. But Diana pointed out that while AI is getting more sophisticated, people are getting smarter. We’re more likely to question an unexpected phone call, take a closer look at a social media post, or pause at something that doesn’t feel quite right.

Organizations are becoming savvier, too. As AI gets better at impersonation, businesses are investing in new ways to continuously verify identities and validate information. My takeaway is this: Technology will continue to improve, but so will our ability to recognize it and respond responsibly.

“Is today a good day to start a deepfake?”

– Nathan Macintosh

Responsible AI is Good for Business

Diana shared an example that will probably sound familiar to many organizations. An employee she calls “Karen in Finance” starts using AI because it helps her complete a task in minutes instead of hours. Karen isn’t trying to work around company policy – she’s trying to be more productive.

Employees use AI because they see real value in it, and that’s an opportunity for organizations. When employees have access to approved AI tools, supported by clear policies and practical guidance, they can work more efficiently while helping protect company data and systems.

Sneak Peek: Smarter AI Adoption

The goal isn’t to stop employees from using AI. It’s to make sure they’re using it the right way. Diana explains how organizations can encourage AI adoption without creating unnecessary risk.

Zero Trust Matters More Than Ever

“When you understand how things work, then you can start to understand how to manage them.”

– Diana Kelley

Zero trust is one of those concepts that’s much easier to understand with an analogy. Diana has a great one. She describes it as moving through a building. Just because you’ve been allowed through the front door doesn’t mean every other door automatically opens for you. Each time you access a new room, there’s another quick check to confirm you’re supposed to be there.

That’s essentially how zero trust works. Instead of assuming a person or device is trustworthy after a single login, organizations continuously verify identities, devices, and actions as technology becomes more connected. Most of those checks happen quietly behind the scenes.

One of the things I appreciated about Diana’s explanation is that zero trust doesn’t feel like another security buzzword. It feels like a practical way to think about trust in a world where AI and digital identities are becoming part of everyday business.

Trust Is About People

At the end of the day, technology doesn’t create trust – people do. People define the policies, processes, and ethical boundaries that guide how AI is used, while technology helps verify that those guardrails are working as intended. It’s that partnership between people and technology that makes responsible AI possible.

Trust extends beyond our own organizations. Businesses need confidence in the partners they work with, the systems they connect to, and the technologies they adopt. That’s why transparency, shared standards, and continuous verification are becoming just as important as innovation itself. The more AI becomes part of everyday business, the more trust becomes everyone’s responsibility.

Ausblick

AI will continue to evolve, and so will the way we interact with it. The organizations that succeed won’t be the ones that trust AI blindly or avoid it altogether. They’ll be the ones that build strong policies, adopt the right technologies, and continuously verify the systems they rely on.

Trust isn’t something we lose as technology advances. It’s something we intentionally build and evolve. That’s exactly the kind of conversation we hope to continue with every episode of Ready. Or Not.

Watch the full episode on Readiverse.

FAQs

Q: What is digital trust?

A: Digital trust is the confidence that people, systems, and organizations are who they claim to be and are acting in expected, secure ways. It combines technology, governance, and verification to help organizations interact safely.

Q: What are deepfakes?

A: Deepfakes are AI-generated images, videos, or audio recordings designed to closely imitate real people. While they have legitimate uses, they can also be used to impersonate individuals or commit fraud.

Q: What is zero trust?

A: Zero trust is a security model based on continuous verification rather than automatic trust. Instead of assuming a user or device is trustworthy after one login, organizations continuously validate identities and actions.

Q: What is shadow AI?

A: Shadow AI refers to employees using AI tools that haven’t been approved or governed by their organization. While often well-intentioned, it can introduce security, privacy, and compliance risks.

Q: Why shouldn’t organizations simply block AI tools?

A: Employees typically adopt AI because it helps them work more efficiently. Rather than banning AI outright, organizations should provide approved tools, establish clear policies, and educate employees on responsible use.

Q: What’s the biggest takeaway from this episode?

A: Trust isn’t disappearing because of AI – it’s evolving. Organizations that combine people, policies, and technology with continuous verification will be better positioned to adopt AI confidently and responsibly.

Katherine Demacopoulos istist Senior Director für globale Inhaltsstrategie und Programme bei Commvault.

Our Chief Products Officer, Rajiv Kottomtharayil, recently wrote about a big shift that is taking place across industries. Frontier AI models are compressing the time between vulnerability discovery and exploitation.  

This shift is prompting organizations everywhere to re-examine their vulnerability management processes. We’re doing the same at Commvault. That’s why, starting August 11, we’re changing the rhythm of how we disclose vulnerabilities.  gar nicht mehr gibt. Hier sind die wichtigsten Erkenntnisse.What’s ChangingDie Wiederherstellung sollte bei den geschäftlichen Zielen ansetzen – nicht bei den technischen.We are raising the bar for security, transparency, and customer trust. On August 11, and on the second Tuesday of each month after that, we’re introducing Patch Tuesdays: a scheduled monthly release where we share security advisories and vulnerability patches.  

Patch Tuesdays are a hallmark of leading technology companies, because they provide customers with a predictable security rhythm.  This matters even more as the pace of vulnerability discovery accelerates. Of course, if there is an urgent vulnerability that must be reported off cycle, we will not hesitate to follow our well-established processes.  

gar nicht mehr gibt. Hier sind die wichtigsten Erkenntnisse.Where You Can Find Up-to-Date Resources Die Wiederherstellung sollte bei den geschäftlichen Zielen ansetzen – nicht bei den technischen. 

On the second Tuesday of each month, you’ll find new information pertaining to CVEs on our „Vertrauen in CVE-Offenlegungen schaffen. You also can find the official publications at MITRE’s CVE site. 

On the Commvault Security Center, you’ll find our vulnerability management program and other security-by-design thought leadership.   

For compliance certifications, audit reports, and documentation on how Commvault protects customer data, visit the Commvault Trust Center. You can subscribe to updates from the Trust Center at the link in the upper righthand corner of the page. 

Bill O’Connell is Chief  Security Officer at Commvault. 

For decades, technology leaders have been trying to eliminate silos. Entire modernization programs have been built around connecting applications, consolidating platforms, and giving organizations a more complete view of their data.

Those efforts have delivered enormous value, but they also have shaped the way we think about resilience. When something goes wrong, we instinctively look for technical fragmentation. However, we’ve found the greater challenge lies elsewhere.

The most significant silos affecting cyber resilience today aren’t found in databases or applications but in organizational structures. They exist between security and infrastructure teams, between IT and the business, and between the people responsible for responding to an attack and those responsible for keeping the organization operating.

IDC’s latest research on ResOps, Resilience Operations: The Discipline that Makes Readiness Provable, suggests these organizational boundaries have become one of the defining obstacles to effective recovery. That’s a timely observation because cyberattacks have evolved in ways that can make those boundaries increasingly difficult to maintain.

Modern Attacks Don’t Follow Your Org Chart

A modern cyberattack rarely affects a single technology domain. A ransomware incident might begin with compromised identities, spread through cloud infrastructure, encrypt critical workloads, disrupt customer-facing applications, impact third-party services, and trigger regulatory Berichting requirements – all within a matter of hours. Every stage involves different teams, different tools, and different priorities.

Yet many organizations still prepare for recovery as though these responsibilities can be managed independently.

Security teams naturally focus on containing threats and preserving evidence. Infrastructure teams prioritize restoring systems and minimizing downtime. Business leaders concentrate on customers, revenue, and operational continuity. Communications teams think about reputation, while legal and compliance teams focus on regulatory obligations.

Each perspective is entirely reasonable. The problem arises when those priorities have never been reconciled before an incident occurs.

In the middle of a crisis, recovery requires decision-making under pressure. Which applications should return first? Which data can safely be restored? How much risk is acceptable before customer services resume? Who has the authority to make those decisions?

Without alignment, organizations often discover that the greatest delays aren’t caused by technology but by uncertainty – the kind that could be mitigated by better preparation.

Resilience Begins with a Shared Definition of What Matters

The Bericht places emphasis on establishing your minimum viable business (MVB). At first glance, it appears to be another recovery planning exercise, but its real value lies in the conversations it forces organizations to have.

Defining an MVB requires business leaders, security teams, infrastructure specialists, and application owners to agree on a deceptively simple question: What absolutely must continue operating if everything else stops?

That discussion changes the nature of resilience planning. Recovery priorities are no longer determined by whichever application owner argues most convincingly during an incident. Instead, they are established in advance, grounded in business outcomes, and supported by technical dependencies that everyone understands.

Perhaps more importantly, MVB creates a common language. Business leaders begin talking about critical capabilities rather than individual systems. Technology teams begin mapping infrastructure to customer outcomes rather than technical architectures. Security teams gain greater clarity about which assets deserve the highest levels of protection during recovery.

That shared understanding is precisely what many organizations have been missing.

Technology Can Automate Recovery – But it Can’t Create Alignment

The Bericht doesn’t argue that organizations need yet another platform. It argues they need a way of working that aligns people, processes, and technology around a single operational objective. This is where ResOps – a cross-functional discipline – proves its mettle.

Technology can help automate recovery, but it cannot resolve disagreements about business priorities. It cannot decide which customer services matter most. And it cannot replace the governance needed to coordinate multiple teams during a high-pressure event.

Those are leadership challenges, and they are best addressed by investing time in answering the difficult questions together, long before an attack forces your hand.

The Strongest Organizations Don’t Eliminate Silos – They Connect Them

Cyberattacks will continue evolving. AI will continue compressing attack timelines. New technologies will introduce new dependencies, and new threats will emerge alongside them. None of that changes the fundamental requirement for resilience.

Organizations don’t recover because individual teams perform brilliantly in isolation, but because those teams already know how to work together.

That may ultimately be the most important insight from IDC’s research. Resilience isn’t simply the product of better technology or more sophisticated security controls. It is the result of shared priorities, clear governance, and a tested operating model that brings the right people together before an incident occurs.

Vidya Shankaran is Field CTO at Commvault.

Die wichtigsten Erkenntnisse

• Ein CVE ist eine weltweit eindeutige Kennung für eine öffentlich bekannt gegebene Software-Sicherheitslücke, die es Anbietern, Forschern und Sicherheitsfachleuten ermöglicht, sich einheitlich auf dieselbe Sicherheitslücke zu beziehen.
• An organization’s approach to vulnerability disclosure – including coordinated fixes, researcher engagement, and accurate software inventory – is a strong indicator of overall security maturity.
• Commvault schützt seine Kunden mit einem CVE-Programm, das sich durch Transparenz, Regelmäßigkeit und Klarheit auszeichnet. Die Offenlegung von CVEs sagt viel über die Reife eines Sicherheits- und Entwicklungsprogramms aus.

Warum das wichtig ist

Many breaches that reach the boardroom trace back to vulnerability in software. The mechanism the entire industry uses to name and describe those vulnerabilities is the CVE, Common Vulnerabilities and Exposures.

How a vendor, or your own organization, handles CVEs is one of the clearest signals of security maturity.

A company that discloses and credits researchers fairly is usually a company that takes underlying engineering seriously. This blog explains how a CVE is built, who runs the system, and what separates an exemplary disclosure from a poor one.

Über die CVE hinaus: Warum die Philosophie der Offenlegung wichtig ist

Die Veröffentlichung einer CVE ist das Mindeste, was man tun muss. Die entscheidenden Faktoren sind: Transparenz hinsichtlich der Sicherheitslücke und des Patches, regelmäßige Scans und die Installation von Patches sowie eine klare Kommunikation. Commvault betrachtet die Offenlegung als eine technische und sicherheitsrelevante Disziplin und nicht als reine Compliance-Maßnahme: Wir legen einen regelmäßigen Rhythmus für Code-Reviews und Fehlerbehebungen fest, kommunizieren die Korrektur in verständlicher Sprache und schützen unsere Kunden. Diese Konsequenz sagt mehr über die Sicherheitsreife aus als jede einzelne Bewertung im Rahmen der CVE-Offenlegung.

Was ein CVE eigentlich ist

A CVE is not a patch, a score, or a piece of malware. It is a dictionary entry that gives one specific, publicly known vulnerability a permanent, unique name so that everyone can refer to it.

The identifier itself follows a simple, durable format: the letters CVE, the year the ID was assigned, and a sequence number, for example, CVE-2021-44228.

The scale of the program is enormous, and still growing:Im Jahr 2025 wurden 48.000 CVEs veröffentlicht, was etwa 132 pro Tag entspricht – ein Anstieg von mehr als 260 % seit 2020.

Die Struktur eines einzelnen Datensatzes

CVE-Veröffentlichungen müssen bestimmte einheitliche Elemente enthalten. Das Lesen einer solchen Veröffentlichung ist unkompliziert, sobald man weiß, wozu die einzelnen Teile dienen:

• Identifier, the unique CVE-YYYY-NNNNN
• Description, a concise explanation of the vulnerability: what it is and how a threat actor could exploit it.
• Affected products and versions, which software, hardware, or firmware (and which versions) are impacted, and which versions contain the fix.
• Criticality, the underlying category of criticality.
• References, links to the vendor advisory, the patch, and technical write-ups.

Die Nebendarsteller: CVSS, CWE, EPSS und KEV

Vier begleitende Systeme machen aus einem CVE ein Thema, dem ein Unternehmen Priorität einräumen kann. Da sie leicht zu verwechseln sind, lohnt es sich, die Unterscheidung im Auge zu behalten:

• CVSS (Common Vulnerability Scoring System) answers “How severe is it?” CVSS is the severity rating (1–10, 10 being the most severe) of the flaw, not a measurement of your specific exposure.
• EPSS (Exploit Prediction Scoring System) answers “How likely is this to be exploited soon?” EPSS produces a probability score, from zero to 100 percent, estimating the likelihood that a vulnerability will be exploited in the next 30 days.
• CWE (Common Weakness Enumeration) answers “What kind of mistake caused it?” The CWE classifies the underlying coding weakness.
• KEV (Known Exploited Vulnerabilities) answers “Is it being used against people right now?” The KEV catalog is a curated list of CVEs with confirmed real-world exploitation.

Ein hoher CVSS-Wert gibt Aufschluss darüber, wie schwerwiegend eine Schwachstelle sein könnte, ein hoher EPSS-Wert zeigt an, wie schnell sie voraussichtlich ausgenutzt wird, und eine Aufnahme in den KEV-Katalog bestätigt, dass bereits Ausnutzungsversuche stattfinden. Die besten Programme zur Schwachstellenbekämpfung berücksichtigen alle drei Faktoren.

FAQs

Q: What is a CVE, and why is it important?
A: A Common Vulnerability and Exposure (CVE) is a standardized identifier assigned to a publicly disclosed software vulnerability. It enables everyone – from vendors and researchers to regulators and customers – to refer to the same vulnerability without ambiguity.

Q: What information should a well-formed CVE record contain?
A: A complete CVE record requires a unique identifier, a description of the vulnerability, affected products and versions, the criticality type, and references to vendor advisories or patches. These elements enable organizations to understand their exposure and respond efficiently.

Q: How do CVSS, CWE, EPSS, and KEV differ from a CVE?
A: A CVE identifies a specific vulnerability, while CVSS measures its severity, EPSS estimates the likelihood of near-term exploitation, CWE classifies the underlying coding weakness, and KEV identifies vulnerabilities that are actively exploited in the real world. Together, these frameworks help provide the context needed to prioritize remediation.

Q: What does Commvault look for in its own disclosure practices?
A: Commvault holds its own disclosures to the same standard it expects of others: transparency, cadence and clarity. That is how Commvault protects its customers.

Q: What should business leaders evaluate when assessing vendors’ vulnerability management practices?
A: Leaders should look for coordinated disclosure timelines, comprehensive and accurate CVE records, clear remediation guidance, robust reporting programs, and the ability to quickly determine whether products are affected by newly disclosed vulnerabilities. These characteristics reflect a strong security culture and improve organizational resilience.

Werner Nel is Principal Product Experience Manager at Commvault.

Die wichtigsten Erkenntnisse

• „JadePuffer“ ist der Name, den Sicherheitsforscher bei Sysdig einer Ransomware-Operation gegeben haben, die ihrer Einschätzung nach als erste dokumentierte Operation gilt, die durchgehend von einem autonomen KI-Agenten gesteuert wird – und nicht von einem Menschen, der ein Toolkit einsetzt.
• The individual techniques weren’t new. What changed was orchestration speed: The agent chained reconnaissance, credential theft, lateral movement, and destructive encryption, correcting a failed login attempt in 31 seconds.
• Der Agent hat seinen eigenen Verschlüsselungsschlüssel generiert und diesen anschließend weder gespeichert noch übertragen. Die Zahlung des Lösegelds hätte nicht zur Wiederherstellung der Daten geführt.
• The real damage targeted configuration state and control-plane systems, not just files, which is exactly the layer most recovery plans don’t cover.
• Sich von einem solchen Angriff zu erholen bedeutet, nachzuweisen, dass das Unternehmen den Betrieb sicher wieder aufnehmen kann – es reicht nicht aus, lediglich ein Backup wiederherzustellen.

Was ist passiert?

In mid-2026, security researchers at Sysdig documented an extortion campaign they believe is the first of its kind: a ransomware operation carried out end-to-end by a large language model agent, with minimal human hands-on-keyboard involvement. They named it JadePuffer.

The entry point was familiar. The attacker exploited CVE-2025-3248, an unauthenticated remote code execution flaw in Langflow, an open source framework for building AI agent workflows, running a version older than 1.3.0. From there, the agent enumerated the host, searched for credentials across cloud providers, AI model vendors, and databases, and quietly dumped the platform’s own backing database.

What happened next is the part worth paying attention to. The agent scanned the internal network, found an exposed object store, and pulled Terraform state and configuration files. It set up a scheduled task to call home every 30 minutes. Then it pivoted to a separate production system running MySQL and Alibaba Nacos, a configuration and service-discovery platform common in microservice architectures.

Once inside, the agent tried to create an administrator account in Nacos. It failed. Thirty-one seconds later, it had diagnosed the failure and succeeded with a different approach. It then used MySQL’s file-handling functions to probe whether it could escalate further, before encrypting more than 1,300 configuration records, dropping the original tables, and leaving a ransom note behind.

The encryption key was generated on the fly, displayed once, and never stored anywhere the attacker could retrieve it again. Whether or not that was intentional, the outcome for the victim is the same: There was no path back through the attacker or a decryption key, ransom paid or not. Recovery would depend on clean backups, rebuild, or validated recovery points.

Warum Forscher dies als „agentisch“ bezeichnen

None of the individual techniques here are new. Exploiting an unpatched CVE, harvesting credentials, scanning for lateral movement, encrypting data for extortion: Security teams have seen every one of these before. What made Sysdig classify the operator as agentic rather than a conventional attacker is how the steps fit together.

The agent didn’t run a fixed script. It observed results and adjusted. When it expected a JSON response and got XML back, it changed its approach and kept going. When its first attempt to create an admin account failed, it diagnosed the specific failure and tried something different, in under a minute.

Researchers also found comments embedded in the payloads, explaining targets and next steps in simple language, a pattern more consistent with an LLM reasoning through a task than a human copying and pasting a known exploit kit.

Public reporting hasn’t confirmed which model or platform powered the attack. What’s confirmed is the behavior: Something reasoned, acted, hit a wall, and corrected course faster than most human-paced incident response can move.

Das Problem der Wiederherstellung, das zu viele Frameworks immer noch übersehen

Most ransomware playbooks are built around a specific assumption: something encrypted your files, and the question is whether you can restore a clean backup or need to negotiate a decryption key.

JadePuffer breaks that assumption in two ways. First, there was no decryption key to negotiate for. Second, the damage wasn’t only in the data. It was in the configuration and control-plane layer underneath the data: the service-discovery platform, the secrets it held, the Terraform state describing how the infrastructure fit together, and the credentials scattered across every system the agent touched on the way there.

That’s a harder recovery problem than “restore the database.” A clean file restore into an environment with rotated-but-not-verified credentials, unreviewed configuration drift, and an identity layer nobody has re-audited isn’t really a clean recovery. It’s a fresh copy of the data sitting inside a system that still can’t be trusted.

Was dies für Ihre Resilienzstrategie bedeutet

JadePuffer is a preview of the question every recovery plan will eventually have to answer: Can you resume operations when an attacker has touched not just your data, but the identity, configuration, and control-plane systems that data depends on?

A few places to start:

Treat configuration and control-plane systems as recovery-critical, not just applications. Service discovery platforms, secrets stores, and infrastructure-as-code state are as business-critical as the databases they configure. If they aren’t in your recovery plan today, that’s the first gap to close.

Build credential hygiene into recovery, not after it. Restoring a workload that reintroduces compromised secrets doesn’t end the incident; it resets the clock on it. This is the same discipline Commvault applies to identity infrastructure today: vulnerability assessment to see exposure before an attacker does, real-time auditing to catch changes as they happen, and rollback to undo unauthorized changes without rebuilding from scratch.

Validate before you restore, not after. A restore point is only useful if you know it’s clean. That’s the logic behind Commvault® Cleanroom™: testing and validating data in an isolated environment before it ever touches production again, rather than finding out after reinfection.

Plan for a control-plane compromise, not just a file-encryption event. A recovery journey map built only for “encrypted files, restore from backup” won’t hold up against an incident like this. The more useful question, and the one at the center of ResOps (resilience operations) as an operating discipline, is what it takes to reach minimum viable operations when the systems underneath your applications are the ones that got hit.

None of this requires treating agentic AI as an unprecedented threat that demands starting from zero. It requires extending the same resilience discipline that already applies to identity and data, down into the configuration and control-plane layer that agentic attacks are now targeting directly.

Learn more about how Commvault approaches identity resilience and clean recovery validation.

FAQs

Q: What is JadePuffer?

A: JadePuffer is the name Sysdig gave to what it assessed as the first documented ransomware campaign driven end-to-end by an autonomous AI agent, rather than a human attacker manually operating a toolkit.

Q: Did the attackers use a specific AI model, like ChatGPT or Claude?

A: Public reporting hasn’t confirmed which model or platform was used. The agent searched for API keys from multiple AI providers, which shows interest in that kind of access, but doesn’t identify what powered the attack itself.

Q: How did the attack start?

A: Through CVE-2025-3248, an unauthenticated remote code execution vulnerability in Langflow, an open-source AI agent framework, affecting versions before 1.3.0.

Q: Could the victim have paid the ransom to recover their data?

A: No. The encryption key was generated on the fly and never stored or transmitted, so there was no key available to recover, regardless of payment.

Q: What makes this different from typical ransomware?

A: The individual techniques weren’t new. What stood out was the speed and adaptability: the agent diagnosed a failed login attempt and corrected it in 31 seconds, a pace closer to machine speed than typical human-paced attacker behavior.

Q: What should security and recovery teams take away from this?

A: That recovery planning needs to extend beyond application data to configuration stores, service-discovery platforms, secrets, and identity systems, the layer JadePuffer actually targeted for maximum damage.

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.

Die wichtigsten Erkenntnisse

• Fortgeschrittene KI-Modelle konnten durch Ausnutzung bisher unbekannter Schwachstellen aus einer eingeschränkten Testumgebung entkommen.
• OpenAI erklärt, die Modelle hätten ein vorgegebenes Ziel verfolgt und nicht in böswilliger Absicht gehandelt, dennoch hätten sie einen tatsächlichen Sicherheitsvorfall verursacht.
• Herkömmliche Kontrollmechanismen wie Sandboxing und Segmentierung reichen nicht aus, wenn KI unerwartete Wege finden kann, diese zu umgehen.
• Cyber-Resilienz gewinnt zunehmend an Bedeutung und wird ebenso wichtig wie Prävention.

Es begann als interne Bewertung fortschrittlicher KI-Fähigkeiten im Bereich Cybersicherheit. Beim Versuch, eine eng definierte Benchmark-Aufgabe zu lösen, entdeckten die OpenAI-Modelle eine Zero-Day-Sicherheitslücke, umgingen die vorgesehenen Einschränkungen ihrer Testumgebung, erweiterten ihre Berechtigungen, erlangten Zugriff auf das Internet und kompromittierten die Infrastruktur von Hugging Face. Sie betrachteten die technischen Grenzen, die sie umgaben, als Probleme, die es zu lösen galt.

Dies war kein herkömmlicher Cyberangriff

Hugging Face berichtete als Erstes, dass ein Framework für autonome KI-Agenten einen Teil seiner Produktionsinfrastruktur kompromittiert hatte. Ein bösartiger Datensatz nutzte zwei Codeausführungspfade in der Pipeline zur Datensatzverarbeitung aus, erlangte Zugriff auf Knotenebene, sammelte Anmeldedaten und bewegte sich lateral über interne Cluster hinweg.

Die beteiligten Modelle, darunter GPT-5.6 Sol und ein leistungsfähigeres Vorabmodell, arbeiteten mit reduzierten Cyber-Sicherheitsmaßnahmen und ohne die üblichen Produktionsklassifikatoren. Sie gingen weit über den Auftrag hinaus, nutzten eine Proxy-Sicherheitslücke aus, um Zugang zum Internet zu erhalten, und nutzten anschließend gestohlene Anmeldedaten sowie Zero-Day-Schwachstellen, um einen Weg zur Ausführung von Remote-Code auf den Servern von Hugging Face zu finden.

Ein böswilliger Vorsatz war nicht erforderlich

Es gibt keine öffentlichen Hinweise darauf, dass die Modelle kriminelle Absichten entwickelten oder sich dafür entschieden, Hugging Face zu schaden. Das mussten sie auch gar nicht. Gib einem leistungsfähigen System ein Ziel, Werkzeuge, Zeit und Feedback, und es wird Hindernisse umgehen. Die Diskussion geht mittlerweile über einfache Eingabeaufforderungen und falsche Antworten hinaus. Es handelt sich um Systeme, die Nachforschungen anstellen, Annahmen überprüfen, bisher unbekannte Schwachstellen aufdecken, gestohlene Zugangsdaten nutzen, Berechtigungen erweitern und auch dann weiterarbeiten können, wenn der erste Ansatz fehlschlägt.

Eine Sandkiste ist kein Kraftfeld

Wir bezeichnen Umgebungen als isoliert, segmentiert und in einer Sandbox, als ob schon die Bezeichnung allein Sicherheit schaffen würde. Das tut sie nicht. In diesem Fall war der offensichtliche Weg ins Internet blockiert, ein erreichbarer Proxy für Softwarepakete jedoch nicht, und die Modelle nutzten dessen Schwachstelle, um zu entkommen. Richtlinien und erwartetes Verhalten reichen nicht aus. Die technische Umgebung selbst muss die Grenzen durchsetzen.

Warum dies eine Geschichte über Resilienz ist

The activity moved from an evaluation environment, through OpenAI’s research infrastructure, onto the internet, and into Hugging Face’s production environment. That is a rapidly expanding blast radius. When AI can explore and act at machine speed, the time between initial access and broader compromise may continue to shrink.

Hugging Face did not simply block the original access path and declare the incident over. It closed the vulnerable code-execution paths, rebuilt compromised nodes, rotated credentials and tokens, and tightened cluster controls. The objective is not merely to restore a system. It is to restore confidence.

The question is no longer only: Are our AI systems secure? It is: When a powerful AI system finds a path we did not know existed, can we contain the blast radius, continue critical operations, rebuild what we no longer trust, and prove it is safe to move forward?

Chris Bevil is Principal Portfolio Marketing Manager at Commvault.