If you sell security, whether that's penetration testing, a managed SOC, incident response, a security SaaS product, or vCISO and GRC consulting, your insurance problem is different from that of the companies you protect. A customer's claim against you won't usually be "we were hacked". It will be "we were hacked, and you were meant to stop it, find it, or tell us about it". That is a professional liability claim, first and foremost. Your own cyber policy matters too, but it isn't the main event.

This guide is for UK cybersecurity startups and small security firms (limited companies, partnerships, and sole-trader testers) that need to know which policies a security vendor actually needs, how client contracts change the picture, and what underwriters will ask. If you're a normal business trying to buy protection for your own systems, read Cyber Insurance UK instead. If you're a general startup deciding when cyber cover becomes worth it, read When UK Startups Need Cyber Insurance. This page is about the business of selling security.

Mesh'd Limited trading as Meshed is authorised and regulated by the Financial Conduct Authority under firm reference number 1033248. We place cover from the insurers on our panel and charge a flat 10% broker fee, with no admin add-ons. We don't publish "from £X" prices, because security vendors are priced on what you do, who you do it for, and what your contracts say. Named customer quotes are off.

The short answer

Most UK security vendors need a programme built around technology professional indemnity (tech E&O), with cyber for their own systems and for the access they hold to client systems. Public liability and employers' liability come next (EL is a legal requirement once you employ people). Directors' and officers' (D&O) cover becomes important once you raise money or take on a board.

The parts that make a security vendor different:

• Your service is the control. If a breach gets past your tooling, monitoring or test, the client's loss can be framed as your failure. Tech PI is what responds to that allegation.

• You're authorised to do things that are otherwise crimes. Testing someone's systems without proper authorisation can be an offence under the Computer Misuse Act 1990. Your scope letters and rules of engagement are part of your insurance position.

• You hold the keys. Privileged credentials, agents running on client endpoints, remote access tools, and log data make you an attractive route into your clients. Underwriters know this.

• Contracts are tough. Enterprise and public-sector buyers push uncapped indemnities, high insurance minimums, and broad warranties onto security suppliers. What you sign decides what your insurance has to do.

Which kind of security business are you?

Underwriters don't price "cybersecurity" as one thing. The first question is what you actually deliver, because each model fails in a different way.

Many startups straddle two or three rows: a consultancy that launches a product, or an MSSP that also sells pen tests. Tell the underwriter about all of it. A policy written for "IT consultancy" may not respond to a claim that comes from a managed service you never declared.

Why your own cyber policy isn't the main event

Founders in security often assume they need "cyber insurance, but more". A cyber policy is mostly first-party: it pays your incident response costs, data restoration, business interruption, extortion handling, and notification costs when your systems are hit. Most cyber policies also include some third-party privacy and network security liability.

What a cyber policy is not designed for is the allegation that your professional service failed. If a SOC client says your analysts missed the alerts that would have stopped a ransomware attack, the client's losses are the client's cyber incident, not yours. Your exposure is a negligence or breach-of-contract claim about how you did your job. That's tech PI territory.

In practice the two policies overlap and the gaps sit in the overlap:

• A breach of your own environment that spreads to clients (for example, an attacker uses your remote management tool to reach customer networks) can trigger your cyber policy for your own response costs and your tech PI or cyber liability section for the client claims. You want both placed so they don't each point at the other.

• A faulty product update that takes customer systems offline may not be a "cyber event" at all. It's a failure of your technology product. Check that your tech PI covers product failure, not just "professional advice".

• A tester's mistake that knocks over production is usually a professional error claim, not a cyber incident.

The cleanest setup for most security vendors is a combined tech PI and cyber policy from one insurer, or two policies that have been checked against each other. For the basics of each class, see Professional Indemnity Insurance UK and Cyber Insurance UK.

Six claim scenarios security vendors should plan for

These are illustrative, not real claims, but they're the shapes underwriters ask about.

1. The missed finding. You test a client's external estate. Three months later an attacker gets in through a vulnerability the client says was in scope and should have been found. The client claims its incident costs and lost revenue from you. The questions will be what the scope said, what your report said, and whether your method met a reasonable standard.

