MSP client data, MSAs and HIPAA BAAs: what stays out of an MSP data license

Whose records are they? MSP-authored work vs client information

Every MSP record falls somewhere on a line between two ends. At one end is work your team created to run your own practice: the onboarding runbook, the KB article on resetting MFA, the PowerShell script that cleans up a profile, your pricing sheet. At the other end is information about a client: its network diagram, its users, its firewall rules, its passwords, the incident at its office last spring.

The tools do not sort this for you. A single IT Glue instance holds your internal KB next to client organizations, and a single ticket holds your triage decision next to the client user's name and hostname. Vendor terms leave the question open on purpose: Kaseya's Master Agreement says “you or the End User (as applicable) retain all existing rights in and to Content” (source: Kaseya Master Agreement (updated Oct 7, 2025)). Buyers draw the line the same way. Buyer program L says data you hold on behalf of your own clients stays out of scope unless you have the right to license it, and Buyer program K excludes what you hold on behalf of your own clients (source: program terms, Regulr buyer directory).

What your MSP MSA says about client information

Your master services agreement is the document that decides what you may do with client information. MSP MSA templates and contract templates vary, but most include a few terms that matter here (this summary is our reading of common templates, not a quote from any one):

• Confidentiality. The client's information, often defined broadly to include its systems, users and business, is confidential and used only to deliver the services.
• Use limits. Some MSAs say client data may be used only for service delivery. Others add a carve-out for aggregated or de-identified data used to improve the MSP's services. Few mention licensing to anyone.
• Return or deletion. At the end of the relationship, client data is returned or destroyed, which affects former clients' records in your archive.
• Flow-down terms. Clients in regulated industries attach their own addenda: a HIPAA BAA, a data processing addendum, or security requirements from their own regulator.

Two practical points. First, the signed version controls for each client, so a large client that negotiated its own MSA may have stricter terms than your template. Second, where an MSA bars any use beyond service delivery and has no de-identification carve-out, the records tied to that client usually stay out, metadata included. Your own runbooks and scripts do not depend on client MSAs, as long as nothing client-specific is in them.

Client environments, IT Glue passwords and configurations

Client environment documentation is the clearest exclusion in the category. Network diagrams, asset lists, configurations, firewall and VPN settings, Wi-Fi keys, admin accounts and the password vault describe how to get into a client's systems. No buyer we track asks for them, and one broker that names MSPs excludes “client environment details and credentials” outright (source: program terms, Regulr buyer directory).

The practical risk is accidental inclusion. IT Glue exports offer “the ability to include or exclude passwords from exports” (source: Kaseya, IT Glue customizable exports), and an export of a whole instance also carries every client organization. For a data license, export only your internal KB and runbooks, with passwords excluded, and check the result before it goes anywhere. Ticket text needs the same care: techs paste credentials, license keys and connection strings into notes more often than anyone would like. Our guide to ConnectWise, Autotask, HaloPSA and IT Glue export terms covers how each platform exports.

Security incidents and MSP data breach records

Incident tickets, SOC and EDR alerts, forensic notes, ransomware response timelines and breach notifications stay out. They describe a client's weaknesses in detail, and they are typically tied up with the client's cyber insurer, your security vendors' terms and any notification obligations. An MSP that is itself in the middle of a breach response, or had a recent MSP data breach, is usually not in a position to license anything until that is closed.

Generic security procedure is different. A runbook your team wrote on how you triage a phishing report, or your onboarding checklist for a new EDR agent, is MSP-authored material and usually qualifies once client-specific details are removed.

MSP HIPAA compliance: business associates and what a BAA allows

MSPs with medical and dental clients meet HIPAA through the business associate rules. A business associate is a person who “creates, receives, maintains, or transmits protected health information” for a function or activity regulated by HIPAA on behalf of a covered entity, and a subcontractor that does so on behalf of a business associate is one too (source: 45 CFR 160.103, business associate definition (LII)). An MSP supporting a practice's EHR workstations, email or backups typically fits.

The business associate agreement must “Establish the permitted and required uses and disclosures of protected health information by the business associate,” and may not authorize uses or disclosures that would violate the rule if the covered entity made them, apart from the business associate's own management and administration and certain data aggregation for the covered entity (§164.504(e)(2)(i)). At termination the business associate must, if feasible, return or destroy all PHI it still holds (§164.504(e)(2)(ii)(J)) (source: 45 CFR 164.504(e), business associate contracts (LII)).

HIPAA does define de-identified information: data with “no reasonable basis to believe that the information can be used to identify an individual,” reached either by an expert determination or by removing 18 listed identifiers with no actual knowledge that what remains could identify someone (§164.514(a) and (b)) (source: 45 CFR 164.514, de-identification (LII)). But what a business associate may do with PHI starts from its BAA, so de-identification alone does not make healthcare clients' tickets licensable. Buyers typically exclude them, and the clean route is to leave every healthcare client out. An MSP whose revenue is mostly healthcare has a thin licensable slice; one with a few medical clients can license its own material and set those clients aside.

