MSP Security Questionnaire Template: Questions and Evidence

A managed service provider usually holds more standing privilege in your environment than any of your own staff, yet most MSPs are assessed with a generic vendor questionnaire that never asks how their technicians, RMM consoles and multi-tenant tools reach you. This template is a ready-to-send question set for assessing an MSP or MSSP before contract and at each renewal. It concentrates on the areas where national cyber agencies say MSP compromises start and spread: technician identity, privileged access, RMM and remote access tooling, tenant separation, logging, patching, backups and incident notice. It is written for third-party risk teams, IT managers and security leads buying managed services. For the reasoning behind the questions and how to tier the relationship, read the Managed Service Provider Risk Assessment Guide first; this page is the questionnaire itself.

How to use this template

Replace placeholders: text in square brackets, such as [Organisation], [MSP name] and [24 hours], is yours to set. Bracketed values are suggested defaults, not external requirements.
Ask for evidence, not yes or no: each section lists the evidence to request. A "yes" without evidence scores as "partial" in section 12.
Use the red flag column: it lists answers that should stop or escalate the assessment, whatever the overall score.
Size it to the relationship: send sections 1 to 12 to an MSP with administrative access to your identity provider, servers or endpoints. A provider that only supports a single application can answer sections 1, 3, 6, 9 and 11.
Reuse the answers: commitments the MSP makes here (notification times, MFA, log retention) should be copied into the contract. See the Third-Party Security Contract Clauses Template.
Repeat at renewal and after change: re-send sections 3 to 5 when the MSP changes RMM tooling, is acquired, or reports an incident.

1. Respondent and service profile

Ref	Question	Evidence to request
1.1	Legal entity, headquarters, and the locations (countries) of staff and subcontractors who will access [Organisation] systems or data.	Company registration; list of delivery locations
1.2	Which services will you deliver to [Organisation]? Mark each as in scope or out of scope: help desk, endpoint management, server management, identity provider administration, cloud tenant administration, network management, backup, security monitoring (SOC), incident response.	Draft statement of work with a responsibility matrix
1.3	Name the security contact and the out-of-hours incident contact, with a phone number not dependent on your corporate email.	Contact sheet
1.4	Which independent assurance covers the delivery teams and tools that will serve [Organisation]? For example Cyber Essentials Plus, ISO/IEC 27001 certificate with Statement of Applicability, SOC 2 Type 2.	Certificates and reports, with scope statements

Check that the assurance scope covers the service desk, RMM platform and delivery infrastructure, not just the head office. Cyber Essentials certificates can be verified on the scheme's public search. See the How to Read a SOC 2 Report Guide.

2. Security governance

Ref	Question	Evidence to request	Red flag
2.1	Who is accountable for security in your organisation, and how often does leadership review it?	Role description, last review date	No named owner
2.2	Do you hold a current security risk assessment of your own delivery infrastructure (RMM, PSA, documentation and password vault platforms)?	Summary of top risks and treatments	Assessment covers only customer environments
2.3	When was your delivery infrastructure last penetration tested, by whom, and were high findings fixed?	Test summary letter and remediation status	Never tested, or high findings open beyond [90 days]

3. Technician identity and privileged access

Ref	Question	Evidence to request	Red flag
3.1	Does every technician use a named, individual account for all access to [Organisation] systems? Are any shared or generic admin accounts used?	List of accounts the MSP will hold in our environment	Shared admin accounts with no individual attribution
3.2	Is MFA enforced on every account that can reach our environment, including RMM, PSA, password vault and cloud partner portals? Which methods are allowed, and can a technician re-enrol MFA without a second person?	MFA policy and enforcement report	SMS-only or no MFA on RMM or partner portal access
3.3	Are admin credentials ever reused across customers?	Credential management standard	Any reuse
3.4	Do you use a tiered admin model? Is privileged access granted just in time and time-limited, or held permanently?	Role design; just-in-time configuration	Standing domain or Global Administrator for all technicians
3.5	For Microsoft 365 or Entra ID, do you use granular delegated admin privileges (GDAP) with least-privilege roles and an end date, rather than broad standing roles?	Requested GDAP roles and duration per security group	Request for Global Administrator as the default role
3.6	Will MSP accounts be kept out of our internal administrator groups and restricted to the systems you manage?	Proposed group memberships	Request to join Domain Admins or equivalent for convenience
3.7	Where are credentials for our environment stored (password vault, PAM tool), who can view them, and is every retrieval logged?	Vault access policy; sample retrieval log	Credentials in spreadsheets, tickets or documentation wikis
3.8	Which service accounts, API keys, app registrations or OAuth consents will your tools create in our environment, with what permissions, and how are their secrets rotated?	Inventory of non-human identities with scopes and rotation interval	Tenant-wide read and write scopes with no rotation or owner
3.9	How quickly are accounts removed when a technician leaves or changes role?	Leaver procedure and last audit	No defined timescale

