The MSP is the one party in a CPCSC program that doesn't sign anything and still ends up in the assessment. It isn't a defense supplier. Its client is. But if it administers the systems where the client's Specified Information lives, its access, its tooling, and its personnel are inside the client's scope, and the assessor will look at them.
Most MSP relationships weren't built with that in mind.
The bench with a remote tool on every machine
I've had MSPs tell me "this is how we do it" while their whole bench had a remote tool on every machine.
That is very hard to defend against the access control and maintenance requirements, because it isn't role-based anything. Does every technician need access to everything? Almost never. And do the people who hold access have the screening the contract requires?
There is also a security argument that has nothing to do with compliance. I've seen remote support tools compromised and used to wipe fleets. The tool that lets the MSP fix your server is the same tool an attacker wants.
What I'd build instead
Put remote access through a jump host with MFA on the session. 03.07.05, non-local maintenance, requires MFA for it. The technician authenticates to the jump host, the jump host is the only path into the enclave, and the jump host is where the logging happens.
Keep administrative work on separate admin workstations, and never work under an admin account day to day. 03.14.09 sets a stricter bar for those workstations.
If a remote support tool stays, turn on session recording from the moment of login.
The assessor's questions are ordinary. When was the server last touched? By whom? Show the login and logout. Show the patch window and what was applied. Screenshots and a basic central log server answer all of it. Nobody is asking for a SIEM.
Who assesses the MSP's work
Your IT provider shouldn't be assessing its own work. Some won't tell on themselves.
So keep the checking at arm's length. Run your own vulnerability scans, with proper tools. Audit switch and firewall configurations with something like rConfig or Nipper. If the MSP says "we do vulnerability management for you," or "our tool says you're secure," verify it with your own scan and your own read of the configs.
Two red flags. A provider that hides behind "proprietary" or refuses configuration access. And an MSP running a sales-oriented assessment tool and calling it a security assessment. It may tick a box, and it is still a sales tool.
Put it in a matrix
"They handle our IT" is not a control description. The program forces a written responsibility matrix: requirement by requirement, who operates the control, who holds the evidence, and what deliverable arrives on what cadence. Sample rows from the one I use:
- Patch management: MSP operates, MSP holds evidence, patch report monthly
- Firewall rule set: MSP operates, rule review quarterly, client keeps a copy
- Log collection and review: MSP operates, weekly digest to a client mailbox
- Backup and restore test: MSP operates, restore test log quarterly
If the MSP runs the control, the MSP produces the evidence, on a schedule, as a contract deliverable. Have that conversation early and in writing. It surfaces 2 uncomfortable discoveries at a survivable moment. Some MSPs can't support this work, and 2026 is a better time to learn that than mid-assessment. And the MSP's own security posture is part of your risk story, because its remote access into your enclave is one of your attack paths.
Top comments (0)