2. The late escalation. Your SOC sees suspicious activity overnight but the escalation goes to an out-of-date contact. By morning the client's file servers are encrypted. The client points to the SLA. This is why your SLA wording and your contact-verification process matter as much as your limit.

3. The test that took production down. A load test or an aggressive scan crashes a payment system for an afternoon. Nobody was hacked, but the client has a clear financial loss and a contract that says you'll avoid disruption.

4. Outside the scope. A tester pivots to a system the client didn't own, such as a third-party host or a supplier's environment. The third party complains, and there's a question of whether access was authorised. This can become a criminal issue as well as a civil one. Insurance won't fix a criminal problem, which is why the authorisation section below matters.

5. Your product is the breach. A vulnerability in your agent or your SaaS platform is exploited, and attackers use your access to reach customers. You face your own incident costs, notification issues as a processor, and claims from many customers at once. This is the scenario that needs the most limit, and the one where aggregate limits get tested.

6. The advice that didn't hold. Your vCISO service tells a client its controls are ready for a certification audit or a client security review. It fails, and the client loses a contract it says it would have won. Pure financial loss from advice is a classic PI claim.

The authorisation problem: Computer Misuse Act 1990

Offensive security work only exists because a client authorises it. Under section 1 of the Computer Misuse Act 1990, a person commits an offence if they cause a computer to perform any function with intent to secure access to any program or data held in any computer, where that access is unauthorised and they know it is. Section 3 covers unauthorised acts done with intent to impair the operation of a computer, or with recklessness as to impairing it.

For a pen test firm, that means the paperwork isn't admin. It's the line between a commercial service and an offence. From an insurance point of view:

• Insurers won't cover criminal liability. No policy will pay a fine for a criminal offence or make a prosecution go away. Some PI and cyber wordings will pay defence costs for certain investigations, subject to the wording, but you should assume intentional or knowingly unauthorised acts are excluded.

• Scope errors are the most common route to trouble. Testing the wrong IP range, a host the client doesn't actually own, or a cloud tenant that belongs to a third party. Your process for confirming ownership and authority is something underwriters will ask about.

• Get authority from someone who has it. A signed letter of authority from a person who actually controls the systems, with clear dates, targets, and methods. Where the client uses third-party hosting or SaaS, check the provider's testing policy.