Question 3.8 matters more than it looks. In the ConnectWise Cloud Backup breach, a stolen credential for an MSP backup tool's multi-tenant application was used to sign in to more than 160 Microsoft 365 tenants without any user being phished. See the GDAP and MSP Delegated Admin Access Guide and the Privileged Access Management Guide.

4. RMM and remote access tooling

Ref	Question	Evidence to request	Red flag
4.1	Which remote monitoring and management (RMM), remote support and scripting tools will you install on our systems? List product names and versions.	Tool list with versions	Unwilling to list tools
4.2	Is the RMM console self-hosted or vendor-hosted? If self-hosted, is it exposed to the internet, and how fast are vendor security updates applied?	Hosting model; patch history for the console	Internet-exposed self-hosted console patched on a fixed monthly cycle only
4.3	Is RMM console access protected by MFA, single sign-on and network restrictions (for example source IP allow lists)?	Console security settings screenshot	Password-only console login
4.4	Who can run scripts or push software to all customers at once? Is mass deployment subject to approval or a second person?	Role permissions in the RMM; change procedure	Every technician can script against every customer
4.5	Is remote access to our network through a dedicated VPN or equivalent secure method, and can it be restricted to the systems you manage?	Connectivity diagram	Direct RDP or SSH exposed to the internet
4.6	Will you tell us which agents to allow so that we can block every other remote access tool?	Agent hashes, signing certificates, domains	Technicians install ad hoc remote tools
4.7	Are RMM actions (sessions, scripts, file transfers) logged per technician and available to us?	Sample session log for a test device	No per-technician log

RMM tools are a known route for abuse of trusted relationships: MITRE ATT&CK tracks this as T1199 Trusted Relationship and T1219 Remote Access Tools. See the RMM Tool Security Guide and the Unauthorised Remote Monitoring and Management Tool Playbook.

5. Tenant separation and delivery infrastructure

Ref	Question	Evidence to request	Red flag
5.1	How are our data, credentials and RMM configuration separated from other customers' and from your corporate network?	Architecture description	Flat network shared by corporate and delivery systems
5.2	Can a technician assigned to another customer see or act on our systems? How is that enforced in the RMM, PSA and vault?	Role-based access configuration per customer	All technicians see all customers by default
5.3	Do multi-tenant tools you operate (backup, monitoring, M365 management) use one application identity for all customers? How is its credential protected and monitored?	Application inventory; secret storage and alerting	One long-lived secret shared across all tenants with no monitoring
5.4	Are technician workstations managed, encrypted and protected by EDR, and are personal devices barred from admin access?	Endpoint standard	Admin access from unmanaged devices

6. Logging and monitoring

Ref	Question	Evidence to request	Red flag
6.1	What do you log about your own access to our environment, where is it kept, and for how long? The joint MSP advisory recommends at least six months for the most important logs.	Log source list and retention settings	Under [6 months], or logs only on systems the attacker would control
6.2	Can we access these logs directly, or receive them in our SIEM?	Export or forwarding method	Logs available only on request after an incident
6.3	If you provide monitoring, which events trigger an alert to us, who analyses them, and what are the response targets?	Use case list; SLA	No defined escalation to [Organisation]
6.4	Do you alert on failed logins and MFA changes for MSP accounts, including failures immediately after password resets?	Detection rule list	No monitoring of MSP accounts

7. Patching and vulnerability management

Ref	Question	Evidence to request	Red flag
7.1	What are your patch timescales for the systems you manage for us? NCSC guidance for SMEs suggests critical or high-risk vulnerabilities within 14 days.	Patch policy; last [3] months of compliance reports	No defined timescale
7.2	Do you prioritise vulnerabilities in the CISA Known Exploited Vulnerabilities catalogue?	Prioritisation procedure	CVSS score is the only input
7.3	How fast do you patch your own RMM, PSA, VPN and vault platforms?	Patch record for the last emergency advisory	Delivery platforms patched slower than customer systems
7.4	Who tracks end-of-life systems in our estate and tells us?	Sample health report	Nobody owns it

See the CISA KEV Catalogue Guide.

8. Backups and recovery

