What Your Cybersecurity Contract Should Actually Say

Most business contracts specify a response time for a broken printer more precisely than they specify who responds to a live security incident. That is not an exaggeration to make a point. It is genuinely how a lot of managed service agreements are structured, because printers are simple to define and cybersecurity, until recently, was treated as a single line item rather than a set of distinct obligations.

The result is that "we have cybersecurity covered" ends up doing a great deal of work in a sales conversation and almost none in a written agreement. This is not usually because a provider is being deliberately vague. It is because cybersecurity contract terms were, for a long time, genuinely difficult to write well, and plenty of existing agreements have simply never been updated to reflect what a modern security stack actually involves. Either way, the gap sits there quietly until an incident happens, at which point it becomes very much everyone's business.

The terms your contract will actually use

Before looking at what a contract should say, it helps to know what it is talking about. These are the terms that tend to appear, loosely or otherwise, in most cybersecurity agreements.

EDR (Endpoint Detection and Response) is software installed on laptops, desktops and servers that watches for suspicious behaviour, such as a program trying to encrypt files or disable security controls. It notices a problem. It does not decide what to do about it.

XDR (Extended Detection and Response) does the same job as EDR but extends it beyond individual devices, pulling in signals from email, cloud applications and network activity so that related warning signs across different systems get connected rather than reviewed in isolation.

Email security covers the tools and settings that filter phishing attempts and impersonation emails before they reach an inbox, including technical authentication standards such as SPF, DKIM and DMARC, which stop someone else sending convincing fake emails from your own domain.

SIEM (Security Information and Event Management) is a system that collects activity logs from across a business and lines them up so patterns become visible. It does not detect or stop anything by itself. Someone still has to review what it surfaces.

MDR (Managed Detection and Response) is the service of a team of analysts monitoring EDR, XDR and SIEM alerts, working out which ones are genuine threats, and acting on them. This is usually delivered through a SOC, or security operations centre, and is the difference between a tool raising an alarm and a person actually responding to it.

Vulnerability management is the ongoing process of finding and closing the gaps an attacker could exploit, such as unpatched software or misconfigured settings, before they become the way an attacker gets in.

None of these terms are complicated once explained plainly. The problem is that contracts rarely explain them at all, which is exactly why it is worth knowing what each one is before reading what your own agreement does or does not promise.

Why "covered" is not a contract term

A sales pitch and a contract clause are different documents with different jobs. One is designed to build confidence. The other is designed to survive a dispute. Cybersecurity contract terms only do their job if they specify three things clearly: which products are actually in use, who is responsible for acting when something goes wrong, and what happens financially if it does.

Vague language is not always a red flag on its own. Plenty of businesses have run for years on loosely worded agreements without issue. But loosely worded agreements are precisely the ones that get tested during an actual incident, and that is a considerably worse moment to discover what was and was not included.

Walking a phishing incident through the stack

The clearest way to see where contract terms should get specific is to follow one incident from start to finish, because it passes through every layer named above.

A convincing phishing email reaches the inbox, where email security acts as the first layer of defence.

An employee receives an email that looks like it came from a supplier. Email security is the first line of defence here. Tools such as Barracuda filter known phishing patterns and verify sender authenticity. A contract should name which of these controls are actually in place, rather than referring to "email protection" as a single undefined feature.

If the message slips through and the attachment is opened, the threat moves from the inbox to the endpoint.

Say the email slips through anyway, because filtering is good rather than infallible, and the attachment gets opened. This is where EDR and XDR take over. Software such as SentinelOne watches behaviour on the device itself and raises an alert the moment something looks like an attack in progress. If you want the fuller distinction between EDR and its managed counterpart, we have covered that in more detail here.

EDR monitors device behaviour, detects suspicious activity and can begin containing the threat before it spreads.

An alert firing is not the same as someone responding to it. Software can notice that something is wrong. It cannot decide on its own whether the activity is a genuine attack, and it cannot contain it. That decision belongs to a person, and a well-written agreement states plainly whether that person is available around the clock through a 24×7 SOC, rather than during business hours with an on-call arrangement bolted on afterward.

An alert still needs someone to investigate it, confirm the threat and decide what action to take.

Finally, it is worth asking why the file was able to run in the first place. The honest answer is frequently an unpatched piece of software or a known vulnerability that sat open for weeks before anyone acted on it. Nothing dramatic announces an unpatched system. It simply exists as an open door. Vulnerability management tools, such as ConnectSecure, exist to find those doors and close them before an attacker does, and a contract should specify that this scanning happens on a defined schedule rather than "as needed."

