The Legacy Modernisation Decision: Retain, Rehost, Replatform, Refactor, Replace or Retire

Before replacing or retaining a legacy system, check what the business depends on it to do. Record its actual risks and costs, the data and integrations that must survive, and the team's ability to run a replacement. Compare transitions that can be reversed or stopped safely.

1. The Market Connection Context

Customers experience legacy decisions through service continuity, accuracy, waiting time, channel choice, trust and the organisation's ability to respond when markets change. A stable older system may still support a valuable capability. A newer platform may still fail if data, integration, controls and operating ownership are weak. Age is context, not a disposition.

This guide converts pressure into a bounded executive choice:

Business capability and customer consequence → current asset evidence
→ cost, risk, data, integration and operability → viable options
→ transition and procurement conditions → named human disposition
→ controlled gate, learning and rollback

By [decision date], the CIO or CTO will classify each bounded asset-capability unit RETAIN, CONTAIN, MODERNISE, REPLACE, RETIRE, VALIDATE or STOP. MODERNISE may contain a specifically evidenced rehost, replatform or refactor path. The decision is not made by age, vendor preference, a composite score or sunk cost.

The Fundable Transformation Roadmap: Outcomes, Dependencies, Capacity and Decision Gates owns the fundable transformation roadmap and sequence. The Legacy Modernisation Decision: Retain, Rehost, Replatform, Refactor, Replace or Retire supplies a bounded legacy option and its dependencies to that roadmap. The Transformation Partner Appointment and Commercial-Control Playbook owns partner appointment and delivery assurance. The Stalled Transformation Recovery and Value-Realisation Standard: Recover, Stop or Scale owns recovery when an authorised programme is already consuming capital without operating proof. This guide does not appoint a supplier, authorise implementation or recover a stalled programme.

Working files

• Legacy Decision Charter and Authority Register
• Asset, Dependency and Risk Evidence Register
• Option and Transition Evidence Ledger
• Executive Legacy Disposition and Review Register

The UK Government Technology Code of Practice requires technology decisions to be user-centred, secure, open, interoperable and sustainable. The UK Government Sourcing Playbook provides official commercial guidance on delivery models, market management, risk allocation and contracting. NIST Cybersecurity Framework 2.0 supports governed identification, protection, detection, response and recovery. NIST SP 800-160 Volume 1 addresses systems-security engineering across the lifecycle. The US Government Accountability Office legacy-systems report GAO-23-106821 documents recurring federal legacy risks and modernisation challenges. These are VERIFIED official or primary sources. Their use in this commercial method is INFERRED. The Abrasim sequence is PROPOSED, and every local cost, risk and transition claim REQUIRES VALIDATION.

2. The Leadership vs. Delegation Boundary

The reader recognises that the choice depends on business value, technical health, data migration, dependencies, risk, operating capacity and transition economics.

An internal team can run the assessment when it can inspect the asset, contracts, costs, incidents, data, integrations and operating work; challenge owners; and stop unsafe action. Independent support is useful where supplier evidence is opaque, institutional knowledge is thin, a preferred replacement is predetermined or sunk cost shapes judgement.

Stop when credentials or production data cannot be protected, records may be destroyed unlawfully, safety or regulatory authority is absent, an option assumes invented cost or benefit, critical integrations are concealed, or retirement has no accepted continuity and archive path. Technical obsolescence, vendor end-of-support and vulnerability severity require qualified verification. Procurement, tax, accounting, employment, privacy and legal conclusions remain with authorised specialists.

When a narrower specialist or simpler intervention is sufficient

Use a security, records, data, resilience, accessibility, finance, procurement or architecture specialist for one bounded evidence or transition question when the asset-capability boundary is accepted. A contained configuration, support or archive correction is proportionate when it preserves the capability and has an owned acceptance test. Do not commission a replacement programme to avoid a local lifecycle or control decision.

Questions for evaluating a provider

Ask how the provider will preserve business, technical, data, risk and commercial authority; verify asset, dependency and cost evidence; test continuity and rollback; disclose conflicts and assumptions; leave usable transition, archive and operating artefacts; and return funding, risk acceptance and irreversible retirement to the named authority. Reject age-led replacement or product-first recommendations.

3. The Step-by-Step Execution Standard

Step 01: Charter the asset-capability decision

Purpose and decision served Bound one asset and the business capability, customer journey and decision affected by its future.

