Why MSP Internal Audits Require a Different Approach
Before working through the audit script, it is worth understanding what makes MSP internal audits structurally different from standard enterprise ISMS audits because that difference determines what the script needs to test.
MSPs Have Two Attack Surfaces
The internal audit scope for an MSP does not end at the MSP’s own perimeter. Your RMM platform, backup console, PSA system, and privileged admin accounts in client tenants are all part of your audit scope. An audit that only tests MSP-internal controls and ignores how you access client environments is an incomplete audit.
Shared Accounts Are Structurally Embedded
Generic service accounts, shared break-glass passwords, and pooled RMM super-admin credentials are operational norms in most MSPs — and they are exactly the control weaknesses that both auditors and attackers look for first. Testing these controls requires explicit procedures, not just a policy that says shared accounts should be minimized.
Backup Controls Are Evidenced Inconsistently
Most MSPs back up client data and have backup policies. What they frequently lack is documented evidence that restoration testing happened, that backup integrity was verified, and that specific clients’ backup SLAs are being met. The audit gap is not in operations it is in evidence.
Vendor Controls Span a Broader Ecosystem
An MSP’s vendor list includes RMM platforms, PSA tools, documentation systems, security tooling, cloud providers, and subcontractors many with privileged access to MSP systems or client environments. The audit must verify these relationships are formally assessed, contractually governed, and actively monitored.
How to Use This Audit Script
This script is structured as a three-part internal audit covering shared access, backup, and vendor controls. Each section follows the same format:
What Each Section Contains
→Audit Objective — what the audit is designed to confirm
→ISO 27001 Reference — the specific control(s) being tested
→Audit Questions — the questions the auditor asks of the process owner
→Evidence to Request — the specific documents, records, or system outputs to review
→Test Procedures — the active verification steps beyond document review
→Finding Language — how to document a non-conformity if the control is absent or not operating
Independence Requirement
Run each section with the relevant process owner, not with the ISMS owner reviewing their own work. The internal audit must have sufficient independence to be credible — which means the person auditing shared access controls should not be the person who manages those accounts.
The internal audit must have sufficient independence to be credible to your certification body. An audit that confirms the control owner’s own work finds nothing — because it was designed to find nothing.
Part
1
Annex A 5.15 · 5.16 · 5.17 · 8.2 · 8.18
Auditing Shared and Privileged Access Controls
Audit Objective
To verify that privileged and shared access to client environments, MSP internal systems, and critical tooling (RMM, PSA, backup consoles) is governed by documented controls, that individual accountability is maintained, and that access is reviewed and revoked appropriately.
1.1
Does the organization maintain an inventory of all privileged accounts including service accounts, break-glass accounts, and shared admin credentials across the MSP’s own systems and all client environments?
Evidence to Request
→Privileged account inventory or register (spreadsheet, PSA record, or identity management platform export)
→Date of last review and name of reviewer
→Confirmation that the inventory includes both internal MSP accounts and accounts held in client tenants
Test Procedure
Cross-reference the account inventory against a live export from the RMM platform and the MSP’s Identity Provider (IdP). Check for accounts present in the live export that are not reflected in the inventory. Specifically look for:
→ Generic or role-named accounts (admin@, support@, svc-backup@) with no named owner
→ Accounts with no login activity in the past 90 days that remain active
→ Accounts associated with former employees still active in any environment
Finding Language (Non-Conformity):
“A review of the privileged account inventory against the live RMM and IdP export identified [X] accounts present in active systems that are not reflected in the documented account register. [X] accounts showed no login activity in the past [Y] days and remain in an enabled state with no documented justification. This does not satisfy the requirements of ISO 27001 Annex A 8.2 (Privileged Access Rights), which requires that access rights be formally managed and reviewed.”
Finding Language (Observation):
“The privileged account inventory exists but was last reviewed [date], which exceeds the documented quarterly review cycle. No accounts appear incorrectly provisioned, but the review cadence is not consistent with the documented policy.”
1.2
Are shared or generic admin accounts used to access client environments via the RMM platform and if so, is use of those accounts individually accountable through session logging or a check-out/check-in process?
Evidence to Request
→RMM platform configuration showing whether shared accounts are in use or whether access is tied to named individual accounts
→Session logging configuration confirmation that all remote sessions are logged with the initiating user’s identity, session duration, and systems accessed
→Break-glass account procedure the documented process for using emergency access credentials, including pre-authorization requirements and post-use review
Test Procedure
Log into the RMM platform’s session history or audit log. Sample five recent remote sessions to client environments. For each session, confirm that the initiating user is individually identifiable (not a shared account), the session duration and accessed systems are logged, and the session was associated with a ticket or documented task.
Request the audit log for any break-glass or emergency admin account used in the past 90 days. Verify that each use has a documented pre-authorization record and a post-use review note.
Finding Language (Non-Conformity):
“Review of RMM session logs identified [X] remote sessions initiated by a shared service account (account name: [X]) with no individual accountability for the initiating technician. Session logging configuration does not capture the identity of the individual who used the shared credential. This represents a non-conformity against ISO 27001 Annex A 8.2 and Annex A 8.18, which require that privileged utility access is restricted to authorized individuals and that access is logged and accountable.”
1.3
Is there a documented and operating access review process that periodically verifies all privileged access internal and client-side is still appropriate for the current role and employment status of each account holder?
Evidence to Request
→Access review records for the past two review cycles (date, reviewer, accounts reviewed, changes made)
→Evidence that the review covers both internal MSP accounts and accounts in client tenants
→HR offboarding records for any staff departures in the past six months — evidence that access was revoked within the documented SLA
Test Procedure
Select two former employees who left the organization in the past six months. Cross-reference their departure date against the access revocation records in the IdP, the RMM platform, and the PSA system.
Confirm that all access was revoked and on what date. Calculate the gap between departure date and revocation date and compare against the documented offboarding SLA.
Finding Language (Non-Conformity):
“Access revocation records for [employee name/role], who departed on [date], confirm that RMM platform access was not revoked until [date] – [X] days after departure. The documented offboarding SLA requires revocation within 24 hours. This represents a non-conformity against ISO 27001 Annex A 5.15 and 8.2.”
1.4
Is Multi-Factor Authentication (MFA) enforced on all privileged accounts — including RMM, PSA, backup console, and all client tenant administrative accounts without exception?
Evidence to Request
→MFA configuration reports from each critical platform (RMM, PSA, backup console, IdP)
→Evidence of any accounts with MFA exceptions — named accounts, documented business justification, and compensating controls
→Date of last MFA compliance review
Test Procedure
Request an export of all admin-level accounts from the RMM platform and the backup management console. Cross-reference against the MFA status report. Identify any accounts at admin privilege level with MFA disabled or not enforced.
There should be zero. Any exception requires a documented and current business justification with a compensating control record. A policy that “requires” MFA but allows exceptions without documentation is not operating as written.
Finding Language (Non-Conformity):
“The MFA status report for the RMM platform identified [X] accounts at administrative privilege level with MFA not enforced. No business justification or compensating control record is documented for these accounts. This does not satisfy ISO 27001 Annex A 5.17 (Authentication Information) or the organization’s own Access Control Policy, which requires MFA on all privileged accounts.”
Is Your MSP Audit Programme Certification-Ready?
Find your gaps before the surveillance auditor does
Canadian Cyber designs and delivers internal audit services tailored specifically for MSPs including privileged access reviews, backup control verification, vendor assessment, and full ISMS audit programme management under ISO 27001 Clause 9.2.
Part
2
Annex A 8.13 · 8.14 · 5.29
Auditing Backup Controls
Audit Objective
To verify that backup controls for managed client environments are implemented as documented, that backups are verified as restorable, that backup integrity testing occurs at the documented frequency, and that recovery time and recovery point objectives are being met.
2.1
Does the organization maintain a current backup coverage inventory — a documented record of which client systems are backed up, at what frequency, with what retention period, and to which target and is this inventory verified as accurate?
Evidence to Request
→Backup coverage inventory or backup register (listing client, system/asset, backup frequency, retention period, backup target, and last verified date)
→Evidence of the last accuracy review confirming the inventory matches what is actually configured in the backup management platform
→Any clients with systems not covered by backup — with documented business justification (e.g., client declined backup service)
Test Procedure
Select three client environments from the backup coverage inventory. Log into the backup management console and verify that the backup policy configuration matches what is documented for each selected client frequency, retention, and target. Identify any discrepancy between the documented and configured backup policy.
Additionally, pull the backup failure alert log for the past 30 days. Identify any backup jobs that have failed consistently without a documented resolution or client notification.
Finding Language (Non-Conformity):
“Cross-referencing the backup coverage inventory against the live backup console configuration for [client name] identified a discrepancy: the inventory documents a daily backup with 30-day retention, while the active backup policy is configured for weekly backup with 14-day retention. No change record or client authorization for this discrepancy exists. This does not satisfy ISO 27001 Annex A 8.13, which requires that backup procedures are implemented and verified.”
2.2
Is backup restoration testing conducted at the documented frequency — and is the outcome of each test recorded with sufficient detail to confirm the backup is recoverable?
Evidence to Request
→Backup restoration test log for the past 12 months — listing client, system, test date, restoration method, files/volumes tested, test result, and test conductor
→Evidence of both automated integrity verification (hash/checksum checks, screenshot verification) and manual restore testing
→Any restoration test failures and the corrective actions taken
Test Procedure
Review the restoration test log and calculate the percentage of covered client environments that received a documented restoration test in the past 12 months. For any client that has not had a restoration test in the documented period (typically quarterly for critical systems, annually for standard), document as a finding.
Pull the automated backup verification logs from the backup platform. Confirm that automated integrity checks are configured and running at the documented frequency. Identify any systems where automated verification is disabled or returning uninvestigated errors.
Finding Language (Non-Conformity):
“The backup restoration test log shows that [X] out of [Y] client environments in scope have not had a documented restoration test in the past 12 months. The MSP’s backup policy requires annual restoration testing for all covered environments. This is a non-conformity against ISO 27001 Annex A 8.13 and represents a material gap in the MSP’s ability to assure clients of backup recoverability.”
Finding Language (Observation):
“Restoration testing is conducted and documented; however, the test records do not capture the specific files or volumes tested, the restoration duration, or confirmation that the restored system was functionally operational. This level of documentation is insufficient to satisfy a client or auditor request for restoration test evidence.”
2.3
Are backup targets protected against ransomware specifically, are backups stored in immutable or air-gapped locations, and is access to the backup management console separately controlled from the systems being backed up?
Evidence to Request
→Backup architecture documentation confirming immutable storage configuration or air-gapped backup targets
→Confirmation that backup management console credentials are not the same as, or derivable from, the credentials used to access the systems being protected
→Evidence that backup console MFA is enforced separately and that access is reviewed independently of general access reviews
Test Procedure
Review the backup platform configuration for immutability settings. Confirm that the backup retention lock or equivalent feature is enabled for the retention period documented in the backup policy. Verify that the configured immutability period cannot be changed or disabled without a separate authorization step.
Cross-reference the backup console admin accounts against the RMM and domain admin account lists. Identify any accounts that have both backup console admin access and domain admin or RMM admin access in the same client environment these represent single points of failure where one credential compromise could destroy both the production environment and its backup.
Finding Language (Non-Conformity):
“Review of the backup platform configuration for [X] client environments identified that immutable retention lock is not enabled. Backups for these clients are stored in a location accessible with standard backup console admin credentials, which are not separated from the domain admin credential set. A ransomware operator with domain admin credentials would have the ability to access and delete backup data for these clients. This is a non-conformity against ISO 27001 Annex A 8.13 and represents a critical gap in the MSP’s backup resilience architecture.”
2.4
Are documented Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) in place for each client tier and does the current backup configuration demonstrably meet those objectives?
Evidence to Request
→Client service agreements or backup addenda documenting agreed RTO and RPO by client tier
→Backup configuration showing backup frequency (confirming RPO is achievable based on backup interval)
→Most recent restoration test results confirming the restoration duration (confirming RTO is achievable based on actual recovery speed)
Test Procedure
Select two clients one from each service tier if tiered services are offered. Compare their contracted RTO and RPO against the current backup configuration frequency and the most recent restoration test duration.
Document any gap between the contractual commitment and what the current configuration and testing evidence demonstrates is achievable. An RTO committed in a service agreement but never validated against a real restore test is an unverified claim and an audit finding.
Finding Language (Non-Conformity):
“Client [name] has a contracted RTO of 4 hours. The most recent restoration test for this client, conducted [date], recorded a restoration duration of 6.5 hours. No remediation action or client notification is documented following this test result. The current backup architecture does not demonstrably meet the contracted recovery time commitment.”
Part
3
Annex A 5.19 · 5.20 · 5.21 · 5.22
Auditing Vendor and Supplier Controls
Audit Objective
To verify that the MSP’s vendor and supplier relationships are formally identified, risk-assessed, contractually governed, and actively monitored and that the controls governing vendor access to MSP systems and client data are operating as documented.
3.1
Does the organization maintain a current, complete supplier register — listing all third-party vendors and subcontractors with access to MSP systems or client data, including cloud platforms, software tools, and subcontracted labour?
Evidence to Request
→Supplier register (listing vendor name, service type, data access scope, risk tier, contract reference, last review date, and security certification status)
→Confirmation that the register is reviewed and updated at least annually, or when new vendors are onboarded or existing relationships change materially
→Any vendors identified as having access to client data that are not on the register
Test Procedure
Pull a list of currently active vendor accounts in the RMM platform, PSA system, and identity provider. Cross-reference against the supplier register. Identify any vendor accounts in active tooling that are not reflected in the register.
Additionally, check procurement records or the finance system for any software subscriptions or services paid in the past 12 months that are not on the supplier register. A supplier register that does not reflect your finance system’s active vendor payments is an incomplete register.
Finding Language (Non-Conformity):
“Cross-referencing active vendor accounts in the RMM platform against the supplier register identified [X] vendor accounts with access to client environments that are not listed in the register. Additionally, a finance system review identified [X] active software subscriptions with potential access to MSP or client data that are not captured. The supplier register does not represent a complete picture of the MSP’s vendor ecosystem. This is a non-conformity against ISO 27001 Annex A 5.19.”
3.2
Are Data Processing Agreements (DPAs) or contractual security schedules in place with all vendors that process personal data specifically covering data handling obligations, breach notification requirements, and subprocessor disclosure?
Evidence to Request
→DPAs or security addenda for all Tier 1 (critical) vendors in the supplier register
→Confirmation that DPAs are current not expired and not based on a prior regulatory regime
→Any vendor relationships where personal data is processed without a current DPA in place
Test Procedure
For each Tier 1 vendor in the supplier register, confirm the existence of a current DPA or security schedule. Review the DPA for the following minimum provisions:
→ Explicit description of data types processed and the purpose of processing
→ Breach notification clause with a defined timeline (72 hours is the PIPEDA benchmark)
→ Subprocessor disclosure and consent mechanism
→ Data deletion or return provision upon contract termination
→ Security standard commitments (SOC 2, ISO 27001, or equivalent)
Finding Language (Non-Conformity):
“The supplier register lists [vendor name] as a Tier 1 supplier with access to client personal data. No Data Processing Agreement is on file for this relationship. The MSP’s Supplier Security Policy requires a DPA for all vendors processing personal data. This is a non-conformity against ISO 27001 Annex A 5.20 and represents a potential PIPEDA compliance gap.”
3.3
Are vendor security certifications (SOC 2, ISO 27001, or equivalent) verified as current — and is there a process for monitoring certification expiry and requesting renewal evidence?
Evidence to Request
→Security certification records for all Tier 1 vendors — SOC 2 Type II report date, ISO 27001 certificate expiry date, or equivalent
→A monitoring calendar or reminder system for certification renewal review
→Any vendors where the most recent certification is more than 12 months old
Test Procedure
For each Tier 1 vendor, check the audit period or expiry date of the most recent security certification on file. SOC 2 Type II reports are typically issued annually — any report older than 18 months represents a gap.
ISO 27001 certificates are valid for three years but should be checked against the certification body’s public registry to confirm the certificate has not been suspended or withdrawn. Identify any vendors where no current certification is on file and no alternative security evidence is available.
Finding Language (Non-Conformity):
“The security certification file for [vendor name] a Tier 1 supplier with direct access to client environments — contains a SOC 2 Type II report with an audit period ending [date], which is [X] months ago. No current report or interim security evidence has been obtained. The MSP’s Supplier Security Policy requires annual verification of security certifications for Tier 1 vendors. This is a non-conformity against ISO 27001 Annex A 5.22.”
3.4
Is vendor access to MSP systems and client environments governed by the same privileged access controls as internal staff including named accounts, MFA enforcement, session logging, and formal access revocation upon contract termination?
Evidence to Request
→List of all active vendor accounts in the RMM, PSA, and backup platforms
→MFA status for each vendor account
→Session logs confirming vendor access is individually accountable and logged
→Offboarding records for any vendor relationships terminated in the past 12 months — evidence that access was revoked promptly upon contract end
Test Procedure
Export the vendor account list from each critical platform. For each vendor account, confirm that the account is tied to a named individual (not a company-level shared login), MFA is enforced, and access scope matches the contracted service scope.
Select any vendor relationships terminated in the past 12 months. Verify that access was revoked on or before the contract termination date. Calculate any gap between termination date and revocation date — this gap is the window of unauthorized access.
Finding Language (Non-Conformity):
“The RMM platform contains an active account for [vendor name] associated with a vendor contract that terminated on [date]. The account remains active [X] days after termination with no documented deactivation request or access review. This represents a non-conformity against ISO 27001 Annex A 5.19 and 8.2 and creates ongoing unauthorized access risk to client environments.”
How to Document and Report Your Audit Findings
Every finding from this audit script whether a non-conformity, an observation, or an opportunity for improvement — is recorded formally and reported to the ISMS owner for management review.
The Finding Log — Required Fields
→Finding Reference — a unique identifier (e.g., AU-2026-001)
→Audit Section — Access / Backup / Vendor
→ISO 27001 Reference — the specific control the finding relates to
→Finding Type — Non-Conformity (Major or Minor) or Observation
→Finding Description — what the audit test found, stated factually with evidence references
→Evidence Reviewed — the specific records, system outputs, or interviews that produced the finding
→Assigned Owner — the named person responsible for the corrective action
→Corrective Action Required — the specific action needed to close the finding
→Target Closure Date — the date by which the corrective action must be completed
→Closure Evidence Required — what the owner must produce to demonstrate the finding is closed
The Audit Report — Required Sections
→Audit summary — scope, dates, auditor, methodology, and number of findings by type
→Executive summary — a plain-language paragraph on the overall health of the three control domains, suitable for the management review record
→Finding log — the complete table of all findings
→Priority findings narrative — an explanation of the most significant non-conformities and why they represent material risk
→Status of previous findings — confirmation of whether findings from the prior audit cycle were closed as committed
Pro Tip: The audit report is not a performance review of the people who own the controls. It is a review of whether the controls are operating. Language in the report should be factual, evidence-referenced, and specific not evaluative or personal. An audit that produces findings is a successful audit. An audit that produces no findings in a first or second year is almost certainly an incomplete one.
Best Practices for Running a Credible MSP Internal Audit
The MSPs that earn and retain enterprise client trust are the ones whose internal audit programme finds real gaps and closes them before the surveillance auditor does.
1
Separate the auditor from the control owner
The most common credibility failure in MSP internal audits is the ISMS owner reviewing their own controls. For shared access controls, the auditor should be someone other than the person who manages access. For backup controls, someone other than the backup team lead. Use cross-functional audit pairs, engage a vCISO as your internal auditor, or bring in an external ISO 27001 Lead Auditor for the audit function.
2
Test controls, do not just review documents
Policy review is necessary but not sufficient. Every control in this script has a Test Procedure that goes beyond document review — checking live system exports, sampling specific records, and calculating gaps against documented commitments. An audit that only confirms policies exist produces findings like: “Policy exists, no issues noted.” An audit that tests operating effectiveness produces findings that are actionable.
3
Run the audit on a defined schedule and protect the time
ISO 27001 Clause 9.2 requires an audit programme not a single audit. For an MSP, a practical programme is a rolling quarterly partial audit (rotating through access, backup, and vendor controls over three quarters) with a full-scope annual audit before the surveillance audit. Protect the scheduled time as you would any client commitment.
4
Use findings as improvement fuel, not compliance paperwork
The value of the internal audit is not the finding log it is the corrective actions that follow it. Every finding should produce a specific, assigned, time-bound action. Every corrective action should be verified as closed with documented evidence. The next audit should open by confirming every prior corrective action was completed. This cycle find, fix, verify, repeat is what ISO 27001 Clause 10 (Continual Improvement) actually looks like in practice.
5
Make your audit records your surveillance audit preparation
When your certification body’s surveillance auditor arrives, hand them your most recent internal audit report, the prior period’s corrective action closure records, and the management review minutes that addressed both. That package demonstrates that your ISMS is actively managed which is the primary thing a surveillance audit is designed to verify. Organizations that prepare this package proactively move through surveillance audits faster and with fewer findings.
The Internal Audit That Finds Nothing Is the Riskiest One of All
The purpose of an MSP internal audit is not to confirm that your ISMS is operating perfectly. It is to find the gaps before your certification auditor, your cyber insurer’s assessor, or an attacker finds them first.
Shared accounts that have persisted beyond an employee’s departure. Backup restorations that have never been tested for the clients most at risk. Vendor relationships where the DPA was signed at onboarding and never reviewed since. These are not hypothetical findings they are among the most common non-conformities identified in ISO 27001 surveillance audits at MSPs, and every one of them represents a genuine security risk, not just a compliance gap.
An audit programme that uses this script will find findings. That is the point. The findings produce corrective actions. The corrective actions close real gaps. The next audit verifies the gaps are closed. That cycle is what makes your ISMS real rather than documented and what distinguishes the MSPs that earn enterprise client trust from those who learn about their gaps from a breach notification.
Looking to formalize your MSP’s internal audit programme or prepare for your next ISO 27001 surveillance audit with confidence? Canadian Cyber designs and delivers internal audit services tailored specifically for managed service providers, including privileged access reviews, backup control verification, vendor assessment, and full ISMS audit programme management under Clause 9.2.
Book a Pre-Surveillance Audit Review With Canadian Cyber
We’ll find your shared access, backup, and vendor gaps before your ISO 27001 surveillance auditor does — and deliver a corrective action plan your team can execute before the audit date.
