Cancelling a SaaS subscription does not disconnect it: the OAuth grants, API keys, SCIM connectors, webhooks and integration users it held in your other systems keep working until someone removes them, and your data stays with the provider until it is deleted. This template is a per-application exit record for retiring a SaaS product, whether the reason is a contract end, a replacement tool, a vendor incident or a shadow IT clean-up. It covers the exit decision, the inventory of every connection, data export and verification, token and integration revocation in both directions, single sign-on and SCIM removal, account closure and the deletion evidence you need from the provider. It is not a leavers checklist: for people, use the Employee Offboarding Security Checklist. For the commercial and contractual side of ending a supplier relationship, read the Vendor Offboarding and Termination Guide; this page is the record you fill in for one application.
How to use this template
- Open one copy per application being retired and link it to the change or procurement ticket. Replace text in square brackets, such as [Organisation], [application], [IdP] and [SIEM], with your own details.
- Deadlines are relative to the cut-off time (C), the moment the application stops being used for business. For an exit forced by a vendor security incident, C is now, and section 5 runs first, before the data export.
- Mark each line Done (with date and evidence), Not applicable (with a reason) or Exception (with the approver). A blank line is a fail.
- Examples name Google Workspace, GitHub, Microsoft Entra ID and Slack because they are common connection points. Platforms are listed alphabetically; the same checks apply to any identity provider, code platform or collaboration tool you use.
- Keep the completed record for the retention period your audit or regulatory obligations require. It is the evidence that the supplier relationship ended cleanly (NIST CSF 2.0 GV.SC-10).
1. Application exit record
| Field | Value |
|---|
| Application, provider, tenant or workspace ID | [application], [provider], [tenant ID or URL] |
| Reason for exit | [contract end / replaced by [new tool] / vendor incident / shadow IT removal / consolidation] |
| Cut-off time (C) and contract end date | [date, time zone]; contract ends [date]; notice given [date] |
| Business owner and technical owner | [name, role]; [name, role] |
| Highest data classification held | [public / internal / confidential / restricted]; personal data [yes / no] |
| Data protection role of the provider | [processor / controller / sub-processor]; data processing agreement reference [ref] |
| Successor system, if any | [system], migration owner [name] |
| Checklist owner and ticket | [name], [ticket ID] |
2. Connection inventory (C minus 30 days)
A SaaS application is connected in two directions. Inbound: the application holds credentials to reach your systems, such as an OAuth grant in your identity provider, a token for your CRM, or a key for your cloud storage. Outbound: your systems hold credentials to reach the application, such as its API keys in a pipeline or a SCIM token in your IdP. Both must be listed before anything is switched off, or revocation will break a dependency you did not know about. The NHI Inventory Reconciliation guide covers matching these lists against your wider inventory.
| # | Connection type | Where to find it | Recorded |
|---|
| 2.1 | SSO application object (SAML or OIDC) | IdP enterprise application or app integration list | [ ] |
| 2.2 | SCIM provisioning connector and its bearer token | IdP provisioning settings for the app | [ ] |
| 2.3 | OAuth grants the application holds into your tenants | Google Workspace: Security > Access and data control > API controls > Manage App Access, Accessed apps list; Microsoft Entra ID: Enterprise apps > the app > Permissions (Admin consent and User consent tabs); GitHub organisation settings, Third-party Access; Slack: Apps and workflows | [ ] |
| 2.4 | Integration users or service accounts created for the application in other systems (CRM, ticketing, data warehouse) | User lists filtered by integration or API-only profile; NHI inventory | [ ] |
| 2.5 | API keys and tokens the application issued to you, stored in your pipelines, scripts, vaults or other SaaS | Secrets manager search for the provider name and key prefix; CI/CD variables; code secret scanning | [ ] |
| 2.6 | Keys or credentials you gave the application to reach your systems (cloud access keys, database users, SFTP accounts, storage signed URLs) | Cloud IAM, database user lists, the application's own integration settings page | [ ] |
| 2.7 | Webhooks in both directions, and IP allowlist entries for the provider | Webhook settings in each connected system; firewall and WAF rules | [ ] |
| 2.8 | DNS records pointing at the provider (CNAMEs for custom domains, SPF includes, DKIM keys, domain verification TXT records) | DNS zone files | [ ] |
| 2.9 | Browser extensions, desktop agents and mobile apps for the product on managed devices | Endpoint management and extension inventory | [ ] |
| 2.10 | Local (non-SSO) accounts in the application, including admin and break-glass accounts | The application's own user list compared with IdP assignments | [ ] |
3. Data export and verification (C minus 14 days to C)
| # | Check | Owner | Done |
|---|
| 3.1 | Data to keep is decided with the business owner and the records manager, using the retention schedule. Data with no retention need is not exported at all. See the Data Retention and Disposal Policy Template. | Business owner | [ ] |
| 3.2 | Export method and format agreed: the provider's bulk export, API extraction or a migration tool. Attachments, comments, audit logs and metadata are listed separately, because bulk exports often leave them out. | Technical owner | [ ] |
| 3.3 | The application's own audit logs are exported for the period your investigation and compliance needs require, before the tenant closes. After closure they are usually gone. | Security | [ ] |
| 3.4 | Export runs under a named, time-limited admin account or a short-lived token, not a long-lived API key, and the export files land in an approved location with the same classification controls as the source. | Technical owner | [ ] |
| 3.5 | Export is verified: record counts, file hashes and a sample restore or import into the successor system, signed off by the business owner. | Business owner | [ ] |
| 3.6 | Exported data is scanned for secrets (passwords and keys pasted into tickets, notes or chat) and any found are rotated at source. | Security | [ ] |
| 3.7 | Temporary export credentials and staging copies are deleted once the verified copy is in place. | Technical owner | [ ] |
4. Users, SSO and SCIM (at C)
| # | Check | Owner | Done |
|---|
| 4.1 | SCIM provisioning stopped in the IdP and its bearer token revoked in the application, so a later IdP change cannot recreate accounts. See the SCIM Provisioning Guide. | Identity team | [ ] |
| 4.2 | All user accounts in the application deactivated, including local and break-glass accounts found in 2.10. Admin accounts are last, after the export is verified. | Technical owner | [ ] |
| 4.3 | SSO application object disabled first, then deleted after a hold period. In Microsoft Entra ID, deactivating an enterprise application stops token issuance and sign-in while keeping its configuration; a deleted enterprise application stays restorable for 30 days and is then hard deleted. | Identity team | [ ] |
| 4.4 | IdP groups, app roles and access packages that existed only for this application removed, so they are not reused by accident. | Identity team | [ ] |
| 4.5 | Licences ended and the application removed from the IdP app catalogue and the self-service portal. | IT | [ ] |
5. Tokens and integrations it held into your systems (at C, or immediately on a vendor incident)
This is the section that matters most if the provider has been breached. In the Salesloft Drift breach, OAuth tokens that a chat integration held for its customers' Salesforce and Google Workspace tenants were used to export data directly through the APIs, with no phishing and no platform flaw. The customer-side response was the same as a planned exit: revoke every token the integration held and rotate credentials found in the data it could read. OWASP lists this under NHI3:2025 Vulnerable Third-Party NHI and recommends a playbook for revoking and reissuing connected tokens.
| Platform | Where the grant lives | Action and note | Done |
|---|
| GitHub | Organisation settings, Third-party Access, GitHub Apps and OAuth app policy | Uninstall the GitHub App from the organisation. Suspend keeps it installed but blocks access, which is useful while you investigate. Uninstalling removes organisation access; ask users who authorised the app personally to remove it under Authorized GitHub Apps in their own settings. | [ ] |
| Google Workspace | API controls, Manage App Access, Accessed apps | Set the app to Blocked so it has no access to any Google service, then confirm it leaves the accessed apps list (the list can take up to 48 hours to update). Revoke tokens per user where your tooling allows. | [ ] |
| Microsoft Entra ID | Enterprise apps, the app, Permissions | Revoke admin consent permissions on the Admin consent tab. Revoke user consent grants (oauth2PermissionGrants) with Microsoft Graph or PowerShell. Then disable the app or block consent, because revoking a grant does not stop users consenting again. | [ ] |
| Slack | Admin, Apps and workflows | Uninstall the app. Set it to Restrict as well, so members cannot reinstall or request it; restricting alone leaves an installed app working. | [ ] |
| # | Check | Owner | Done |
|---|
| 5.1 | Integration users created for the application in CRM, ticketing, data and finance systems disabled, their sessions ended and their API tokens revoked. | System owners | [ ] |
| 5.2 | Credentials you gave the application (cloud access keys, database users, SFTP keys, signed URLs) deleted or rotated, from list 2.6. | Cloud and data teams | [ ] |
| 5.3 | Webhooks pointing to the application removed, and inbound webhook secrets it used rotated. | Technical owner | [ ] |
| 5.4 | IP allowlist entries for the provider's ranges removed from firewalls, conditional access named locations and SaaS network policies. | Network | [ ] |
| 5.5 | Vendor incident only: credentials that appeared in any data the integration could read are treated as exposed and rotated, using the Secrets Rotation Runbook Template. | Security | [ ] |
6. Credentials it issued to you (C plus 1 day)
| # | Check | Owner | Done |
|---|
| 6.1 | API keys and personal access tokens issued by the application revoked in its admin console while you still have access, and removed from vaults, CI/CD variables and configuration files. | Technical owner | [ ] |
| 6.2 | Scripts, scheduled jobs and pipelines that called the application removed or repointed to the successor; any job that fails after cut-off is investigated, not re-enabled with an old key. | Engineering | [ ] |
| 6.3 | Desktop agents, browser extensions and mobile apps uninstalled from managed devices and blocked in endpoint policy. | Endpoint team | [ ] |
| 6.4 | Inventory records for every non-human identity tied to the application closed. See the NHI Offboarding and Decommissioning Guide. | Identity team | [ ] |
7. Domains, DNS and external references (C plus 7 days)
| # | Check | Owner | Done |
|---|
| 7.1 | Custom domain unbound from the tenant in the provider first, then the CNAME deleted. A CNAME left pointing at a released tenant can be claimed by someone else (subdomain takeover). | DNS owner | [ ] |
| 7.2 | SPF includes, DKIM selectors and domain verification TXT records for the provider removed, so it can no longer send mail as your domain. | Email team | [ ] |
| 7.3 | Links to the application removed from intranet pages, runbooks, email signatures and customer-facing documents. | Business owner | [ ] |
8. Account closure and deletion evidence (by contract end)
| # | Check | Owner | Done |
|---|
| 8.1 | Deletion requested in writing through the provider's documented closure process, naming the tenant, the data sets and backups. Where the provider is a processor under the UK GDPR or EU GDPR, Article 28(3)(g) requires it to delete or return all personal data at the controller's choice at the end of the services and delete existing copies unless law requires storage. | Business owner, privacy | [ ] |
| 8.2 | Provider's backup and log retention after closure recorded (how long deleted data persists in backups before it ages out). | Privacy | [ ] |
| 8.3 | Deletion confirmation or certificate received, stating the scope, method and date, and covering sub-processors. Article 28(3)(h) supports asking for the information needed to demonstrate this. | Privacy | [ ] |
| 8.4 | Customer-managed encryption keys (BYOK) used by the tenant destroyed or disabled after deletion is confirmed; this is your strongest evidence that residual copies cannot be read. NIST SP 800-88 Rev. 2 covers sanitisation methods, including cryptographic erase. | Security | [ ] |
| 8.5 | Billing stopped, payment cards and purchase orders closed, and the admin contact email changed to a monitored shared mailbox so closure notices are not lost. | Finance | [ ] |
9. Verification and sign-off (C plus 30 days)
| # | Check | Evidence | Done |
|---|
| 9.1 | No sign-ins, token issuance or API calls by the application or its integration users in IdP and SaaS logs since C. | [SIEM query and result] | [ ] |
| 9.2 | The application no longer appears in OAuth app inventories or SaaS discovery tooling, and no new user has connected it. | [screenshot or report] | [ ] |
| 9.3 | No failed jobs or alerts caused by the removal remain open. | [ticket list] | [ ] |
| 9.4 | Asset register, data map, record of processing and supplier register updated. | [register IDs] | [ ] |
| 9.5 | Business owner, security and privacy sign off; record archived. | [names, date] | [ ] |
Implementation guidance
Order of work: inventory first, export second, revoke third, delete last. Revoking before the export is verified can lock you out of your own data; deleting before revocation leaves grants in your tenants with no application object to find them by. The exception is a vendor incident, where section 5 comes first and the export waits until the provider confirms its platform is safe.
Disable, hold, then delete: disable the SSO object and integration users at C, keep them for a short hold period ([14] days) to catch broken dependencies, then delete. Rollback during the hold is re-enabling the object; after deletion it means re-creating the integration from scratch.
Small and large organisations: a small business can run this as a one-page list per app, and the biggest risk is the OAuth grants users made themselves without IT. Large organisations should drive section 2 from SaaS discovery and the OAuth inventory, and feed retirements into the governance process in the SaaS and OAuth App Governance Guide.
Metrics: retired applications with a completed record (target 100%); integrations or grants still active 30 days after C (target 0); days from contract end to deletion confirmation; API calls by retired integrations after C (target 0); retired apps with dangling DNS records (target 0).
Common failures: cancelling the contract but leaving OAuth grants in place; forgetting the integration user in the CRM because it was created by the vendor's onboarding wizard; deleting the CNAME before unbinding the domain, or never deleting it; losing audit logs because they were not exported before closure; accepting "your data will be deleted" without a confirmation covering backups; and a pipeline still holding the provider's API key, which someone revives months later.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|
| Inventory (2) | CM-8, SA-9 | ID.AM-02 | T1199 Trusted Relationship |
| Users, SSO, SCIM (4) | AC-2, IA-4 | PR.AA-05 | |
| Tokens and credentials (5, 6) | IA-5, CA-3 | PR.AA-05 | T1528 Steal Application Access Token; T1550.001 Application Access Token |
| Deletion and disposal (8) | MP-6, SR-12 | GV.SC-10 | |
In ISO/IEC 27001:2022 Annex A, the record supports 5.19 to 5.23 on supplier relationships and the use of cloud services, including exit from them.
Standards and references
Related NHI Mgmt Group resources: Vendor Offboarding and Termination Guide · SaaS and OAuth App Governance Guide · Cloud Exit Plan Template · Employee Offboarding Security Guide · SaaS deprovisioning