Accountable owner CIO or CTO.

Delegated lead and contributors Assessment Lead with Business Owner, CFO, Security, Data, Procurement and Independent Challenger.

Preconditions, inputs and access Asset identity, current concern, business sponsor, evidence access and decision date.

Actions

1. Name the capability, users and service consequence.
2. Define the asset and surrounding scope.
3. State the decision, exclusions and uncertainty.
4. Record conflicts, risk limits and stop conditions.

Evidence to retain Signed charter, asset references, capability map, authority and conflict record.

Decision or scoring rule Proceed only when one bounded asset-capability unit and consequence are explicit.

Output and template Charter row in the Legacy Decision Charter and Authority Register.

Acceptance gate DECISION BOUNDARY ACCEPTED or RE-CHARTER.

Leadership checkpoint The sponsor confirms that technology age is not the decision criterion.

Human control point Only leadership accepts criticality and value-at-risk boundaries.

Failure modes and safeguards Reject estate-wide scope, vague modernisation goals and preselected products.

Change, stop or escalation condition Stop if the asset, capability or authority cannot be bounded.

Handoff to the next step Transfer scope to authority and evidence-access design.

Step 02: Establish authority, access and independent challenge

Purpose and decision served Assign business, technical, risk, data, commercial and retirement authority.

Accountable owner CIO or CTO.

Delegated lead and contributors Governance Lead with specialists, system owner, supplier manager and Independent Challenger.

Preconditions, inputs and access Charter, delegations, contracts, access policies, mandates and conflicts.

Actions

1. Name accountable owners by evidence domain.
2. Approve read-only technical and commercial access.
3. define protected dissent and specialist escalation.
4. Separate assessment, risk, procurement and funding decisions.

Evidence to retain Authority matrix, access approval, conflict declaration and escalation map.

Decision or scoring rule No domain conclusion is accepted without qualified ownership and inspectable evidence.

Output and template Authority rows in the Legacy Decision Charter and Authority Register.

Acceptance gate AUTHORITY COMPLETE or HOLD.

Leadership checkpoint Leadership confirms supplier and sponsor conflicts are controlled.

Human control point Qualified authorities retain security, legal, finance and procurement judgements.

Failure modes and safeguards Prevent self-assurance by a vendor or team whose option is under assessment.

Change, stop or escalation condition Escalate denied access, missing ownership or material conflict.

Handoff to the next step Give authorised scope to business-criticality assessment.

Step 03: Establish business and service criticality

Purpose and decision served Determine which customer, operating, financial and control capabilities depend on the asset.

Accountable owner Business Owner.

Delegated lead and contributors Process Lead with service owners, frontline roles, Finance, Risk and continuity specialists.

Preconditions, inputs and access Process maps, demand, service obligations, incidents, workarounds and continuity plans.

Actions

1. Trace critical workflows and customer consequences.
2. identify outage, degradation and error tolerances.
3. Record manual alternatives, capacity and hidden labour.
4. Classify evidence and unresolved business assumptions.

Evidence to retain Capability map, service evidence, continuity tests, workaround observations and limitations.

Decision or scoring rule Criticality is based on consequence and recoverability, not user count alone.

Output and template Criticality rows in the Asset, Dependency and Risk Evidence Register.

Acceptance gate CRITICALITY BOUNDED or VALIDATE.

Leadership checkpoint The business owner accepts customer and operating tolerances.

Human control point Specialists accept safety, regulatory or contractual criticality.

Failure modes and safeguards Avoid undercounting shadow work and overclaiming irreplaceable uniqueness.

Change, stop or escalation condition Stop if continuity consequences cannot be understood safely.

Handoff to the next step Transfer capability evidence to asset-health analysis.

Step 04: Assess technical health and operability

Purpose and decision served Establish the asset's condition, supportability, security, resilience and operating burden.

Accountable owner Technology Owner.

Delegated lead and contributors Technical Lead with operations, security, engineering, support and supplier representatives.

Preconditions, inputs and access Architecture, versions, code or configuration, incidents, vulnerabilities, capacity and support evidence.

Actions

1. Inspect lifecycle, dependencies and support status.
2. Analyse incidents, recoverability and observability.
3. assess skills concentration and change failure.
4. Record verified issues separately from hypotheses.

