The MSP Integration Security Checklist: 12 Questions Clients' CISOs Will Ask Before You Connect to Their Systems
Last updated: November 2026
Before a managed service provider connects its tools to a client's ServiceNow, Jira or Azure DevOps environment, the client's security team will review the integration. The 12 questions in this checklist cover what most CISOs ask: where data is stored, how credentials such as OAuth tokens and personal access tokens are handled, which permissions the integration needs, how activity is logged, where data resides, and how access is revoked. Preparing clear, documented answers in advance shortens security reviews and builds trust in your integration security. The integration platform you choose shapes many of those answers; ZigiOps, the no-code integration platform by ZigiWave, is one example designed to simplify them, for instance by not storing transferred data.
Integrations are an attractive target. A single integration user often has read and write access to thousands of tickets, and those tickets can contain system names, IP addresses, error logs and personal data. For a client, connecting an MSP's platform to its ITSM means extending its trust boundary to a third party. It is no surprise that security teams look closely.
For MSPs, the security review is often the slowest part of onboarding. The fix is preparation: a standard set of answers, backed by documentation, that you can hand over at the start. The checklist below is organized into four areas: data, credentials and access, operations, and governance.
Why integration security reviews are getting stricter
Several trends push clients to scrutinize integrations more carefully:
- Supply chain and third-party risk programs now routinely include integration tools and managed services platforms.
- Regulations and frameworks in many regions put more emphasis on third-party ICT risk and data protection.
- Clients increasingly connect AI assistants and automation to ITSM data, which raises questions about what each connected system can read.
- Token-based attacks on SaaS platforms have made credential handling a board-level topic.
The result is that "we use the API" is no longer an acceptable answer. Clients want to know exactly how the API is used.
Part 1: Data questions
1. What data will the integration read and write?
Provide the data contract: the tables or projects, the fields and the direction of each flow. Clients are reassured when you can show that the integration reads only tickets assigned to the MSP, not the whole incident table, and only the fields required.
2. Does the integration store our data, and if so, where and for how long?
This is often the first question. Some integration tools act as a pass-through and do not persist ticket content; others store payloads, queues or history in their own database. Be precise: describe what is stored (for example, correlation IDs, configuration, logs), whether ticket content is cached, the retention period, and how it is deleted. ZigiOps, for example, does not store the transferred data; it keeps only a few kilobytes of runtime state, which shortens this part of the review considerably.
3. Where is the data processed and hosted (data residency)?
State the hosting region of your integration platform, or whether it can run on-premises or in the client's own cloud. For clients in regulated industries or with strict data residency rules, a deployment option inside their environment may decide the review. ZigiOps can run on-premises or in the cloud, which lets an MSP offer a residency option that matches the client's policy.
4. How is data protected in transit and at rest?
Confirm TLS for all connections and encryption at rest for anything stored. Mention how encryption keys are managed if you store sensitive configuration.
Part 2: Credentials and access questions
5. How does the integration authenticate to our systems?
Explain the method per system. Common options include OAuth 2.0 for ServiceNow and many SaaS platforms, API tokens for Jira Cloud, and personal access tokens or service principals for Azure DevOps. Where OAuth is supported, it is usually preferred because tokens can be scoped and revoked without sharing a password.
| Method | Typical systems | What the CISO will ask |
|---|---|---|
| OAuth 2.0 | ServiceNow, Salesforce, many SaaS tools | Which scopes are requested? How are refresh tokens stored and rotated? |
| API tokens | Jira Cloud and other Atlassian products | Which account owns the token? Does it expire? Who can see it? |
| Personal access tokens (PATs) | Azure DevOps, GitHub | Which scopes are granted? What is the expiry? Is it tied to a person or a service account? |
| Basic authentication (username and password) | Some on-premises tools | Can it be replaced by token-based auth? Is the password vaulted and rotated? |
| Service principals or managed identities | Microsoft cloud services | Which roles are assigned? Who manages the identity? |
6. What permissions does the integration user need?
Apply least privilege and document it. For ServiceNow, a dedicated integration user with a custom role granting access only to the required tables is a common pattern. For Jira, limit the integration account to the relevant projects. For Azure DevOps personal access tokens, request only the scopes needed (for example, work item read and write) rather than full access. Clients will ask why any broad role, such as admin, is needed; ideally, it is not. The ZigiOps documentation for ServiceNow follows exactly this pattern: a dedicated integration user with a custom role that grants read access to a few system tables, plus the itil role.
7. How are credentials stored, rotated and revoked?
Describe where secrets live (a vault or encrypted store), who on the MSP side can access them, how often they are rotated and what happens when a token expires. Also explain the revocation path: the client should be able to cut off access instantly by disabling the integration user or revoking the token.
8. Is the integration user a shared or personal account?
Clients prefer a dedicated, non-personal service account for each integration. Tokens tied to an individual engineer create risk when that person leaves, and they make audit trails harder to read.
Part 3: Operational questions
9. What is logged, and can we see it?
Audit logging is essential for incident investigations. Explain what your platform logs (transactions, errors, configuration changes, user logins), how long logs are kept, and whether the client can access them or receive them in their SIEM. Note that actions performed by the integration user also appear in the client's own system logs, which helps with traceability.
10. How do you handle incidents and vulnerabilities?
Clients want to know your security incident response process, notification timelines and how you patch the integration platform. If the platform is a third-party product, explain how you receive and apply its security updates.
Part 4: Governance questions
11. Which certifications and assurance reports can you provide?
Certifications such as ISO 27001 and assurance reports such as SOC 2 are common requests, for both the MSP and any integration platform it uses. If you rely on a vendor's platform, have its certificates and security documentation ready to share under NDA. ZigiOps, for example, is ISO 27001 certified, which gives MSPs a ready answer for the platform side of this question. Other platforms, such as Workato, ONEiO or Exalate, publish security information in different levels of detail, so collect it during selection rather than during a client review.
12. What happens to access and data when the contract ends?
Describe offboarding: credentials revoked, connections disabled, any stored data deleted or returned according to the contract, and written confirmation. Clients are increasingly asking for this before signing.
Preparing system-specific answers
Generic answers only go so far. Security teams usually own a specific platform and know its permission model well, so prepare short, system-specific notes for the tools you connect to most often.
ServiceNow
Describe the integration user, the custom role you request and the tables it covers (for example, incident, sys_journal_field for comments and work notes, and any reference tables needed to resolve users or groups). State whether you use OAuth or basic authentication, and whether access is limited to records assigned to the MSP's assignment group through filters or access controls. ServiceNow administrators will also ask whether the integration needs a separate license and whether it touches system tables.
Jira Cloud and Jira Service Management
Explain which projects the integration account can browse and edit, whether it uses an API token or OAuth, and who owns the Atlassian account behind the token. If the integration listens for webhooks, describe how incoming requests are verified.
Azure DevOps
List the personal access token scopes or service principal roles, the token expiry and the organizations and projects in scope. Azure DevOps administrators often have organization-level policies on token lifetime and scope, so check them early to avoid rework.
Questions MSPs should ask their own integration vendor
If your eBonds run on a third-party integration platform, your answers depend on the vendor's answers. Before you sign, ask the vendor the same 12 questions, plus three more: whether the platform supports multiple client tenants with isolated credentials, whether it can be deployed in a specific region or on-premises, and how quickly it notifies customers about security incidents. Store the responses in your security pack.
How this works in ZigiOps
Applied to ZigiOps, the vendor answers are straightforward to document. It is a standalone application that connects to each system through its API, so no plugin is installed inside the client's ServiceNow or Jira. It does not store transferred data, it is ISO 27001 certified, and it can run on-premises or in the cloud. Each pair of connected instances is configured separately, which keeps one client's connection settings and mappings apart from another's.
The checklist at a glance
| # | Question | Evidence to prepare |
|---|---|---|
| 1 | What data is read and written? | Data contract with fields and directions |
| 2 | Is data stored, where and for how long? | Data storage statement and retention policy |
| 3 | Where is data processed? | Hosting regions and deployment options |
| 4 | How is data encrypted? | Encryption in transit and at rest description |
| 5 | How does the integration authenticate? | Authentication method per system |
| 6 | What permissions are needed? | Role and scope list, justified line by line |
| 7 | How are credentials managed? | Secret storage, rotation and revocation process |
| 8 | Shared or personal account? | Service account policy |
| 9 | What is logged? | Logging scope, retention and export options |
| 10 | How are incidents handled? | Incident response and patching process |
| 11 | Which certifications apply? | ISO 27001 certificate, SOC 2 report or equivalent |
| 12 | What happens at contract end? | Offboarding and data deletion procedure |
Red flags that slow down or stop a review
- Requesting admin rights "to make setup easier".
- Tokens tied to a named engineer's personal account.
- No clear answer on whether ticket content is stored.
- Credentials stored in scripts, spreadsheets or shared documents.
- No audit log of integration activity.
- Personal access tokens with full scope and no expiry.
- No documented offboarding process.
How to turn the checklist into a reusable security pack
Rather than answering each questionnaire from scratch, build a security pack once and update it quarterly:
- A two-page integration architecture overview describing components and data flows in plain language.
- The standard data contract template.
- A permissions matrix per supported system (ServiceNow, Jira, Azure DevOps, Freshservice and others).
- Your credential management policy.
- Certificates and assurance reports for your organization and your integration platform (for example, the ISO 27001 certificate for ZigiOps if that is the platform you use).
- The offboarding procedure.
Send the pack at the start of onboarding, before the client asks. It signals maturity and often removes several rounds of questions.
Frequently asked questions
What is integration security?
Integration security covers how connections between systems authenticate, which data they access, how that data is protected and stored, and how activity is logged and governed.
Is OAuth more secure than API tokens for ServiceNow integrations?
OAuth 2.0 is often preferred for ServiceNow because it supports scoped access and revocable tokens without sharing a password. The overall security still depends on how tokens are stored and which permissions the integration user has.
What scopes should an Azure DevOps personal access token have?
Only the scopes the integration needs, typically work item read and write, with a defined expiry date. Avoid full-access tokens and tokens tied to an individual's account.
Do clients require ISO 27001 or SOC 2 from MSPs?
Many enterprise clients ask for one or both, for the MSP and for any integration platform it uses. Requirements vary by industry and region.
Should an integration platform store ticket data?
Not necessarily. Storing as little as possible reduces risk. If data is stored, document what, where, for how long and how it is deleted.
Does ZigiOps store ticket data?
No. ZigiOps does not store the transferred data. It keeps only minimal runtime state, such as the correlation information that links records, which simplifies answers about storage, retention and deletion in a client security review.
How can MSPs speed up security reviews?
Prepare a reusable security pack covering data flows, permissions, credentials, logging, certifications and offboarding, and share it at the start of onboarding.
Key takeaways
- Client CISOs focus on data storage, credentials, permissions, logging, residency and offboarding.
- Use dedicated service accounts, least-privilege roles and scoped, expiring tokens such as OAuth or narrowly scoped personal access tokens.
- Be precise about whether and where your integration stores ticket data.
- Collect certifications and security documentation from your integration platform vendor during selection.
- A platform such as ZigiOps, which stores no transferred data and is ISO 27001 certified, answers several of the hardest CISO questions before they are asked.
- A reusable security pack turns a slow, repeated review into a predictable step of onboarding.