The Problem of Vendor-Dependent Technology

External technology delivery is not inherently a loss of enterprise control.

The risk emerges when the enterprise delegates implementation without retaining sufficient authority, rights, technical control, knowledge and continuity capability.

The research supports three independent conditions of effective technology ownership:

Legal Rights. Technical Control. Demonstrated Competence.

These conditions are related but not interchangeable.

A company may legally own software it cannot rebuild. It may administer infrastructure it does not understand. It may possess documentation without the competence to recover production.

The central research position is that vendor governance must evaluate the enterprise's ability to sustain the technology, not merely the supplier's ability to deliver it.

Enterprise technology sourcing has historically been governed through contracts, service levels, delivery milestones, commercial performance and supplier-risk assessments.

These remain necessary.

However, increasingly interconnected systems, specialized delivery platforms, proprietary vendor tooling, cloud infrastructure and multi-vendor dependencies expose a deeper problem.

Technology can become operationally dependent on its original supplier even when contractual delivery obligations have been fulfilled.

The governing question therefore changes:

From: Did the vendor deliver what was contracted?

To: Can the enterprise independently govern, operate, change, recover and transition what was delivered?

This is a shift from delivery assurance toward durable technology control.

1. 01

   Contractual ownership does not establish technical ownership

   Legal rights, technical control and demonstrated competence must be evaluated independently.

2. 02

   Architecture authority cannot be silently delegated

   Vendors may own implementation responsibility, but enterprise-wide architecture decisions and risk authority require accountable enterprise ownership.

3. 03

   Engineering evidence is stronger than delivery assertions

   Verified source, builds, tests, deployed configurations and independent validation establish more than supplier self-attestation.

4. 04

   Documentation is not executable knowledge

   Knowledge ownership requires demonstrated internal ability to understand, diagnose, recover and change technology.

5. 05

   Production operation is not final acceptance

   Architecture conformance, security clearance, production authorization and contractual acceptance answer different questions.

6. 06

   Supplier dependency is created throughout the lifecycle

   Proprietary tooling, credentials, architectural decisions and concentrated knowledge can make replacement difficult long before contract termination.

7. 07

   Transition readiness must be designed into technology

   A credible exit capability depends on usable rights, assets, operational knowledge and independently demonstrated continuity.

This research concerns technology delivered or operated by external providers, including custom software, system integration, cloud and data engineering, managed services and relevant commercial platforms.

It does not assume that enterprises must develop all technology internally or possess proprietary source code for every commercial product.

It does not claim that all vendor dependence is avoidable or economically undesirable.

The relevant distinction is between deliberately accepted dependency and dependency that remains unrecognized, uncontrolled or impossible to transition safely.

The research synthesizes recognized standards, documented buyer practices and engineering methods. It does not claim that a single external standard prescribes the complete model.

Contractual ownership and practical maintainability

Enterprise technology contracts commonly settle the question of who owns what was produced. They rarely settle whether the enterprise can keep it working. A deliverable can be assigned to the buyer in full and still be practically unmaintainable without the people, tools and environments that produced it.

The gap matters because ownership is usually tested at moments of stress: a supplier exits, a key engineer leaves, a defect appears in production, or the enterprise needs to change direction faster than the delivery relationship allows. At those moments, the relevant question is not what the contract says the enterprise owns. It is what the enterprise can actually do.

Foreground and background intellectual property

Delivery contracts typically distinguish foreground intellectual property, created specifically for the engagement, from background intellectual property, which the supplier brings to it. Foreground material is often assigned to the buyer. Background material is usually licensed, and the scope of that licence determines how far the delivered system can be used, modified or transferred once the relationship ends.

Where a delivered system depends on background components, the enterprise's effective rights are bounded by the narrowest licence in the dependency chain. Assignment of the foreground code does not extend those rights.

Rights to use, modify, operate and transfer

Ownership in practice is a bundle of distinct rights. The right to use a system does not imply the right to modify it. The right to modify does not imply the right to have a third party modify it on the enterprise's behalf. The right to operate internally does not imply the right to transfer operation to a successor provider. Each of these rights needs to be present, explicit and exercisable for the enterprise to retain meaningful control.

Proprietary accelerators and third-party dependencies