Ref	Question	Evidence to request	Red flag
8.1	What do you back up for us, how often, and where? Does frequency match our recovery point objectives?	Backup schedule	Frequency not linked to RPO
8.2	Are backups isolated or immutable, encrypted, and protected by keys held separately from the production environment?	Immutability and key management settings	Backups deletable with the same admin credentials used for production
8.3	When did you last restore a full system or tenant for us, and how long did it take?	Restore test record	No restore test in [12 months]
8.4	How would you recover our service if your own RMM or backup platform were compromised or unavailable?	Contingency plan extract	No plan that assumes the MSP itself is down

9. Incident response and notification

Ref	Question	Evidence to request	Red flag
9.1	Within what time will you notify us of a suspected or confirmed incident affecting our systems or data? Will you also notify us of an incident in your own environment that could affect us?	Contractual notification commitment	Notification only for confirmed incidents, or longer than [24 hours]
9.2	What will the first notice contain (affected tools, accounts, time window, actions taken), and how often will you update us?	Notification template	No defined content
9.3	Can you revoke all your access to our environment within [1 hour] on request, and how?	Emergency revocation procedure	Only possible by the MSP, not by us
9.4	When did you last exercise your incident response plan, including a scenario where your RMM is compromised?	Exercise date and lessons	Never exercised
9.5	Who does what in an incident: you, us, or our incident response retainer?	RACI	Responsibilities undefined

See the Third-Party Incident Notification Clauses Guide and, for the response itself, the Compromised MSP Playbook.

10. Personnel, subcontractors and supply chain

Ref	Question	Evidence to request	Red flag
10.1	How are technicians screened before getting customer access, and do they receive security training at least [annually]?	Screening and training policy	No screening for privileged staff
10.2	Will any subcontractor or offshore partner access our systems? Will you tell us before that changes?	Subcontractor list; change notice commitment	Undisclosed subcontractors
10.3	Which software vendors does your service depend on (RMM, PSA, backup, vault), and how do you assess them?	Key supplier list	No view of their own supply chain

11. Offboarding and exit

Ref	Question	Evidence to request	Red flag
11.1	At contract end, will you remove all accounts, agents, app registrations, OAuth consents, VPN paths and stored credentials, and confirm in writing within [5 working days]?	Exit procedure	No written exit procedure
11.2	Will you hand over documentation, configurations and admin credentials, and return or delete our data with confirmation?	Data return and deletion commitment	Data retained indefinitely
11.3	How will you help transition to another provider?	Transition plan outline	Transition charged and undefined

See the Vendor Offboarding and Termination Guide.

12. Scoring and sign-off

Score	Meaning
2: Met	Answered, with evidence that matches the answer
1: Partial	Answered without evidence, or evidence covers part of the scope
0: Not met	Not in place, not answered, or contradicted by evidence

Weight sections 3, 4 and 9 at [double] for MSPs with administrative access to identity systems.
Any red flag in sections 3, 4 or 5 requires remediation before go-live or a written risk acceptance by [CISO], with compensating controls and a date.
Record: assessor, date, MSP respondent, overall score, red flags, agreed remediation and the contract clauses that carry each commitment.

Implementation guidance

Running the questionnaire

Tier first: confirm what access the MSP will hold. Administrative access to identity providers, RMM agents on every endpoint, or backup administration all justify the full set.
Send early: issue the questionnaire before commercial terms are fixed, so that answers can become contract clauses.
Verify a sample: pick three answers in sections 3 and 4 and ask to see them live on a screen share, for example RMM console MFA and per-customer role restrictions.
Close the loop in your own tenant: after onboarding, list every account, GDAP relationship, app registration and agent the MSP created and compare it with the answers to 3.1, 3.5 and 3.8.
Reassess: annually for MSPs with privileged access, and after any incident, acquisition or tooling change.

Framework mapping

Framework	Reference	Questionnaire sections
NIST CSF 2.0	GV.SC-05 requirements in contracts; GV.SC-06 due diligence before the relationship; GV.SC-07 risks monitored over the relationship; GV.SC-10 after the relationship ends	All; 11
NIST SP 800-53 Rev. 5	SA-9 External System Services; SR-6 Supplier Assessments and Reviews; PS-7 External Personnel Security; AC-6 Least Privilege; AC-17 Remote Access; AU-11 Audit Record Retention; CP-9 System Backup; IR-6 Incident Reporting	1 to 10
ISO/IEC 27001:2022	Annex A 5.19 to 5.22 (supplier relationships, agreements, ICT supply chain, monitoring and change)	All
CIS Controls v8.1	Control 15 Service Provider Management	All
MITRE ATT&CK	T1199 Trusted Relationship; T1219 Remote Access Tools	3, 4, 5

MSP Security Questionnaire Template: Questions and Evidence Before an MSP Holds Your Keys