Terms for a cybersecurity product

A security product is bought to prevent something the supplier cannot promise to prevent, and its terms have to hold that line without making the product sound useless: a defined scope of protection, a statement of what is not guaranteed, the authorisation the supplier needs to scan and monitor systems without committing an offence, careful handling of the access and data the product involves, a clear incident process, and a liability position that survives the breach the customer bought the product to avoid. I draft those terms for a fixed fee of £995, delivered in five working days.

Who this is for

Cybersecurity businesses in England and Wales selling monitoring, endpoint protection, vulnerability scanning, penetration testing, managed detection and response, email security or similar products and services to business customers.

What matters in cybersecurity product terms

Scope of protection and what is not guaranteed

The terms should define what the product does (monitors, detects, alerts, blocks, tests) and for which systems, and should say that no product detects or prevents every threat, that the supplier does not guarantee that the customer will not suffer a security incident, and that the product is one part of the customer's security arrangements. The supplier's obligation is to provide the service with reasonable care and skill under section 13 of the Supply of Goods and Services Act 1982 in accordance with the documentation, and the exclusion of any wider warranty is tested for reasonableness under section 3 of the Unfair Contract Terms Act 1977, where a clear scope statement does most of the work.

Authorisation for scanning, testing and monitoring

Accessing a computer without authorisation is an offence under section 1 of the Computer Misuse Act 1990, and impairing its operation under section 3, and a supplier that scans, tests or monitors a customer's systems needs the customer's authorisation for exactly what it does, in writing, from someone entitled to give it, extending to systems hosted by third parties only where those third parties have consented. The terms should contain the authorisation, require the customer to warrant its authority over the systems in scope, and provide for rules of engagement for testing, including what is out of bounds and when testing stops.

Access to the customer's systems and data

The product sees traffic, logs, credentials and content, and the terms should describe what the supplier accesses and retains, for how long, and for what purposes, contain the processor terms Article 28 of the UK GDPR requires for the personal data within it, state security under Article 32 that a security supplier will be held to, list subprocessors and locations under Article 46, and impose confidentiality on the supplier's staff. Use of threat data across the supplier's customer base to improve detection should be stated expressly and confined to data that does not identify the customer.

Incident detection, response and notification

The terms should say what the supplier does when it detects an incident (alerts within a stated time, contains where the product can, escalates), what response is included and what is chargeable, the customer's own responsibilities in the process, and that the supplier's notification to the customer supports but does not replace the customer's own obligations under Article 33 of the UK GDPR and, for operators of essential services and digital service providers, under the Network and Information Systems Regulations 2018. A supplier that is asked to take over incident response should do so under a separate statement of work.

The customer's obligations and the things the product cannot fix

The terms should require the customer to keep systems patched and configured as the supplier advises, to act on alerts, to control its own credentials, to tell the supplier about changes to the systems in scope, and to maintain backups, and should say that failures caused by the customer's inaction are outside the supplier's responsibility. Findings from testing belong to the customer and are confidential, and the terms should say that the supplier may retain them for its records and use them anonymously.

Liability, insurance and the boilerplate

The liability cap should be a multiple of the annual fees that the supplier's professional indemnity and cyber insurance support, with consequential loss and the customer's own breach losses excluded and the exclusions tested under section 11 of the Unfair Contract Terms Act 1977; customers will ask for a higher cap for incidents the product should have detected, and the terms should state the supplier's position. Export controls under the Export Control Order 2008 can apply to security software, sanctions compliance should be stated, and English law should apply with third-party rights excluded under the Contracts (Rights of Third Parties) Act 1999.

What it costs

SaaS terms of service, £995. Your standard customer-facing terms. Five working days.

Buying online forms the engagement on payment. The scope is what the saas and technology contracts page describes, you accept the Terms of Service at checkout, and I email you within four working hours to get started. If you would rather ask something first, email me.

What you get

• A bespoke contract drafted for how your product is sold, delivered and supported
• Service levels you can meet, with remedies that are proportionate rather than aspirational
• A liability position that is defensible and will survive enterprise procurement
• IP and data provisions that fit together rather than contradicting each other
• A commercial note on where you will get pushback and what is worth conceding
• One round of amendments

What is not included

• Negotiating individual enterprise deals, which I quote separately
• Advice on the law of jurisdictions outside England and Wales
• Technical security certification or audit
• Regulatory advice for regulated sectors such as financial services or health

Questions I am often asked

A customer was breached despite our product and wants to claim. Are we liable?

Within the cap, if the supplier failed to provide the service with reasonable care, such as missing an alert the product generated. Not for the fact of the breach, if the terms define the scope and say that no product prevents every attack. The evidence is the logs and the alerts.

Do we need written authorisation before a penetration test?

It is needed, from someone with authority over the systems, extending to third-party hosts. Without it the test can be an offence. The terms contain the authorisation and the rules of engagement.

Can we use what we learn from one customer to protect others?

Threat indicators and patterns that do not identify the customer, if the terms say so. Customer-identifying findings are confidential and stay with the customer.

Related guidance and services

• SaaS and technology contracts, £995, the service this page describes
• Contract review, £495
• Data protection agreements and privacy terms, £795
• Managed service provider agreement
• SaaS terms of service for a B2B product

This page is general guidance for businesses in England and Wales, not advice on your own circumstances. Last reviewed: September 2026. Email geoffrey@caesar.co.uk.