Insurance for IT Contractors

IT contractors can cause or suffer loss through software errors, failed migrations, security weaknesses, accidental deletion, service interruption, damaged hardware, missed deadlines and access to client systems. The relevant insurance is determined by the assignment and responsibility accepted, not simply by whether the contractor calls the work development, support, consulting or engineering.

This guide covers UK independent IT consultants, developers, infrastructure specialists, cloud contractors, support providers, data professionals and small technology service businesses. It does not replace contract, cyber-security or regulated advice.

Quick answer

An IT contractor commonly reviews:

professional indemnity insurance for errors, omissions and alleged failure of technology services;
cyber insurance for incident response, restoration, interruption, privacy and security liability;
public liability insurance for work at client premises and hardware installation;
employers’ liability insurance if people work for the business;
portable equipment cover for laptops, test devices and specialist tools;
contractual liability, intellectual-property and dishonesty provisions;
business interruption and supplier-dependency arrangements.

Start with the Business Insurance by Industry guide and describe the technical work precisely.

Map the actual technology services

List each activity separately, for example:

software design and development;
coding, testing and quality assurance;
cloud architecture or migration;
network configuration;
managed support and monitoring;
cybersecurity assessment;
data engineering and analytics;
database administration;
hardware supply or installation;
project management;
user training;
hosting or software-as-a-service;
access to live production systems.

These activities can create different underwriting questions. A contractor who recommends a platform has a different exposure from one who hosts it, processes customer data, controls privileged accounts or guarantees uptime.

Professional indemnity for technology work

Professional indemnity insurance may respond to allegations that professional services caused financial loss. Examples include defective code, incorrect configuration, failed data migration, inadequate testing, negligent advice or project-management errors. The What Professional Indemnity Insurance Covers guide explains the general cover boundary.

Technology wordings may differ materially. Check:

whether software development and implementation are included;
whether the policy covers negligence only or broader civil liability;
contractual liability and performance warranties;
delay and failure to meet service levels;
intellectual-property infringement;
loss or corruption of client data;
cyber events and security liability;
product liability where hardware or packaged software is supplied;
work for financial services, healthcare, critical infrastructure or other restricted sectors;
North American or worldwide jurisdiction;
defence costs, excess and aggregate limits.

A technology-specific wording may combine professional and cyber liability, but the schedule and endorsements must confirm the sections purchased.

Cyber risk and incident response

IT contractors often hold credentials, configuration information, source code and personal data or have pathways into client environments. The ICO requires appropriate security for personal data, and the NCSC recommends practical controls for smaller organisations. Insurance can support an incident, but security must be built into operations.

Review:

multi-factor authentication for remote and privileged access;
separate administrator accounts;
secure development and code-review practices;
vulnerability and patch management;
logging and monitoring;
tested, segregated backups;
encryption and secure transfer;
secrets and credential management;
access revocation at the end of an assignment;
supplier and open-source dependency management;
incident response and client escalation.

The Cyber Insurance guide explains first-party loss, incident services and third-party liability. Check whether social engineering, funds transfer, ransomware, dependent-system failure and voluntary shutdown are covered or restricted.

Contracts, statements of work and service levels

Technology disputes often turn on scope, acceptance and change control. Keep a signed agreement and statement of work defining:

deliverables and exclusions;
client responsibilities and dependencies;
assumptions about data, access and existing systems;
testing and acceptance criteria;
change requests;
service levels and remedies;
security roles;
data-controller and processor responsibilities;
intellectual-property ownership and licences;
liability cap and excluded loss;
notification and cooperation after an incident.

An insurance policy may not cover an absolute uptime promise, service credit, liquidated damages or liability accepted beyond the common law. Check significant contract amendments before signing them.

Intellectual property and open-source software

Code, documentation, designs, brands and data can involve copyright, trade marks, licences and confidential information. UK government guidance recognises copyright and other forms of intellectual property, and ownership may depend on employment or contract terms.

For each assignment, record:

who owns newly created code and documentation;
which pre-existing tools remain the contractor’s property;
licences granted to the client;
third-party and open-source components;
licence obligations and attribution;
rights to reuse generic methods;
warranties about infringement.

