Is my MSP responsible for security, or are we?

Your contract decides the starting point, and this order shows it may not decide the whole answer. Read your agreement for what the provider is assigned — then assume that account hygiene and the security of the provider's own access to your systems are expected either way. In this settlement a provider contracted for 'management (not security)' was still faulted for a single shared administrative account with unrestricted access and for a poorly secured remote support tool. Don't rely on an assumption in either direction; get the split in writing.

What should an MSP contract say about security responsibility?

It should assign each security function to a named party in a written responsibility matrix. The order itself calls for 'responsibility assignment matrixes to clearly establish the responsibilities of various participants in the information security business process.' Beyond the matrix, the contract should cover how the provider authenticates into your environment (no shared, unrestricted accounts), how its remote tooling is configured and logged, and your right to assess the provider. Have counsel review the final language.

We're a healthcare practice — does this apply to us?

We can't tell you what applies to you legally; that is a question for your counsel. Operationally, the questions apply to any organization that gives an outside provider administrative access to systems holding sensitive data. The order notes the IT provider was a HIPAA business associate and that the affected systems held patient information. If you use such a provider, read its contract against the checklist in this post.

Does a 'management, not security' clause protect an MSP?

In this order it did not fully protect the provider. The Attorneys General faulted it for how it handled the client accounts it used and how it secured its own remote support tool, even though the contract covered management and not security. Whether such a clause protects any particular provider is a legal question we can't answer — but operationally, basic account hygiene and securing your own access tooling are expected regardless of how the scope is written.

Blog · 5 min read · October 19, 2026

Who Owns Security in Your MSP Contract?

A New York / Connecticut AG settlement announced October 16, 2026 faulted an MSP contracted for management, not security — for a shared unrestricted admin account and an under-secured remote support tool. The lesson is to get the security split in writing.

ProIT NW, a senior-led Microsoft consultancy in Seattle serving the regulated mid-market, wrote this post to help IT leaders in healthcare, GovCon, and finance work out who owns security in their MSP contract — using a New York and Connecticut Attorneys General settlement announced October 16, 2026.

This is operational and contractual guidance, not legal advice. It does not tell you what any law requires of your organization. Take contract language to your counsel.

What the order says happened

The Attorneys General of New York and Connecticut settled with a pediatric health network, Boston Children's Health Physicians (BCHP), and its IT provider, XTIUM. The headline figure is $2.7 million: about $2.1 million to New York and $540,000 to Connecticut, with a further $1.04 million (NY) and $260,000 (CT) contingent on a breach of the settlement. The incident affected about 825,000 New York residents and 62,871 Connecticut residents; more than 170,000 people had Social Security or driver's license numbers involved.

The detail that matters for contracts is in the Assurance of Discontinuance itself. BCHP used two IT vendors. The one responsible for "both management of and security for" the active patient-records system was not breached. The second vendor, XTIUM, "was contractually responsible for the management of (not security for)" BCHP's other IT systems — and those were the systems breached. The order also identifies XTIUM as a HIPAA business associate.

So this was not a case of a client assuming its MSP did security while the contract said otherwise. The contract said "management, not security," and the provider was still faulted.

How the order describes MSPs

The order defines the term in its own words: "MSPs provide general technology services, such as IT systems management. MSP services are administrative and operational in nature… MSPs generally do not provide security services, such as threat detection, threat prevention, risk management, scanning, incident response, and compliance." It contrasts that with a managed security service provider (MSSP), which provides those security services.

Read that as the Attorneys General's characterization in this order. It is not a universal rule, and plenty of MSP contracts include security services. What it does show is that regulators are willing to draw the line where the contract draws it — which cuts in your favor only if the contract draws the line clearly.

Where the provider was still on the hook

This is the part that matters, because the order does not treat "management, not security" as a shield.

The remote support tool. The breach came "through its implementation of a third party remote support tool." XTIUM "did not implement the remote support tool utilizing all of the security measures recommended by the third party vendor," and "did not have sufficient logging or monitoring." The order says XTIUM "cannot definitively confirm how the threat actors accessed the XTIUM system," and that its logging "was so poor that it prevented meaningful forensic analysis."
The shared admin account. XTIUM managed certain IT functions "using a single shared administrative account with unrestricted access and unlimited privileges." The attacker used that account to reach BCHP, then compromised four additional unrestricted BCHP accounts.

The order also notes that BCHP "failed to implement and enforce common standard security policies." That did not settle the question. It states that XTIUM "neither requested these BCHP policies nor followed common standard practices," and that XTIUM "should have applied common standard practices to secure the client accounts it used."

The honest framing: the provider was faulted for two things that sit outside any security-services scope — basic hygiene on the accounts it used, and the security of its own remote-access tooling. The client's own policy gaps did not erase that.

What the order requires going forward

