SaaS security maturity runs from not knowing which apps you use, to continuous, automated control of settings, access and connections. This model has five levels. Each one lists what you can do, how to tell you are there, and the single next move that gets you to the following level.
The levels are an original working model, not an industry standard. Adjust them to your company.
Level 1: Unknown
Teams sign up for tools with a corporate card and an email address. Nobody has a list. Security learns about an app when a customer questionnaire asks about it.
You are here if you cannot name your five most sensitive SaaS apps and their owners.
Next move: build the list. Pull from your identity provider's app directory, expense reports and browser sign-in data. Mark each app with an owner and the type of data it holds.
Level 2: Inventoried
A list exists, with owners and data types. Basic controls are applied by hand: single sign-on on the big apps, multi-factor sign-in for admins, a short offboarding checklist.
You are here if every critical app has an owner and you can say who the administrators are.
Next move: pick a baseline and check against it. Start with a small set of settings per critical app: who can share data externally, how admins sign in, whether audit logs are on. Use the vendor's own security documentation as a starting point and write the baseline down.
Level 3: Measured
A posture tool or a disciplined script reads settings through each app's API and reports drift from the baseline. NIST SP 800-137 describes continuous monitoring as visibility into assets, vulnerabilities and control effectiveness, and this is the level where you start to have that visibility for SaaS.
You are here if you can say how many critical apps are connected for monitoring and how many findings are open per owner.
Next move: close the loop. Turn findings into tickets that land with owners, with due dates and an exception path. Track time to fix by team.
Level 4: Managed
Findings flow to owners and get fixed. Third-party connections are reviewed, admin accounts are minimal, and exceptions expire. Offboarding removes SaaS access automatically through the identity provider where the app supports it.
You are here if your median time to fix is known and improving, and exceptions have review dates.
Next move: prevent instead of detect. Move recurring findings into enforced defaults. If the same setting drifts every quarter, find who changes it and why, then lock it or give that person a supported alternative.
Level 5: Enforced
Baselines are applied as policy. New apps go through a short intake that checks data type and connection scope before access is granted. High-risk changes need approval. Findings that do appear are rare and trend toward zero by cause, not by suppression. Reviews happen on a calendar and after incidents.
You are here if a new SaaS app cannot reach company data without passing intake, and drift is tracked by cause.
Next move: keep it alive. Test the process with an exercise, such as asking a team to onboard a deliberately risky test app, and see what stops it.
How to place yourself honestly
Teams tend to rate themselves one level higher than the evidence supports. Use evidence. For each level, write one proof item you could show an auditor: the app list, the baseline document, the ticket report, the exception register. If you cannot produce it, you are one level lower.
Common stumbling points
Skipping from 1 to 3. Buying a posture tool before you have a list means it watches only the apps someone remembered to connect.
Measuring coverage by connected apps. Coverage should be against your known list, not against the tool's own list.
Treating exceptions as permanent. An exception without an expiry date is a policy change nobody approved.
Ignoring non-human access. OAuth grants and API tokens for integrations are accounts too. Give them owners.
What to do
- Place yourself on the model with one proof item per level.
- Build or refresh the SaaS app list, with owners and data types.
- Write a baseline of five to ten settings per critical app.
- Connect monitoring against that baseline and route findings to owners.
- Add expiry dates to every exception.
- Convert repeat drift into enforced defaults.
Where Safeguard fits
SaaS posture management is outside Safeguard's focus today, and Safeguard does not replace it. Safeguard works on the application and software supply chain side, including dependency inventory and release policies. The overlap is the habit this model teaches: keep an owned inventory first, then enforce rules against it.
Quick check
Do we need a tool to reach level 3?
Not necessarily. A careful script or manual review on a schedule can work for a handful of critical apps, though it gets hard to sustain as the list grows.
How often should levels be reassessed?
Twice a year is reasonable, or after a major change such as a merger or an identity provider switch.
Sources
- NIST SP 800-137, Information Security Continuous Monitoring
- NIST SP 800-53 Rev. 5, controls CA-7 and CM-8 (OSCAL catalog)
Last reviewed: 18 October 2026.