Evidence to retain Technical inventory, support notices, incident evidence, recovery tests and skills map.

Decision or scoring rule No age-based score; classify each material condition by evidence, consequence and available control.

Output and template Health rows in the Asset, Dependency and Risk Evidence Register.

Acceptance gate HEALTH EVIDENCE FIT or VALIDATE.

Leadership checkpoint The CIO accepts current residual risk and evidence limits.

Human control point Qualified security and reliability owners judge severity and recovery.

Failure modes and safeguards Prevent unsupported “obsolete” labels and vulnerability counts without exposure context.

Change, stop or escalation condition Escalate active compromise, unsafe operation or unsupported critical dependency.

Handoff to the next step Pass health evidence to data and integration tracing.

Step 05: Trace data, records and integrations

Purpose and decision served Expose the information, interfaces and external dependencies that every option must preserve or retire lawfully.

Accountable owner Data Owner.

Delegated lead and contributors Data Architect with Integration Lead, Records, Privacy, Security and business owners.

Preconditions, inputs and access Schemas, interface inventories, data flows, retention rules, consumers and representative records.

Actions

1. Trace authoritative data, meaning and history.
2. Map inbound, outbound, manual and supplier integrations.
3. identify quality, retention, residency and access limits.
4. Test archive, extract and reconciliation feasibility.

Evidence to retain Data map, integration contracts, lineage, record obligations, extract and reconciliation tests.

Decision or scoring rule An option fails when a mandatory record, meaning, integration or permitted-use condition has no viable treatment.

Output and template Dependency rows in the Asset, Dependency and Risk Evidence Register.

Acceptance gate DEPENDENCIES TRACEABLE or HOLD.

Leadership checkpoint Data and business owners accept what must migrate, coexist, archive or be destroyed.

Human control point Qualified privacy and records authorities approve treatment.

Failure modes and safeguards Avoid counting interfaces without understanding semantics and manual exception paths.

Change, stop or escalation condition Stop an option that requires unlawful use or untestable data loss.

Handoff to the next step Transfer dependencies to cost and commitment analysis.

Step 06: Establish lifecycle cost and commitments

Purpose and decision served Compare current and option burdens using bounded, comparable cost evidence.

Accountable owner CFO.

Delegated lead and contributors Finance Lead with Technology, Procurement, Operations and Workforce Planning.

Preconditions, inputs and access Invoices, contracts, licences, hosting, labour, incidents, support and transition assumptions.

Actions

1. Define cost population, period and categories.
2. separate sunk, avoidable, committed, transition and recurring costs.
3. Include internal labour, risk treatment and dual-running burden.
4. Classify estimates, ranges and validation needs.

Evidence to retain Cost contract, source records, assumptions, ranges, commitments and Finance reconciliation.

Decision or scoring rule Compare like-for-like lifecycle boundaries; do not treat sunk cost as future benefit.

Output and template Cost rows in the Asset, Dependency and Risk Evidence Register.

Acceptance gate COST BOUNDARY ACCEPTED or VALIDATE.

Leadership checkpoint The CFO accepts the comparison boundary and uncertainty.

Human control point Accounting, tax and procurement treatment stays with qualified authority.

Failure modes and safeguards Prevent hidden internal labour, omitted transition overlap and false precision.

Change, stop or escalation condition Escalate commitments or exit costs that materially change viability.

Handoff to the next step Give the evidence pack to option construction.

Step 07: Construct distinct legacy options

Purpose and decision served Create viable alternatives that address evidenced conditions without assuming replacement.

Accountable owner CIO or CTO.

Delegated lead and contributors Architecture Lead with business, data, security, operations, Finance and Independent Challenger.

Preconditions, inputs and access Criticality, health, data, integration, cost and risk evidence.

Actions

1. Define RETAIN, CONTAIN, MODERNISE, REPLACE and RETIRE where viable.
2. Specify rehost, replatform or refactor only inside a bounded modernise option.
3. Record mechanism, dependencies, limits and reversibility.
4. Reject options that cannot meet mandatory conditions.

Evidence to retain Option definitions, architecture sketches, dependency treatments, assumptions and rejection rationale.

Decision or scoring rule Each option must solve an evidenced problem and preserve required capability; variety alone is not viability.

Output and template Option rows in the Option and Transition Evidence Ledger.

Acceptance gate VIABLE OPTIONS BOUNDED or REWORK.

