The SaaS Security Checklist Every IT Team Should Run Quarterly

SaaS security failures are rarely the result of vendor breaches. They're almost always the result of misconfiguration: overly permissive sharing settings, OAuth integrations granted excessive permissions, admin accounts without MFA, and former employees retaining access. A quarterly security review catches these issues before they become incidents.

The Quarterly Checklist

MFA coverage: Verify that MFA is enforced for all users on every business-critical application. Pay particular attention to admin accounts and to tools not connected to SSO.

OAuth audit: Review all third-party integrations authorised through OAuth in your identity provider. Revoke integrations for tools no longer in use. Flag any integration requesting write access to sensitive data stores.

Sharing settings: Review default sharing settings in file storage (Google Drive, SharePoint, OneDrive) and collaboration tools. Externally shared files that no longer need to be shared are a persistent leak.

Former employee access: Cross-reference your HR system's list of departures in the last quarter against your SaaS access records. Even with an automated offboarding process, spot-check a sample to verify revocation completed successfully.

Privilege review: Review the admin user list for every critical application. Admin access should be limited to those who actively need it. Remove or downgrade admin privileges for users who no longer require them.

OAuth Integration Security

OAuth integrations — connections where one SaaS tool is granted access to data in another — are one of the most significant and least managed SaaS security risks. An employee who connects a productivity app to their Google Drive, or a marketing tool to their Salesforce account, is granting that third-party application read (and sometimes write) access to sensitive corporate data. Review your identity provider's OAuth audit log quarterly and revoke any integrations for tools that are no longer in use.

Pay particular attention to OAuth integrations requesting write access or admin-level permissions. A calendar scheduling tool that needs read access to your calendar is low risk. An integration that requests write access to your file storage, or full admin access to your Salesforce organisation, warrants careful review of why the level of access is needed and whether it can be restricted to a narrower scope. Many integrations request the maximum available permission "just in case" rather than the minimum needed for their actual functionality.

Multi-Factor Authentication Coverage

MFA is the single most effective control against account compromise, and yet most organisations have gaps in their MFA coverage — particularly for applications not connected to SSO, for legacy tools with poor MFA support, and for service accounts and shared credentials. Map every SaaS application against its MFA status: SSO-connected (inherits MFA from identity provider), tool-native MFA enabled, or no MFA. Applications in the third category that have access to sensitive data should be prioritised for either SSO connection or native MFA enablement.

Responding to Vendor Security Incidents

When a SaaS vendor discloses a security incident or data breach, your response needs to be fast and structured. The immediate steps: assess the scope of the incident as described in the vendor's notification, determine what data of yours may have been affected, check whether the incident affects your regulatory obligations (breach notification under GDPR, for example), and communicate internally to affected stakeholders. Having a documented vendor security incident response process — with named roles and decision criteria — allows you to respond in hours rather than days.