Technology Partner Due Diligence: A Practical Checklist

A material technology partnership can give another organisation access to your customers, systems, intellectual property and daily operations. Before committing, establish what you will depend on, what could fail, and which evidence would make that dependency acceptable.

Technology partner due diligence should end with a documented decision about a defined scope of work. Scale the investigation to the partner’s access, your dependence on it, the sensitivity of the information involved and the impact of failure. Check important claims through documents, demonstrations and independent verification, then record unresolved risks and who owns them.

This operational checklist is for UK founders, business leaders and procurement teams. It is not legal, financial, security or compliance advice. Material commitments need appropriate legal, procurement, finance, privacy and technical review; regulated or high-assurance services may require additional specialist checks.

Set the scope before requesting evidence

Start with a one-page description of the proposed relationship. State the legal entities, service, users, systems, information, delivery stages and expected duration. Identify what the partner can change, what it can access and what would stop working if it disappeared tomorrow.

If the sourcing decision is still open, first use the build, buy or partner framework. Due diligence becomes more useful once the proposed dependency is clear.

Use four questions to set its depth:

Treat the highest material exposure as a reason for deeper review; an average score can hide a serious weakness. A design workshop using synthetic information may need basic identity, capability and confidentiality checks. A partner operating a customer platform needs substantially more scrutiny, even if its first invoice is small.

This approach reflects the NCSC’s guidance on proportionate supplier security requirements. The evidence thresholds below are a practical starting framework to adapt, not an official certification scheme.

Assign a buyer-side owner for each review area and agree the criteria before requesting material. Stage requests so suppliers disclose sensitive documents only when necessary, through controlled access or appropriately redacted evidence.

Establish identity and commercial resilience

Confirm the contracting entity’s exact name, registration number where applicable, address and authority to enter the agreement. Check that proposals, contracts and invoices identify the intended entity; explain any parent-company, trading-name or overseas-entity differences.

For a UK company, review the register, filing history, accounts and relevant notices. Companies House explains that it checks filings for completeness and validity, but makes only basic checks on accounts. Registration and identity evidence do not establish current solvency, delivery capacity or financial resilience.

Ask your finance reviewer which additional evidence is proportionate: recent management information, funding assumptions, customer concentration or the resources available to support your contract. Establish the period each document covers. Historical accounts cannot answer every question about the supplier’s present position. Avoid universal turnover ratios or a blanket rule that young companies are unsuitable.

Where insurance matters, have an appropriate adviser assess the actual policy or broker confirmation: insured entity, activities, limits, exclusions, excess, expiry and notification conditions. A certificate or large headline limit does not establish that a particular loss will be covered. Insurance also does not keep a service running.

Use reference conversations to investigate comparable delivery and support commitments. Ask what happened when priorities changed, an incident occurred or knowledge had to transfer. Record the limits of each reference: a successful short project says little about years of production support.

Verify the team and delivery commitments

Identify who will perform the work, their roles, availability, location, supervision and replacement arrangements. Distinguish the people in the sales meeting from the proposed delivery team. Ask who can approve architectural decisions, releases, scope changes and emergency actions.

Request a capacity plan tied to your milestones and support hours. For important roles, agree what happens during leave, departure or simultaneous incidents. A named substitute needs access, knowledge and allocated time to provide meaningful cover.

Map subcontractors by activity and access. Establish which appointments need approval, how changes are disclosed and who remains accountable for their output. A delivery subcontractor and a personal-data subprocessor are related but different review categories; assess each role explicitly.

Walk through a recent, shareable delivery example: requirement, acceptance criteria, review, test evidence, release decision and follow-up. Redacted records or a demonstration can protect other customers’ information while revealing whether the process works.

The broader guide to choosing a software development partner helps assess fit. Here, the task is to verify the commitments your proposed engagement will depend on.

Inspect technical quality and access in practice

Give a technical reviewer a bounded question: can this team maintain, release and recover the service you are buying under the proposed operating arrangements?

Request an architecture view showing components, integrations, data stores and responsibility boundaries. Inspect a sample change from code review through automated checks to release approval. Ask how dependencies, security findings and unsupported components are tracked, prioritised and resolved.

For access, request a demonstration of the proposed account model: named identities, appropriate authentication, least necessary privileges, logging and prompt removal when someone leaves. Check who controls privileged access to cloud accounts, repositories, deployment pipelines and signing credentials. Review separation between development, testing and production, including how test data is obtained.

For critical services, examine recent security assessment findings and evidence of remediation appropriate to the risk. Check a certificate’s issuer, scope, covered services and validity; decide what additional product-specific evidence is required. A completed questionnaire should point to evidence that a reviewer can examine.

Agree relevant release, monitoring and recovery requirements before delivery begins. Ask the team to demonstrate a restore or recovery exercise against agreed tolerances. Confirm what data, dependencies and manual steps it includes. The secure mobile app development guide provides further engineering questions where mobile delivery is involved.

Define tolerable service interruption and data loss with the operational owner, then ask for measured results against those limits. Distinguish a discussion of the recovery plan from a successful technical exercise. For each proposed recovery method, request an explanation of how it treats later records, dependent services and external transactions. Test the proposed handling of those cases instead of accepting a general promise to restore a backup or revert a release. Ask which actions are irreversible, who can authorise recovery and when the buyer would receive an accurate status update.

