Back to home

Before depending

Reversibility audit

Prove that a service can leave a supplier or technology without losing its data, critical functions or operating capability.

Discuss your situationExplore the engagement
Engagement at a glance
Tested unit
One service, version, source and identified target
Exercise
Export, rebuild, execute, switch and roll back
Conclusion
Exit demonstrated, conditional or not demonstrated

Evidence principle

An available export does not demonstrate a viable exit

Reversibility exists when the expected assets are recovered, checked, restored on an independent target and operated by the team that will take over the service. A contract grants rights; only an exercise exposes incomplete formats, hidden dependencies and operations that remain impossible without the supplier.

Before the exercise, the mandate fixes the critical function to preserve, the observed version, the recovery target, exclusions and the authority that will accept or reject the result.

Register

Read dependency from the service being delivered

The inventory does not begin with the supplier contract. It begins with the service the organisation must preserve, then descends to the assets that make each function possible.

  • Data — objects, metadata, schemas, provenance and useful history
  • Models — exportable weights or API, versions, parameters, prompts and evaluations
  • Infrastructure — images, configurations, networks, storage, queues and jobs
  • Identities — accounts, roles, keys, certificates, tokens and segregation of duties
  • Interfaces — formats, API contracts, events and upstream or downstream dependencies
  • Rights — licences, intellectual property, return, erasure and subcontracting
  • Skills — written procedures, scarce operations and knowledge that remains tacit

Test protocol

Move the assets through to an observable recovery

The sequence preserves the same scope and version from beginning to end. Every phase produces timestamped evidence and a condition for moving forward.

  • Freeze — approved mandate, inventory, target and criteria
  • Extract — manifests, volumes, formats, logs and errors
  • Check — integrity, exclusions, rights and reconciliation gaps
  • Rebuild — environment, identities, interfaces and observability
  • Exercise — critical journeys, incident, restoration and autonomy
  • Switch — recovery time, data loss, revocation and rollback

Measures

Measure recovery, not delivery of a file

No threshold is universal. Criteria come from service criticality, applicable obligations and what the authority accepts before the exercise.

Minimum measures for a reversibility test

MeasureObservationDecision condition
CoverageRecovered assets and justified exclusionsNo unexplained critical asset
IntegrityHashes, volumes, schemas and reconciliationsNo unresolved critical discrepancy
ServiceCritical journeys executed on the targetPrior threshold achieved
RecoveryObserved switch time and data lossApproved objectives met
AutonomyOperations executed by the target teamNo critical unplanned assistance
ResidualSource calls, accounts, licences or know-howNo unaccepted critical dependency

Coverage

Observation
Recovered assets and justified exclusions
Decision condition
No unexplained critical asset

Integrity

Observation
Hashes, volumes, schemas and reconciliations
Decision condition
No unresolved critical discrepancy

Service

Observation
Critical journeys executed on the target
Decision condition
Prior threshold achieved

Recovery

Observation
Observed switch time and data loss
Decision condition
Approved objectives met

Autonomy

Observation
Operations executed by the target team
Decision condition
No critical unplanned assistance

Residual

Observation
Source calls, accounts, licences or know-how
Decision condition
No unaccepted critical dependency

Conclusion

Conclude without hiding a critical failure inside an average

The result does not come from a composite score. One critical impossibility can leave the exit unproven even when the rest of the test succeeds.

  • Exit demonstrated — critical criteria met and recovery verified
  • Conditional exit — recovery achieved, gaps accepted, assigned and dated
  • Exit not demonstrated — critical asset, right, function or autonomy missing

Applicable framework

Law structures the exit; the test establishes capability

The Data Act has applied since 12 September 2025. For covered data-processing services, Articles 23 to 30 address switching obstacles, contractual terms, information on formats and certain technical aspects of portability.

Within its own financial-sector scope, DORA requires exit strategies and transition plans for ICT services supporting critical or important functions. These frameworks prove neither export integrity nor target-team autonomy: they define requirements to be examined in the mandate.

Sources and references

Frequently asked questions

Is a business continuity plan enough?

No. It organises continuity or recovery after an incident. Reversibility tests a different capability: leaving a technology or supplier with data, configurations and skills that remain usable.

Do we have to migrate to test reversibility?

No. A bounded exercise checks the export, its integrity, restoration in an isolated target, reconnection of a few interfaces and recovery of a minimum service, without moving production.

Does hosting in France remove the dependency?

No. Hosting location matters, but it resolves neither technical lock-in, nor access to configurations, nor scarce skills, nor the exit terms of the contract.

What does the Data Act change for a cloud exit?

For covered services, it governs switching and the removal of exit obstacles. It does not prove that your exports are complete or that your teams can rebuild the service: the exercise still matters.

Scope the exercise

Which service must you be able to recover without its supplier?

State the service, version, supplier and critical function to preserve. We determine whether an isolated test can support a useful conclusion.

Tell us about your situation