Is Your DevOps Data Truly Resilient? Key Takeaways From “Breaking The DevOps Data Loss Chain”

As more businesses across the globe turn toward the cloud, data loss is not a hypothetical scenario. It is a matter of when, not if. And when it hits your DevOps toolchain, the fallout can be intense: broken releases, stalled pipelines, scrambling teams, and shaken customer trust.

During a recent webinar, Building resilience: Breaking the DevOps data loss chain, Jon Brown, Senior Analyst at Omdia, and James Ciesielski, Co-Founder and CPTO at Rewind, unpacked what real resilience looks like for modern DevOps teams and why platforms’ native protections are not enough.

This recap breaks down the speakers’ key insights, along with practical steps for building a DevOps data resilience strategy that actually works.

DevOps data is your IP, not just “technical detail”

When most people think about data protection, they jump straight to customer records and regulated data. Jon Brown argued that this view is too narrow for DevOps-driven organizations.

“When we are talking about critical DevOps data, we are talking about your company’s intellectual property… your engineers, the code they are developing, that is your IP.”

It’s not just source code. Critical DevOps data includes:

• Configuration data that defines environments and connections
• CI or CD pipeline definitions and deployment workflows
• Observability and incident data over time
• Internal documentation and design decisions
• Project and workflow data in tools like Jira and monday.com

James shared a stat from Rewind’s 2024 State of SaaS Data and Recovery report: about 85% of organizations reported at least one data loss event in the past year. When you map that reality onto the list above, the risk is clear. Losing any one of those elements can directly impact your ability to ship.

The hidden causes of DevOps data loss

A lot of organizations expect to lose data after a massive disaster, like a data breach or ransomware attack. The reality is more mundane and more dangerous.

James highlighted the most common causes of data loss that Rewind sees from our customers:

• Human error: Someone hits the wrong key combination, runs the wrong script, or bulk edits the wrong set of issues.
• Misconfigurations: Teams introduce a configuration change with good intentions but do not fully understand the side effects, which can lead to outages or data loss.
• Fragile integrations: Modern toolchains are stitched together with integration glue. Bugs or edge cases in that glue can have cascading consequences.
• Misunderstood responsibility in the cloud: Many teams skip through SaaS platforms’ Terms and Conditions. As James put it, most tools are very clear that you are responsible for safeguarding the data you put into them.

“If they paused and read the terms in their entirety, they would likely find a line saying ‘any data you put into this tool is your responsibility to safeguard and secure.’”

Jon added a layer of emerging risks, including:

• Malicious insiders
• AI-driven complexity and new failure modes
• Ongoing ransomware evolution
• Supply chain attacks on open source and third party components
• Shadow IT (where anyone can add a SaaS tool to your organization’s tech stack and quietly plug it into critical workflows)

In short, there is no single root cause to defend against. You need a resilience strategy that assumes multiple, overlapping risks.

Why native SaaS backup and recovery is not enough

Many teams assume their SaaS platforms “have backup covered.” Jon and James were blunt about why that assumption is dangerous.

First, there is the contractual reality: “In the licensing, they tell you explicitly they are not responsible for your data.”

But even beyond the Shared Responsibility Model, there are technical and architectural constraints:

1. Platform availability is not data resilience: The app can be up while your account data is corrupted, deleted, or misconfigured.
2. Multi-tenant limitations: As James explained, your account is only a slice of a multi-tenant dataset. Restoring the whole system to fix one tenant is not realistic.
3. Shallow or same platform “backups”: Some tools offer limited account exports or snapshots, but often store them in the same environment, which fails the basic 3-2-1 backup rule.

James used a simple analogy:

To build real resilience, both speakers came back to the 3-2-1 rule: 3 copies of your data, stored in 2 different places in the cloud, 1 of which is not your SaaS provider.

Who actually owns data resilience?

One of the most important messages from the webinar was also one of the simplest:

“The bottom line is that the company, not the SaaS provider, is responsible for data resilience. If you walk away from this webinar with one message, it is that this is on you.”