Trace personal data, hosting and incident handling

Create a data-flow map covering collection, storage, support access, backups, logs, analytics and deletion. Identify the organisations involved and assess their role for each activity with your privacy reviewer. Require explanations for discrepancies between the map, the contract and the supplier’s answers.

For controller–processor arrangements, the ICO’s contract guidance covers processing details, instructions, confidentiality, security, assistance, audit and end-of-contract provisions. It also addresses written authorisation for subprocessors and an opportunity to object to changes under general authorisation. Have the relevant agreement assessed against the actual service.

Request a current subprocessor list with function, legal entity, location, information accessed and change process. Include support providers and tools introduced by delivery teams where they process relevant personal data. Resolve undisclosed dependencies before granting the affected access.

A UK hosting location alone does not settle international-transfer questions. The ICO’s January 2026 transfer guide includes making personal information accessible to a separate organisation overseas. Map those arrangements and have the applicable transfer requirements assessed; avoid assuming every overseas connection has identical legal treatment.

Test an incident scenario with named contacts, escalation routes, containment responsibilities and an update schedule. Distinguish acknowledgement from investigation and restoration. ICO processor guidance requires notification of a personal data breach to the relevant controller without undue delay. Agree operational timings and information requirements that support your obligations, including communication while facts remain incomplete.

The ICO’s contracts and processor guidance remained marked for review following the Data (Use and Access) Act when checked. Confirm current requirements and their application before signing; this checklist cannot establish compliance.

Prove ownership, continuity and exit readiness

Separate ownership of commissioned work from licences to background technology, open-source components and third-party services. Identify what rights your business needs to use, modify, maintain and transfer the deliverables.

The Intellectual Property Office explains that commissioning copyright work does not automatically make the commissioner its first owner. Have the agreement and chain of rights reviewed, including contributions from freelancers and subcontractors. Repository access is useful operational evidence; it does not itself establish intellectual-property ownership.

For custom development, agree where repositories, infrastructure configuration, build instructions and operational documentation will live, and when your organisation obtains access. For a hosted product, source access may be unavailable or unnecessary: concentrate on usable exports, integration information, service continuity and the practical switching path.

Ask another suitably authorised person to follow the handover instructions. Can they obtain the agreed artefacts, build or deploy where relevant, restore required data and understand outstanding issues without the departing specialist translating every step?

Test a representative export in a safe environment. Check relationships, attachments, identifiers and required history, then establish whether a receiving system can use it. An export button alone cannot prove portability.

Agree termination assistance, notice periods, transition responsibilities, charges, access revocation and treatment of retained copies. Document dependencies that cannot transfer and what replaces them. If escrow is proposed, review release conditions, update arrangements and whether the deposited material can actually support recovery. An inaccessible or unusable deposit offers little operational reassurance.

Use an evidence acceptance checklist

The following examples make requests reviewable. Set the actual tolerances before assessment, proportionate to the service. Acceptance should identify evidence, a qualified reviewer and any restrictions on the scope being authorised.

Record both the document’s date and its relevance to the proposed scope. A recent report for a different service may be less useful than older evidence with a verified, relevant update.

For a material engagement, bring the commercial, technical and privacy reviewers together for one evidence walkthrough. Follow a representative service request across the architecture, support process and subcontractor map. Conflicting answers often reveal an assumption that separate questionnaires leave unresolved. Compare the resulting commitments with the proposed contract, including support hours, exclusions, acceptance, change control and transition charges. Record any mismatch for the relevant specialist to resolve before signature.

Record the decision and keep it current

Use a decision record containing the scope and dependency assessment, evidence references, reviewers, findings, unresolved risks, conditions, owners, deadlines and reassessment triggers. Name the person authorised to accept residual risk. A condition should specify what must happen and what remains prohibited until it does.

Choose one of four outcomes:

• Proceed: evidence meets the agreed criteria for the defined scope.
• Proceed with conditions: bounded activity is acceptable, with explicit restrictions and a tracked remedy.
• Defer: a material gap needs evidence or correction before commitment or access.
• Decline: the proposed relationship exceeds risk limits or essential evidence cannot be established.

For example, imagine a supplier for a business-critical booking service has convincing demonstrations but cannot identify a support subprocessor or produce a usable export. This is a hypothetical situation, not a client result. A buyer might permit a synthetic-data evaluation while deferring production access until those gaps are resolved. Attractive demonstrations do not close either finding.

Escalate inconsistent entity information, unexplained subcontracting, missing rights, untested recovery promises or refusal to provide proportionate evidence. A confidentiality restriction can justify an alternative assurance method; it should not silently turn an unanswered question into acceptance.

Set ongoing reviews according to dependency and change. Reassess after material service changes, new access, subcontractor changes, serious incidents, ownership changes or deteriorating delivery. Track agreed remedies and sample whether important controls still operate. Suppliers preparing their side of this process can use the enterprise partnership readiness guide.

Make the commitment you can support with evidence

Start with the dependency, define acceptable evidence and verify the claims that matter most. A useful review leaves your team able to explain what it approved, what remains uncertain and how it will respond if circumstances change.

To discuss the delivery and operating assumptions behind a material partnership, review a critical technology partnership before commitment with FlutterCraft.

Evidence checked: 30 October 2026. Next review due: 28 January 2027, or sooner if relevant guidance or the proposed arrangement changes.