ResOps Needs an Enforcement Layer

Resilience Operations, or ResOps, is emerging from a fairly simple realization: having backup systems, disaster recovery plans, security controls, and recovery objectives does not necessarily mean a business can recover when disruption actually occurs.

That distinction matters.

Traditional resilience programs tend to describe an intended state. Critical applications should be protected. Recovery objectives should be met. Backup copies should remain immutable. Recovery procedures should be tested. Dependencies should be understood. Evidence should be available when regulators or auditors ask for it.

ResOps changes the operating model by asking teams to manage those conditions continuously rather than treating recovery as a plan that is periodically reviewed.

That is an important shift. But it introduces another question that deserves more attention:

What happens when the organization discovers that the required resilience state is no longer true?

Finding the gap is not the same as closing it. That is why ResOps needs an enforcement layer.

ResOps changes the question from “do we have backups?” to “can the business recover?”

For decades, recovery planning largely revolved around infrastructure-oriented questions.

Did the backup job complete? What is the Recovery Time Objective? What is the Recovery Point Objective? Where is the secondary copy? When was the last disaster-recovery exercise?

Those questions remain useful, but they describe pieces of the recovery problem rather than the complete outcome.

A backup can exist and still be unusable. An RTO can be documented and still never have been demonstrated under realistic conditions. A recovery procedure can have passed its annual test while the underlying environment changes significantly over the following months. A service can also depend on identity, storage, networking, cloud configuration and multiple protection systems that are managed by different teams.

ResOps is emerging because recoverability increasingly has to be treated as a property of the operating environment itself.

That means understanding critical services, defining acceptable disruption, protecting the systems and data those services depend on, validating recovery capability, and continuously learning from changes in the environment.

The emphasis moves from possessing recovery mechanisms to proving that recovery remains possible.

The industry is already moving in this direction. ResOps frameworks increasingly emphasize continuous governance, recovery assurance, clean recovery, measurement, cross-functional ownership and business-service context rather than relying exclusively on conventional backup-success metrics.

But making resilience continuously visible creates a second problem. Visibility exposes drift faster than traditional operating processes can necessarily resolve it.

Every resilience policy eventually meets operational drift

A resilience architecture does not remain static after it has been approved.

New workloads appear. Cloud accounts are added. Storage policies change. Retention periods are modified. Backup administrators change roles. Application dependencies evolve. Teams introduce new SaaS platforms or cloud-native protection services. An acquisition introduces another backup vendor.

Someone modifies an immutability configuration during troubleshooting and never restores the original setting. A critical workload moves to another region without the protection policy moving with it.

Nothing needs to “fail” for resilience to deteriorate. The organization can simply move away from the state it originally intended.

This is resilience drift.

Consider a relatively straightforward requirement:

Tier-1 workloads must maintain an immutable recovery copy outside the primary failure domain.

At the policy level, that statement is easy to understand. At the operational level, proving it continuously may require answering several different questions.

• Which workloads are currently Tier 1?
• Where are their recovery copies?
• Are those copies geographically independent?
• Are they actually immutable?
• Has the retention configuration changed?
• Does the policy hold across Veeam, AWS Backup, Azure Backup, Commvault or another platform being used elsewhere in the enterprise?
• Did an administrator make a change yesterday that altered the answer?

The desired resilience state may remain unchanged while the underlying environment changes every day.

This is where ResOps becomes much more than a recovery-planning methodology. It requires a mechanism for continuously reconciling what should be true with what is actually true.

Detection is necessary. It is not enforcement.

Modern resilience and security tooling has made organizations considerably better at seeing problems.

Platforms can identify unprotected workloads, configuration weaknesses, failed backup jobs, policy violations, exposed infrastructure and deviations from recommended practices.

That observability matters. But most operational systems eventually reach the same handoff point:

Here is the problem. Someone should fix it.

The issue enters a queue. A ticket is created. An engineer investigates. The right team has to be identified. The proposed remediation has to be understood. Someone may need to approve it. The change is eventually made. Ideally, someone returns later to confirm that the original risk has actually been removed.

