Requirements - Technology Choices
-
T03 - Vendor Lock-in
An appraisal should be made of any vendor lock considerations and associated risks, and these are understood and accepted/mitigated.
Requirement description
This requirement is concerned with understanding and managing the risks associated with vendor lock-in.
Many technologies, products and cloud services introduce varying degrees of dependency on a supplier. Such dependencies are not automatically a problem, but they should be consciously assessed. Teams should understand the consequences of becoming dependent on a supplier's technology, commercial model, skills ecosystem, data formats, APIs or hosting platform.
Where vendor lock-in risks exist, they should either be mitigated or consciously accepted through appropriate governance and decision-making processes.
In simple terms:
Teams should know where supplier dependency exists, understand the risks it creates and have a clear rationale for either accepting or reducing those risks.
Scoring rubric table – T03 Vendor Lock-In Assessment
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that vendor lock-in has been considered as part of technology selection or architecture design. |
No supplier dependency assessment. No technology risk analysis. No documented architecture rationale. |
Significant service risk. Technology choices may create unmanaged dependencies and future cost, migration or operational challenges. |
| 1 | Limited awareness of vendor lock-in risks. Dependencies may be acknowledged informally but are not assessed or documented. |
Informal discussions. Undocumented assumptions. Supplier recommendations accepted without challenge. |
High-risk gaps. Technology decisions could create long-term constraints that are poorly understood. |
| 2 | Some assessment of supplier dependency exists, but analysis is incomplete, inconsistent or lacks evidence. |
Partial options appraisal. Basic supplier assessment. Limited discussion of migration or exit considerations. Some architecture rationale. |
Significant notable gaps. Important lock-in risks may not be fully understood, quantified or managed. |
| 3 | Much of the vendor lock-in position is understood. Significant dependencies have been identified and key risks have been documented. |
Technology options assessment. Architecture Decision Records. Vendor risk analysis. Documented rationale for technology selection. Some mitigation planning. |
Notable gaps remain. Exit strategies, migration approaches or formal risk acceptance may not be fully defined. |
| 4 | Most vendor lock-in risks have been assessed and either mitigated or formally accepted through governance processes. |
Comprehensive supplier dependency assessment. Documented mitigation plans. Governance review of lock-in risks. Exit or migration considerations. Cost and operational impact analysis. |
Minor gaps only. Remaining dependencies are understood and present limited risk. |
| 5 | Comprehensive and exemplar management of vendor lock-in considerations. Dependencies are actively governed and influence architecture and investment decisions. |
Formal lock-in assessment methodology. Comprehensive technology and supplier evaluations. Documented exit strategies. Regular review of supplier dependency risks. Governance-supported acceptance or mitigation decisions. Evidence that lock-in considerations actively influence solution design and procurement decisions. |
Minimal or no significant gaps. Supplier dependencies are transparent, strategically managed and regularly reviewed. |
What assessors should look for
- Identification of dependencies – Has the team identified where supplier-specific technologies, services or platforms are being used?
- Risk understanding – Are commercial, technical, operational and migration risks documented and understood?
- Options analysis – Were alternative products, technologies or architectures considered?
- Mitigation measures – Have actions been defined to reduce unnecessary lock-in where appropriate?
- Risk acceptance – Where lock-in is considered acceptable, is this documented and supported by governance?
- Future flexibility – Has the team considered future migration, portability, interoperability or replacement scenarios?
What separates a 3 from a 4 or 5
A score of 3 generally means that supplier dependencies have been recognised and documented, but mitigation plans, exit considerations or governance approval may be incomplete.
A score of 4 requires a structured assessment of lock-in risks, documented mitigation or acceptance decisions and evidence that supplier dependency has been considered during architecture and technology selection.
A score of 5 requires vendor lock-in management to be an established part of architecture governance and technology decision-making. The organisation can demonstrate that dependency risks are routinely assessed, reviewed and used to influence long-term architecture strategy.
Suggested evidence examples (not SAF-mandated artefacts)
- Technology options appraisals
- Architecture Decision Records (ADRs)
- Vendor dependency assessments
- Supplier risk assessments
- Commercial and procurement evaluations
- Migration or exit strategy documentation
- Architecture review outputs
- Technology governance records
- Solution Design Overview documents
- Risk registers containing vendor lock-in risks
Updated: 04 September 2026 (SAF Version 1.1)