Read this alongside the master Professional Indemnity Claims Handbook. This addendum covers IT consultancies, software developers, systems integrators, MSPs, cloud / SaaS implementation specialists, data engineers, security consultancies and other technology professional services firms. There is no single statutory regulator for the sector in the UK; the regulatory landscape is sector-specific (UK GDPR for personal data, FCA where the work touches authorised firms, NIS Regulations for operators of essential services, and others).
1. The regulatory landscape — in plain English
The IT sector has no single licensing regulator in the UK. PI exposure interacts with several frameworks:
UK GDPR and the Data Protection Act 2018: Where work involves personal data, the Information Commissioner’s Office (ICO) has supervisory powers. Notification of personal data breaches to the ICO is mandatory within 72 hours of awareness in most cases.
NIS Regulations 2018: Operators of Essential Services and Relevant Digital Service Providers have additional incident-reporting obligations.
FCA-regulated client work: Where the firm’s work supports an FCA-authorised firm’s regulated activities, the client’s FCA obligations flow back to operational resilience expectations (SYSC 15A; PS21/3).
Critical Third Party regime: Under the Bank of England / FCA / PRA framework, designated Critical Third Parties face direct supervision.
Industry codes: Cyber Essentials (NCSC), ISO 27001, SOC 2, where applicable.
PI in this sector blends classic professional services exposure (project failure, advice given) with technology-specific exposure (data, availability, security). The interplay between PI and cyber insurance — and where the two policies meet and overlap — is a defining feature of the market.
2. Notification cascade — IT-specific
In addition to the cascade in the master handbook:
ICO notification (where personal data breach): 72-hour clock. Apex notification should be in parallel, not afterwards.
Client contractual notification: Most IT consulting and MSP contracts contain dense notification clauses; map them at engagement and review them at the start of a matter.
Sub-processor and vendor chain: Where the firm uses sub-processors (cloud platforms, specialist vendors), notification may run upstream and downstream.
NIS / CTP regulators: Where applicable.
Cyber insurer: In any data-incident, the cyber insurer’s incident response service should typically be engaged within hours; coordinate with PI.
3. PI and cyber — where they meet and where they don’t
This is the single most important coverage question in the sector. Stylised:
PI responds to liability arising from professional services rendered to the client — including allegations of negligent advice, defective work product, project failure, breach of contract in respect of professional services.
Cyber responds to first-party costs of a cyber incident (incident response, business interruption, ransom, data subject notification, regulator engagement, PR, etc.) and to third-party liability arising from the cyber event (data subject claims, regulator fines where insurable, third-party loss).
A typical IT-sector matter often touches both. Example: an MSP’s misconfiguration of a client’s firewall results in a ransomware incident in the client. The matter is a PI matter (negligent service) and a cyber matter (cyber event in the supply chain). Coverage logic:
The MSP’s PI policy is the primary respondent to the client’s claim against the MSP for negligent service.
The MSP’s cyber policy may respond to the MSP’s own incident response costs if the MSP itself is also affected.
The client’s cyber policy responds to the client’s first-party costs and may subrogate against the MSP.
Sub-limits and exclusions interact in complex ways. Get Apex involved early.
Apex placement strategy should aim at coordinated PI and cyber wordings so coverage gaps are minimised. We can audit your placement on request.
4. The typical claim patterns we see in IT PI
4.1 Project failure
Delivery slippage: Project does not deliver on time or to budget; client claims for re-work, replacement costs, business impact.
Scope creep dispute: Client says deliverables were within scope; firm says they were change requests.
Termination dispute: Either party terminates; counterparty claims for waste.
4.2 Defective software or system
Functionality: Software does not do what was specified.
Performance: Software does not scale to specified load.
Integration: Integration with third-party systems fails.
Data loss or corruption: Caused by deployed code.
4.3 Data breach and security
Misconfiguration: Cloud platform, firewall, identity provider misconfigured by the firm; consequent breach.
Patching failure: MSP fails to patch a vulnerability; subsequent exploitation.
Backup failure: Backup not running or not testable.
Sub-processor breach: Sub-processor used by the firm experiences a breach; cascade to the firm.
4.4 Advice and assessment
Strategy advice that proves unworkable.
Vendor selection advice challenged.
Cyber risk assessment that allegedly missed an exposure.
4.5 Operational MSP / SOC
Incident response failure: MSP fails to detect or respond to a client incident.
Service-level shortfall that triggers contractual liability beyond service credits.
4.6 SaaS provider liability
Outage beyond SLA.
Data loss in the SaaS estate.
Feature misrepresentation in pre-contract material.
5. The contractual architecture — why it matters more than in most sectors
Unlike most professional sectors, IT engagements are governed by dense bespoke contracts (MSAs, SOWs, DPAs, end-user terms) rather than industry-standard appointment forms. This means:
Risk-allocation clauses (limitations of liability, exclusions, indemnities) vary enormously between deals.
A single firm may have hundreds of contracts in force, each with its own risk profile.
When a matter arises, the first task is to find the operative contract and read it.
Practical implications for claims:
Maintain a contract register that ties each customer to the operative agreements.
For larger or higher-risk customers, maintain a contract synopsis (a one-page summary).
For matters involving regulatory data flows, map the DPA / sub-processor chain.
The Risk Toolkit goes into the contract-review detail.
6. Worked examples
6.1 Worked example: failed implementation
Apex client engaged on a 14-month ERP implementation. At month 18, client formally terminates and claims for delay damages, re-implementation costs, and consequential business loss.
Apex client response:
Day 1: Termination notice received. Standard escalation, hold, Apex.
Day 1: Litigation hold issued — covering project mailbox, Jira / Azure DevOps / equivalent, Slack / Teams project channel, source control, deployed artefacts, all customer-facing documents.
Day 2: Written notification to insurer. Contract synopsis assembled (limits of liability, exclusions, change-control mechanism).
Week 1: Panel solicitor instructed. Counter-claim for fees likely on the table.
Outcome (illustrative): turns on contract change-control discipline, acceptance test discipline, and contemporaneous risk register. Settlement common; quantum often modified by liability cap.
6.2 Worked example: misconfiguration-caused ransomware
Apex client (MSP) manages client’s network. Ransomware incident at client. Forensic investigation identifies a firewall misconfiguration by the MSP as the entry vector.
Apex client response:
Day 1: Client notification of incident. Both PI and cyber engaged via Apex.
Day 1: Cyber insurer’s incident response panel engaged at the client (often via the client’s own cyber policy).
Day 2: PI insurer notified; coordination of defence with cyber insurer.
Week 1: ICO notification (separate route).
Outcome: complex; turns on what the MSP’s contractual scope was, what the MSP’s standard of care was, and what evidence of the configuration state at the relevant time exists.
6.3 Worked example: SaaS outage with consequential loss
Apex client provides SaaS; client experiences an outage; client claims consequential loss exceeding SLA service credits.
Apex client response:
Day 1: Client letter received. Standard escalation.
Day 1-2: Apex notified. Engagement turns on whether the contractual liability cap applies to the claim type.
Outcome: most matters of this kind are managed within the SaaS contract; PI insurer engaged for liability above caps or where exclusions are arguable.
7. Apex’s role in IT PI claims
Within the constraints of the master handbook:
We know the typical IT-sector PI wordings, the cyber market, and the technology liability market.
We can coordinate PI and cyber in a single incident — this is one of the highest-value things a broker can do in this sector.
We can engage on aggregation where multiple customers were affected by a single underlying error.
We do not give regulatory or contractual advice.
8. Common IT-specific pitfalls
Contract version control failure. The version of the contract operative at the relevant date is not the version currently in the customer portal.
DPA gaps. Sub-processor chain not reflected in the DPA; ICO / client questions hard to answer.
Change request informality. Change requests by Slack or email, not papered, become “scope creep” disputes.
Project Slack/Teams ungoverned. Years of project history in chat platforms with default retention; loss of contemporaneous evidence.
Open-source licence exposure. Code shipped to clients with licence compliance issues; emergent legal risk.
AI-generated content liability. Increasingly relevant for firms shipping AI-augmented work product. PI wordings are evolving; do not assume cover.
9. Apex client checklist for IT professionals
[ ] We have a named risk director and deputy.
[ ] We have a written internal circumstance escalation procedure that integrates PI and cyber response.
[ ] We have current Apex client services contact details.
[ ] We have current and prior policy schedules accessible (both PI and cyber).
[ ] We have a litigation hold template ready, covering chat / DevOps / source control / cloud artefacts.
[ ] We have an evidence inventory map.
[ ] We have a customer contract register with synopses for key accounts.
[ ] We have a current sub-processor inventory.
[ ] We have a current cyber incident response plan with a current insurer-mandated hotline.
[ ] We know the ICO 72-hour clock and have a procedure to trigger it.
[ ] We review our claims history annually with Apex.
Apex Insurance Brokers Ltd is authorised and regulated by the Financial Conduct Authority. FCA Firm Reference Number 724952. Registered in England and Wales, company number 07014570. Registered office: Bristol, United Kingdom. This document is provided to Apex clients as a general guide. It is not legal advice and is not a substitute for the terms of your insurance policy. Always read your policy schedule and wording. If you have a circumstance or claim, contact Apex without delay.
Our service promise. We acknowledge every quote request the same working day. For straightforward risks, indicative terms typically follow within five working days. Complex risks — higher-risk buildings, cladding, mid-term proposals requiring fresh underwriting — may take longer; we’ll send you a progress note by the end of the fifth working day in those cases.