Law firm, accounting and financial clients

• Law firms. A law firm client's file shares, email and practice-management system hold matter content protected by the firm's own confidentiality duties. Tickets that touch that content stay out. Our guide for law firms covers what those duties mean for the firms themselves.
• Accounting and tax firms. Section 7216 of the Internal Revenue Code penalizes a person in the business of preparing returns, or providing services in connection with their preparation, who knowingly or recklessly discloses or uses return information for other purposes (source: 26 U.S.C. 7216, disclosure by tax return preparers (LII)). An MSP supporting a CPA firm's tax software sits close to that information, so those tickets stay out. See our guide for accounting firms.
• Financial institutions. Under the FTC Safeguards Rule, covered financial institutions must oversee service providers by “Requiring your service providers by contract to implement and maintain such safeguards” (§314.4(f)) (source: 16 CFR 314.4, FTC Safeguards Rule elements (LII)). Those contract terms usually limit what an MSP may do with customer information, so lenders', brokers' and similar clients' records stay out.

Federal and defense clients: Controlled Unclassified Information

Controlled Unclassified Information is “information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government,” that a law, regulation or government-wide policy requires or permits an agency to handle with safeguarding or dissemination controls (source: 32 CFR 2002.4, CUI definitions (LII)). MSPs supporting defense contractors or federal agencies handle CUI and work under contract security requirements. Those clients' records stay out entirely, and an IT provider whose work is mostly federal is usually outside this category altogether.

De-identifying ticket text: a working identifier list

If you and a buyer decide that some ticket free text from clients whose MSAs allow it is in scope, the scrubbing has to be thorough. HIPAA's safe harbor list is written for health data, but it doubles as a practical checklist for IT tickets. Among its 18 identifiers are names, telephone numbers, email addresses, account numbers, device identifiers and serial numbers, web URLs, IP address numbers, biometric identifiers, full-face photographs, and any other unique identifying number or code (source: 45 CFR 164.514, de-identification (LII)).

For MSP tickets, add the items that identify a company or a system rather than a person:

• Client company names, domains, tenant names and office locations
• Hostnames, computer names, MAC addresses, asset tags and serial numbers
• Usernames, UPNs, mailbox names and shared drive paths with user names in them
• License keys, connection strings, API keys and any pasted password
• Screenshots and attachments, which usually come out entirely

What remains: the licensable MSP record

After the exclusions, a typical MSP still has a meaningful record: years of runbooks and KB articles, a script and policy library, technician training, project templates, contract templates and pricing, and a ticket metadata corpus showing how your service desk triages, routes, escalates and resolves work, with SLA and reopen outcomes attached. Buyers name each of these. One buyer program asks for “SOPs, playbooks, runbooks” and requires that the company owns the records in its systems, and Broker A notes that regulated, privileged or third-party records may be excluded (source: program terms, Regulr buyer directory).

You approve the scope, and every exclusion is named in the contract. For how buyers value the remaining package, see the MSP and IT services page on what your records could qualify for or our data value checker. If a sale is coming, read our guide to selling an MSP before you scope anything.

Checklist: sorting your MSP records

1. Pull your MSA template and the signed MSAs for your ten largest clients.
2. Note which clients have a BAA, a data processing addendum or flow-down security terms.
3. Tag healthcare, legal, accounting, financial and federal clients for exclusion.
4. Separate internal KB and runbooks from client organizations in IT Glue or Hudu.
5. Move generic scripts to a repository; strip secrets and client-specific logic.
6. Plan ticket metadata with client identity tokenized and free text dropped.
7. Leave out incidents, SOC alerts, password vaults and client configurations.
8. Decide the scope in writing before any export leaves your environment.

The MSP data licensing guide puts this in the context of the buyers that name MSPs, and our buyer directory lists each program's published scope.

Frequently asked questions

Sources

HIPAA regulations, 26 U.S.C. 7216, the FTC Safeguards Rule, the CUI definition and the vendor pages were read on October 18, 2026. Common MSA terms are our reading of the category, not quotes. Program terms were checked on October 15, 2026; our buyer directory lists the programs and links to their published terms.

1. 45 CFR 160.103, business associate definition (LII)
2. 45 CFR 164.504(e), business associate contracts (LII)
3. 45 CFR 164.514, de-identification (LII)
4. 26 U.S.C. 7216, disclosure by tax return preparers (LII)
5. 16 CFR 314.4, FTC Safeguards Rule elements (LII)
6. 32 CFR 2002.4, CUI definitions (LII)
7. Kaseya Master Agreement (updated Oct 7, 2025)
8. Kaseya, IT Glue customizable exports
9. program terms, Regulr buyer directory