"Data trust." "Data hygiene." "ResOps."
Three terms that now appear in every backup and resilience keynote, session, and demo. Not one of the vendors using them defines them.
That's not an accident. Terms without definitions are marketing. They fill the space where clarity would be inconvenient, where a precise definition might reveal that the product doesn't quite do what the slide implies.
I'm going to define them. And then I'm going to explain why the definitions matter more than the terms.
I've spent 20 years at the C-level as a CISO, CIO, and CTO, making the recovery decisions these terms are supposed to describe.
The definition test
Data hygiene has at least fifty different uses in enterprise technology. Are we talking about how we manage data operationally? Our ability to apply compliance requirements to data? Our capacity to classify, govern, or protect it? The term means different things to different teams in the same organization, let alone across organizations.
"Data hygiene" without a definition is a sound. It communicates nothing actionable.
Data trust is worse. Trust is a contract. That's not a metaphor. It's a functional description of what trust actually is.
With humans, we constantly renegotiate that contract based on experience and behavior. We extend trust, we revoke it, we update the terms. With systems, the contract has to be written down. What does it mean for this system to be trusted? What specific conditions does it have to meet? How do I verify that it meets them? How do I know when it doesn't?
"Data trust" without a contract is just confidence without evidence. That's not a security posture. It's a feeling.
Until someone hands me a written trust contract that specifies what the conditions are, what the verification looks like, and what happens when the contract is violated, "data trust" means nothing to me as a practitioner.
The ResOps problem
ResOps isn't one vendor's term. Every major backup vendor is using it. Commvault, Cohesity, Rubrik, Veeam, all of them are talking about Resilience Operations or some variant of it. The collective industry has decided this is the frame.
That's actually the problem.
The "Ops" suffix carries meaning. DevOps, SecOps, MLOps, FinOps. Each of those terms describes not just a toolset but a practice with an operating model. People, process, and tools working together at scale. DevOps didn't become DevOps when someone bought a CI/CD pipeline. It became DevOps when organizations redesigned how people and processes worked around that toolset. Most companies still haven't done that, by the way. DevOps is mostly a mess. SecOps is unfinished work. MLOps exists in maybe a dozen enterprises that actually got it right.
The enterprise practitioner community is exhausted by this game. Every new capability gets an *Ops label. None of them come with an operating model. All of them require the customer to figure out the people and process layers on their own while paying the vendor for the tool.
An operating model is not a console. It's how your organization runs something repeatedly, reliably, with defined roles, handoffs, escalation paths, and improvement mechanisms. Backup vendors have decades of investment in the tools layer. The people dimension, outside of the person who operates the console, is almost entirely outside their expertise. The process dimension, how enterprises actually build and run resilience practices at scale, is invisible in every vendor's roadmap.
ResOps as a term implies an operating model. Not one vendor using it has published one. What exists is an aspiration, a direction, and a marketing label for a set of tools that could become an operating model if someone does the actual work.
That's not a dismissal. It's a challenge. Build the operating model and you win the category. Keep shipping tools without one and ResOps joins the pile of *Ops terms that looked good in a keynote and died in implementation.
The budget problem nobody is naming
Here's the organizational reality underneath all of this that the backup vendors aren't talking about.
For twenty years, backup and recovery lived clearly under the CIO. It was an IT operations problem. Operational continuity, RTO, RPO: all of it was a technology infrastructure conversation.
Now these same vendors are selling threat detection, DSPM, identity resilience, and AI governance. Those are CISO conversations. Different buyer. Different budget. Different success metrics.
In many enterprises, the CIO and CISO still have a reporting relationship where the CISO reports to the CIO. In that structure, the expand motion works. You start with backup (CIO conversation), establish value, then bridge to the security capabilities (same budget conversation, same org). One relationship, one expansion path.
But that structure is changing. The CISO is rising to peer status with the CIO in more organizations every year, especially after a cyber incident or when a competitor gets hit. At Amazon, the Chief Security Officer reports directly to the CEO and board. The CISO sits under the CSO. These aren't the same conversation anymore.
When CIO and CISO are peers with separate budgets, asking them to jointly fund a platform that spans both functions is extraordinarily hard. Nobody shares budget easily, and nobody shares budget with a peer. The expand motion is still viable: start with an existing backup customer, then sell the CISO on the security layer. The new logo motion, trying to sell both simultaneously to two peers who don't share budget authority, is a much harder problem that no vendor's sales playbook has actually solved yet.
This matters for how you buy. The unified platform pitch is most compelling when you already have a relationship with one side. Build the trust there first, then bridge.
And for vendors: the platform vision requires an organizational change in how you sell it. Sales motions designed for a single buyer don't work when you need two separate budget owners to each say yes.
The maturity model question
Several backup vendors are now shipping data and AI trust maturity models: four pillars, a dozen dimensions, dozens of sub-dimensions, five maturity levels. On paper that's a real maturity model structure. The architecture suggests someone put genuine thought into it.
The question I'd ask is simpler: does any answer in the model lead to less spend with the vendor that built it?
A good maturity model is completely self-service. It tells you where you are, what better looks like, and gives you a path to improve, independent of any specific vendor. You can use it to evaluate your posture, identify gaps, and make decisions about where to invest. The model serves you.
A model that requires a four-to-eight-week services engagement to interpret and apply, delivered by the vendor who built the model, is not a maturity model. It's a discovery engagement. The primary beneficiary is the vendor, not the customer, because the vendor gets to see inside your environment and recommend their own products to address what they find.
That's a conflict of interest. And it's one that practitioners should be clear-eyed about.
If I use a vendor's maturity model, and the vendor then helps me interpret the results and recommend a path forward, I've essentially handed them a qualified lead. I've invited them to diagnose me so they can prescribe themselves.
Does the maturity model ever produce a result that leads to less spend with its author? Does it ever point to a different vendor for a specific capability? If not, it's a sales tool with academic branding.
That doesn't mean it's useless. A well-designed maturity framework can still surface real gaps and help you have better internal conversations about where to invest. But use it with eyes open about who built it and why.
The honest verdict on the converged platform
There's a genuinely hard thing happening in this market, and it's worth crediting. Backup vendors are trying to fuse twenty years of backup and resilience expertise with real security and data-governance platforms, often through acquisition. The ambition is real. The data portability story some of them tell, backup on one hypervisor and restore to Azure or AWS, is genuinely differentiated.
That portability angle deserves serious attention from enterprise buyers. There are real use cases: testing restores in non-production environments, validating that applications are complete and actually run, migrating workloads when licensing costs make on-premises untenable, and testing cloud cost estimates with real workload data.
But the vocabulary is still catching up to the vision. ResOps needs an operating model. The maturity model needs to be self-service to be trustworthy. The security language needs to be grounded in specifics, not atmosphere.
Evaluate these platforms seriously. Do a proof of concept. Ask the hard questions about integration, about the versioning economics of their immutability claims, about the identity recovery story, about how their threat detection feeds your existing security stack.
And if you haven't gotten the basics right, start there. Confident, fast, verifiable recovery doesn't wait for the next platform to hit general availability.
The close
The most basic claim I know about this category: backup is bullshit, recovery is everything.
Everything else is a specific dimension of that same claim: immutability, identity, AI, trust, the channel problem, the codebase. They're all ways that organizations think they have recovery handled when they don't.
The threats in 2026 are not going to wait for the industry to catch up with better vocabulary. They're not going to wait for maturity model frameworks to become self-service. They're not going to wait for backup vendors to develop genuine operating model expertise.
What you can control is whether you have a recovery contract: a specific, written, tested definition of what recovery means in your environment, what trust looks like when you've achieved it, and how you verify it before the incident tells you whether you were right.
Build the contract. Test the recovery. Don't buy the feeling.
To enterprise IT leaders: Demand definitions. When a vendor says "data trust," ask them to define it in writing, specific to your environment. If they can't, the term isn't load-bearing.
To CISOs: The operating model gap in resilience operations is a real opportunity. The vendors aren't filling it. You can. Define the people and process layers in your own organization before your backup vendor's roadmap catches up.
To vendors: Self-service maturity models are trustworthy ones. If your model requires your services to interpret, you've built a sales tool. Build the real thing.