SaaS Security Maturity Model: Five Levels

Most organisations run hundreds of SaaS applications but secure only the few that IT bought, while integrations, OAuth grants and API tokens connect the rest to their most sensitive data. This model uses NHI Mgmt Group's five levels, Ad hoc, Developing, Defined, Managed and Optimised, to score SaaS security across six capability areas: discovery, configuration posture (SSPM), OAuth and integration governance, identity and access, detection and response (SaaS ITDR), and governance. It is for security architects, identity teams and SaaS owners who need to score where they stand, agree a target and sequence the work. The risks themselves are covered in the Top 10 SaaS Security Risks and the programme in the SaaS Security Guide; this page is the scoring tool.

Key takeaways

Discovery caps every other score. You cannot harden, govern or monitor an application or integration you do not know exists, so an organisation with no SaaS inventory is Level 1 overall.
Integrations are the new perimeter. In the Salesloft Drift breach, stolen OAuth tokens let an attacker export data from many Salesforce tenants without touching a user password or MFA prompt.
Level 3 is the first sensible target: inventory with owners, baseline configurations checked against a published standard such as CISA's SCuBA baselines, admin approval for third-party app access, and SaaS logs in the SIEM.
Level 4 is continuous. Posture drift, new OAuth grants and anomalous token use are detected automatically and acted on within agreed times, not found at the annual audit.
Score per area, report both ends. A strong posture tool with no integration governance is a Level 4 posture and a Level 1 integration programme, and the board should hear both.

The five levels

Level	Name	What it looks like
1	Ad hoc	SaaS is bought by business units on cards. Nobody holds an inventory. Users consent to third-party apps freely. Admin settings are defaults. Audit logs are on whatever retention the licence gives and nobody reads them.
2	Developing	Core platforms (email, collaboration, CRM) sit behind single sign-on and MFA. Some discovery from expense data or a CASB. Configuration reviews are one-off projects. OAuth grants are reviewed after an incident or a vendor breach notice.
3	Defined	A SaaS security standard sets onboarding, baseline settings, owners and offboarding. The inventory covers sanctioned apps and known integrations. Baselines are assessed against a published standard. Third-party app access needs admin approval. SaaS audit logs are collected centrally with defined retention.
4	Managed	Discovery is continuous. Posture is scanned automatically with drift alerts and remediation SLAs. OAuth apps and API tokens are inventoried with owner, scopes and last use, and unused grants are removed. Detection rules cover token abuse and bulk export. Metrics are reported monthly.
5	Optimised	Policy as code: baselines are enforced and drift is auto-remediated. Integration access is least privilege, IP-restricted where the platform allows, and time-bound. SaaS detections feed automated response such as session and token revocation. Vendor token-handling practices are part of supplier assurance.

Capability areas

Score each area separately. The columns show what Levels 1, 3 and 5 look like; Levels 2 and 4 sit between them.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Discovery and inventory	None, or a list of what IT bought	Inventory of sanctioned apps and their integrations, each with a business owner, data classification and authentication method	Continuous discovery from identity provider logs, OAuth grants, browser and network telemetry and spend, reconciled with the inventory
Configuration posture (SSPM)	Defaults	Baselines for critical platforms assessed against a published standard; findings tracked	Continuous assessment, drift alerting and automated remediation for approved settings
OAuth and integration governance	Users consent to any app; tokens never reviewed	Admin approval for third-party app access; integration register with scopes and owners; periodic grant review	Least-privilege scopes, last-use tracking, automatic removal of stale grants, vendor token-storage assurance
Identity and access	Local accounts and shared admin logins	SSO and phishing-resistant MFA for admins on critical platforms; joiner-mover-leaver linked to SaaS	All apps behind SSO where supported; privileged SaaS roles just-in-time; deprovisioning verified, including API tokens
Detection and response (SaaS ITDR)	Logs unread, short retention	Sign-in and admin activity logs from critical apps in the SIEM; rules for impossible travel, new admin, mass download	Behavioural baselines per user and integration; automated session and token revocation; SaaS forensics playbooks tested
Governance and third parties	No standard, no owners	SaaS security standard and onboarding review; supplier assurance for critical apps	Risk-tiered reviews, contract clauses on token storage and breach notice, metrics reviewed by leadership