Vulnerability management looks beyond the immediate incident to find the weakness that allowed it to happen and make sure it is patched.

The clause that gets skipped: incident response

If there is one clause worth reading twice before signing anything, it is this one. Once an incident is confirmed and containment work begins, is that labour included in the existing agreement, or is it billed separately as the incident unfolds.

Both models exist, and neither is inherently unreasonable on its own. What causes genuine disputes is discovering which model applies for the first time while an incident is actually happening, when a business has very little leverage to negotiate anything and very good reason not to want the conversation at all. This is precisely the kind of term that should be settled in writing, in a calm moment, long before it is ever needed.

What good contract language actually looks like

In our experience, the difference between a strong agreement and a weak one rarely comes down to which products are named. Most reasonable security stacks cover similar ground. The difference comes down to whether the contract states, in plain terms, who does what and by when.

A well-written agreement typically names the specific tools in use rather than describing them generically, states whether monitoring and response are genuinely 24×7 or business-hours only, defines a target response time between an alert firing and a human reviewing it, and states explicitly whether incident response labour is included or billable. None of this requires unusual technical detail. It requires the same precision most contracts already apply to far less consequential things.

It is also worth saying plainly that a separate SIEM platform is not automatically required on top of a well-integrated EDR and SOC arrangement. SIEM exists to correlate activity logs and surface patterns a human would otherwise miss. If an EDR platform and its SOC are already performing that correlation and response together, a contract that adds a second platform on top is not necessarily buying additional protection. Occasionally it is simply buying an additional line item.

Terms worth checking in your own agreement

• The specific products covering endpoint detection, email security and vulnerability management, named rather than described generically.
• Whether monitoring and incident response are genuinely 24×7, or business-hours with an on-call arrangement layered on top.
• A stated target response time between an alert firing and a person reviewing it.
• Whether incident response labour is included in the existing fee or billed separately once an incident begins.

If your current agreement does not answer these questions clearly, that is worth raising as a straightforward request for clarification, not as an accusation. Most providers can answer these questions easily. The issue is usually that nobody has been asked to put the answer in writing.

A framework worth measuring against

For Australian businesses, the Essential Eight from the Australian Cyber Security Centre remains a practical benchmark for where these controls should sit, covering patching, multi-factor authentication, application control and backups. It will not tell you what your specific contract should say word for word, but it gives you a concrete standard to hold any agreement against, rather than relying on how reassuring it sounds. It is also worth weighing your current setup against your actual risk profile, since what counts as adequate coverage changes considerably depending on what a business has to lose.

Where Affinity MSP Fits In

We wrote this piece the way we did because it is the same standard we hold our own agreements to. Affinity MSP's cybersecurity practice runs on SentinelOne EDR backed by a 24×7 SOC, so detection and response sit with the same team rather than being split across a tool and a separate monitoring arrangement. Email security runs through Barracuda, and vulnerability management runs through ConnectSecure, on a defined scanning schedule rather than an ad hoc one. There is no separate SIEM layered on top, for the same reason argued above: when EDR and SOC are already correlating and responding together, a second platform does not add meaningful coverage, it adds cost.

Reading through an existing agreement with this list in hand is a reasonable way to spend twenty minutes, and it does not require a legal or technical background, just a willingness to ask for specifics rather than assurances. AffinityScan gives you a free starting point regardless of who your current provider is, checking your domain's email security, network visibility and known vulnerabilities in about sixty seconds. Run a free AffinityScan check to see where your own setup stands before your next contract renewal.

FAQ

What should a cybersecurity contract specify?
At minimum, it should name the specific products covering endpoint detection, email security and vulnerability management, state whether monitoring is genuinely 24×7, define a target response time for alerts, and state clearly whether incident response labour is included or billed separately.

Is incident response usually included in a managed security contract?
It varies by provider. Some include investigation and containment as part of the standard fee. Others treat it as billable time-and-materials work once an incident begins. Confirming which applies before anything happens avoids a costly surprise during one.

Do I need a SIEM if I already have EDR and a 24×7 SOC?
Not necessarily. A SIEM correlates activity logs so a human can spot patterns. If an EDR platform and its SOC are already doing that correlation and response together, a separate SIEM may add cost without adding meaningful coverage.

What does Affinity MSP's own cybersecurity stack include?
Affinity MSP runs SentinelOne for endpoint detection and response, backed by a 24×7 security operations centre, Barracuda for email security, and ConnectSecure for vulnerability management on a defined scanning schedule. There is no separate SIEM layered on top, since EDR and SOC already handle that correlation and response work together.