How to Audit Third-Party Access Controls in MSP Agreements

import CTA from ’../../components/CTA.astro’;

How do you audit third-party access controls in MSP agreements?

To audit third-party access controls in MSP agreements, we recommend reviewing three things together: what the contract says, what the MSP and its subcontractors can actually access, and what evidence proves those controls are enforced over time. In practice, that means validating least-privilege access, MFA, privileged account handling, onboarding and offboarding, logging, audit rights, breach notification language, and recurring access reviews instead of assuming the contract alone is enough.¹²³

That matters because most third-party risk does not come from one dramatic failure. It usually comes from smaller control gaps that compound quietly: a stale admin account, a broad support login, undocumented subcontractor access, missing log review, or vague shared-responsibility language that leaves everyone assuming someone else owns the problem.³⁴

We see this most often in organizations that depend on an MSP for core infrastructure, cloud administration, endpoint support, or regulated workflows. The relationship may be productive overall, but if nobody periodically checks who can access what, under which conditions, and with what oversight, the agreement can create more hidden exposure than leadership realizes.

That is why we think the right audit question is not just, “Does our MSP have security controls?” It is: can we prove third-party access is limited, reviewed, monitored, and contractually enforceable before an incident forces the issue?

Which contract terms matter most when auditing third-party access?

The contract is where access expectations should become operationally testable. If the agreement is vague, the audit usually becomes vague too. We recommend starting with the clauses that define who may access your systems, what controls govern that access, and what rights you have to verify compliance.²³

Shared-responsibility language should be explicit

A strong MSP agreement should make it clear which party owns endpoint configuration, identity controls, logging, incident escalation, backup protections, data retention, and third-party oversight. If the contract uses broad phrases like “industry-standard security” without assigning ownership, the audit will likely uncover blind spots instead of accountability.²⁵

We usually want to see language that answers questions like:

Who provisions and approves privileged accounts?
Who is responsible for MFA enforcement?
Who reviews access logs and how often?
Who approves subcontractor or fourth-party access?
Who handles account removal when support staff roll off the account?

That same discipline should carry into related operating documents, including your managed IT services overview, internal vendor reviews, and broader vendor governance process.

Right-to-audit and evidence clauses matter more than teams expect

If your contract does not let you request evidence, review controls, or assess exceptions, the audit may stop at promises. The Institute of Internal Auditors specifically highlights the value of robust right-to-audit language in third-party risk management because it gives the customer a real mechanism to validate control performance instead of relying on marketing claims alone.³

At minimum, we want audit language that supports requests for:

current access control policies
privileged account inventories
MFA evidence or configuration attestations
recent access review results
subcontractor lists and scope of access
SOC 2 Type II or comparable assurance reports
incident response and breach notification procedures

Data handling clauses should define boundaries, not just intentions

Contracts should also document where sensitive data lives, what encryption standards apply, how long data is retained, and how data is deleted at contract end.² This is especially important when an MSP touches regulated workflows tied to healthcare IT, financial services IT, or multi-site operations that depend on remote administrative access.

What evidence should you request from the MSP and its vendors?

A useful audit is evidence-driven. We recommend asking for documents and records that show how access is granted, limited, reviewed, and revoked in practice. That includes both formal assurance artifacts and operating evidence from day-to-day support workflows.¹²

Start with governance and assurance evidence

Ask for the current access control policy, vendor risk management policy, incident response plan, and any shared-responsibility matrices tied to your services. If the MSP has a recent SOC 2 Type II report, ISO 27001 certification support, or similar assurance documentation, review the sections tied to logical access, privileged activity, change management, and third-party oversight.²⁵⁶

Those reports do not replace your own audit, but they help narrow where you need deeper testing. A clean report can still hide operational friction if the control descriptions are broad, the exceptions are not understood, or the scope excludes a subcontractor with meaningful access.

Then ask for operating evidence

This is where many audits get more useful. Beyond policy documents, ask for evidence such as:

a list of all vendor and MSP accounts with administrative or remote-support access
role descriptions for each privileged group
the approval trail for recent account creation and access changes
the latest user access recertification results
termination or offboarding records for recently removed vendor users
samples of login logs, PAM session logs, or remote access logs
evidence that stale accounts are disabled on schedule

If the MSP uses a subcontractor, ask whether those users appear in the same review process or live in a separate system. Hidden fourth-party access is one of the easiest ways for vendor risk to become harder to see and harder to control.³

Pay attention to exceptions and emergency access

Most environments need some form of break-glass or urgent support access. That is not automatically a red flag. The issue is whether emergency access is logged, time-bounded, approved, and reviewed after use. We are usually more concerned by undocumented “temporary” admin access than by a well-controlled emergency process.

How should you test privileged access and least privilege?

Privileged access is usually the center of the audit because a single broad admin account can bypass multiple downstream controls. We recommend evaluating not only whether privileged roles exist, but whether they are constrained to the minimum scope necessary for support delivery.¹³⁷

Review who has administrative access and why

Map each privileged account to a real function. If a technician has global administrator access to Microsoft 365, domain admin rights, backup admin rights, and firewall privileges at the same time, we want to know why that breadth is necessary and how it is governed.

Questions we typically ask include:

Is access role-based or assigned ad hoc?
Are named accounts used instead of shared admin credentials?
Is privileged access separated from daily user activity?
Are admin roles segmented by system, site, or client?
Is just-in-time or time-limited elevation used where feasible?

CISA has repeatedly emphasized MFA and stronger controls around MSP administrative access because attackers actively target service-provider pathways as a way to reach many customers at once.⁷

Check whether least privilege survives real operations