Among the controls the order requires are "vendor assessments" and "responsibility assignment matrixes to clearly establish the responsibilities of various participants in the information security business process." In other words, part of the remedy is writing down who does what.

What to check in your contract

If you buy IT management from an MSP — or from any provider with administrative access to your environment — check these:

Shared administrative accounts. Does the provider use named, individual accounts with scoped privileges in your environment, or one shared account? Ask for the answer in writing, and for how often it is reviewed.
Remote-tool security configuration. Which remote support or RMM tool does the provider use against your systems? Does the contract require it to be configured to the tool vendor's recommended security measures, and who confirms that? Our write-up on treating RMM as tier-0 infrastructure has the specific questions to put to a provider here.
Logging and monitoring. Does the provider log activity in its own remote-access tooling, for how long, and can it hand those logs to you or a forensic team? Logs that can't support an investigation are a finding in this order.
A written responsibility matrix. Does the contract include a table assigning each security function — identity, endpoint protection, patching, monitoring, incident response, backups, access reviews — to you, the provider, or a third party? A function nobody is assigned is a function nobody owns.
Vendor assessments. Do you assess the provider's own security practices before signing and on a schedule afterward? Does the contract let you?
The gap between "manage" and "secure." If the contract says the provider manages a system but does not secure it, who does? Name them.

Where ProIT fits

ProIT NW works as a senior-led project consultancy, not a full-outsource MSP, and it is not an MSSP. We don't run your day-to-day IT or sell managed security services, and we hold no certification that this order or your regulator would recognize. What we do is the work that comes before and around these contracts: identity and access design, Microsoft 365 and Entra security configuration, and readiness advisory — including, for healthcare teams, the HIPAA and business-associate side of it. The contract-scope conversation in this post is one a regulated buyer should have with any provider, including us.

The 30-second version

A New York / Connecticut AG settlement announced October 16, 2026 faulted an IT provider that was contracted for "management, not security" of the systems that were breached. The provider was still on the hook — for a single shared administrative account with unrestricted access, and for a remote support tool it did not secure to the vendor's recommendations or log adequately. The remedy includes vendor assessments and a written responsibility matrix. The move for any organization that hands a provider admin access: stop relying on an assumption about who owns security, and put the split — accounts, remote tooling, logging, each security function — in writing.

If you want a senior engineer to review how an outside provider authenticates into your environment and what your contract actually assigns, the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.

Sources and further reading

Pro IT NW is a senior-led Microsoft consultancy for the regulated mid-market in Seattle and the Pacific Northwest. Vendor-neutral, labor-only. Nothing here is legal advice; for how any settlement or regulation applies to your organization, talk to counsel.

Questions we get asked

Is my MSP responsible for security, or are we?: Your contract decides the starting point, and this order shows it may not decide the whole answer. Read your agreement for what the provider is assigned — then assume that account hygiene and the security of the provider's own access to your systems are expected either way. In this settlement a provider contracted for 'management (not security)' was still faulted for a single shared administrative account with unrestricted access and for a poorly secured remote support tool. Don't rely on an assumption in either direction; get the split in writing.
What is the difference between an MSP and an MSSP?: In this order the Attorneys General describe a 'managed service provider' (MSP) as providing general technology services such as IT systems management — services that are 'administrative and operational in nature' — while a 'managed security service provider' (MSSP) provides security services such as threat detection, threat prevention, risk management, scanning, incident response, and compliance. That is the order's characterization, not a universal rule: plenty of real MSP contracts include security services. The label on the vendor matters less than the list of functions written into the agreement.
What should an MSP contract say about security responsibility?: It should assign each security function to a named party in a written responsibility matrix. The order itself calls for 'responsibility assignment matrixes to clearly establish the responsibilities of various participants in the information security business process.' Beyond the matrix, the contract should cover how the provider authenticates into your environment (no shared, unrestricted accounts), how its remote tooling is configured and logged, and your right to assess the provider. Have counsel review the final language.
We're a healthcare practice — does this apply to us?: We can't tell you what applies to you legally; that is a question for your counsel. Operationally, the questions apply to any organization that gives an outside provider administrative access to systems holding sensitive data. The order notes the IT provider was a HIPAA business associate and that the affected systems held patient information. If you use such a provider, read its contract against the checklist in this post.
Does a 'management, not security' clause protect an MSP?: In this order it did not fully protect the provider. The Attorneys General faulted it for how it handled the client accounts it used and how it secured its own remote support tool, even though the contract covered management and not security. Whether such a clause protects any particular provider is a legal question we can't answer — but operationally, basic account hygiene and securing your own access tooling are expected regardless of how the scope is written.

Related service

Identity, Security & Compliance

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle and the Pacific Northwest, delivered USA-wide.

Share on LinkedIn Follow Pro IT NW