SaaS Integration Security Questionnaire Template

Every OAuth app and API connection approved into a SaaS platform is a non-human identity holding standing access to your data, and the 2025 Salesloft Drift and Gainsight incidents showed that one compromised integration vendor can open hundreds of customers' CRM instances at once. This template is a ready-to-send security questionnaire for the vendor behind a SaaS-to-SaaS integration, OAuth app, marketplace connector or AI agent that will connect to your platforms, plus an internal approval checklist for the business owner. It covers scopes and permissions, token handling and storage, rotation and expiry, the vendor's own security and breach history, data residency, monitoring and offboarding. It is written for SaaS administrators, identity and third-party risk teams. It is the prevention side of the SaaS integration token breach response guide.

How to use this template

Customise: replace [Organisation], [Vendor], [Integration] and [SaaS platform] and delete questions that do not apply.
Tier the depth: section 3 and section 4 go to every integration. Sections 5 to 8 apply when the integration requests write access, access to [confidential or personal data], administrative scopes, or offline access (refresh tokens).
Evidence over assertion: each question names the evidence expected. "Yes" without evidence scores as partial.
Answer the internal questions too: section 2 is completed by the requesting business owner and the platform administrator, not the vendor.
Record and repeat: keep answers and the decision in the integration inventory and the third-party risk record; re-send at renewal, when scopes change, or when the vendor reports an incident. For general supplier assessment use the Third-Party Risk Management Guide; this template adds the integration-specific questions.

1. Scope and triggers

[Organisation] uses this questionnaire before approving any of the following in [SaaS platforms]:

A third-party OAuth application requesting user or admin consent.
A marketplace app, connector, or integration user created for a vendor.
An API key, personal access token or service account issued to a vendor or its product.
An AI agent, assistant or MCP server that will act on [SaaS platform] data.
A change to an approved integration: new scopes, new data, new hosting region, change of ownership of the vendor.

Response time: [10 working days]. Integrations are not enabled in production until section 9 is signed.

2. Internal request (completed by [Organisation])

Question	Answer
2.1 Business owner accountable for the integration, and a technical owner	[names]
2.2 Business purpose and the specific data and actions needed for it	[description]
2.3 Platform(s) it connects to and environment (production, sandbox)	[list]
2.4 Scopes or permissions requested, exactly as shown on the consent screen or app manifest	[list]
2.5 Grant type: per-user delegated, admin consent for the whole tenant, integration user, API key	[type]
2.6 Data classification of the data reachable with those scopes	[classification]
2.7 Is there an existing approved integration that does the same job?	[yes or no]
2.8 Planned end date or review date	[date]

3. Vendor and integration profile

Legal entity, ownership and country of incorporation of [Vendor]; any planned change of control.
Description of [Integration], the platforms it connects to, and whether it connects to other customers' tenants from the same infrastructure (multi-tenant).
Sub-processors and fourth parties that receive [Organisation] data or tokens, including AI model providers.
Where integration data and tokens are stored and processed (regions), and options for [Organisation]'s required region. Evidence: data processing agreement, sub-processor list.
Is the app published by a verified publisher on [SaaS platform]'s marketplace, and has it passed any platform security review? Evidence: listing link, review status.

4. Scopes and permissions

List every scope or permission requested and, for each, the feature that needs it. Which scopes are optional?
Does the integration request read-only access where it only reads? Can write, delete or administrative scopes be disabled without breaking core features?
Does it need offline access (refresh tokens) or can it work only while a user is present?
Can access be limited to specific objects, sites, channels, repositories or records rather than the whole tenant?
Does it request tokens restricted to a specific audience or resource, in line with RFC 9700 guidance that access tokens be least privilege and audience-restricted?
Does the integration access data on behalf of individual users (delegated) or as itself across the tenant (application permission)? Explain why.

See the OAuth Scope Design Guide.

5. Token and credential handling

#	Question	Evidence expected
5.1	How are [Organisation]'s access tokens, refresh tokens, API keys and client secrets stored? Name the encryption, key management service or HSM, and whether tokens are encrypted per customer.	Architecture description
5.2	Which vendor staff and systems can read tokens in clear? How is that access approved, logged and reviewed?	Access control policy, last review
5.3	Are tokens or secrets ever held in source code, CI/CD variables, logs, support tickets or analytics tools? How is that prevented and detected?	Secret scanning coverage
5.4	Does the integration authenticate with client secrets, private key JWT, mutual TLS or workload identity federation? Are refresh tokens sender-constrained or rotated on use?	Configuration details
5.5	Are API calls to [Organisation] made from a published, fixed set of IP addresses that [Organisation] can allowlist?	IP list
5.6	How does the vendor isolate one customer's tokens from another's, so that a compromise of one tenant or component does not expose all customers?	Design description

See the OAuth Refresh Token Rotation and Expiry Guide and the API Keys vs OAuth Tokens Guide.

6. Rotation, expiry and revocation

What is the lifetime of access tokens and refresh tokens the integration holds? Does it work with a refresh token policy that expires unused or old tokens?
Can [Organisation] rotate the client secret or API key without downtime? How often does the vendor rotate its own signing keys and secrets?
If [Organisation] revokes the grant, what stops working, and does the vendor delete cached data and tokens? Within what time?
Can the vendor revoke all customer tokens quickly in an incident, and has this been rehearsed?