Leadership checkpoint Leadership confirms retain and retire received fair consideration.

Human control point Architecture and business owners accept mechanisms and capability effects.

Failure modes and safeguards Avoid renaming one preferred replacement as several false options.

Change, stop or escalation condition Return unsupported claims to validation before comparison.

Handoff to the next step Pass viable options to transition testing.

Step 08: Design transition, coexistence and rollback

Purpose and decision served Show how each option reaches operation without unsafe discontinuity or irreversible surprise.

Accountable owner Transition Owner.

Delegated lead and contributors Programme Architect with operations, data, integration, security, service and change owners.

Preconditions, inputs and access Viable options, dependencies, service tolerances, migration evidence and capacity.

Actions

1. Define transition increments and evidence gates.
2. Map coexistence, data migration, cutover and rollback.
3. estimate dual operation and workforce burden.
4. Test continuity, reconciliation and irreversible points.

Evidence to retain Transition map, cutover tests, reconciliation, rollback evidence, capacity and stop conditions.

Decision or scoring rule An attractive target cannot compensate for an unsafe or unowned transition.

Output and template Transition rows in the Option and Transition Evidence Ledger.

Acceptance gate TRANSITION FEASIBLE, VALIDATE or REJECT.

Leadership checkpoint The COO and CIO accept service continuity and operating burden.

Human control point Named owners authorise irreversible cutover and rollback decisions.

Failure modes and safeguards Prevent big-bang assumptions, permanent dual running and untested archive recovery.

Change, stop or escalation condition Stop an option without a safe treatment for mandatory continuity.

Handoff to the next step Transfer feasible options to market and procurement validation.

Step 09: Validate delivery model and market conditions

Purpose and decision served Determine whether internal, external or blended delivery can meet the option's evidence and control needs.

Accountable owner Commercial or Procurement Authority.

Delegated lead and contributors Commercial Lead with Architecture, Legal, Security, Finance and Delivery Assurance.

Preconditions, inputs and access Feasible options, capability gaps, market evidence, contract estate and sourcing rules.

Actions

1. Define outcomes, retained authority and evidence obligations.
2. test market capacity without promising an award.
3. Assess lock-in, exit, intellectual property and continuity.
4. Record procurement route, conflicts and validation gaps.

Evidence to retain Market evidence, delivery-model analysis, commercial constraints, conflict declarations and assurance needs.

Decision or scoring rule Market interest is not supplier fitness; appointment remains under The Transformation Partner Appointment and Commercial-Control Playbook and authorised procurement.

Output and template Commercial rows in the Option and Transition Evidence Ledger.

Acceptance gate DELIVERY MODEL PLAUSIBLE or VALIDATE.

Leadership checkpoint Procurement and CIO accept retained ownership and exit conditions.

Human control point Only authorised procurement can approve route, competition and award.

Failure modes and safeguards Prevent vendor-shaped requirements and unauthorised pre-market commitments.

Change, stop or escalation condition Escalate market dependence, lock-in or conflict that changes option viability.

Handoff to the next step Give options and market constraints to challenge and reconciliation.

Step 10: Reconcile options through separate gates

Purpose and decision served Compare options without allowing a strength to hide a fatal business, control or transition failure.

Accountable owner Executive Sponsor.

Delegated lead and contributors Independent Challenger with business, Finance, Technology, Risk, Data and Procurement.

Preconditions, inputs and access Complete option evidence, assumptions, contradictions, dissent and specialist gates.

Actions

1. Test business criticality, lifecycle cost, risk, data, integration, operability and transition separately.
2. classify each gate pass, conditional, validate or fail.
3. Reconcile contradictions and missing evidence.
4. Prepare bounded option implications and dissent.

Evidence to retain Gate matrix, contradiction ledger, challenge notes, specialist views and unresolved gaps.

Decision or scoring rule No weighted average; one mandatory failure can hold or reject an option.

Output and template Reconciliation rows in the Option and Transition Evidence Ledger.

Acceptance gate DECISION PACK FIT or RETURN TO EVIDENCE.

Leadership checkpoint Leadership sees why each option remains, changes or exits.

Human control point Independent challenge protects minority evidence and dissent.

Failure modes and safeguards Avoid arbitrary scores, fabricated ROI and risk averages.

Change, stop or escalation condition Stop decision if a material gate is concealed or unsupported.