• Social engineering and physical tests need their own written authority. They also raise PL questions (you're on someone's premises) and employment questions (you're testing people).

None of this is legal advice on your specific engagements. The point is that clean authorisation keeps your insurance position clean too. A claim that starts with "the tester wasn't authorised" is much harder to defend than one that starts with "the tester missed something".

Contract clauses that decide what your insurance must do

Enterprise and public-sector clients send security suppliers some of the toughest terms they issue. Here's how the common clauses interact with insurance.

A word on fairness of terms: under section 3 of the Unfair Contract Terms Act 1977, where one party deals on the other's written standard terms of business, the party relying on those terms can't exclude or restrict its liability for breach unless the term satisfies the requirement of reasonableness. Section 11 sets out the reasonableness test. Where a term limits liability to a specified sum, section 11(4) says regard must be had in particular to the resources available to meet the liability and how far it was open to the party to cover itself by insurance. So a security vendor's own standard terms with an unrealistically low cap may not hold up, and your insurance limit can become part of that argument. Get commercial legal advice on your terms. Our job is to make sure the insurance matches whatever you sign.

For the security questionnaires and insurance schedules that come with enterprise deals, see MSA Security Questionnaire Insurance Evidence and SaaS SOC 2 and ISO Buyer Questionnaires.

You're probably a data processor

If you run a SOC, host logs, operate an MDR platform, or have access to client data during a test, you're very likely processing personal data on your clients' behalf. Under UK GDPR:

• Article 28 says a controller may use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. That's why clients ask security vendors so many questions, and why they want to see your insurance.

• Article 33(2) says the processor shall notify the controller without undue delay after becoming aware of a personal data breach. If your own platform is breached, the clock is on you.

• Article 82 gives anyone who has suffered damage from an infringement a right to compensation from the controller or processor. A processor is liable only where it has not complied with obligations specifically directed to processors, or has acted outside or contrary to the controller's lawful instructions.

For insurance, this means your cyber policy should include privacy liability and the cost of handling a breach where you're the processor, not just the controller. Ask whether regulatory defence costs are covered, and treat any cover for fines as limited and subject to what is legally insurable.

Regulation coming down the track

The Cyber Security and Resilience (Network and Information Systems) Bill is before Parliament. As of October 2026 it has reached report stage in the House of Lords and is not yet law. The government's factsheet says it would bring medium and large "relevant managed service providers" into the scope of the NIS Regulations 2018, and that small and micro businesses would be excluded. Managed services in that description include managed security services such as SOC and SIEM.

What that means for you, carefully:

• It's a Bill, not an Act. Details can change before Royal Assent, and much will depend on regulations made afterwards.

• If you're small or micro, you'd be outside the managed service provider duties on the factsheet's description. But your larger clients may themselves be in scope and will push the requirements down to you by contract.

• If you grow into a medium-sized MSP or MSSP, plan for incident reporting duties and regulatory oversight. Underwriters will ask about it at renewal once it's in force.

We'll update this page once the Bill becomes law. Don't rely on any summary, including ours, for compliance. Read the Act and the guidance when it lands.

Selling to government and critical national infrastructure

Public-sector and CNI buyers often ask for evidence beyond insurance:

• CHECK. The NCSC's CHECK scheme is the scheme under which NCSC-assured companies can carry out authorised penetration tests of public sector and CNI systems and networks. If you want that work, the scheme has its own requirements.

• Cyber Essentials and Cyber Essentials Plus. NCSC describes Cyber Essentials as covering five technical controls, with Cyber Essentials Plus adding independent technical testing. Many public contracts ask suppliers to hold one or the other. For a security vendor it's table stakes.

• Insurance schedules. Public contracts often set specific limits for PI, PL, EL, and sometimes cyber. Check the tender documents before you bid, not after you win. See Insurance for Public Sector Contracts UK.

Holding certifications doesn't change your legal liability, but it helps underwriters. Firms that can show mature controls and recognised assurance usually have a better conversation with the insurers on our panel.

The policy-by-policy view for a security vendor

Tech PI / E&O. The core policy. It should cover negligence, breach of professional duty, and, for product companies, failure of your technology product to perform. Check:

• whether it's written on a "civil liability" basis (broad) or a narrower negligence-only basis;

• that pen testing, managed services and incident response are all named in your business description;

• that it covers subcontracted testers and analysts;

• that it includes defence costs and isn't eroded by them in a way that leaves you short;

• what it excludes about contractual liability, guarantees, and warranties.

Cyber. Your own incident costs, restoration, business interruption, extortion handling, and privacy and network security liability. Security vendors should look closely at:

• cover for incidents that spread from your environment to customers;

• cover for your own tools (RMM, agents, platforms) being used as the attack route;

• whether a "failure to maintain security" condition or exclusion could be argued against a security business;

• business interruption for your own SaaS platform. See SaaS Business Interruption Insurance.

Public liability. Needed if you're on client premises: physical tests, hardware installs, workshops, SOC visits. Covers injury to people and damage to property. See Public Liability Insurance UK.

Employers' liability. Once you employ staff, EL is generally compulsory under the Employers' Liability (Compulsory Insurance) Act 1969. The regulations set a minimum of £5 million for any one occurrence. Freelance testers on contract can still count as employees for EL purposes depending on how they work, so tell us about them. See Employers' Liability Insurance UK.

D&O. Investors often expect it after a priced round. Security founders face extra board-level risk if a major incident leads to claims that the directors misled customers or investors about security. See Directors and Officers Insurance UK.

Crime / social engineering fraud. Security firms aren't immune to invoice fraud or payment diversion, and a successful attack on a security vendor's finance team is embarrassing as well as costly. See Crime and Fidelity Insurance for UK Startups.

Employment practices liability. Useful once you have a team, especially if you run insider-threat monitoring or social engineering tests that involve staff. See Employment Practices Liability Insurance for UK Startups.

What changes as you grow

If you're earlier than this, start with Startup Insurance UK. If your product is AI-led detection or response, AI Insurance for UK Startups covers the model-specific questions.

What underwriters will ask a security vendor

Have answers ready for these. Fair presentation isn't optional: under section 3 of the Insurance Act 2015, before a policy starts you must make a fair presentation of the risk, which means disclosing every material circumstance you know or ought to know, or at least enough to put the insurer on notice to ask more.

About your services

• Split of revenue by service: testing, managed services, incident response, product, consultancy.

• Largest clients, sectors (financial services, healthcare, public sector, CNI), and countries.

• Whether you hold privileged or persistent access to client systems, and how it's secured.

About your own security

• MFA everywhere, especially on remote access and admin tools.

• How you segregate client data and credentials; whether testers use dedicated, hardened machines.

• Patch management for your own tooling and platforms; secure development practices if you ship software.

• Backups, and whether they're isolated from your production environment.

• Certifications held (for example Cyber Essentials Plus, ISO 27001, CHECK, CREST, or similar).

About your contracts

• Your standard terms: liability cap, carve-outs, warranties.

• How often you accept client terms, and who reviews them.

• Use of letters of authority and rules of engagement for testing.

About your history

• Any claims, complaints, or incidents, including near misses where a client threatened action.

• Any incidents in your own environment.

Clear answers usually mean a cleaner conversation with the insurers on our panel. Gaps, such as no MFA on a remote-access tool, can lead to exclusions or no offer at all.

Common mistakes we see

• Buying "IT consultancy" PI and assuming it covers managed services. If the business description doesn't match what you do, a claim can be disputed.

• Signing uncapped security-breach indemnities. Your insurance has a limit. An uncapped contractual promise doesn't.

• Not telling the insurer about the product. A consultancy that quietly launches an agent-based tool has changed its risk.

• Forgetting freelancers. Contract testers working under your name need to be covered for the work they do for you.

• Choosing a limit to match the cheapest option rather than the contract. Read the insurance schedule in your biggest MSA first.

• Leaving cyber and PI on different insurers without checking how they interact. That's where disputes about who pays tend to start.

FAQs

Do pen testers need professional indemnity insurance?

In practice, yes. Clients usually require it in the contract, and a missed finding or a test that causes disruption is a professional liability claim. Make sure the policy names penetration testing in your business description.

Is cyber insurance enough for a cybersecurity company?

Usually not on its own. Cyber covers your own incidents and some privacy liability. Claims that your service or product failed to protect a client sit mainly under tech PI. Most security vendors need both.

Will insurance cover me if a test goes outside scope?

It depends on the facts and the wording. A genuine mistake within an authorised engagement may be a professional error. Knowingly unauthorised access is a different matter and is unlikely to be insurable. Good authorisation paperwork protects you on both fronts.

Can a sole-trader pen tester get cover?

Yes. Sole traders are in scope. You'll need PI, usually cyber, and PL if you work on client sites. Some clients prefer to contract with limited companies, so check their supplier requirements.

Our clients want £5m or £10m of PI. Is that realistic for a startup?

Sometimes, and sometimes it needs an excess layer. Limits depend on your revenue, services, and controls. Talk to us before you agree the contract so the limit is achievable.

Does the Cyber Security and Resilience Bill apply to us?

It's a Bill, not yet law, as of October 2026. On the government's factsheet, medium and large managed service providers would be in scope and small and micro businesses excluded. Your larger clients may still pass requirements down to you by contract.

Do you name insurers or publish prices?

No. We place cover with the insurers on our panel and give you terms once we understand the risk. We don't publish "from" prices because they'd be meaningless for security vendors.

Talk to us

If you run a security business and want your PI, cyber, and contracts lined up properly, speak to us. Bring your standard terms, your largest client contract, and a short description of each service you sell. We'll tell you what the insurers on our panel will need and where your gaps are.

Mesh'd Limited t/a Meshed / Meshed Cover · FCA FRN 1033248 · flat 10% broker fee · Ltd, partnerships, and sole traders · no fake prices · Speak to us