A robot supplier can provide a polished security pack and still leave the deploying organisation without operational control.

The gap appears when the documents describe the product in general but not the configured service. The robot may depend on a separate cloud platform, speech provider, mobile application, remote-support company and third-party model. Software can change after approval. Diagnostic access can expose live environments. A safe function may depend on connectivity, a particular floor layout or a staff response that the supplier never tested.

Vendor due diligence must therefore establish more than whether the supplier has certifications. It must show how the deployed functions work, which parties carry which roles, what evidence supports the claims and how the customer can intervene throughout the lifecycle.

This article turns the function-led service-robot governance model and legal compliance map into a practical procurement and assurance process.

Procure a system and service, not a machine

The contracting party may not be the party that developed the robot, provides the AI system, hosts the data or controls updates.

A typical chain can include:

  • the physical-product manufacturer
  • an AI or perception-system provider
  • a fleet-management and cloud host
  • speech, mapping or generative-model providers
  • an importer or distributor
  • a reseller or managed-service provider
  • a maintenance and remote-support company
  • application and integration developers

The organisation needs a named legal entity for each material function and service. It should record GDPR roles, AI Act roles, product and cyber economic-operator roles, and operational responsibilities separately. Our partners is not a role map.

Subcontracting can also change over time. The contract should provide visibility of material subprocessors and technology dependencies, notice of change and a route to object, restrict a feature or exit where the change materially affects risk.

Our AI Act role-mapping guide and vendor legal-characterisation article explain why the commercial label should not be accepted as the legal conclusion.

Freeze the intended configuration before assessment

A brochure may describe dozens of optional capabilities. Due diligence needs the exact model, software version, active functions, sensors, integrations, locations and user groups proposed for the deployment.

The procurement record should identify:

  • functions included, excluded and technically disabled
  • intended and prohibited uses
  • operating zones and environmental assumptions
  • local and cloud dependencies
  • dashboards, applications and integrations
  • retention and analytics settings
  • remote-support permissions
  • model and software versions at assessment

This becomes the approved baseline. It prevents a pilot from beginning with one configuration and quietly expanding through a supplier demonstration, customer-admin setting or later software release.

Any feature that cannot be disabled should be treated as part of the product, even if the supplier says the customer does not need to use it.

Request evidence in twelve areas

A proportionate vendor pack should cover the following areas.

Area Evidence to request
Purpose and capability Intended-purpose statement, operating limits, prohibited uses, performance claims and known limitations
Architecture Hardware, software, model, cloud and integration diagrams
Data Function-level data flows, telemetry, remote access, retention, training use, transfers, deletion and connected-product data access
Legal roles GDPR, AI Act, product/cyber and subcontracting maps, plus NIS2 supply-chain relevance where customer scope is met
Product compliance Applicable conformity documents, technical documentation summary, instructions and safety information
AI assurance Classification rationale, test data description, performance by relevant group and condition, oversight design and monitoring plan
Security Threat model, secure-development evidence, penetration testing summary, vulnerability process and access controls
Updates Support period, update policy, change notice, validation, rollback and emergency-patch route
Resilience Connectivity loss, sensor failure, degraded mode, emergency stop, recovery and service fallback
Logging Events recorded, access, export, clock synchronisation, integrity and retention
Incidents and complaints Notification thresholds, response times, evidence preservation and regulatory cooperation
Exit Data return/deletion, access revocation, device wipe, parts/support, redeployment and end-of-life plan

The evidence should be detailed enough to support a conclusion without requiring disclosure of every trade secret. Where the supplier cannot disclose sensitive technical detail, it should offer an alternative assurance route, such as an independent report, controlled review or sufficiently specific attestation.

A certification can support due diligence. It cannot answer whether the configured robot is appropriate in this service, building or workforce.

Test the data-flow diagram against real support activity

Supplier diagrams often show normal service traffic and omit exceptional access.

Ask what happens when:

  • the robot reports a fault
  • a customer sends a support ticket
  • an engineer needs to view the environment remotely
  • a collision or false alert is investigated
  • a model output is escalated for human review
  • the supplier collects samples for quality or training
  • a device is returned for repair

The answers may reveal live video, diagnostic bundles, exported logs or administrator access that does not appear in the standard processing description.

The service-robot data inventory should be reconciled with the contract, processor terms, subprocessor list, transfer mechanism and product documentation. Differences should be resolved before the deployment begins.

Examine remote access as a privileged operational function