Handoff to the next step Transfer the reconciled pack to executive disposition.

Step 11: Make the executive legacy disposition

Purpose and decision served Choose a bounded path while keeping funding, procurement and implementation gates separate.

Accountable owner CIO or CTO with executive investment authority.

Delegated lead and contributors Assessment Lead prepares; CEO, CFO, COO, Risk and Independent Challenger advise.

Preconditions, inputs and access Decision pack, residual risk, constraints, dissent, capacity and opportunity cost.

Actions

1. Review all non-compensating gates.
2. choose one permitted disposition.
3. Record evidence boundary, owner, condition and expiry.
4. Separate funding and procurement authorisation.

Evidence to retain Signed disposition, gate evidence, residual risk, dissent, resource boundary and next gate.

Decision or scoring rule Use RETAIN, CONTAIN, MODERNISE, REPLACE, RETIRE, VALIDATE or STOP.

Output and template Decision row in the Executive Legacy Disposition and Review Register.

Acceptance gate LEGACY DISPOSITION RECORDED.

Leadership checkpoint Leadership states what is decided, excluded, unfunded and still uncertain.

Human control point Disposition, risk acceptance, funding and supplier appointment remain distinct human decisions.

Failure modes and safeguards Prevent conditional evidence from becoming an unconditional replacement mandate.

Change, stop or escalation condition Stop when conflicts, evidence gaps or irreversible consequences are hidden.

Handoff to the next step Transfer the bounded disposition to roadmap and review ownership.

Step 12: Handover, monitor and reopen the decision

Purpose and decision served Place the accepted path into controlled sequencing and keep its assumptions under review.

Accountable owner CIO or CTO.

Delegated lead and contributors Portfolio Owner with operating, architecture, security, data, Finance and commercial owners.

Preconditions, inputs and access Signed disposition, The Fundable Transformation Roadmap: Outcomes, Dependencies, Capacity and Decision Gates roadmap gate, measures, owner, archive and stop route.

Actions

1. Transfer dependencies and evidence gates to The Fundable Transformation Roadmap: Outcomes, Dependencies, Capacity and Decision Gates.
2. Assign monitoring for cost, risk, service and transition assumptions.
3. Record The Transformation Partner Appointment and Commercial-Control Playbook partner needs separately.
4. Reopen or route to The Stalled Transformation Recovery and Value-Realisation Standard: Recover, Stop or Scale when evidence materially changes.

Evidence to retain Handover acceptance, measure contracts, decision version, changed assumptions and review record.

Decision or scoring rule Continue only while evidence remains within the accepted boundary; sunk cost cannot prevent reassessment.

Output and template Review rows in the Executive Legacy Disposition and Review Register.

Acceptance gate CONTINUE, CHANGE, VALIDATE, ROLL BACK, RETIRE or STOP.

Leadership checkpoint The CIO and portfolio owner accept ongoing decision accountability.

Human control point Material scope, risk, supplier or irreversible transition changes require renewed approval.

Failure modes and safeguards Prevent an assessment decision from becoming permanent implementation authority.

Change, stop or escalation condition Re-charter when capability, asset, evidence, market or control context changes materially.

Handoff to the next step Archive evidence and open the appropriate roadmap, partner or recovery gate.

4. The Evidence & Measurement Checklist

Preflight and authority

• One asset-capability decision is explicitly chartered. Evidence: signed charter. Owner: CIO.
• Business, technical, risk, data and commercial owners are named. Evidence: authority matrix. Owner: Governance Lead.
• Independent challenge and conflicts are controlled. Evidence: conflict register. Owner: Executive Sponsor.
• Read-only evidence access is authorised. Evidence: access record. Owner: Security Owner.
• Exclusions and stop conditions are accepted. Evidence: boundary register. Owner: CIO.

Evidence access and quality

• Customer and service consequences have inspected evidence. Evidence: criticality map. Owner: Business Owner.
• Technical health claims distinguish verified issues from hypotheses. Evidence: health register. Owner: Technology Owner.
• Data, record and integration dependencies are traced. Evidence: dependency map. Owner: Data Owner.
• Lifecycle costs use comparable boundaries. Evidence: Finance contract. Owner: CFO.
• Evidence gaps remain visibly classified. Evidence: validation ledger. Owner: Assessment Lead.

Method execution