That workflow is perfectly reasonable for some classes of change. It becomes less reasonable when the organization intends resilience to operate continuously.

A control cannot realistically be called continuously governed if the organization continuously detects its failure but restores it only when the relevant humans work through the queue.

The gap between detection and restored state is therefore an important ResOps concern in its own right. We can think of it as an enforcement gap.

Continuous validation proves that something works. Enforcement preserves the conditions that allow it to work.

Continuous validation is one of the most important developments in modern resilience.

Organizations should test recovery. They should verify that recovery points can actually be restored. They should validate that recovered data and systems are trustworthy before relying on them during a real incident. They should collect evidence rather than assuming that configuration implies recoverability.

But validation and enforcement solve different problems.

Validation asks: Does our recovery capability work?

Enforcement asks: When something moves away from the required state, what brings it back?

Imagine that a recovery test confirms a workload can be restored successfully today. That is valuable evidence.

Tomorrow, however, a retention policy could change. An immutable copy could lose its protection. A new workload could be deployed without the required secondary copy. A cloud account could be added without entering the existing recovery governance process. A privileged change could silently weaken the control that yesterday's test verified.

The test was not wrong. The environment changed.

This is why ResOps should not stop at continuous assurance. The operating loop needs to connect assurance to action.

What an enforcement layer actually has to do

Enforcement does not mean automatically changing every resilience configuration without human oversight. That would replace one class of operational risk with another.

A useful enforcement layer needs context, policy, decision boundaries, verification and evidence. The operating loop looks closer to this:

Discover → Assess → Enforce → Verify → Report

Discovery establishes the current resilience state across the environment. Assessment compares that state with policies, business criticality, recovery requirements and other controls. Enforcement determines what action is required when the current state deviates from the desired state.

Some actions may be safe enough to execute automatically. Others may require explicit human approval. High-impact changes should remain governed by stronger authorization boundaries.

Verification then determines whether the remediation actually restored the required state. Reporting preserves the evidence: what changed, why it changed, who or what authorized the action, what state existed before the change, and whether the expected outcome was achieved.

This closes the loop.

• Without verification, automation can only prove that an action was attempted.
• Without policy context, automation cannot reliably determine whether that action was appropriate.
• Without guardrails, automation can create unacceptable operational risk.
• Without evidence, the organization cannot explain what happened later.

Continuous enforcement therefore is not simply “automated remediation.” It is a governed mechanism for moving resilience from a detected deviation back toward an approved state. That loop is what Forttic calls Continuous Resilience Enforcement.

Multi-vendor resilience makes enforcement harder—and more necessary

This problem becomes particularly visible in enterprises that operate more than one protection platform.

A single organization may use a traditional enterprise backup product for data-center workloads, a cloud-native service for AWS resources, another mechanism for Microsoft 365, and a different platform inherited through acquisition.

Each platform can be functioning correctly within its own boundaries while the enterprise still lacks a consistent answer to a broader question:

Is our resilience policy true across the estate?

A requirement such as 3-2-1-1-0 illustrates the challenge. It is not enough to ask whether an individual product has replication, retention, immutability or recovery features. The organization needs to determine whether the intended resilience outcome holds across workloads, locations, failure domains, storage technologies and vendors.

That requires a layer of policy above the individual execution systems.

Backup platforms should continue doing what they are designed to do: execute protection and recovery operations. The ResOps layer should reason about the outcome the enterprise requires across those systems. And the enforcement layer should make sure identified deviations do not remain indefinitely between dashboards, tickets and operational teams.

This is particularly important because enterprise resilience rarely begins from a clean architectural slate. Organizations cannot simply replace every existing backup product, cloud service and recovery process in order to adopt a new operating model. ResOps has to govern the environment that actually exists. See vendor coverage for the protection platforms Forttic sits above.

From ResOps to Enforced ResOps

The important distinction is not between ResOps and Continuous Resilience Enforcement. They operate at different levels.

