Test a vendor claim of complete coverage against the accounts and systems it actually checks. A cybersecurity self assessment should show what you've checked in your MSP's environment and what you still don't know. Start with the administrative access that can reach client systems. A reassuring score means little if the connected account list describes a different business.
Keep a findings record that says what you checked, who owns each gap, and how you'll verify the fix. Choose work you can examine properly in the time available, then record what remains outside that review. A short booking in the calendar is no basis for declaring an unexamined environment secure.
Confirm Whose Environment the Tool Is Assessing
Write down which business and systems you're checking before connecting another integration. Identify the MSP-owned tenant and management services, with the administrative paths into client environments recorded separately. An account that can see a system doesn't give you permission to inspect it.
Justin Esgar describes a compliance tool connected through his Cloudflare account reporting missing MFA on client accounts he could access, although he intended to assess his own MSP. That practitioner account illustrates a scope problem. That doesn't mean every integration includes the wrong accounts. It gives you something specific to check.
Compare the tool’s account and asset list with the environment you intended to assess. Resolve unexplained inclusions and omissions before interpreting its results. Whose tenant you're checking matters more than the color of the dashboard.
Treat the checklist like checking a building’s fire doors: the inspection needs the right doors and evidence that each one works. A claim about what the product can do doesn't show how it's configured in this MSP.
Follow Administrative Access to Its Reach
Start with the people and service identities that administer the tools used to reach clients. Record what each identity can do and who owns it. Check whether privileges match the current role rather than assuming that a familiar account is still required.
Checking ordinary email users won't tell you whether a separate remote-management login is protected.
For human administrator access, review the effective authentication requirement and any exception. For a service integration, identify the credential or permission mechanism actually in use and its owner. Don't mark an integration protected by MFA just because the person who created it uses MFA to sign in.
Check recovery access too. Check whether an authorized responder can regain administration when the normal sign-in route fails. Check how that recovery access is controlled. If nobody owns the recovery account, you've found another access gap to resolve.
Require Evidence for Each Finding
Use this as a proposed assessment record, adapted to the controls and services your MSP operates. Retain the relevant evidence securely and reference it from the record. Avoid copying client secrets into a general-purpose checklist.
| Area to Examine | Evidence to Seek | Owner of the Follow-Up |
|---|---|---|
| Administrative identity | Effective privileges and authentication requirements for the actual management accounts, with explained exceptions. | Identity owner |
| Remote-management access | The authorized access routes and current account list for the tools used to reach client systems. | Tool owner |
| Endpoint and email protection | The MSP's expected device and user list compared with actual deployment and policy status. | Internal systems owner |
| Maintenance | The applicable update state, with failed or deferred work identified and assigned. | Internal systems owner |
| Detection handover | A permitted test event that reaches the intended responder and produces a recorded next action. | Monitoring owner |
| Recovery | A completed recovery check for the selected service, including the access needed to perform it. | Recovery owner |
| Incident authority | The named person who can lead the response and the client communication route if normal systems are unavailable. | MSP owner |
| Unverified items | The missing evidence or unexamined system, with a reason and a named next action. | Assessment lead |
The model makes baseline security part of every service plan. Apply that expectation to your own MSP while checking the actual implementation. A policy document and an installed agent are different evidence, and neither by itself proves every relevant asset is covered.
This proposed record is an internal working method, not a certification assessment or a promise of insurer acceptance.
Test Who Finds Out First
An alert configured in a console can still fail at the handover to a person. Arrange a permitted test that the tool supports, then follow the event to the intended responder. Record whether the person can interpret it and take the authorized next action.
If the event reaches an unattended mailbox, the mailbox may be the first place the evidence arrives while nobody responsible sees it. Correct the routing and repeat the same permitted test. Don't assume every detection works because an unrelated notification arrived.
Check how that route behaves when the usual responder is unavailable. Name the backup and confirm access to the information needed for the response. Keep responsibility explicit where an external monitoring provider receives the event first.
Use a suitable recovery test to examine a selected critical service. Confirm that the recovered result is usable for the intended task. If the test relies on a credential stored only inside the failed system, record that dependency and resolve it before claiming the recovery route works.
Separate a Gap From a Conclusion You Cannot Support
Whether a breach at your MSP reaches a client depends on how your tools reach that client. Map those paths. Don't assume every incident compromises every client. Prioritize the gaps by what the evidence shows they can reach and what that means for the business, and record what you still don't know.
A missing tool result could mean an unprotected asset, failed collection, or a tool checking the wrong systems. Investigate which explanation the evidence supports. Don't call unavailable evidence a confirmed control failure.
If the work identifies signs of an active incident, route it through the incident process and preserve the relevant evidence. Don't keep treating it as a routine checklist item. If it's past what your team can investigate, call someone who can.
Close Findings With a Repeatable Check
Have the assessment lead record each finding and the evidence that supports it. Have the person responsible write the corrective action and the check needed to close it. If a risk stays open, you decide what happens to it within your authority and obligations. Write that decision down.
Retest the specific control after the change. Keep the before-and-after evidence tied to the finding so the next reviewer can see why it was closed. A closed remediation ticket doesn't show the fix worked without that check.
Start with an administrative route into a client environment and confirm which identities it can use. Follow the selected control through to its evidence and owner. Extend the review from there. Keep the work you haven't checked visible; don't let the tool's summary stand in for the assessment.
mspoutpost.com/articles/cybersecurity-self-assessment-check-your-own-msp
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.