What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

A managed security service provider (MSSP) partnership works when both sides know exactly what the provider runs and what the customer still owns. The provider contributes security services and expertise. The customer keeps responsibility for its own organization, its business decisions, and the coordination needed when something goes wrong. Four practices make that split workable: put scope and responsibilities in writing, keep communication routine rather than crisis-only, govern the provider’s access to systems and data, and review service levels and reports as needs change.

What the relationship divides

Most MSSP disputes trace back to an assumption that one party was handling something the other believed it still owned. A provider may monitor logs around the clock while the customer assumed someone else was deciding whether to take a production system offline. The useful way to think about the partnership is as shared operational work, with a boundary drawn in advance.

The UK National Cyber Security Centre (NCSC) asks buyers to settle service boundaries and roles before a problem arises. Its guidance for choosing a managed service provider is written for small and medium-sized businesses, and it points larger organizations toward more detailed material. The NSA’s May 11, 2022 joint guidance on managed service providers offers a useful framing. NSA Cybersecurity Director Rob Joyce said, “This joint guidance will help MSPs and customers engage in meaningful discussions on the responsibilities of securing networks and data.”

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The Security Engineering Institute (SEI) guidebook on MSSP partnerships makes a related point from a supply-chain angle: a customer cannot hand its cyber success over completely to an MSSP, and it should stay engaged with executive oversight. Its examples focus on manufacturing and supply chains, so the lessons transfer to other sectors with some adjustment.

The four practices below are a practical way to organize that guidance. They are not a formal framework published by any one of these bodies.

1. Put scope, exclusions and responsibilities in writing

A contract is the only place where a shared understanding becomes enforceable. It should describe, in terms both parties can read without a security background, what the provider delivers, what it does not deliver, and what the customer must do itself.

What the agreement should cover

  • Services and assets in scope: the named services, systems, sites, and environments, plus any that are explicitly excluded.
  • Customer responsibilities: tasks the customer must perform, such as approving changes, maintaining asset inventories, or providing timely access to staff.
  • Escalation points: who on each side is contacted first, second, and third for each type of event.
  • Incident notification: what counts as a reportable incident, the time window for notice, and the channel used.
  • Liability: how responsibility and financial exposure are divided when a service fails or a breach occurs.
  • Third parties: any subcontractors or platforms the provider relies on, and whether the customer has any say over them.
  • Service levels: measurable targets, covered in practice four below.

Canada’s Centre for Cyber Security procurement guidance for security operations centre (SOC) services recommends that service contracts establish service level agreements (SLAs), task orders, and the governing standards. That guidance is written for procurement and is not legal advice, so customers should have counsel review the final terms.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use a responsibility matrix to find gaps

A shared responsibility matrix lists each security activity and marks who performs it, who approves it, and who is informed. Writing one often exposes gaps, such as two parties each assuming the other owns log retention, or overlapping duties that waste effort. For example, the provider might triage alerts and recommend containment, while the customer keeps the decision to isolate a business-critical server. Making that split explicit before an incident is far cheaper than negotiating it during one.

2. Make communication routine, not crisis-only

Many partnerships work well on day-to-day monitoring and fall apart when an incident forces decisions quickly. Routine contact is what makes emergency contact fast.

Name owners on both sides

  • An executive sponsor on the customer side who oversees the relationship and can resolve disputes.
  • A day-to-day operational contact who handles tickets, reports, and routine questions.
  • Matching provider contacts for the executive, operational, and incident roles, so each side knows who it is talking to.
  • Recurring reviews and a fixed reporting cadence, agreed in the contract.
  • A named incident channel that works when email or the ticketing system is down.

SEI describes a transparent two-way channel and active client engagement as core to an MSSP partnership. The NCSC guidance likewise stresses open communication and clear reporting. A customer that receives reports but never asks questions about them is not really engaged.

Agree how incidents are reported, including incidents at the provider

Before an incident occurs, both parties should settle:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • What the provider must report, and within what time frame, for each severity level.
  • What the customer must do in return, such as confirming a containment decision or supplying system owners.
  • How the provider reports its own incidents when they affect its platform or the customer’s data, and whether the customer is told about compromises that touch other clients.
  • Who speaks to regulators, customers, or the public, and who approves any statement.

The NCSC’s guidance on choosing a provider puts this as a direct buyer question: “What will happen if things go wrong?” A written answer to that question is more useful than a reassurance from a sales team.

3. Govern provider access and shared data

An MSSP usually needs privileged access to do its job, which makes the provider itself a point of risk. Compromise of a provider can affect the trust relationships it holds with its customers and can reach multiple clients at once. Access therefore needs the same discipline the customer applies to its own administrators.

Control provider accounts

  1. Inventory provider accounts. List every account, service identity, and integration the provider uses, and record what each can reach.
  2. Require multi-factor authentication (MFA) for every provider account that can reach production systems, administrative consoles, or security tools.
  3. Monitor provider activity. Review sign-ins and privileged actions performed by provider accounts, not only by the customer’s own staff.
  4. Remove accounts that are no longer needed when a project ends, a staff member leaves the provider, or a service is retired.
  5. Apply least privilege. Grant only the permissions a specific service requires, and review them when the scope changes.

These steps reflect guidance from the NSA’s joint material and the NCSC, which both treat provider access as a shared-security issue rather than only the provider’s problem.

Ask how customer data is separated and stored

Before signing, the customer should understand:

  • How the provider segregates customer data and platforms from other clients.
  • What logs are collected, how long they are retained, and who can access them.
  • Where data is stored and processed, which matters for legal jurisdiction and data residency obligations.
  • How changes to access arrangements or data handling are communicated, and how much advance notice the customer receives.

A provider that answers these questions clearly is giving the customer material to assess risk. A provider that cannot answer them has told the customer something too.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

4. Review service levels, reports and changing needs

Service levels should measure the service the customer actually buys. Targets should cover response and resolution expectations, monitoring and escalation, incident handling, reporting, continuity, and review. Targets appropriate for one service or risk level may be wrong for another, so they should be set per service rather than copied from a template.

The NCSC’s small-business guidance offers illustrative examples of what SLA targets can look like. These are examples from UK guidance, not industry averages or guaranteed performance. The page’s publication date is not stated.

Request type (NCSC example) Example response target Example resolution target
General or minor request 1 business day Not stated
Urgent request Under 1 hour Not stated
Routine, medium-priority request Not stated 2–3 business days, offered as a starting point

The NCSC also cautions that quicker response times can increase cost, so faster targets are a commercial decision as well as a technical one. Canadian procurement guidance similarly calls for service-specific SLAs that stay aligned with the customer’s changing security needs.

What to review on a schedule

  • Whether the provider met its response and resolution targets, and what caused any misses.
  • Whether the reports answer the questions the customer is actually asking, rather than only counting alerts.
  • Whether business changes, such as new applications, acquisitions, or new regulatory duties, have altered the scope.
  • Whether the security gaps found in earlier reviews have been closed, and by whom.
  • Whether the responsibility matrix still matches how the two organizations work.

A review that ends with a list of missed targets and no change to scope or ownership is only a status report. The purpose of a scheduled review is to adjust the partnership, not just to record it.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Taken together, these four practices keep the provider doing what it does best while the customer keeps the decisions, the data oversight, and the coordination that remain its own.

“

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.