Most SaaS security problems are decided before the contract is signed: whether the app supports SSO and SCIM, whether its logs can leave the platform, where the data lives, what OAuth access it asks for and who can administer it. This template is an intake checklist for reviewing a new SaaS application before purchase, sized so a low-risk tool can be approved in a day and a high-risk one gets the scrutiny it needs. It covers identity (SSO, MFA, SCIM), the admin model, logging, data residency and handling, OAuth scopes and integrations, vendor assurance and exit. It is for security, IT and procurement teams who own the approval step. For the risks behind each check, see Top 10 SaaS Security Risks; for connecting a third-party app to a SaaS platform you already run, use the SaaS Integration Security Questionnaire Template.
How to use this template
- Replace text in square brackets, such as [Organisation], [identity provider] and [Security review team], with your own values.
- Complete section 4 (triage) first. It sets the tier, and the tier decides which of sections 5 to 11 apply. Do not send a 200 question questionnaire for a low-risk tool.
- Answer each item with Yes, No or Partial, plus the evidence: a link to the vendor's documentation, a trust centre document, a screenshot from a trial tenant, or a contract clause.
- Items marked Must block approval at that tier unless an exception is approved. Items marked Should become conditions or risk notes.
- Test identity and logging claims in a trial tenant where you can. A feature listed on a pricing page may sit in a higher plan than the one being bought.
1. Purpose
This checklist sets the security requirements a SaaS application must meet before [Organisation] buys or adopts it, and records the evidence for the decision. It supports third-party risk management and gives audit evidence for NIST CSF 2.0 GV.SC (cybersecurity supply chain risk management) outcomes, ISO/IEC 27001:2022 Annex A 5.19 to 5.23 on supplier relationships and cloud services, and NIST SP 800-53 SA-9 External System Services.
2. Scope and triggers
- Any new SaaS application, including free and trial tiers, browser extensions with a cloud back end, and AI services, used with [Organisation] data or accounts.
- A material change to an approved app: a new module that processes new data, a plan downgrade that removes SSO or logging, or a new integration with high-privilege scopes.
- Renewals of high-tier apps, where the review is repeated in a lighter form.
Apps already in use without approval are found through discovery and then brought through this checklist. See the Shadow SaaS and Unsanctioned App Discovery Guide.
3. Roles and responsibilities
- Requester and business owner: completes section 4, names an app owner and an administrator, and owns the app after approval.
- [Security review team]: reviews sections 5 to 11, sets conditions and records the decision.
- [IAM team]: confirms SSO, SCIM and admin role design.
- [Privacy team or DPO]: reviews personal data, residency and transfers.
- [Procurement and legal]: ensures contract terms in section 11 are included and that the plan bought includes the security features relied on.
4. Triage and tiering
| Question | Answer that raises the tier |
|---|
| What data will it hold or process? | Personal data, special category data, customer data, financial data, source code, credentials or [restricted] data |
| How many users, and who? | All staff, customers or external parties |
| Will it connect to other systems? | OAuth access to email, files, calendar, CRM or code repositories; API keys to production systems |
| Is it business critical? | An outage stops a core process |
| Does it act on data automatically? | AI features or agents that read content or take actions |
| Tier | Typical example | Sections required | Target turnaround |
|---|
| Low | Design tool with no company data and a few users | 5 (SSO where available), 9 | [1 working day] |
| Medium | Team collaboration or project tool with internal data | 5 to 9, 11 | [5 working days] |
| High | HR, finance, CRM or any app with OAuth access to core platforms or sensitive data | All, plus a trial tenant test | [15 working days] |
5. Identity and authentication
| ID | Requirement | Level |
|---|
| ID-1 | Supports single sign-on through [identity provider] using SAML 2.0 or OpenID Connect, on the plan being purchased. | Must (Medium, High) |
| ID-2 | Local password login can be disabled for all users once SSO is on, or limited to named break-glass accounts. | Must (High) |
| ID-3 | Where SSO is not available, the app enforces MFA for all users and admins, set by the tenant administrator rather than left to each user. | Must |
| ID-4 | Supports automated user provisioning and, critically, deprovisioning through SCIM 2.0 or an equivalent API, so leavers lose access when their identity provider account is disabled. | Must (High), Should (Medium) |
| ID-5 | Sessions time out and can be revoked centrally by an administrator. | Should |
| ID-6 | Service accounts, API keys and personal access tokens can be listed, scoped, given an expiry and revoked by an administrator. | Must (High) |
Without ID-2 and ID-3, one infostealer-harvested password can be enough: the Snowflake Breach 2024 involved customer accounts accessed with stolen credentials where MFA was not enforced. Detail on SCIM is in the SCIM Provisioning Guide.
6. Administration model
| ID | Requirement | Level |
|---|
| AD-1 | Role-based administration with separate roles for user management, security settings, billing and data export, so not every admin is a super admin. | Must (High) |
| AD-2 | Admin roles can be mapped from [identity provider] groups, so admin rights follow the joiner, mover, leaver process. | Should |
| AD-3 | Vendor support access to the tenant is off by default, granted by the customer for a limited time, and logged. | Must (High) |
| AD-4 | Tenant-wide security settings (sharing defaults, external users, third-party app installs) can be locked by administrators. | Must (Medium, High) |
| AD-5 | Named app owner and at least two administrators are recorded, with no shared admin accounts. | Must |
7. Logging and monitoring
| ID | Requirement | Level |
|---|
| LG-1 | Audit logs record sign-ins, admin changes, permission and sharing changes, data exports and API or token activity. | Must (Medium, High) |
| LG-2 | Logs can be exported by API or streaming to [SIEM], on the plan being purchased. | Must (High) |
| LG-3 | In-app log retention is stated, and covers at least [90 days] or export runs continuously. | Should |
| LG-4 | The vendor notifies customers of security incidents affecting their data within a contractual time limit. | Must (High) |
Log availability and plan tiers are covered in the SaaS Audit Log Retention and Licensing Guide.
8. Data protection and residency
| ID | Requirement | Level |
|---|
| DP-1 | Data storage and processing locations are documented, and a region can be selected where [Organisation] requires it. | Must (High) |
| DP-2 | Sub-processors are listed, and the vendor gives notice of changes. | Must (where personal data) |
| DP-3 | A data processing agreement is in place, with an international transfer mechanism where data leaves [jurisdiction]. | Must (where personal data) |
| DP-4 | Data is encrypted in transit and at rest; customer-managed keys are available if required for this data class. | Must (encryption), Should (keys) |
| DP-5 | Customer data is not used to train the vendor's AI models without an explicit opt-in, and AI features can be switched off by the tenant administrator. | Must (High) |
| DP-6 | Data can be exported in a usable format and is deleted within a stated period after termination. | Must (Medium, High) |
9. OAuth scopes and integrations
| ID | Requirement | Level |
|---|
| OA-1 | Every OAuth permission requested from [Microsoft 365 / Google Workspace / Salesforce / GitHub] is listed, with the reason for each. Application permissions (no signed-in user) are treated as high risk. | Must |
| OA-2 | Requested scopes are the minimum: read-only where the feature only reads, and limited to specific sites, mailboxes or repositories where the platform allows. | Must (High) |
| OA-3 | Consent is granted by an administrator through [admin consent workflow], not by individual users. User consent in the tenant is restricted to verified publishers and low-impact permissions, or disabled. | Must |
| OA-4 | The vendor describes how it stores and protects refresh tokens and API keys it holds for customers, and how customers can revoke them. | Must (High) |
| OA-5 | Integration identities and tokens are recorded in the NHI inventory with an owner and review date. | Must (High) |
OAuth tokens held by a vendor are a supply chain path into your tenant: in the Salesloft Drift Breach 2025, stolen OAuth tokens from one chatbot integration opened hundreds of Salesforce tenants. Revoking consent stops future access but check the platform's revocation method; in Microsoft Entra ID, changing consent settings affects future consents only, so existing grants remain until removed.
10. Vendor assurance
| Evidence | What it shows | What to check |
|---|
| SOC 2 Type II report | An auditor tested controls over a period against the AICPA Trust Services Criteria | Period covered, system in scope matches the product, exceptions, complementary user entity controls you must operate. See the How to Read a SOC 2 Report Guide. |
| ISO/IEC 27001 certificate | A certified information security management system | Certificate scope includes this product and its hosting; certificate is current and issued by an accredited body. |
| CSA CAIQ or STAR entry | Yes or no answers mapped to the Cloud Controls Matrix (v4.1, 197 control objectives in 17 domains); STAR Level 1 is a self-assessment, Level 2 involves a third party | Level and date; self-assessment answers are claims, not tested evidence. |
| Penetration test summary | Independent testing of the application | Date, scope, and that high findings were fixed. |
| Secure configuration baseline | Settings the tenant should use. For Microsoft 365 and Google Workspace, CISA's SCuBA baselines and the ScubaGear and ScubaGoggles assessment tools | Whether the vendor publishes a hardening guide; apply it at onboarding. |
11. Contract, exit and decision
- Contract: security incident notification time, right to receive assurance reports annually, data processing agreement, sub-processor notice, data return and deletion on exit, and the plan that includes SSO, SCIM and log export written into the order form.
- Exit: how data is exported, how long it is retained after termination, and how integrations and tokens are revoked. Offboarding steps are in the SaaS deprovisioning guide.
- Decision: Approved, Approved with conditions (listed with owner and due date), or Rejected. Record the tier, reviewer, date and next review date.
Standards and references
Implementation guidance
- Put the intake where people buy: attach section 4 to the purchase request and the expense process, so free and card-paid tools are caught too.
- Publish the tiers and turnaround: a promised turnaround per tier is what stops teams going around the process.
- Pre-approve common apps: keep an approved catalogue so repeat requests take minutes.
- Lock tenant consent first: restricting user consent (OA-3) and setting an admin consent workflow catches high-risk integrations even when an app slips past procurement. Pilot the restriction in report mode where the platform supports it and communicate the request route before switching.
- Measure: median approval time per tier, percentage of approved apps behind SSO, percentage of high-tier apps with SCIM deprovisioning and SIEM log export, OAuth grants with application permissions reviewed in the last [6 months], and apps discovered that bypassed review.
- Small versus large: a small organisation can run sections 4, 5 and 9 alone for most tools. Large organisations should feed decisions into the third-party risk register; see the Third-Party Risk Management Guide.
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: SaaS Security Guide · Top 10 SaaS Security Risks · Identity Provider and SSO Security Guide · SaaS Security Buyer's Guide