The average company uses 130 SaaS applications. Each one is a potential entry point, a data store, and a compliance obligation. Yet most organizations treat SaaS security as an afterthought — they vet vendors during procurement and never look again. That's how breaches happen. Not from sophisticated zero-day exploits, but from a forgotten admin account on a SaaS tool that nobody remembered the company was still paying for.
This checklist isn't theoretical. Every item comes from a real incident I've either investigated, read the postmortem of, or helped prevent. Print it, share it with your security team, and work through it systematically.
Authentication and Access Control
Identity Management
Centralize authentication through SSO. Every SaaS application should authenticate through your identity provider (Okta, Azure AD, Google Workspace). If a SaaS tool doesn't support SSO, that's a red flag — and if they charge extra for SSO (the infamous "SSO tax"), budget for it anyway. The alternative is username/password accounts that persist after employees leave.
Enforce MFA everywhere. SSO with MFA at the identity provider level is the baseline. For critical applications (admin consoles, financial tools, code repositories), require phishing-resistant MFA — FIDO2/WebAuthn hardware keys or passkeys. SMS-based MFA is better than nothing but vulnerable to SIM swapping. Our MFA implementation guide covers the technical details.
Implement SCIM provisioning. Manual account creation and deletion doesn't scale and doesn't work. SCIM (System for Cross-domain Identity Management) automates user provisioning and — critically — deprovisioning. When someone leaves the company, disabling their IdP account automatically disables all connected SaaS accounts. Without SCIM, you're relying on a manual checklist that someone will eventually forget.
Review access quarterly. Who has admin access to your CRM? Who can export customer data from your support tool? Who has owner permissions on your cloud infrastructure? Run quarterly access reviews for all critical SaaS applications. You'll find orphaned accounts, over-privileged users, and external collaborators who should have been removed months ago. Every single time.
Least Privilege
Default to viewer/reader roles. New users get the minimum access needed. Elevate only when justified and documented. The number of companies where every employee has admin access to Slack, Jira, or Confluence because "it was easier" is depressing.
Time-bound elevated access. Admin access for a specific task should expire after the task is complete. Just-in-time access tools (Azure PIM, Okta Privileged Access, ConductorOne) make this practical. Nobody needs permanent admin access to your production database — they need admin access for the 30 minutes they're running a migration.
Data Protection
Data Classification
Know where sensitive data lives. Map which SaaS applications store PII, financial data, health records, or intellectual property. Most companies can't answer this question accurately, which means they can't protect data they don't know exists in applications they've forgotten they use.
Enable DLP (Data Loss Prevention) where available. Google Workspace, Microsoft 365, Slack, and most enterprise SaaS platforms support DLP rules. Configure rules to detect and block sharing of credit card numbers, social security numbers, and other sensitive data patterns. The rules won't catch everything, but they catch the accidental shares that cause the most breaches.
Control data export. Can any user export your entire customer database from the CRM? Can any employee download all files from your shared drive? Restrict bulk export capabilities to authorized roles and log every export event. Data exfiltration often looks like a legitimate export.
Encryption
Verify encryption at rest and in transit. Every SaaS vendor claims encryption, but verify the implementation. TLS 1.2+ for transit (reject anything less). AES-256 for rest. Check whether the vendor holds the encryption keys or whether you can bring your own (BYOK). For regulated data, customer-managed keys may be a compliance requirement.
Understand the vendor's key management. If the vendor is breached and the attacker gets the database and the encryption keys (which are often stored alongside the database), encryption provides zero protection. Ask vendors: are encryption keys stored separately from encrypted data? Are they protected by HSM? This question alone filters serious security vendors from checkbox-security vendors.
API Security
Inventory all API integrations. Every SaaS-to-SaaS integration (Zapier connections, OAuth grants, API keys) is an access path. A compromised integration can access data in both connected systems. Audit your integration inventory monthly — tools like Grip Security, Nudge Security, and Valence Security automate this discovery.
Rotate API keys regularly. API keys to SaaS platforms should be rotated at least quarterly. Automate rotation where possible. A single leaked API key (in a Git commit, a Slack message, or a support ticket) can provide persistent access that survives password changes and SSO enforcement. For broader application security context, see our cybersecurity guide.
Monitor OAuth grants. When an employee clicks "Allow" on an OAuth consent screen, they're granting a third-party application access to your data. Most employees don't read consent screens carefully. Review OAuth grants across your SaaS platforms regularly and revoke unnecessary ones. Google Workspace Admin and Azure AD both provide visibility into third-party app grants.
Vendor Assessment
Check SOC 2 Type II reports. SOC 2 Type I means the vendor designed security controls. SOC 2 Type II means an auditor verified those controls worked over a period of time. Always ask for Type II. If a vendor only has Type I or no SOC 2 at all, that tells you something about their security maturity.
Review the vendor's breach history. Not to penalize them for past incidents (every company gets breached eventually) but to evaluate their response. Did they disclose promptly? Did they provide clear impact assessments? Did they implement meaningful improvements? A vendor that handles a breach well is more trustworthy than one that's never been tested.
Understand data residency. Where is your data physically stored? Which country's laws apply? For EU companies under GDPR, data stored in the US is subject to different legal frameworks. Many SaaS vendors now offer regional data residency options — use them if compliance requires it.
Evaluate the vendor's security page. Serious SaaS companies publish security documentation: architecture overviews, penetration test summaries, bug bounty programs, compliance certifications. If a vendor's security page is a single paragraph saying "we take security seriously," they probably don't.
Monitoring and Incident Response
Centralize SaaS logs. Critical SaaS applications should forward audit logs to your SIEM or log management platform. At minimum: authentication events, admin actions, data exports, permission changes, and API access. Without centralized logging, detecting a breach across 130 SaaS applications means checking 130 separate admin consoles.
Alert on anomalies. Login from a new country, bulk data download, admin role assignment, MFA disablement, API key creation — these events should trigger alerts. Most SaaS platforms support webhook-based event forwarding to tools like Tines, Torq, or your SIEM's alerting engine.
Have an incident response plan for SaaS breaches. When a SaaS vendor discloses a breach, your response needs to be immediate: assess impact (what data was exposed), rotate credentials, notify affected users, check for unauthorized access in your logs. Don't have time to figure this out during an incident — document the playbook now.
Compliance Framework Mapping
| Checklist Item | SOC 2 | ISO 27001 | GDPR | HIPAA |
|---|---|---|---|---|
| SSO/MFA | CC6.1 | A.9.4 | Art. 32 | 164.312(d) |
| Access Reviews | CC6.2 | A.9.2.5 | Art. 32 | 164.312(a) |
| Encryption at Rest | CC6.7 | A.10.1 | Art. 32 | 164.312(a)(2)(iv) |
| Audit Logging | CC7.2 | A.12.4 | Art. 30 | 164.312(b) |
| Vendor Assessment | CC9.2 | A.15.1 | Art. 28 | 164.314 |
| Incident Response | CC7.3 | A.16.1 | Art. 33-34 | 164.308(a)(6) |
FAQ
How often should I audit SaaS security?
Access reviews: quarterly. Vendor assessments: annually or when the vendor reports a material change. Integration audits: monthly. Configuration reviews (SSO enforcement, MFA status, DLP rules): monthly. Full security posture assessment: annually. The cadence matters less than consistency — a mediocre review done every quarter beats a perfect review done once.
What's the most common SaaS security failure?
Orphaned accounts. An employee leaves, their SSO is disabled, but their local account on a SaaS platform that doesn't support SSO still works. Or an ex-contractor's API key still functions because nobody tracked it. Automated deprovisioning through SCIM prevents this, but only for applications that support SCIM.
Do I need a CASB (Cloud Access Security Broker)?
For organizations with 500+ employees or stringent compliance requirements, probably yes. CASBs (Netskope, Zscaler, Microsoft Defender for Cloud Apps) provide visibility into shadow IT, enforce security policies across SaaS applications, and detect risky user behavior. For smaller organizations, manual processes can suffice — but they don't scale.
How do I handle shadow IT — SaaS tools purchased without IT approval?
You can't prevent it entirely, and trying to creates friction that drives more shadow IT. Instead: provide easy procurement for approved tools, use a CASB or SaaS management platform to discover unauthorized tools, and focus enforcement on applications that handle sensitive data. A marketing team using an unapproved design tool is low risk. A sales team using an unapproved CRM with customer data is not.