Ownership is where many organizations stumble:

• In smaller companies, ownership is often scattered. Every team spins up its own tools and owns its own resilience, if it exists at all.
• In larger organizations, SaaS ownership tends to fall under IT or a central function, but shadow IT and decentralized decision making still create gaps.

Jon recommended using a RACI framework and making ownership explicit:

• Who is Responsible for day-to-day operations and data backups?
• Who is Accountable for uptime and recovery targets?
• Who should be Consulted when changes or incidents occur?
• Who needs to be Informed when something goes wrong?

James also stressed the importance of testing, not just planning:

“Everyone has a plan until they get punched in the face.”

At Rewind, the team runs regular tabletop exercises, including scenarios where core decision makers are intentionally unavailable, to make sure the plan works when reality gets messy.

The hidden costs of SaaS data loss

Jon and James also dug into what really happens when things go wrong. The costs go far beyond the immediate recovery work.

From Jon’s perspective, the big cost drivers include:

• Direct incident costs
• Regulatory fines, especially in regulated industries such as healthcare and finance
• Cyber insurance increases
• Legal and reputational fallout
• Recovery costs: Full restores of large datasets can be very expensive, especially if you lack granular restore options.

James added a more human angle:

“Beyond the direct costs and downtime, there is this internal challenge where people build up cynicism. You end up debating whether to switch tools instead of focusing on delivering value.”

He described this as part of the “data loss domino effect”: downtime leads to revenue loss, reputational harm, missed opportunities, and internal distraction.

How AI changes the data protection conversation

AI showed up in the discussion as both a helper and a new source of risk.

On the positive side, Jon shared research showing that organizations using AI to plan and execute restores are seeing about an 11% reduction in recovery time. AI can:

• Prioritize what to restore first
• Understand dependencies between systems
• Orchestrate restores in a way that aligns with business priorities

But AI also generates a lot of new data. Prompts, responses, and interaction histories are rarely backed up today.

“I fully expect that a few years from now we are going to have to be able to explain what AI did. Part of that explanation will be retention of AI inputs and outputs.”

James pointed out that this is not just a compliance issue. People are already relying on AI systems in very practical ways. Losing a long running chat thread or analysis can be painful, even before regulation arrives.

He also called out opportunities for AI in backup itself, especially around anomaly detection and guiding teams during high stress incidents.

A practical DevOps resilience checklist

To close the session, Jon and James shared a checklist that any DevOps or platform team can use as a starting point for building their resilience strategy:

• Back up data outside the platform
• Follow the 3-2-1 rule with at least one independent, off site copy
• Build infrastructure redundancy where you can restore and test
• Continuously monitor emerging threats and incorporate them into planning
• Use anomaly detection on backups to spot suspicious change patterns
• Identify what is truly critical and why it matters
• Establish clear ownership and escalation paths
• Automate backups, monitor them, and ensure immutability
• Document the plan, version it, and share it with all stakeholders
• Test it often, through tabletop exercises

This list forms a solid blueprint for moving beyond “checkbox” compliance and toward resilience that actually keeps your teams shipping.

Final takeaway: resilience is your last line of control

In their closing thoughts, both experts came back to a single theme: resilience is not optional anymore.

James summed it up for teams moving to or scaling with SaaS:

“In the cloud, your data resilience is your last line of control. You need to worry about this for compliance and for business continuity. Everyone will care about this when something goes wrong.”

Jon framed it as a mindset shift:

“There was a time when we were more comfortable with downtime. As work becomes more dependent on continuously operating, integrated software systems, the risks and costs of not having resilience, grow.”

If you are not actively thinking about how to make your SaaS applications more resilient, you are probably not thinking about it enough.

Watch the full webinar on demand

This recap only scratches the surface of the Building resilience: Breaking the DevOps data loss chain webinar with Jon Brown and James Ciesielski.

To hear the full discussion, including real world stories from Rewind customers and deeper dives into AI, shared responsibility, and backup architecture, watch the on-demand webinar.