Platform settings let you enforce some of this yourself. Platforms are listed alphabetically, as examples only:

Platform	Relevant controls (from vendor documentation)
Microsoft Entra ID	User consent settings: do not allow user consent, or allow it only for apps from verified publishers and for permissions classified as low impact; admin consent workflow for requests. Changing consent settings affects future consents only, so review existing grants separately.
Salesforce	Connected app OAuth policies: Permitted Users ("Admin approved users are pre-authorized" instead of self-authorisation); Refresh Token Policy (expire if not used for a period, or after a fixed period, instead of valid until revoked); IP Relaxation set to enforce IP restrictions. Salesforce recommends external client apps for new integrations.

The Gainsight Salesforce breach involved 285 OAuth tokens, some created as early as 2017, which is exactly what questions 6.1 and 6.3 are meant to surface. See the How to review Salesforce connected apps and integration users guide.

7. Vendor security, breach history and monitoring

Provide a current independent assurance report (for example SOC 2 Type II or ISO/IEC 27001 certificate with scope) covering the integration's infrastructure.
List security incidents in the last [three] years affecting customer data, tokens or source code, with root cause and remediation.
How are the vendor's own source code repositories, CI/CD and cloud accounts protected (phishing-resistant MFA, secret scanning, least privilege)? The Salesloft Drift compromise reportedly began in the vendor's code hosting before reaching the environment that held customer tokens.
Does the vendor monitor use of customer tokens for anomalies (new source infrastructure, bulk export, unusual queries) and alert customers?
Commit to notify [Organisation] of an incident affecting [Organisation] tokens or data within [24 hours] of awareness, with indicators (IP addresses, user agents, time window).
Does the integration send user agent strings and identifiers that let [Organisation] distinguish its traffic in [SaaS platform] logs?

See the Salesloft Drift breach and the How to detect use of a stolen OAuth refresh token guide.

8. AI agents and automated actions

Does the integration use AI models or agents to act on [Organisation] data? Which model providers receive the data, and is it used for training?
What actions can the agent take without human approval? Can [Organisation] restrict it to read-only or require approval for write actions?
How does the integration defend against prompt injection from content in [SaaS platform] that could cause it to misuse its scopes?
Are agent actions logged and attributable to the agent and the user who invoked it?

For deeper AI questions use the AI Vendor Security Questionnaire Template.

9. Scoring, approval and offboarding

Area	Low risk (approve)	Needs conditions	High risk (reject or escalate)
Scopes	Read-only, limited objects	Write scopes justified	Tenant-wide admin or full data access without need
Tokens	Encrypted per customer, expiring, rotated	Long-lived but revocable and monitored	Stored in clear, never expire, no isolation
Vendor assurance	Current report, no unresolved incidents	Report pending, incident remediated	No assurance, undisclosed incidents
Data location	Required region	Other region with safeguards	Unknown sub-processors or regions
Monitoring and notice	Fixed IPs, alerts, 24-hour notice	Notice only	No commitment

Decision: [approve / approve with conditions / reject], signed by business owner, platform administrator and [security or third-party risk lead], dated.
Conditions: for example restricted scopes, admin-approved users only, refresh token expiry, IP allowlisting, review in [six] months.
Offboarding: when the contract ends, the business owner leaves without a successor, or the integration is unused for [90] days: revoke the grant and tokens, remove integration users and keys, request written confirmation of data deletion, and update the inventory. See the NHI Offboarding and Decommissioning Guide.

Implementation guidance

Rollout

Close the side door first: restrict user consent and self-authorisation on each platform so new integrations must come through this process, using an admin consent request workflow so users are not blocked silently.
Inventory what is already connected: list existing grants, integration users and keys with scopes, last use and owner. See the Shadow SaaS and Unsanctioned App Discovery Guide.
Triage existing grants: send this questionnaire first to integrations with offline access to sensitive data, and revoke unused ones.
Apply to new requests: publish the process and the expected turnaround, so teams do not route around it.
Review on a schedule: high-risk integrations [every six months], others yearly, and immediately when a vendor reports an incident.

Metrics

Percentage of connected integrations with a named owner and a completed questionnaire.
Number of integrations with refresh tokens that never expire, trending down.
Grants unused for [90] days revoked within [30] days.
Median days from request to decision.
Vendor incident notices received and time from notice to token revocation.

Reference frameworks

Area	Framework reference
Supplier due diligence before approval	NIST CSF 2.0 GV.SC-06; NIST SP 800-53 SR-6; ISO/IEC 27001:2022 A.5.19
Supplier risk recorded and monitored	NIST CSF 2.0 GV.SC-07; NIST SP 800-53 SA-9; ISO/IEC 27001:2022 A.5.20
Least privilege scopes	NIST CSF 2.0 PR.AA-05; NIST SP 800-53 AC-6; RFC 9700 section 2.3
Third-party NHI risk	OWASP Non-Human Identities Top 10 (2025) NHI3 Vulnerable Third-Party NHI
Token theft and replay to detect	MITRE ATT&CK T1528 Steal Application Access Token; T1550.001 Application Access Token

SaaS Integration Security Questionnaire Template: Vetting OAuth Apps Before You Grant Access