Retirement, disposition and programme closure

Retirement, disposition and programme closure

RT-01 — Retirement policy

[Organisation] retires systems and dependencies through an authorised plan that addresses stakeholder needs, continuing obligations, information, access, assets and evidence. The system owner coordinates retirement and remains responsible until the recorded responsibilities are closed or transferred. A project ending, a subscription expiring or a server being switched off does not by itself complete disposition.

The plan identifies the reason, scope, proposed end date and the systems, people and suppliers affected. It considers replacement, migration, continued limited support and final disposal as distinct activities. The decision authority receives the effect on essential functions, obligations, cost and risk before confirming the approach.

RT-02 — Identify dependencies and obligations

The owner reviews the stakeholder, configuration, supplier and information inventories to identify continuing reliance on the system. The review covers interfaces, scheduled jobs, users, credentials, certificates, data exports, reporting, recovery arrangements and supplier commitments. Hidden dependencies discovered during the review are assigned for resolution.

The obligation owner identifies records to retain, information to return or delete, notices to provide, contracts to close and support commitments that continue. Retention or preservation holds are recorded with their authority. The plan identifies who will hold required evidence after the original team or service is no longer available.

RT-03 — Plan transition and communication

The transition owner records how required functions and information will move to a replacement arrangement or cease with stakeholder agreement. Migration identifies source and destination, compatibility, data quality checks, access, timing, recovery and acceptance. The owner assesses whether the replacement changes privacy purposes, supplier exposure or risk and initiates the relevant reviews.

Communications identify affected stakeholders, the change, dates, actions required, support routes and known limitations. The owner confirms that operators and users can act on the notice, including those who do not regularly access the retiring system. End-of-support notices distinguish the end of new development, security fixes, operational service and access to archived information where those dates differ.

RT-04 — Execute disposition

The performer confirms the approved scope and prerequisites before changing service availability or disposing of assets. Actions follow the change procedure and preserve the evidence needed to establish what was done. Access removal covers users, service identities, supplier accounts, tokens, connectors, trusted relationships and unattended workflows. Shared identities or services are checked for continuing use before removal.

Information disposition follows the approved retention and disposal decisions. The custodian considers primary stores, backups, replicas, caches, exports, devices and supplier copies. Deletion claims identify the actual scope and evidence. Where a provider cannot demonstrate removal of a particular copy or derived artefact, the limitation is recorded with the decision on the remaining exposure.

RT-05 — AI-specific closure

Where the retired capability uses AI, the owner identifies models, training and evaluation datasets, prompts, retrieval stores, embeddings, experiment records and provider-held information. The owner determines which artefacts must be retained for evidence and which should be disposed of under the data schedule. Access to remote services and model registries is closed according to the authorised scope.

The owner records any continuing reliance on outputs or decisions produced by the capability. Necessary correction, explanation or support arrangements remain assigned. Deleting an application does not establish that a provider has deleted submitted information, and deleting source data does not necessarily remove information from a trained model. Closure states what has been verified and what remains uncertain.

RT-06 — Verify and accept closure

The reviewer verifies that the intended service has ended or transitioned, required information remains accessible, unneeded authority has been removed and disposal actions have evidence. Checks include whether retired interfaces, names, scheduled jobs or integrations still receive traffic or requests. The reviewer confirms that essential functions and agreed stakeholder outcomes are sustained by the replacement where required.

The decision authority accepts closure with any continuing conditions explicitly assigned. Outstanding work is transferred to named owners with dates and evidence requirements. The system inventory records the retired status and the location of retained evidence. Monitoring or supplier charges that continue temporarily remain visible until their own closure conditions are met.

RT-07 — Programme learning

The owner reviews whether earlier design, acquisition or information decisions made retirement unnecessarily difficult. Lessons identify improvements to portability, supplier agreements, dependency records, retention and operating procedures. Actions are assigned through the improvement process. The programme retains enough knowledge to answer later questions about what the system did, who authorised it and how its obligations were concluded.