• Retain, contain, modernise, replace and retire were fairly considered. Evidence: option set. Owner: Architecture Lead.
• Each option solves an evidenced problem. Evidence: mechanism record. Owner: Business Owner.
• Transition, coexistence and rollback are explicit. Evidence: transition design. Owner: Transition Owner.
• Options pass separate non-compensating gates. Evidence: gate matrix. Owner: Independent Challenger.
• Modernise variants state rehost, replatform or refactor precisely. Evidence: option definition. Owner: Technology Owner.

Governance, privacy, security and risk

• Security risks have qualified verification and owners. Evidence: security assessment. Owner: Security Owner.
• Privacy, records and retention decisions are authorised. Evidence: specialist decision. Owner: Data Owner.
• Access and production testing use safe controls. Evidence: test approval. Owner: Security Owner.
• Procurement engagement follows authorised route. Evidence: commercial record. Owner: Procurement Authority.
• Irreversible and safety-critical gates retain human approval. Evidence: control map. Owner: Risk Owner.

Deliverables and acceptance

• All four working files are complete and consistent. Evidence: controlled decision pack. Owner: Assessment Lead.
• Material contradictions and limitations are near the decision. Evidence: challenge record. Owner: Independent Challenger.
• Option dependencies and owner commitments are explicit. Evidence: option ledger. Owner: CIO.
• Executive disposition is signed and bounded. Evidence: disposition record. Owner: CIO.
• Funding and procurement remain separate gates. Evidence: authority record. Owner: CFO.

Measurement

• Service, cost, risk, data and operability measures have contracts. Evidence: measure set. Owner: Measurement Lead.
• Baselines use named populations and periods. Evidence: baseline record. Owner: Finance Lead.
• Mandatory segments and controls are not averaged away. Evidence: gate evidence. Owner: Risk Owner.
• Transition outcomes preserve guardrails. Evidence: transition review. Owner: COO.
• Attribution stays within the evaluation design. Evidence: attribution statement. Owner: Independent Challenger.

Decision and handover

• The Fundable Transformation Roadmap: Outcomes, Dependencies, Capacity and Decision Gates receives dependencies and evidence gates. Evidence: roadmap handover. Owner: Portfolio Owner.
• The Transformation Partner Appointment and Commercial-Control Playbook partner needs remain separate from appointment. Evidence: procurement handoff. Owner: Commercial Lead.
• The Stalled Transformation Recovery and Value-Realisation Standard: Recover, Stop or Scale recovery triggers are defined. Evidence: escalation map. Owner: Transformation Sponsor.
• Each condition has one owner and review gate. Evidence: disposition register. Owner: CIO.
• Retirement includes continuity, archive and access evidence. Evidence: retirement plan. Owner: Data Owner.

Review, change and stop controls

• Decision assumptions have expiry and monitoring owners. Evidence: review register. Owner: CIO.
• Material risk or service change can reopen the disposition. Evidence: trigger test. Owner: Risk Owner.
• Sunk cost cannot block reassessment. Evidence: governance rule. Owner: CFO.
• Unsafe transition can roll back or stop. Evidence: rollback test. Owner: Transition Owner.
• Changed capability or asset scope requires re-charter. Evidence: change-control record. Owner: Executive Sponsor.

Measurement contracts

Measure A: Business-service continuity

Measure B: Lifecycle cost evidence

Measure C: Data and integration reconciliation

Measure D: Operational risk exposure

Measure E: Transition operability

Evidence classifications used in this guide

• VERIFIED: supported by an inspected controlled record or cited primary source.
• INFERRED: a bounded interpretation with assumptions and alternatives visible.
• PROPOSED: an option, mechanism, control or disposition awaiting authority.
• REQUIRES VALIDATION: an important claim or condition not safe to rely upon yet.

Source notes

1. UK Technology Code of Practice: official principles for user-centred, secure, interoperable and sustainable technology.
2. UK Government Sourcing Playbook: official commercial guidance used for delivery-model and market controls.
3. NIST Cybersecurity Framework 2.0: official cybersecurity risk framework used for govern, identify, protect, detect, respond and recover concepts.
4. NIST SP 800-160 Volume 1 Rev. 1: official systems-security engineering guidance used for lifecycle control principles.
5. US GAO-23-106821: official report used as evidence that legacy risks and modernisation constraints require specific management evidence; it does not establish local conditions.