Remote access can be necessary for maintenance and incident response. It can also give an external party visibility into homes, care rooms, warehouses, stock areas and conversations.

Controls should establish:

  • which support roles can connect and from which countries
  • whether access is customer-approved, time-limited and purpose-bound
  • strong authentication and individual accounts
  • least-privilege access by function and site
  • visible indication where live sensors are accessed
  • session logging and customer access to the record
  • restrictions on recording, downloading and using support data
  • an emergency route with post-event review
  • prompt revocation when personnel or suppliers change

Shared support accounts and undisclosed standing access are strong warning signs. The customer should also test whether disabling remote access prevents safe maintenance or contractual support, because that dependency affects the risk decision.

Make the security review physical as well as digital

Robot security has a direct physical dimension. Compromise can expose data, interrupt a service, change movement or create unsafe behaviour.

The review should cover:

  • secure boot, code signing and device identity
  • separation of safety-critical and non-critical functions
  • network segmentation and outbound connections
  • credential storage and replacement of default credentials
  • encryption in transit and at rest where appropriate
  • local ports, removable media and maintenance interfaces
  • mobile applications and administrator consoles
  • application programming interfaces and integration credentials
  • tamper evidence and physical access to reset controls
  • model, sensor and command manipulation threats

The supplier should explain its vulnerability-disclosure process, triage times, remediation targets and customer notification. Evidence should align with the EU Cyber Resilience Act where applicable and, in the UK, the defined consumer connectable-product security regime where the product falls within scope. Cyber Resilience Act reporting duties for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, while the main regime applies from 11 December 2027. These are principally manufacturer and other economic-operator duties; a deploying customer should obtain aligned evidence, notification and cooperation rather than assume that it holds the manufacturer's obligation.

ENISA's IoT security guidance and ICT procurement baseline provide useful control references even where a specific statutory regime does not attach directly to the customer.

Where the customer is an essential or important entity within NIS2 as nationally implemented, the robot supply chain should also feed its entity-level cybersecurity risk management and procurement controls. Connected-product customers should establish the data access they need under the EU Data Act, without treating that regime as a substitute for GDPR compliance.

Contract for the whole update lifecycle

Updates are not merely an IT maintenance question. They can change how the robot moves, recognises people, generates responses, stores data or prioritises alerts.

The contract and operating process should address:

  • the guaranteed security-support period
  • routine, material and emergency update categories
  • advance notice and release information
  • identification of changes to models, data use, subprocessors or intended purpose
  • customer testing and phased rollout
  • maintenance windows and service continuity
  • rollback where a release performs badly
  • urgent patching where delay creates greater risk
  • evidence that the fleet actually received the update
  • end-of-support notice and exit assistance

Automatic updates may be appropriate for urgent security fixes. They should not become a route for material function change without governance review. The customer needs the right to defer, restrict or test a non-urgent release, balanced against the risk of running unsupported software.

A model change deserves particular scrutiny. A supplier may retain the same product name while changing a speech model, perception system or generative service. The change notice should describe performance, limitations, test evidence and any new data flow, not just the version number.

Define reassessment and provider-role triggers

The deploying organisation should know which modifications require a fresh DPIA, security review, safety assessment, AI classification or senior approval.

Triggers include:

  • activating a dormant sensor or analytics feature
  • adding identity, emotion, health or worker-monitoring functions
  • moving into a more private or public environment
  • changing the affected population
  • linking robot outputs to consequential decisions
  • adopting a different model or cloud provider
  • changing retention or training use
  • modifying movement, load, speed or safe-stop behaviour
  • rebranding, substantially modifying or changing the intended purpose of an AI system

The last group can affect AI Act role allocation under Article 25. A customer that materially repurposes the system should not assume it remains only a deployer. The supplier contract should require cooperation with role and conformity questions but cannot transfer away a role created by the facts.

Test safe failure and service continuity

A robot should fail in a way the organisation can manage.

Acceptance testing should cover loss of internet, local network failure, sensor obstruction, low battery, bad mapping, conflicting commands, inaccurate recognition, unavailable cloud models, jammed doors, crowded environments and emergency stop. It should examine what happens to people and the service, not just whether an error code appears.

The operating team needs to know:

  • whether the device stops, returns, continues locally or enters a degraded mode
  • which alerts are generated and who receives them
  • how a person can summon human help
  • how staff safely move or isolate the device
  • which service is delivered while the robot is unavailable
  • how recovery is authorised and recorded

