Most third-party integrations are approved by a single click on a consent screen, and that click gives an outside company a standing token into your SaaS tenant, often with broader scopes, longer lifetimes and more data than the use case needs. This template is a pre-go-live gate for any integration that connects an external application to your systems: an OAuth app, a marketplace app, an AI assistant, a vendor integration user or an API key handed to a supplier. It records the owner, the identity model, the exact scopes, the token type and lifetime, the data classes reached, the network and monitoring controls, and the expiry and review date, and it ends with an approve, approve with conditions or reject decision. It is written for the security, identity and platform teams who review requests and the business owners who raise them. The reasoning behind each control sits in the SaaS and OAuth App Governance Guide; this page is the form you complete before anything goes live.
How to use this template
- Open one copy per integration request and attach it to the request ticket. Replace text in square brackets, such as [Organisation], [integration], [IdP] and [platform], with your own details.
- Sections 1 to 3 are completed by the requester. Sections 4 to 9 are completed by the reviewer with the requester, using the vendor's documentation and the actual consent screen, not the sales description.
- Each check is answered Pass, Fail or Not applicable (with a reason). Any Fail in a line marked Gate blocks approval unless an exception is signed in section 10.
- The form only works if users cannot bypass it. Turn on the consent controls in section 4 first, so integrations reach this gate through a request workflow rather than a user's own consent.
- Examples name GitHub, Google Workspace, Microsoft Entra ID and Slack. Platforms are listed alphabetically; apply the same checks to your CRM, ticketing, data and cloud platforms. Approved integrations then join the periodic review in the SaaS and OAuth Integrations Health Check.
1. Request record
| Field | Value |
|---|
| Integration name, vendor and publisher identity | [integration], [vendor], [publisher or app ID as shown on the consent screen] |
| Target systems | [Google Workspace / Microsoft 365 / GitHub / Slack / CRM / other]; production or non-production |
| Business purpose in one sentence | [what it does and why it needs access] |
| Business owner (accountable) and technical owner | [name, role]; [name, role]. A named person, not a team mailbox. |
| Requested go-live date and planned end date | [date]; [date or contract end] |
| Vendor risk assessment reference | [TPRM ID and tier], or "not yet assessed" (blocks approval for data classes above internal) |
| Contains AI or autonomous agent features | [yes / no]. If yes, also complete the Agentic AI Risk Assessment Template. |
2. Identity model
| # | Check | Gate | Result |
|---|
| 2.1 | The integration's identity model is recorded: delegated OAuth (acts as a user), application or app-only OAuth (acts as itself), platform app installation (for example a GitHub App or Slack app), integration user with an API token, or a static API key. See OAuth Apps vs Integration Service Accounts. | Gate | [ ] |
| 2.2 | Where the vendor offers both, the model that keeps working when a person leaves and can be scoped to selected resources is chosen. GitHub, for example, documents that GitHub Apps use fine-grained permissions, can be limited to selected repositories and keep working if the installing user leaves, while OAuth apps act as the authorising user across all resources that user can reach. | | [ ] |
| 2.3 | No shared human account, personal access token or employee's password is used to connect the integration. | Gate | [ ] |
| 2.4 | Integration users are dedicated, API-only where the platform supports it, excluded from interactive sign-in, and recorded in the NHI inventory with the owner from section 1. | Gate | [ ] |
3. Data classes and flows
| # | Check | Gate | Result |
|---|
| 3.1 | Data classes the integration can read, write or delete are listed against your classification scheme (for example customer personal data, financial, source code, credentials, health data). See the Data Classification Guide. | Gate | [ ] |
| 3.2 | Where data goes is recorded: copied to the vendor's storage, processed in transit only, or sent on to sub-processors or AI model providers. Data residency regions are stated. | Gate | [ ] |
| 3.3 | Personal data: data processing agreement in place and the processing added to the record of processing activities. | | [ ] |
| 3.4 | The vendor states how it stores your tokens and secrets (encryption, key management, access by its own staff), and how it would notify you of a compromise. | | [ ] |
| 3.5 | Data that the integration can reach but does not need (for example support cases where customers paste credentials, or HR folders) is excluded by scope, sharing settings or a separate tenant area. | | [ ] |
These platform settings decide whether this checklist is ever seen. Set them once, then confirm for each request that the integration came through them.
| Platform | Setting that routes requests to review | Approval note |
|---|
| GitHub | OAuth app access restrictions for the organisation (on by default for new organisations); members request approval of an app and owners are notified | Approve GitHub App installations against the selected repositories and permissions recorded in section 5. |
| Google Workspace | Security > Access and data control > API controls: set Unconfigured third-party apps to the restrictive option and turn on User requests to access unconfigured apps | Approve by setting the app's access to Specific Google data (only the scopes you specify) or Limited, keeping Trusted for apps that need restricted services and pass every gate. |
| Microsoft Entra ID | User consent limited to Allow user consent for apps from verified publishers, for selected permissions (policy microsoft-user-default-low, which covers permissions you classify as low impact), plus Users can request admin consent to apps they are unable to consent to with named reviewers and an expiry in days | Reviewers need the rights to grant the consent themselves; Microsoft states that only Global Administrators can approve requests for Microsoft Graph application permissions. See How to restrict user consent to apps in Entra ID. |
| Slack | Require approved apps with Only allow pre-approved apps and Allow members to request apps for approval; app managers selected | Approving a request approves the scopes the app uses, so review the scope list in section 5 before selecting Approve. |
| # | Check | Gate | Result |
|---|
| 4.1 | The request arrived through the platform's approval workflow, not through a user consent that already happened. An integration found already connected is handled as a retrospective review with a deadline. | Gate | [ ] |
| 4.2 | The publisher shown on the consent screen matches the vendor in section 1 (verified publisher where the platform supports it), and the redirect URIs belong to the vendor's own domains. | Gate | [ ] |
| 4.3 | The request was raised by the business owner, not by someone who was asked to "enter a code" or approve an app by a caller. See the Consent Phishing and Illicit OAuth Grants Guide. | Gate | [ ] |
The ShinyHunters Salesforce data theft campaign shows why check 4.3 exists: callers posing as IT support talked employees into authorising an attacker-controlled connected app, which then had persistent API access for bulk export, with no platform vulnerability involved. A rule that only a small admin group can approve connected apps, and only through this gate, removes that path.
5. Scopes and permissions
| # | Check | Gate | Result |
|---|
| 5.1 | Every requested scope or permission is copied from the consent screen or app manifest into the scope table below, with the feature that needs it. A scope with no feature is removed or the request is rejected. | Gate | [ ] |
| 5.2 | Read-only scopes are used where the feature only reads. Write, delete, admin and "full access" scopes have a named justification. | Gate | [ ] |
| 5.3 | Resource selection is as narrow as the platform allows: selected repositories, selected channels, selected sites, specific objects or a dedicated folder, not the whole tenant. | | [ ] |
| 5.4 | Tenant-wide application permissions (app-only access to all mailboxes, all files or all users) need security architecture sign-off and a recorded reason why delegated or resource-limited access will not work. | Gate | [ ] |
| 5.5 | Access tokens are audience-restricted to the resources the integration needs, in line with RFC 9700 section 2.3 (least privilege and audience restriction). | | [ ] |
| 5.6 | For an integration user, the profile or role grants API access and bulk export rights only if the use case needs them. | Gate | [ ] |
| Scope or permission | Read / write / admin | Feature that needs it | Decision |
|---|
| [scope] | [R / W / A] | [feature] | [keep / remove / justify] |
| [scope] | [R / W / A] | [feature] | [keep / remove / justify] |
For the difference between what a scope permits and what a token claims, see OAuth Claims vs Scopes.
6. Token type, lifetime and storage
| Token or credential type | Typical lifetime | Approval stance |
|---|
| Short-lived access token from an app installation or client credentials | Minutes to an hour (GitHub App installation tokens currently expire after 1 hour) | Preferred |
| Delegated access token with refresh token | Short access token; refresh token often long-lived | Accept with refresh token rotation or sender-constraining, and revocation tested |
| Long-lived OAuth token | Until revoked (GitHub OAuth app tokens are long-lived unless the app opts into 8-hour expiry) | Accept only with expiry date in section 9 and monitoring |
| Static API key or integration user password | Until rotated | Exception only, with a rotation interval and vault storage |
| # | Check | Gate | Result |
|---|
| 6.1 | Token type and lifetime recorded from vendor documentation, including refresh token lifetime. | Gate | [ ] |
| 6.2 | The flow is not the implicit grant or the resource owner password credentials grant; RFC 9700 says clients should not use the implicit grant and the password grant must not be used. Public clients use PKCE. | Gate | [ ] |
| 6.3 | Any secret, key or certificate on your side (client secret, API key you issue to the vendor) is stored in [secrets manager], has an owner and a rotation date. See API Keys vs OAuth Tokens Guide. | Gate | [ ] |
| 6.4 | Revocation path documented and tested in non-production: where to revoke, who can, and how long until the integration stops working. | Gate | [ ] |
7. Network and conditional controls
| # | Check | Gate | Result |
|---|
| 7.1 | Where the platform supports it, token use is restricted to the vendor's published IP ranges or trusted networks, so a stolen token cannot be used from anywhere. | | [ ] |
| 7.2 | Workload or app conditional access policies applied where available (location, risk). | | [ ] |
| 7.3 | Webhooks the integration receives are signed and verified, and endpoints you expose to it are authenticated. | | [ ] |
8. Logging and monitoring
| # | Check | Gate | Result |
|---|
| 8.1 | The integration's sign-ins, token grants and API calls appear in platform audit logs that reach [SIEM]. | Gate | [ ] |
| 8.2 | Baseline recorded: expected call volume, objects touched and source IP ranges. | | [ ] |
| 8.3 | Alerts set for bulk export, new scopes granted, use from unexpected networks and activity outside the baseline. OWASP NHI3:2025 recommends alerting on unusual token activity of this kind. | | [ ] |
| 8.4 | The integration is added to the vendor-incident playbook: which tokens to revoke and which credentials to rotate if the vendor reports a breach. | Gate | [ ] |
The Salesloft Drift breach is the reason for 8.4: OAuth tokens the vendor held for its customers' tenants were used directly against their APIs, and the customers who could revoke quickly were the ones who knew which integrations and scopes they had approved.
9. Expiry, review and exit
| # | Check | Gate | Result |
|---|
| 9.1 | Approval expiry date set (default [12] months, [6] months for write or admin scopes, contract end if sooner). | Gate | [ ] |
| 9.2 | Review date in the integrations register, with the business owner as reviewer. | Gate | [ ] |
| 9.3 | Exit route recorded: how data is exported and deleted and how every grant is removed when the integration is retired, using the SaaS Offboarding Checklist. | | [ ] |
| 9.4 | Change rule agreed: any new scope, permission or data class requested later comes back through this checklist. | Gate | [ ] |
10. Decision and sign-off
| Field | Value |
|---|
| Decision | [Approved / Approved with conditions / Rejected] |
| Conditions | [for example: read-only scopes only; IP restriction before production; re-review in 90 days] |
| Exceptions to Gate lines | [line number, reason, compensating control, exception expiry, approver] |
| Approvers | Business owner [name, date]; Security [name, date]; Platform administrator who granted consent [name, date] |
| Granted configuration matches this record | [evidence: screenshot of granted permissions or export of the grant] |
Implementation guidance
Rollout order: first inventory what is already connected, because turning on consent restrictions cuts off unapproved apps (GitHub notes that enabling OAuth app access restrictions removes access for unapproved OAuth apps, and Google Workspace revokes tokens of untrusted apps when a service is set to Restricted). Pilot the restrictive consent settings on one group or organisation, run the retrospective reviews, then extend. Rollback is relaxing the setting for the pilot group while missing approvals are processed.
Tiering: a low-risk path (read-only, low-impact scopes, internal data, verified publisher) can be approved by the platform team in a day; anything touching confidential data, write or admin scopes, tenant-wide app permissions or AI features goes to the full gate. Small organisations can use the same form with one approver plus the business owner; the gates do not change.
Metrics: integrations live without a completed record (target 0); median days from request to decision; percentage approved with fewer scopes than requested; approvals past expiry date (target 0); integrations with a tested revocation path (target 100%).
Common failures: approving the vendor rather than the scope list; leaving user consent open so the gate is optional; accepting tenant-wide application permissions because the vendor's setup guide asks for them; approving with no expiry, so the token outlives the contract; one admin both requesting and granting; and never adding the integration to the incident playbook.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|
| Request, vendor and data (1, 3) | SA-4, SA-9 | GV.SC-06, GV.SC-07 | T1199 Trusted Relationship |
| Identity model and scopes (2, 5) | AC-6, IA-4 | PR.AA-05 | |
| Tokens and connections (6, 7) | IA-5, CA-3 | PR.AA-05 | T1528 Steal Application Access Token; T1550.001 Application Access Token |
| Register and review (8, 9) | CM-8, AC-2 | ID.AM-02 | |
In ISO/IEC 27001:2022 Annex A, the checklist supports 5.19 to 5.23 on supplier relationships and the use of cloud services.
Standards and references
Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · SaaS and OAuth Integrations Health Check · OAuth Apps vs Integration Service Accounts · GitHub Apps vs Personal Access Tokens vs OAuth Apps · Top 10 Third-Party Risk Mistakes