SaaS Security Policy Template: Approving, Configuring and Retiring SaaS Applications

SaaS applications are bought with a credit card, connected to corporate data with one OAuth consent click and rarely switched off, so most organisations hold far more SaaS access than anyone approved or can see. This template sets the rules for how a SaaS application is requested, risk-assessed and approved, how it must be connected to single sign-on, which security settings are mandatory, how third-party app integrations and OAuth consent are controlled, and how an application and all its access are retired. It is written for CISOs, IT and procurement leads and SaaS application owners who need a policy to adopt with light editing. The Top 10 SaaS Security Risks and the SaaS Security Guide explain the risks and controls; this page is the policy document that makes them mandatory.

How to use this template

• Replace text in square brackets, such as [Organisation], [Head of IT], [the SaaS register] and [90 days], with your own terms. Bracketed values are suggested defaults, not external requirements.
• "Must" is mandatory. "Should" is recommended practice where a documented exception may be justified.
• Keep the SaaS risk tiers (section 4.1) and the configuration baselines (section 4.4) as separately versioned standards, so they can change without re-approving the policy.
• For the vendor due diligence questions, use the SaaS Integration Security Questionnaire Template and the SaaS Application Security Review Checklist.
• Generative AI tools are SaaS applications and fall under this policy; the Shadow AI Policy Template adds AI-specific rules.

1. Purpose

This policy sets the requirements for selecting, approving, configuring, integrating, monitoring and retiring software-as-a-service applications used by [Organisation], so that every SaaS application holding [Organisation] data is known, owned, connected to central identity, configured to an agreed baseline, and fully deprovisioned when no longer needed.

2. Scope

• All SaaS applications that store, process or can access [Organisation] data, whether paid, free, trial or personal accounts used for work.
• Third-party applications, add-ons, browser extensions, bots and AI assistants that connect to approved SaaS platforms through OAuth, API keys or marketplace installs.
• Non-human identities created in or for SaaS: integration users, API tokens, service principals and app passwords.
• All staff, contractors and service providers acting for [Organisation].

Infrastructure and platform cloud services (IaaS and PaaS) are governed by [the cloud security policy].

3. Roles and responsibilities

4. Policy statements

4.1 Request and risk tiering

1. No SaaS application may be used for [Organisation] data until it is recorded in [the SaaS register] with an owner, tier, data classification, user population and renewal date.
2. Before approval, the requester must check the register for an existing approved application that meets the need.
3. Tier 1 and Tier 2 applications must complete a security assessment covering: independent assurance (for example ISO/IEC 27001 certification or a SOC 2 Type II report), SSO and MFA support, audit log availability and retention, data location, encryption, breach notification terms, sub-processors and data return and deletion at contract end.
4. Free trials must not receive Confidential or Restricted data or connect to corporate data sources.

4.2 Identity and access

1. Tier 1 and Tier 2 applications must authenticate users through [the corporate identity provider] by SAML or OpenID Connect single sign-on. Local passwords must be disabled except for documented break-glass accounts. See the Identity Provider and SSO Security Guide.
2. Where the application supports it, user accounts must be provisioned and deprovisioned automatically (for example SCIM) from the identity provider, so leavers lose access when their corporate account is disabled.
3. Phishing-resistant MFA must be required for all administrator accounts. Administrator rights must be held by named individuals, limited to [two to five] per application, and reviewed [quarterly]. See SaaS Admin Account Protection.
4. User access to Tier 1 applications must be reviewed by the application owner at least [every six months].

4.3 Third-party integrations and OAuth consent

1. Users must not be able to consent to third-party applications accessing [Organisation] data on core platforms (identity provider, email, collaboration, file storage, CRM, source code) except for applications from verified publishers requesting permissions classified as low impact. Microsoft's guidance for Entra ID recommends allowing user consent only for verified publishers, and only for permissions classified as low impact.
2. An admin consent workflow must be enabled so users can request review instead of working around the control.
3. Google Workspace tenants must use application access controls to restrict third-party access to Workspace services; CISA's SCuBA Google Workspace baseline makes this a requirement for US federal agencies (GWS.COMMONCONTROLS.10.1v1).
4. Every integration (OAuth app, marketplace app, API token, integration user) must have an owner, a documented purpose and the narrowest scopes available. Integrations with tenant-wide read or write scopes (all mail, all files, all records, directory write) are Tier 1 and need [CISO] approval.
5. Integration credentials must be stored and rotated under the Secrets Management Policy Template. Integrations unused for [90 days] must be revoked.
6. A vendor's multi-tenant application is only as safe as the vendor's handling of its own credentials. Grants to vendor applications must be included in incident response plans, so they can be disabled quickly if the vendor is compromised. In the ConnectWise Cloud Backup breach, an attacker used the backup application's own credential to sign in to customer Microsoft 365 tenants, where the app already held tenant-wide access, and MFA played no part.