Suppliers frequently deliver faster by using proprietary frameworks, code generators, deployment tooling and reusable components. These accelerators can create real value. They can also become structural dependencies when the delivered system cannot be built, tested or deployed without them, and when the enterprise holds no usable right to them after the engagement.

Third-party components introduce a parallel form of dependency. Open-source and commercial libraries carry their own licences, maintenance horizons and security obligations, which the enterprise inherits regardless of which party selected them.

Repositories and reproducible builds

A common governance response is to require that source code be held in an enterprise-controlled repository. This is necessary but not sufficient. A repository records what was written. It does not prove that the enterprise can turn that material into the system that is running in production. That requires the build definitions, dependency sources, configuration, secrets management arrangements and environment knowledge needed to reproduce the deployed artifact independently.

Technical ownership as a multidimensional condition

The analysis above leads to the three conditions introduced in the Research Position. These conditions are a Built by Sentient analytical synthesis. They are not drawn from a single external standard, although each draws on concerns that the cited standards address separately.

Legal Rights

The enterprise holds exercisable rights to use, modify, operate and transfer the technology and its dependencies.

Technical Control

The enterprise controls the source, artifacts, infrastructure, configuration, identities and pipelines through which the technology is built and run.

Demonstrated Competence

The enterprise, or a provider of its choosing, has shown that it can understand, operate, recover and change the technology without the original supplier.

Each condition can be present while the others are absent. Treating any one of them as evidence of the other two is the central error this research identifies.

Enterprise architecture authority and vendor solution design

Enterprise architecture practice distinguishes the architecture of the enterprise as a whole from the design of individual solutions within it. The TOGAF Standard frames architecture work as a governed capability of the enterprise, with architecture governance establishing how architectures are approved, monitored for compliance and changed over time.¹

A vendor engaged to deliver a solution is normally well placed to own its internal design. It is not positioned to decide how that solution should relate to the rest of the enterprise estate, which standards it may depart from, or which risks the enterprise is willing to carry as a result. Those decisions concern interests that extend beyond any single contract.

Reserved and delegated decisions

The practical consequence is that architecture decisions need to be classified. Some are delegated to the supplier as part of implementation responsibility. Others are reserved to the enterprise because they affect integration, data, security posture, operability, cost structure or the feasibility of future change. COBIT 2019 treats this kind of allocation as part of enterprise governance of information and technology, separating governance objectives that set direction from management objectives that execute within it.²

When the boundary between reserved and delegated decisions is not explicit, delegation tends to happen by default. The supplier makes the decision because it is the party present when the decision is required.

Cross-system dependencies and enterprise standards

Most consequential architecture decisions concern relationships between systems rather than the internals of one. Interfaces, data ownership, identity models, event contracts and shared platforms create dependencies that no single supplier sees completely. Enterprise technology standards exist to keep those relationships coherent, and departures from them are decisions the enterprise needs to authorize knowingly.

Architecture description and decision records

ISO/IEC/IEEE 42010 defines requirements for architecture descriptions, including the identification of stakeholders and their concerns, the viewpoints used to address those concerns, and the recording of architecture rationale and decisions.³

Recorded architecture decisions serve continuity as much as design. They allow a successor team to understand why the system takes its current form, which constraints were deliberate, and which alternatives were rejected. Where decisions live only in the memory of a supplier's engineers, that rationale leaves with them.

Multi-vendor integration responsibility

Enterprises increasingly assemble systems from several suppliers, platforms and managed services. In that setting, integration responsibility can fall between contracts. Each supplier may meet its own obligations while the end-to-end system fails to behave as intended. Responsibility for the integrity of the whole cannot be contracted away in full, because no single external party is accountable for it.

Conformance and completion

Implementation completion asks whether the contracted work was done. Architecture conformance asks whether what was built matches what was approved, and whether any departures were authorized. These are different tests. A project can complete on schedule while drifting materially from the architecture the enterprise agreed to, and that drift becomes the enterprise's inheritance.

From assertion to evidence

Supplier reporting describes what the supplier believes it delivered. Engineering evidence describes what the delivered technology actually is and how it behaves. Governance that relies only on the first is exposed whenever the two diverge.

Source and artifact control

Technical control begins with the enterprise holding authoritative copies of source, build definitions, infrastructure definitions and the artifacts that are deployed. It also requires that the enterprise can establish the relationship between them, so that a running component can be traced to the source and process that produced it.

Build, deployment and infrastructure independence