A policy may say “least privilege,” but the audit should confirm whether that principle still holds during after-hours work, escalations, migrations, onboarding, and incident response. We often see organizations adopt broad access at the start of a relationship and then never reduce it after the environment stabilizes.

That is why access reviews should not just confirm that a user still works for the vendor. They should verify that the current level of access is still justified by the current scope of work.³

Review authentication controls for privileged activity

Privileged access should generally require MFA, strong identity proofing, and clear device or session controls. We also prefer to see privileged access management or at least enhanced logging around administrative sessions where regulated or high-impact systems are involved.¹²⁸

What should the audit look for in onboarding, offboarding, and review workflows?

A large share of third-party access risk shows up during transitions. New users get added too broadly, old users remain active too long, and role changes are handled informally. We recommend treating lifecycle controls as a core audit area rather than an administrative afterthought.¹³

Onboarding should require approval and scope definition

When a new MSP or subcontractor user is added, there should be a documented request, an approval from the right internal owner, and a clear statement of what systems that user actually needs. If onboarding is handled over chat or email without structured review, over-permissioning tends to follow.

Offboarding should be testable

We want to know how quickly access is removed when a technician leaves the MSP, changes roles, or is removed from your account. Audits should sample recent departures or account changes and confirm that removal was timely, complete, and reflected across all relevant systems.⁷

That often means checking more than identity platforms. Remote monitoring tools, ticketing systems, backup consoles, endpoint tools, VPN accounts, cloud portals, and firewall management platforms may all need separate validation.

Recertification should happen on a schedule

Periodic access reviews are one of the most practical controls in this area. Whether quarterly, semiannually, or risk-based, the key is that someone reviews access lists against current business need and documents the outcome. A review that is never completed or never challenged is not doing much risk reduction.³

For organizations building a broader governance program, this audit usually pairs well with adjacent work like third-party cyber risk assessment checklists, MSP vendor call prep, and managed firewall coverage reviews.

How do logging, monitoring, and incident response fit into the audit?

Access control without visibility is hard to trust. Even if permissions are well designed, the audit should confirm that third-party access is logged, monitored, and tied to escalation procedures that make sense for your environment.¹²

Logs should be useful, retained, and reviewable

We want logs that show who accessed what, when, from where, and with what level of privilege. In more sensitive environments, session-level visibility or privileged action trails may be appropriate. The exact logging stack can vary, but the audit should establish whether the organization can reconstruct third-party activity if something goes wrong.

Questions worth asking:

Are remote support sessions logged?
Are failed login attempts reviewed?
Are privileged changes tied to named users?
How long are logs retained?
Who reviews alerts tied to vendor activity?

Incident response should include third-party access scenarios

An MSP agreement should define how suspicious or unauthorized third-party activity is escalated, contained, investigated, and communicated. That includes breach notification timelines, points of contact, preservation of evidence, and responsibilities for customer notification where required.¹²

If the incident plan says the MSP will notify you “promptly,” we usually want more precision than that. For regulated organizations, ambiguity around notification timing can become a major problem during an actual event.

What does a practical audit checklist include?

A practical audit should usually cover these checkpoints:

contract defines shared security responsibilities clearly
right-to-audit and evidence request language is present
subcontractor and fourth-party access is disclosed
privileged accounts are inventoried and tied to named users
MFA is enforced for remote and privileged access
least-privilege design is documented and reviewed
onboarding and offboarding approvals are retained
periodic access recertification is performed and evidenced
remote sessions and privileged activity are logged
incident response and breach notification obligations are defined
exceptions and emergency access are time-bounded and reviewed
assurance reports are current and relevant to scope

That checklist is not meant to turn the audit into paperwork theater. It is meant to make sure the core access-control questions are answered in a way leadership, compliance teams, and operations leaders can all understand.

What is the takeaway for mid-market and regulated organizations?

The main takeaway is that auditing third-party access controls in MSP agreements is not just a compliance exercise. It is an accountability exercise. The goal is to make sure third-party support access is narrow enough to reduce risk, visible enough to investigate, and documented well enough to enforce when expectations slip.²³⁷

In our experience, the strongest organizations do not treat MSP access as a background assumption. They review it as part of vendor governance, cyber resilience, and day-to-day operational discipline. They know which third parties have elevated access, how that access is approved, how it is monitored, and what evidence exists when auditors, insurers, or executives ask harder questions.

If your team depends on outsourced support, regulated workflows, or complex multi-vendor operations, this is one of the best places to reduce preventable risk before it turns into incident-response pressure.

FAQ: Auditing third-party access controls in MSP agreements

What should an MSP agreement say about third-party access?

An MSP agreement should define who can access your systems, what level of access is allowed, which controls apply to privileged accounts, how subcontractor access is handled, what evidence you can request, and how incidents involving third-party access must be reported and investigated.

How often should third-party access be reviewed?

Most organizations should review third-party access on a recurring schedule based on risk, often quarterly or semiannually for meaningful administrative access. Reviews should also happen when scope changes, key vendor staff change, or a major incident raises new concerns.

Is a SOC 2 report enough to validate MSP access controls?

No. A SOC 2 report is helpful evidence, but it does not replace your own review of contract language, current access lists, privileged roles, lifecycle controls, and the specific subcontractors or tools involved in your environment.

What is the biggest red flag in an MSP access audit?

One of the biggest red flags is broad administrative access that nobody can justify clearly. Shared admin credentials, undocumented subcontractor access, stale accounts, or weak offboarding are also strong signs that the relationship needs tighter control design and oversight.

Healthcare

K-12 Districts

Financial Services & PE

Unified Platform Overview

Continuous Protection

Operational Stability

Strategic Accountability