Professional indemnity policies often restrict or sub-limit intellectual-property claims. Do not assume a broad contractual warranty is insured.

Public liability and equipment

Public liability can be relevant when working at client sites, installing hardware, using cables or tools, or handling client property. The Public Liability Insurance guide explains injury and property-damage cover.

Portable equipment cover should reflect where laptops and devices are used and stored. Check unattended-vehicle exclusions, theft conditions, worldwide cover, accidental damage, single-item limits and whether client-owned equipment in the contractor’s custody is included.

Employees, associates and subcontractors

A contractor using employees or workers should check the Employers’ Liability Insurance guide. Do not infer insurance status solely from the tax label applied to an associate.

Where development or support is subcontracted, establish:

permitted subcontracting under the client contract;
security and access standards;
confidentiality and data-processing terms;
ownership of work product;
the subcontractor’s professional and cyber insurance;
incident-notification deadlines;
responsibility for corrections and claims cooperation.

The main contractor may remain liable to the client for outsourced work.

Business interruption and dependencies

An IT contractor may depend on cloud hosting, repositories, development tools, telecommunications, payment platforms and one or two key people. Standard property interruption may not respond to a cloud outage or cyber incident.

Identify:

maximum tolerable downtime;
alternative devices and connectivity;
backup and recovery time objectives;
dependency on a single platform or account;
access to source code and configuration backups;
substitute personnel and documentation;
contractual service obligations during an outage.

Compare these needs with any cyber interruption, equipment, key-person or additional-expense cover.

Choosing limits and excesses

Consider the largest client system or project affected, the number of customers who could be impacted by one error, data-breach response costs, defence expenses, contractual caps and the cost of restoration or re-performance.

A small contract fee does not necessarily cap loss. A configuration error can affect a larger operation, while one reused software component can create correlated claims. Check whether the limit is each claim or aggregate and whether defence costs reduce it.

Cost and underwriting information

Underwriters may ask about turnover, service mix, client sectors, contract values, outsourced work, claims, security controls, data volumes, hosting, territories, backups and incident response. The Business Insurance Costs guide explains how these factors can influence quotations.

Answer proposal questions accurately. If a control such as multi-factor authentication or offline backup is declared, verify that it is implemented for the systems within scope.

Claims and notification

Potential circumstances include discovery of a serious software defect, accidental deletion, unauthorised access, a failed migration, a client allegation, a threatened withholding of fees or evidence that a reused component infringes rights.

Follow both the incident plan and policy notification terms. Preserve logs, tickets, versions, approvals, test results, backups and communications. Avoid altering evidence or accepting liability before obtaining appropriate advice. The Cyber Insurance Claim Scenarios guide provides examples of how technology incidents can involve several policy sections.

Review triggers

Review cover when the contractor:

moves from advice to hosting or managed services;
gains privileged access to client systems;
processes more sensitive personal data;
supplies hardware or packaged software;
takes on larger clients or service-level commitments;
begins work in a new territory or restricted sector;
employs staff or outsources development;
introduces artificial-intelligence tools or new dependencies;
becomes aware of a defect, breach or complaint.

Use the Business Insurance Review Checklist to document the change.

Next step

Create a service-and-access map showing what the contractor builds, hosts, administers, stores and guarantees. Compare it with the policy business description, cyber controls, contract promises and limits before accepting the next assignment.

Distinguish a service from a product

Technology businesses can move from bespoke services into reusable software, subscription platforms, hosted tools or hardware supply. That shift can change professional, product, cyber and contractual exposure.

Record whether the contractor:

licences software to several customers;
hosts or controls the production environment;
provides updates and security patches;
processes data on the customer’s behalf;
supplies devices or embedded components;
offers warranties about compatibility or performance;
depends on open-source or third-party services;
continues support after the original project.

A policy arranged for consultancy may not automatically cover a software product or hosted service. Notify the insurer before the operating model changes.

Artificial intelligence and automated tools

Use of generative or automated tools can create issues involving confidentiality, data protection, intellectual property, accuracy, bias and contractual restrictions. The insurance question is secondary to governance: the contractor should know what information enters the tool, how outputs are reviewed and whether the client permits its use.

