How do you include a SOC in a managed services contract?

To include a SOC in a managed services contract, a common approach is to add a service schedule. Such a schedule usually covers the monitored scope, who does what, the escalation procedure, service levels and reporting, as well as personal data and exit arrangements. The client keeps one contract and one point of contact: their MSP. This article lists the topics these contracts typically address; it does not propose wording, which is a matter for legal advice.

This article is part of our series on rolling out a managed SOC. For the full approach, see How to implement a managed SOC.

A two-tier contract structure

In an MSP model, two agreements usually sit side by side:

• the managed services contract between the MSP and its client, with a SOC schedule added;
• the partner agreement between the MSP and its SOC provider.

That is Cyna’s model: Cyna works through its partner MSPs, who own the relationship with their clients, the contract, billing and reporting. It therefore makes sense for the schedule agreed with the client to reflect what the partner agreement actually provides, especially on timings and pre-approved actions.

Topics in a SOC schedule

Topic	What it usually covers
Purpose and scope	Monitored sources: endpoints and servers via the EDR, email, firewall; what is excluded
Roles	What the MSP, the SOC and the client each do
Escalation	Severity levels, contacts, channels, pre-approved actions
Service levels	Hours of coverage, response and notification times
Incident response	Its scope, and what is a separate service
Reporting	Content, frequency, format, review meeting
Personal data	Applicable GDPR framework, use of other providers, information in case of a breach
Term and exit	Notice period, return or deletion of data, agent removal

Scope: write down what is monitored

Scope is often the most sensitive topic. Contracts usually list the connected sources (number of endpoints and servers, Microsoft 365 or Google Workspace tenants, firewalls) and state what is not covered. They also explain how sources are added during the contract. A client who believes their whole estate is monitored when part of it is not is the most common source of disputes.

Roles and escalation

The schedule usually restates the split of responsibilities: the MSP administers and remediates, the SOC monitors, triages and takes the agreed first containment actions, and the client decides on heavy actions. It often refers to a detailed escalation procedure kept up to date outside the contract, so there is no need for an amendment every time a contact changes. See How do you build an escalation procedure with a SOC? and Managed SOC and MSP: who does what?.

Incident response

Contracts usually address what happens when an alert becomes a serious incident: who steps in, within what scope, and what is a separate service. It is also worth setting out what the MSP handles itself (rebuilds, restores). At Cyna, the CERT works with the SOC teams and can be mobilised quickly; the incident response on-call team is available 24/7 from the Report an incident page. See What is included in a managed SOC, and what is not?.

Personal data

A SOC processes logs that contain personal data: usernames, IP addresses, file names. This processing falls under the GDPR. Its Article 28 covers the relationship between an organisation and the providers that process data on its behalf, and provides in particular for:

• a contract governing the processing (subject matter, duration, security measures, what happens to data at the end);
• prior written authorisation before another provider is engaged;
• the same obligations to be passed down to that other provider.

Article 33 also provides that the provider informs the organisation on whose behalf it processes data of any breach without undue delay after becoming aware of it, and that notification to the supervisory authority takes place within 72 hours. Contracts therefore usually organise this information chain. Who plays which role under the GDPR depends on each situation and is a matter for a legal adviser or DPO.

Clients in scope of NIS2

Article 21 of NIS2 provides that in-scope entities address supply chain security. An in-scope client may therefore ask its MSP for security clauses, incident notification timings and evidence. The SOC schedule can meet part of those expectations; on its own, it does not make the client compliant. Cyna’s certifications and security documents are available on its Trust Center.

Exit arrangements

At the end of the contract, schedules usually cover the return or deletion of data, the removal or deactivation of agents and handover of the final reports. Clear exit terms reassure the client when they sign.

Talk to an expert

Drafting the SOC schedule for your managed services contracts? If you work with a Cyna partner MSP, they are your first point of contact. If you are an MSP, or do not have a partner yet, get in touch. This article is not a substitute for legal advice on the wording of the clauses.

Frequently asked questions

Does the SOC need a separate contract?

Not necessarily. A schedule to the existing managed services contract is a common approach, and it keeps things simple for the client. The MSP has its own agreement with its partner SOC. The choice of form is for the MSP and its legal adviser.

Should the partner SOC be named in the contract?

Article 28 of the GDPR covers the case where a provider engages another provider to process personal data, and provides for prior written authorisation in that case. How this applies to a given situation, and therefore how to mention the partner SOC, is best checked with a legal adviser.

Can a SOC promise the client there will be no incident?

No. No SOC can rule out every incident. Contracts usually describe resources and handling arrangements, not the absence of incidents.

Which service levels do contracts usually cover?

Usually hours of coverage, response and notification times by severity, and reporting frequency. See What SLAs should you expect from a managed SOC?.