Should a Consultant Get Access to Your MSP’s PSA? Read-Only, Minimal, and in Writing

When the firm’s clients are financial institutions: 16 CFR 314.4(f)

The FTC’s Safeguards Rule, 16 CFR part 314, applies to financial institutions under the Commission’s jurisdiction, and its definition is broader than the everyday phrase. The examples listed in 314.2(h) include an accountant or other tax preparation service, a mortgage broker, an investment advisory company and a credit counseling service, an automobile dealership that leases cars for longer than 90 days, a check casher and a real estate settlement service. A managed IT firm with an accounting practice or a mortgage broker on its client list is working for a covered institution.

Section 314.2(r) defines a service provider as any person or entity that “receives, maintains, processes, or otherwise is permitted access to customer information through its provision of services directly to a financial institution.” An MSP whose work gives it access to that client’s customer information fits that definition. And section 314.4(f) requires the institution to “Oversee service providers, by:”

• “(1) Taking reasonable steps to select and retain service providers that are capable of maintaining appropriate safeguards for the customer information at issue;”
• “(2) Requiring your service providers by contract to implement and maintain such safeguards; and”
• “(3) Periodically assessing your service providers based on the risk they present and the continued adequacy of their safeguards.”

The rule binds the client, and the duty reaches the MSP by contract. The FTC’s compliance guide puts it plainly: the contracts “must spell out your security expectations, build in ways to monitor your service provider’s work, and provide for periodic reassessments.” Among the safeguards the rule lists, 314.4(c)(1) asks covered institutions to limit authorized users’ access “only to customer information that they need to perform their duties and functions,” and 314.4(c)(8) to monitor and log the activity of authorized users. An MSP bound by a contract like that and handing a consultant a broad login to tickets that hold a client’s customer information is passing that information one step further than the contract may allow. Whether a given client is covered and what its contract requires is a question for the firm’s attorney; the safer design is a request that never includes that information.

When the clients are medical practices: the subcontractor chain

HIPAA reaches the same place by a different route. Under 45 CFR 160.103, a business associate includes “A subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate,” and a subcontractor is a person to whom a business associate delegates a function, activity or service. An MSP that holds a medical practice’s protected health information in its systems is that practice’s business associate under the same definition; a consultant the MSP lets into those records would be one link further down.

HHS’s guidance on cloud computing shows how little it takes. A cloud service provider that stores only encrypted ePHI and holds no key is still a business associate, because “An entity that maintains ePHI on behalf of a covered entity (or another business associate) is a business associate, even if the entity cannot actually view the ePHI.” A PSA ticket with a screenshot of a patient record is protected health information wherever it sits. The practical conclusion is not that a consultant needs a business associate agreement to review an MSP’s billing. It is that a billing review should be designed so that no protected health information reaches the consultant at all.

What to send an outside reviewer, and what to keep

Almost every question a business review asks about a managed IT firm — seats billed against seats managed, licenses bought against licenses invoiced, hours worked against hours billed, invoices aging — can be answered from counts and amounts. Nothing in it needs a sentence a technician typed into a ticket.

• Send: the agreement list with client, type, quantity, unit price and start and renewal dates.
• Send: RMM agent counts per client as a number, exported by the firm — not access to the RMM.
• Send: distributor and vendor invoices by SKU and client, and the invoice register for the same months.
• Send: time entries with date, technician, client, agreement, work type, hours and the billable flag — with the notes, descriptions and resolution text removed.
• Send: A/R aging by client, and ticket counts by client, type and agreement, with no ticket text.
• Keep: ticket notes, descriptions, attachments and screenshots; configuration records; documentation and password tools; the RMM and remote-control consoles; client tenant and admin portals; full contact lists; and any client’s own customer or patient data.

Client names can be replaced with codes — Client 01, Client 02 — with the key kept inside the firm. A reviewer who needs to know that one client’s invoices age past 90 days does not need to know which client it is until the firm decides to say.

A read-only login or exports: the trade-off

Exports run by the firm’s own staff leave no standing access to revoke and let the firm see every field before it leaves. The cost is staff time and a slower back-and-forth when a question needs a second cut of the data.

A login is faster and lets the reviewer answer follow-up questions without waiting on anyone. If the firm chooses one, it should be a named account for one person, never a shared or existing technician login; a read-only role limited to agreements, time entries, invoices and reports; multi-factor authentication on; no access to ticket notes or attachments where the PSA’s permissions allow that split; an end date set when the account is created; and a check that the account is disabled when the work ends. CISA’s first action — disable accounts no longer in use — is easier to keep when the end date was written down on day one.

Some firms do both: a short read-only window for the first week, then exports for anything further. The right choice depends on how the PSA’s permissions are built and on what the firm’s client contracts allow, which is why the request list belongs in writing before either one.

What to put in writing before anything moves

These belong in the first conversation and in the signed document, whoever the reviewer is — including us.

• An NDA signed before any record opens.
• The request list, field by field, with why each field is needed and what is never requested.
• Login or exports; if a login, the role, the named user, multi-factor authentication and the end date.
• Where the files will be stored, who at the reviewer’s firm can open them, and on what devices.
• Which other tools or subcontractors will touch the files — including any analysis or AI tool — and under what terms.
• Deletion at the end: what is deleted, by when, and how that is confirmed to the firm in writing.

A reviewer who can answer these on one page has thought about it. One who asks for an admin login “to save time,” or whose answer is “we’re secure,” has answered a different question. The firm can decline that engagement, whatever it promises to find.

When the answer is to share nothing — and how our Review works

If a question can be answered from counts, nothing beyond counts needs to leave the firm. If a client contract forbids sharing even billing-level data about that client, leave that client out or code it. And if the real issue is a security incident, a client audit or a compliance finding, that is work for a security professional and counsel, not for a business reviewer.

Our Revenue Review is built for the minimal end of that range. It reads the firm’s own records: read-only access to the PSA or exports the firm runs itself, a billing-level export of RMM agent counts per client, the distributors’ license bills, and QuickBooks or Xero, under an NDA signed before anything opens. Nothing in client environments: no remote-control rights, no tenant access, no credentials to client systems. It never touches a ticket, ticket notes are not part of the request, and client names can be coded. It takes two weeks and ends in a written report the firm keeps. It gives no legal advice and certifies no compliance with any rule.

The next step is a free 20-minute call. Bring the list of exports the PSA can produce; the call is where a request list gets written before anything moves.