Control of source is weakened when builds and deployments can only be executed through supplier-owned pipelines, accounts or tooling. The same applies to infrastructure and configuration. Where environments are defined, provisioned and administered under supplier identities, the enterprise's ability to act depends on the supplier's continued cooperation.

Release provenance and software supply-chain evidence

The NIST Secure Software Development Framework sets out practices for producing well-secured software, including protecting software and its build processes from tampering and maintaining provenance information for software releases.⁴

The SLSA specification describes graduated levels of assurance about how software artifacts were built, centred on verifiable provenance that links an artifact to its source and build process.⁵

Software bills of materials, expressed in formats such as SPDX and CycloneDX, provide a machine-readable inventory of the components contained in a delivered system. They make inherited dependencies visible to the enterprise rather than known only to the supplier.⁶

NIST SP 800-161 Rev. 1 places these concerns within a broader cybersecurity supply-chain risk management discipline that extends across acquisition, development and operation.⁷

Verification and architecture fitness

Security verification standards such as the OWASP Application Security Verification Standard provide a structured basis for testing application security controls against defined requirements, rather than accepting a statement that the application is secure.⁸

The same principle applies beyond security. Architectural properties such as performance, resilience, operability and conformance to standards can be expressed as verifiable checks. Evidence of this kind is stronger than a design document because it reflects the system as built.

Validity, scope and freshness

Evidence is only as useful as its relationship to the system currently in production. A test report describes one version of one component at one point in time. A security assessment describes a defined scope. Governance therefore needs to ask what each piece of evidence covers, which version it applies to and whether it remains current after subsequent change.

Independent reproduction

The strongest form of engineering evidence is reproduction by a party other than the supplier. When the enterprise or an independent provider can build, deploy and verify the system from enterprise-held materials, the claim that the enterprise controls the technology has been tested rather than asserted.

This research describes the categories of evidence involved. It does not publish the evidence schema or control library through which Built by Sentient applies them in engagements.

The limits of conventional knowledge transfer

Knowledge transfer at the end of a delivery engagement is often treated as a documentation exercise supplemented by a small number of handover sessions. The output is measured by what was provided: documents, recordings, diagrams and runbooks. That measure says little about whether the receiving organization can now act.

Available, understood and executable knowledge

This research distinguishes three states of knowledge. Available knowledge exists somewhere the enterprise can reach. Understood knowledge has been absorbed by people who can explain it. Executable knowledge is knowledge those people have applied to the real system under realistic conditions. Only the third establishes competence. The distinction is a Built by Sentient synthesis.

Documentation usability

Documentation is valuable when it is accurate, current and written for the people who will use it. It loses value when it describes intended rather than actual behaviour, when it assumes context the reader does not have, or when it has not been tested by anyone other than its author.

Independent build, change and diagnosis

The practical tests of knowledge ownership are tasks rather than artifacts. Can the enterprise build the system from source? Can it make and release a meaningful change? Can it diagnose an incident it has not seen before? Site reliability engineering practice emphasizes this orientation, treating operational knowledge as something maintained through practice, incident response and post-incident learning rather than through static documentation alone.⁹

Recovery demonstration

Recovery is the most demanding test because it occurs under pressure and often involves rarely exercised procedures. Service management standards such as ISO/IEC 20000-1 include requirements for service continuity and availability management.¹⁰

Without demonstration, recovery capability remains an assumption.

Internal and successor-provider capability

Demonstrated competence does not have to reside inside the enterprise. It can sit with a successor provider the enterprise is free to engage. What matters is that the capability is not confined to the original supplier, and that the enterprise retains enough expertise to judge whether any provider is performing adequately.

Key-person and supplier dependency

Knowledge concentrated in a small number of individuals creates a dependency that contracts do not capture. When those individuals work for the supplier, key-person risk and supplier dependency become the same risk. Public-sector delivery guidance such as the US Digital Services Playbook and the UK Digital, Data and Technology Playbook both emphasize building in-house capability alongside external delivery partners.¹¹

This research explains why demonstrated competence matters. It does not publish the procedures through which Built by Sentient assesses it.

Six distinct decisions

Enterprises often speak of a system being accepted as if acceptance were a single event. In practice, several distinct decisions are involved, each answering a different question and each normally owned by a different authority.

Architecture approval

Is the proposed design acceptable to the enterprise before it is built?