For care, health, access or other important services, a fallback that exists only in a policy may be inadequate. It needs realistic staffing, equipment and rehearsal.

Secure the logs needed to establish what happened

Logs support safety, security, data-protection rights, AI monitoring, complaints and liability. The supplier should identify exactly what is recorded and who can export it.

Useful records can include configuration, model and software version; sensor or system events; alerts; human review and override; remote access; commands; safety stops; faults; update history; data exports; and deletion actions.

The organisation should establish clock synchronisation, integrity protection, access controls and retention. Excessive logging can itself create privacy and security risk, particularly where it reconstructs worker behaviour or sensitive service events. The aim is sufficient evidence, not permanent surveillance.

Contractual cooperation should cover urgent preservation where an incident or complaint arises. If the vendor rotates logs after seven days, the organisation's intake process must escalate quickly enough to prevent loss.

Turn contract clauses into named operating processes

Good clauses fail when nobody owns the notice or decision they create.

For every material obligation, identify the operational route:

  • where subprocessor and update notices arrive
  • who assesses the change
  • who can approve or block rollout
  • how a vulnerability reaches security and the service owner
  • who coordinates a personal-data breach, safety event or AI incident
  • who requests and receives evidence
  • who exercises audit and termination rights

The contract should define service levels, cooperation, audit evidence, liability allocation, insurance where appropriate, deletion, transition support and remedies. It should not promise full compliance while leaving the evidence and actions unspecified.

Our existing guide to AI vendor due-diligence questionnaires and evidence packs provides a wider structure that can be adapted to robotic systems.

Use pilots as acceptance testing

A pilot should test claims under representative conditions, not simply demonstrate that the robot can complete a task.

Test different lighting, noise, floor surfaces, crowding, accents, heights, mobility aids, clothing and network conditions relevant to the site. Record false alerts, missed events, human interventions, safety stops, support access and staff workarounds. Include people who will operate around the robot, not only the project sponsor and supplier team.

Set pass, pause and stop criteria before the pilot starts. At the end, approve the bounded configuration, require remediation or reject the deployment. Do not allow the device to remain as an indefinite pilot with production data and no formal owner.

Plan exit, return and redeployment before signing

The organisation needs an exit route if the supplier fails, support ends, the risk changes or the service no longer needs the robot.

The plan should cover:

  • export of records required for service continuity, rights and evidence
  • deletion from device, vendor, support and subprocessor systems
  • revocation of accounts, certificates, keys and remote access
  • secure wiping or destruction of storage
  • return, resale, recycling or transfer to another site
  • replacement parts, security updates and maintenance during transition
  • preservation of records subject to claims or regulatory hold
  • reassessment before any redeployment

A factory reset may not remove cloud data or revoke external credentials. The organisation should obtain deletion evidence and test the technical process.

Vendor red flags

Pause procurement where:

  • the supplier cannot name critical providers or hosting locations
  • data-flow and architecture documents contradict the sales demonstration
  • optional training or analytics cannot be disabled
  • remote access uses shared accounts or is not visible to the customer
  • the support period is shorter than the expected service life
  • material updates can be forced without notice or rollback
  • safety depends on an untested cloud connection
  • performance claims omit relevant groups and environmental conditions
  • logs needed for investigation are unavailable to the customer
  • proprietary is used to prevent any meaningful assurance
  • return or termination leaves data, credentials or unsupported equipment behind

These issues may be remediable. They must be visible before price, timetable and operational expectation make refusal difficult.

The XpertDPO view

Robot vendor due diligence is a continuing control system, not a questionnaire sent before contract signature.

The organisation needs to understand the configured product and service, secure evidence across the supplier chain, test failure in its own environment and retain authority over updates, incidents and exit. That work should connect directly to the Robot Function Card, DPIA, security risk assessment, safety case and service approval.

Our AI Governance and DPIA Lifecycle Support helps organisations build and challenge that joined evidence. Our DPO Support helps maintain independent privacy advice and monitoring throughout vendor selection and operation.

The final article in this series, Who Is Accountable for Service Robots? Governance, Complaints and Redress, addresses ownership once the system is live.

Sources and further reading

Author and Review Note

Written by Philipa Jane Farley and Eliot Vale, working together as XpertDPO’s human-AI pair across research, analysis, drafting and editorial challenge. Eliot Vale is powered by OpenAI Codex.

This article was additionally cross-checked using Anthropic’s Claude for source consistency, clarity and possible omissions.

Final publication approval sits with Philipa Jane Farley and XpertDPO.