ResOps is the broader operating discipline. It defines how an organization thinks about resilience across people, processes, technology, critical services, recovery assurance and measurement.

Continuous Resilience Enforcement addresses a specific operational requirement inside that discipline: keeping the desired resilience state aligned with the live environment.

That is why we believe the next stage of ResOps will increasingly focus on enforcement.

As organizations become better at continuously discovering resilience state, continuously measuring it and continuously testing recovery, the unresolved work between those stages becomes more visible.

A resilience control drifts. It is detected. Now what? Who owns it? Is the appropriate action already known? Can it be executed safely? Does it require approval? Was the change successful? Is there evidence? And has the organization actually returned to the resilience state it intended?

Those questions are where an operating discipline becomes an operating system.

Resilience should converge toward the required state

There is a useful way to think about the difference.

A traditional resilience program periodically asks: Are we still compliant with our recovery policy?

A posture-oriented system continuously asks: Where are we deviating from our recovery policy?

An enforced ResOps model goes one step further: How quickly do we return to the required state after deviation occurs?

That final question changes the objective. The goal is no longer merely to produce more resilience findings. It is to reduce the amount of time critical systems spend outside their intended resilience state.

That also creates a different class of metrics. Teams can begin to look beyond how many issues were discovered and toward questions such as how long critical drift remained unresolved, how often remediation required manual escalation, whether recovery verification passed after the change, and whether recurring failures were permanently eliminated.

Those are operating metrics rather than dashboard metrics. And they are much closer to what ResOps is ultimately trying to accomplish.

Forttic's view: backup tools execute, ResOps governs, CRE enforces

Forttic was built around this specific enforcement problem.

We do not think enterprises need another backup product simply to practice ResOps. The existing backup stack remains essential. What is missing in heterogeneous environments is a vendor-neutral decision and enforcement layer above that stack.

Forttic calls that model Continuous Resilience Enforcement, or CRE.

CRE continuously discovers the resilience estate, assesses deviation from policy, enforces approved remediation within defined guardrails, verifies recovery outcomes, and preserves the resulting evidence.

The goal is not to replace ResOps. It is to make one of its most important requirements executable: when resilience reality diverges from resilience policy, close the gap—and prove that it was closed.

That is the distinction we will explore throughout FortticResOps.

Start with the operating model

What Is ResOps? A Practical Guide to Resilience Operations

ResOps turns resilience from a recovery plan into an operating discipline—connecting critical services, recovery readiness, continuous validation, measurement, and action.

Read the guide →

Because resilience should not only be planned. It should not only be observed. And it should not only be tested. It should be continuously brought back to the state the business depends on.

Frequently asked questions

What is ResOps?

ResOps, or Resilience Operations, is an emerging operating discipline that treats organizational recoverability as a continuous, measurable capability rather than a periodic disaster-recovery activity. It brings together recovery planning, governance, architecture, assurance, measurement and cross-functional ownership. See What Is ResOps? for the practical guide.

Is ResOps a product category?

Not in the way backup software or security platforms are product categories. ResOps is better understood as an operating discipline. Different technologies can support parts of a ResOps model, but adopting a single product does not by itself create Resilience Operations.

What is Continuous Resilience Enforcement?

Continuous Resilience Enforcement is Forttic's model for continuously discovering resilience state, assessing drift, enforcing approved remediation, verifying the resulting recovery state and maintaining evidence across backup vendors and cloud environments. See the CRE Framework.

How is continuous enforcement different from continuous validation?

Continuous validation determines whether a recovery capability or control works. Continuous enforcement addresses what happens when the observed state no longer satisfies the required policy. Mature resilience programs need both: proof that recovery works and a mechanism for restoring the required state when it drifts.

Does enforcement mean every recovery change should be autonomous?

No. Enforcement should operate inside defined decision boundaries. Low-risk, well-understood remediation may be appropriate for automation, while higher-impact actions should require human approval. The important requirement is that decision authority, execution and verification are explicit rather than being left to an unmanaged operational queue.