4.4 Configuration baselines

1. Each Tier 1 application must have a documented security configuration baseline, approved by [CISO]. For Microsoft 365 and Google Workspace, CISA's Secure Cloud Business Applications (SCuBA) secure configuration baselines should be used as the starting point, assessed with CISA's ScubaGear (Microsoft 365) and ScubaGoggles (Google Workspace) tools or an equivalent.
2. Baselines must cover at least: authentication and session settings; administrator roles; external sharing defaults and link expiry; guest and external user access; third-party app access; data loss prevention where available; audit logging; and email forwarding where relevant.
3. Configuration must be assessed against the baseline at least [monthly] for Tier 1 applications, automatically where tools allow, and drift remediated within [30 days].

4.5 Data protection and logging

1. Audit logs for sign-ins, administrator actions, sharing changes and integration changes must be forwarded to [the SIEM] for Tier 1 applications and retained for [12 months]. Licence tiers that provide these logs must be bought for Tier 1 applications. See the SaaS Audit Log Retention and Licensing Guide.
2. Data must be classified and handled under [the data classification policy]. Restricted data must not be placed in an application not approved for it.
3. Tier 1 data must be backed up outside the provider where the business impact analysis requires it, under [the backup policy].

4.6 Unapproved SaaS

1. [Organisation] must run discovery for unapproved SaaS use, using [identity provider sign-in data, expense data, network or browser telemetry and OAuth grant reviews], at least [quarterly]. See the Shadow SaaS and Unsanctioned App Discovery Guide.
2. Discovered applications must be approved through section 4.1, replaced by an approved alternative, or blocked, within [60 days].

4.7 Offboarding and retirement

1. When a user leaves, all SaaS access must be removed within [24 hours], including accounts not connected to SSO, personal API tokens and OAuth grants the user made. See the SaaS Deprovisioning Guide guide.
2. When an application is retired, the owner must: export or migrate required data; obtain written confirmation of data deletion from the vendor; revoke every integration, API token and OAuth grant in both directions; remove SSO and provisioning connections; and close the register entry.
3. Ownership must be reassigned within [30 days] when an application owner leaves; applications with no owner are treated as candidates for retirement.

5. Exceptions

1. Applications that cannot meet section 4.2 (for example no SSO support) must be recorded in [the exception register] with compensating controls such as a password manager with unique passwords, MFA, and a quarterly access review.
2. Exceptions for Tier 1 applications are approved by [CISO]; others by [Head of IT]. Exceptions expire after no more than [12 months] or at contract renewal, whichever is sooner.

6. Compliance and monitoring

1. The [Head of IT] must report [quarterly] on:
   • SaaS applications in the register, by tier, and the percentage with a named owner.
   • Percentage of Tier 1 and Tier 2 applications behind SSO, and with automated deprovisioning.
   • Tier 1 baseline conformance score and open drift items.
   • Third-party integrations with high-privilege scopes, and integrations revoked as unused.
   • Unapproved applications discovered, and time to approve, replace or block.
2. Compliance with this policy is subject to internal audit at least [annually].

7. Review and approval

Implementation guidance

Rollout

1. Build the register from evidence: combine identity provider application lists, OAuth grant exports from core platforms and finance data. Expect the first register to be several times larger than the approved list.
2. Tier and assign owners: tier the top applications by data held, then assign owners. Applications nobody claims go to a retirement shortlist.
3. Restrict consent in stages: enable the admin consent workflow first, review the existing grants, then restrict user consent. Announce the change so users know how to request apps.
4. Baseline the big platforms: run ScubaGear or ScubaGoggles read-only against Microsoft 365 or Google Workspace, record the score and plan fixes; repeat monthly.
5. Connect SSO and provisioning by tier: Tier 1 first, then Tier 2; disable local passwords only after a tested break-glass path exists.
6. Roll back safely: consent and sharing restrictions should be changed policy by policy, keeping a record of previous settings, so a single change can be reverted if a critical integration breaks.

Framework mapping

Sources for the default values

• CISA: ScubaGear and Microsoft 365 secure configuration baselines
• CISA: ScubaGoggles and Google Workspace secure configuration baselines
• Microsoft Learn: Configure how users consent to applications
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: SaaS Security Guide · Top 10 SaaS Security Risks · Consent Phishing and Illicit OAuth Grants Guide · SaaS Security Maturity Model · SaaS Security Buyer's Guide