Dimension detail: what moves each area up

Discovery, Level 2 to 3: combine sources. Identity provider sign-in logs show sanctioned apps, OAuth consent records show connected apps, and spend data shows purchases outside IT. None is complete alone. See the Shadow SaaS Discovery Guide and NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
Posture, Level 2 to 3: adopt a published baseline rather than writing your own. CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines, and its open source assessment tools check tenants against them: ScubaGoggles for Google Workspace (Admin SDK export, OPA Rego verification, HTML and JSON reports) and ScubaGear for Microsoft 365 (PowerShell queries of M365 APIs, OPA Rego comparison, HTML, JSON and CSV reports). Platforms are listed alphabetically.
Posture, Level 3 to 4: move from point-in-time assessment to scheduled scans with drift alerts and remediation SLAs, whether through a commercial SSPM product or scheduled runs of the baseline tools. See the SaaS Security Buyer's Guide.
OAuth governance, Level 2 to 3: stop users granting broad scopes to unknown apps by requiring admin approval, and build a register of every integration with scopes, owner and data reached. See the Consent Phishing and Illicit OAuth Grants Guide.
OAuth governance, Level 3 to 4: track last use for each grant and API token, remove what is unused, and restrict integration tokens by IP where the platform supports it. See the SaaS API Token Security Guide.
Detection, Level 2 to 3: check log availability and retention per licence before writing rules; some platforms keep detailed audit events only on higher tiers or for short periods. See the SaaS Audit Log Retention and Licensing Guide and the ITDR Guide.

Mapping to frameworks and techniques

Source	Reference	Relevance to the model
NIST SP 800-53 Rev. 5	SA-9	External system services: the control family for SaaS providers and their assurance.
NIST SP 800-53 Rev. 5	CM-6, CM-7	Configuration settings and least functionality: the basis of SSPM baselines.
NIST SP 800-53 Rev. 5	AC-2, AC-6	Account management and least privilege, applied to users, admins and integrations.
NIST SP 800-53 Rev. 5	AU-6, CA-7	Audit review and continuous monitoring: the detection area.
NIST CSF 2.0	ID.AM-04, GV.SC-04	Inventories of supplier services; suppliers known and prioritised by criticality.
NIST CSF 2.0	PR.PS-01, PR.AA-05, DE.CM-09	Configuration management; access permissions managed and reviewed; software and runtime monitored.
MITRE ATT&CK	T1528, T1550.001	Steal Application Access Token; use of application access tokens for lateral movement.
MITRE ATT&CK	T1671, T1098.003	Cloud Application Integration for persistence; Additional Cloud Roles granted to keep access.

The ScubaGear project states that SCuBA controls have been mapped to NIST SP 800-53 and MITRE ATT&CK, which helps when a baseline finding must be reported against a control framework.

Self-assessment questions

Answer for your five most critical SaaS platforms first. A control in place for one platform but not the others scores Level 2.

Discovery and inventory

Can you produce a list of every SaaS application holding confidential data, with a named business owner for each?
Do you know which third-party integrations are connected to your CRM, email and file-sharing platforms today?
Is shadow SaaS found continuously, or only when someone files an expense claim?

Configuration posture

Are critical platforms assessed against a published baseline, and when was the last assessment?
Would you know within a day if an administrator turned off MFA enforcement or opened external sharing?

OAuth and integration governance

Can a user grant a third-party app access to their mailbox or files without admin approval?
For each integration, do you know its scopes, its owner, when it was last used and who at the vendor stores its token?
If a vendor announced a token breach tomorrow, how long would it take to revoke every token it holds for you? In the Salesloft Drift breach, customers also had to rotate secrets that had been stored in exported support cases.

Identity and access