As-built architecture conformance

Does what was built match what was approved, and are departures authorized?

Security clearance

Has the system been assessed against defined security requirements within a stated scope?

Production authorization

Is the enterprise prepared to run this system in production and accept its operating risk?

Technical ownership acceptance

Can the enterprise, or a provider of its choosing, sustain the system without the original supplier?

Business and contractual acceptance

Has the supplier met the obligations that the contract ties to acceptance?

This six-part distinction is a Built by Sentient synthesis. Life-cycle standards such as ISO/IEC/IEEE 12207 describe processes including verification, validation, transition and acceptance-related activities, and supplier-relationship standards such as ISO/IEC 27036 address security within acquisition. Neither prescribes this exact sequence.¹²

Why production is not acceptance

Successful production operation is evidence that the system works today under the current arrangement. It is not evidence that the system can be maintained by anyone else, that its architecture conforms to what was approved, or that the contractual conditions for acceptance have been met. A system can operate well precisely because the original supplier continues to support it informally.

Collapsing these decisions into one creates a predictable failure. The most visible test, whether the system is running, is allowed to stand in for less visible ones, and the enterprise discovers the gap only when it tries to exercise control it assumed it had.

Technical governance and legal effect

Technical governance decisions and contractual acceptance should remain distinct. Contractual acceptance can carry legal and commercial consequences, such as payment, warranty commencement or the transfer of risk, that are determined by the contract and applicable law. This research does not describe those consequences. Its point is narrower: technical findings should inform contractual decisions without being mistaken for them, and contractual acceptance should not be read as proof of technical ownership.

The detailed gates and acceptance criteria Built by Sentient uses in engagements are not published here.

Lock-in and switching costs

Vendor lock-in is best understood as the cost of switching rather than the impossibility of it. Every supplier relationship creates some switching cost. The governance question is whether that cost is known, proportionate and accepted, or whether it grows unobserved until the enterprise has no practical alternative.

Proprietary delivery and operational support dependencies

Switching costs accumulate through decisions that often appear minor when they are made: adopting a supplier's proprietary tooling, allowing operational procedures to exist only in the supplier's systems, or relying on the supplier's engineers for routine diagnosis. Each decision may be locally rational. Their combined effect can be a dependency the enterprise never chose deliberately.

The cost of retained capability

Retaining technical capability is not free. Internal architects, engineers and operators cost money, and maintaining enough expertise to supervise suppliers competently is a continuing investment. Maximum independence is therefore not always optimal. For some systems, a deliberate and well-understood dependency is the economically sound choice.

Transition, replacement and runtime economics

The economics of control include costs that appear only at transition: rebuilding missing knowledge, reproducing environments, migrating data and running parallel operations. They also include continuing runtime costs. The FinOps Framework describes a practice for managing cloud and technology spending through shared accountability between engineering, finance and business stakeholders, which depends on the enterprise having visibility into how its technology consumes resources.¹⁴

Where infrastructure and accounts sit under supplier control, that visibility can be partial, and cost decisions are effectively shared with the supplier.

Cost per useful business outcome

Comparing sourcing options on contract price alone obscures much of this. A more useful measure relates the full cost of a technology arrangement, including retained capability, dependency risk and expected transition cost, to the business outcomes it supports. This framing is a Built by Sentient synthesis and is offered as an analytical lens rather than a published metric.

Retaining versus outsourcing capability

Supplier-relationship and supply-chain risk guidance, including ISO/IEC 27036 and NIST SP 800-161 Rev. 1, treats dependency as a risk to be identified, assessed and managed across the relationship rather than eliminated.¹³

The economic argument of this research follows the same line. The objective is not independence for its own sake. It is that the enterprise should know the price of its dependencies and choose them knowingly.

Transition planning during initial design

The feasibility of replacing a supplier is largely determined when the system is first designed and contracted. Choices about tooling, hosting, identities, data structures and documentation either preserve the option to transition or erode it. Exit planning that begins at termination inherits whatever those earlier choices left behind.

Supplier loss and key-person failure

Transition is not always planned. Suppliers are acquired, reprioritize, fail or lose the individuals who understood a system. Continuity planning therefore needs to consider unplanned loss as well as orderly exit, and to ask how quickly the enterprise could regain control if the supplier became unavailable.

Independent build, operation and recovery

