Decide on a residual dependency

A residual dependency is an asset, right, service or item of know-how still required from the source after recovery. Each is examined separately: a favourable overall score cannot erase an active account, a missing right or a critical function that was not restored.

The decision rests on observations attached to the tested scenario, not on an abstract view of the supplier.

• Affected function — blocked or degraded business journey
• Break condition — shutdown, contract end, change or unavailability
• Extent — affected users, data, regions and interfaces
• Tolerable delay — point at which the effect becomes unacceptable
• Substitute — actually qualified target and mobilisation time
• Evidence — test observation supporting the conclusion

The authority may accept a dependency when it understands the plausible effect, treatment cost, monitoring conditions and the point at which the decision must be revisited. Acceptance names an owner and is never implicit.

Every treatment must alter an observation from the test and schedule a new verification.

Replacement becomes supportable when the dependency blocks a critical function, exceeds the tolerable delay or cannot be reduced under accepted conditions. The decision identifies the target, window, prerequisites and switching authority.

The previous test becomes the exit-plan baseline. Reservations do not disappear: they become migration entry conditions.

The register makes clear who decided, on which facts and until which date.

• Identifier — dependency and version concerned
• Observation — test phase and evidence
• Decision — accept, reduce or replace
• Authority — person empowered to own the risk
• Deadline — treatment or reassessment date
• Closure — test to replay and expected result

A material change of model, platform, contract, region, team or critical function can make the previous exercise obsolete. An incident or change in exit rights also triggers reassessment.