Do all SaaS admins use phishing-resistant MFA through SSO, with no shared or local admin accounts left?
When someone leaves, are their API tokens and OAuth grants revoked, not just their SSO account? See SaaS deprovisioning.

Detection and response

Are sign-in, admin and data export events from critical platforms in your SIEM with retention long enough for an investigation?
Do you have rules for bulk export by integration accounts, new OAuth grants with broad scopes and token use from unexpected networks?

Governance

Is there an approved SaaS security standard that every new purchase goes through? The SaaS Security Policy Template is a starting point.

Scoring and evidence

Evidence an assessor should ask for	Supports
SaaS inventory export with owner, data class and SSO status	Discovery at Level 3
Baseline assessment reports and finding tracker	Posture at Level 3
Scheduled scan configuration, drift alerts and remediation SLA reports	Posture at Level 4
Consent policy settings and integration register with scopes and last use	OAuth governance at Level 3 to 4
Admin role list with MFA method and SSO enforcement	Identity at Level 3
SIEM data source list, detection rules and incident tickets from SaaS alerts	Detection at Level 3 to 4

Moving up: roadmap

Level 1 to 2, first 90 days: put email, collaboration and CRM behind SSO with MFA for all admins; pull an initial app list from identity provider logs and spend data; export the current OAuth grants on your main platforms and remove obviously abandoned ones.
Level 2 to 3, within 12 months: publish a SaaS security standard; assign owners; assess critical platforms against a published baseline and fix high findings; require admin approval for third-party app access; send audit logs from critical platforms to the SIEM and confirm retention.
Level 3 to 4: automate posture scanning with drift alerts; add last-use tracking and quarterly reviews for integrations and API tokens; write detections for token abuse and bulk export; test a SaaS incident playbook such as the OAuth Token Theft Incident Playbook.
Level 4 to 5: enforce baselines as code with auto-remediation; make integrations least privilege, IP-restricted and time-bound; connect detections to automated token and session revocation; include vendor token-handling in supplier assurance.

Small vs large organisations: a small organisation with a handful of platforms can reach Level 3 with native admin settings, a free baseline assessment tool and a spreadsheet register of integrations. A large organisation with hundreds of apps will need automated discovery and posture tooling to stay at Level 3, because manual reviews cannot keep up with new grants.

Metrics that show progress

Inventory coverage: share of discovered apps with a named owner and data classification.
Baseline conformance: share of baseline checks passing on critical platforms, and mean time to fix high findings.
Stale grants: number of OAuth grants and API tokens unused for 90 days, trending down.
Admin MFA: share of SaaS admin accounts on phishing-resistant MFA via SSO.
Log coverage: share of critical platforms with audit logs in the SIEM at the required retention.
Revocation time: time to revoke all tokens for a given vendor, measured in exercises.

Common failure patterns

Posture without integrations: an SSPM dashboard shows green while broad-scope OAuth apps connected years ago keep full mailbox access.
SSO treated as the whole answer: integration tokens and API keys bypass SSO and MFA entirely, as the Salesloft Drift case showed.
Logs that are not there: detection rules are written for events the current licence does not record or keeps for only a few days.
Offboarding stops at the identity provider: a leaver's personal API tokens keep working after their account is disabled.
Secrets inside SaaS data: credentials pasted into tickets and CRM records turn a SaaS data theft into a wider compromise.

Practitioner checklist

Build a SaaS inventory from at least three sources and assign an owner to every app holding confidential data.
Assess critical platforms against a published baseline and track findings to closure.
Require admin approval for third-party app access and keep an integration register with scopes, owner and last use.
Enforce SSO and phishing-resistant MFA for every SaaS administrator.
Revoke API tokens and OAuth grants in offboarding, not only the SSO account.
Collect SaaS audit logs centrally and confirm the licence retains the events your rules need.
Write detections for bulk export, new broad-scope grants and token use from unusual networks.
Rehearse revoking every token held by a single vendor and record the time taken.

SaaS Security Maturity Model: Score Discovery, Posture, OAuth Governance and Detection