The conditions discussed in earlier chapters converge here. Transferability requires that the enterprise or a successor can build the system from enterprise-held materials, operate it under enterprise-controlled arrangements and recover it from failure without the original supplier.

Intellectual property and licensing constraints

Rights that are sufficient for the enterprise to operate a system may not permit a successor provider to do so. Transferability depends on whether licences for background components, tools and third-party software extend to the parties who will need to use them after transition.

Human and machine identities

Access to modern systems runs through identities: administrative accounts, service accounts, keys, certificates and tokens. Where these are created and held by the supplier, transition requires that every one of them be discovered, transferred or replaced. Machine identities are easily overlooked because they are not attached to people.

Data migration and disposition

Transition also concerns data: its location, format, completeness and the means of extracting it. It concerns disposition as well, meaning confirmation that data held by the outgoing supplier is returned or deleted according to the enterprise's obligations.

Replacement-provider readiness and post-transition verification

A successor provider needs more than access. It needs the knowledge, materials and time to reach competence. Transition is complete only when the new arrangement has been shown to work, through verification that the successor can build, change, operate and recover the system as the original supplier did.

Residual obligations

Some obligations survive transition, including confidentiality, warranty, licence terms and support for a defined period. Identifying them in advance prevents the enterprise from discovering, after the fact, that it still depends on a relationship it believed had ended.

Exit plans and demonstrated transferability

A documented exit plan describes how transition is intended to happen. Independently demonstrated transferability shows that it can. The difference is the same as the difference between documentation and executable knowledge discussed in Chapter IV. Only the second gives the enterprise confidence that its continuity does not depend on a single supplier.

This research does not publish the transition test procedures or exit certification used by Built by Sentient in engagements.

01 — Technology ownership is a system property

Not merely a contractual designation.

02 — Architecture authority must remain institutionally accountable

Even when implementation is external.

03 — Governance requires evidence of actual technology behavior

Not only supplier declarations.

04 — Knowledge ownership must be demonstrated through execution

Not inferred from documentation.

05 — Supplier replaceability must be considered throughout the lifecycle

Not only at termination.

These are unresolved research and design questions, not established conclusions.

1. 01

   How much internal technical capability must an enterprise retain for different risk profiles?

2. 02

   Which vendor dependencies are economically rational to accept?

3. 03

   How should enterprises measure independently demonstrated technology control?

4. 04

   How can governance remain proportionate without creating excessive review bureaucracy?

5. 05

   How do AI-assisted engineering and proprietary agent platforms change technology ownership and transition risks?

6. 06

   Where should technical ownership obligations differ between custom software, SaaS and managed services?

A vendor may design the system.

A vendor may build it.

A vendor may operate it.

But the enterprise remains accountable for the technology on which its business depends.

The decisive test of technology ownership is not whether the enterprise possesses the contract, the repository or the documentation.

It is whether the enterprise retains sufficient rights, technical control and demonstrated competence to govern, recover, modify and transition the technology.

External delivery is a sourcing decision. Retained technology control is an enterprise responsibility.

1. 01

   The Open Group. The TOGAF Standard, 10th Edition.

2. 02

   ISACA. COBIT 2019 Framework: Governance and Management Objectives.

3. 03

   ISO/IEC/IEEE 42010:2022. Software, systems and enterprise — Architecture description.

4. 04

   National Institute of Standards and Technology. NIST SP 800-218, Secure Software Development Framework (SSDF).

5. 05

   Open Source Security Foundation. SLSA: Supply-chain Levels for Software Artifacts, specification.

6. 06

   The Linux Foundation. SPDX specification. OWASP Foundation. CycloneDX specification.

7. 07

   National Institute of Standards and Technology. NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

8. 08

   OWASP Foundation. Application Security Verification Standard (ASVS). OWASP Foundation. Software Assurance Maturity Model (SAMM).

9. 09

   Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.

10. 10

    ISO/IEC 20000-1. Information technology — Service management — Part 1: Service management system requirements.

11. 11

    U.S. Digital Service. Digital Services Playbook. UK Government. The Digital, Data and Technology Playbook.

12. 12

    ISO/IEC/IEEE 12207:2026. Systems and software engineering — Software life cycle processes.

13. 13

    ISO/IEC 27036. Cybersecurity — Supplier relationships.

14. 14

    FinOps Foundation. FinOps Framework.