Document:

approved tools and accounts;
prohibited data types;
human review and testing;
source and licence checks;
security configuration;
customer disclosure where required;
responsibility for errors;
retention of prompts, code and decisions where proportionate.

Do not represent automated output as independently verified. Tell the insurer about material changes in service delivery where they affect the declared risk.

Data-controller and processor roles

An IT contractor may act as a processor for a client, a controller for its own business data, or both. Contracts should identify the role for each processing activity and set security, assistance, deletion, audit and incident obligations.

The existence of a processor contract does not transfer all responsibility to the client. The contractor should understand the systems, data and sub-processors it uses and maintain appropriate security. Where a breach occurs, contractual notification deadlines can be shorter than statutory reporting periods.

Operational resilience and service recovery

Technology contracts may require recovery objectives, support hours and escalation paths. Before agreeing them, confirm that the people, tooling and suppliers can deliver them.

Test:

restoration from backups;
recovery of infrastructure configuration;
access if the main identity provider fails;
handover to another engineer;
response outside normal hours;
communication with affected clients;
availability of incident specialists under the cyber policy.

A policy may pay defined interruption or response costs but cannot guarantee that a system can be restored within a promised time.

Scenario prompts

A deployment corrupts customer data

Preserve logs and backups, stop further damage, follow the client’s incident process and notify insurers as required. Professional, cyber and data obligations may overlap. Do not assume that re-performance costs are automatically insured.

Credentials are stolen and used against a client

This can involve incident response, privacy, security liability and contractual claims. Check access records, notify the client promptly under the contract and use the approved forensic route where the policy requires consent.

A third-party library causes a widespread vulnerability

Identify affected customers, available patches, licence terms and notification duties. One dependency can create correlated claims, so aggregate limits and related-claims wording matter.

A client alleges the project missed a service level

Review the contract, change records, dependencies and acceptance evidence. Service credits or liquidated damages may not be insured even where a negligence claim is.

Questions for the policy comparison

Ask whether:

cyber and professional claims share one aggregate limit;
data restoration and re-performance are covered;
the policy includes subcontractors and offshore development;
intellectual-property allegations are included;
social engineering and funds transfer need separate selection;
voluntary shutdown is covered;
cloud and telecommunications failures are included;
prior acts and retroactive dates align with historic work;
incident vendors must be selected from a panel;
security-control statements are conditions of cover.

The answers should be recorded with the Understanding Business Insurance Documents guide materials.

Security promises and proposal answers

Technology contracts and insurance proposals can both contain detailed security statements. Review them together. A contractor should not promise continuous monitoring, encryption of all data or testing at a particular frequency unless the process exists across the systems in scope.

Maintain evidence for material controls, such as:

multi-factor-authentication configuration;
backup schedules and restoration tests;
vulnerability scans and remediation;
access reviews;
secure-development checks;
incident exercises;
supplier assessments;
staff or subcontractor security training.

If a control changes or cannot be maintained, assess whether the client and insurer need to be told. A cyber policy may contain conditions or exclusions tied to declared controls.

End-of-contract and run-off considerations

Liability can continue after an assignment ends. Close projects carefully by confirming acceptance, outstanding defects, access removal, data return or deletion, licences, support responsibilities and record retention.

Professional indemnity is claims-made, so a contractor leaving the industry or closing a company should consider historic work and run-off. Retain the contracts, policy schedules, code versions, test evidence and notifications needed to respond to a later allegation.

Where a hosted service continues after development stops, separate the continuing operational exposure from historic professional work. The business may need ongoing cyber, technology liability and service arrangements rather than only run-off PII.

Keep technical and insurance records aligned

The service catalogue, data-flow map, supplier list, security controls and incident plan should tell the same story as the insurance proposal. Review them together after material platform, client or staffing changes. This reduces the risk that an accurate technical change becomes an undisclosed insurance change.

Where a policy or contract uses technical definitions, confirm that they match the service architecture. Terms such as system, network, hosted service, data and security event may be narrower than everyday usage, and that difference can affect notification and cover.