SaaS Security Posture Management (SSPM): the mid-market guide

This guide is for IT and security leads at companies of 50 to 500 employees who have just been asked who has access to what across the SaaS stack.

SaaS security posture management (SSPM) is a category of security tooling that continuously assesses the security risk of software-as-a-service applications and manages their configuration, permissions and compliance posture. Gartner defines it in its cloud security reference architecture as tooling that "continuously assesses a SaaS application's security risk and manages its security posture" (Gartner, 25 November 2025). In practice an SSPM watches five things: application settings, user permissions, third-party app connections, data sharing and compliance evidence. Most companies below 500 employees do not buy a dedicated SSPM first. They fix the identity and access layer, because that is where the exposure concentrates and where the remediation is actually possible with the team they have.

If you already run a dedicated SaaS security platform with a full-time owner for its alerts, this guide will be too introductory. It is written for the stage before that, when the question is what to buy, in which order, and whether it is needed at all.

What is SaaS security posture management (SSPM)?

SaaS security posture management is the continuous assessment and correction of how your SaaS applications are configured, who can access them, what those users can do, and what evidence you can produce about it. It exists because SaaS applications shifted control of security settings from the infrastructure team to whoever administers each app, which in a growing company is usually a marketing manager for the CRM, a finance manager for the billing tool and nobody in particular for the eleven apps that arrived through a free trial.

The category was named by Gartner in 2019 and has stabilised around five functional pillars. Vendors describe them with different labels, so the table below uses the functional definition rather than any single vendor's marketing.

Why the definition matters more than the acronym

Every vendor glossary on this query defines SSPM as what that vendor sells. Palo Alto Networks frames it around configuration, Netskope around policy enforcement, Zluri around tool selection. The functional definition above is deliberately vendor-neutral, because the buying decision that follows depends entirely on which pillar is currently failing in your environment. A company whose problem is orphaned accounts does not need the same product as a company whose problem is public file sharing in a document repository.

SSPM vs CASB vs CSPM vs SMP: what each one actually covers

These four acronyms are routinely presented as competitors. They are not. They watch different objects, and Gartner's own cloud security reference architecture lists them as separate components of the same architecture rather than as alternatives.

The distinction that costs the most money to get wrong is CSPM against SSPM. They share a word and nothing else. CSPM secures the servers, storage buckets and networks your engineering team deploys. SSPM secures the applications your employees log into. Buying a CSPM because a search for posture management returned cloud infrastructure vendors is a common and expensive error in companies that have almost no infrastructure of their own.

The fourth row is the one the category leaders leave out. In its cloud security architecture guide, Gartner lists SaaS management platforms alongside SSPM and states that they "control security functions and ensure consistent governance across providers". That is a distinct component with its own mandate, and it is the entry point most mid-market teams take, because the inventory and the access lifecycle have to exist before any posture baseline can mean anything.

Why identity is the pillar that breaks first

Configuration drift is slow. A sharing default that was wrong in January is usually still wrong in June, and it stays exactly as wrong. Identity posture degrades continuously, because it is rewritten by every hire, every internal move, every departure and every trial signup.

Three mechanisms do most of the damage:

• Accounts outside the identity provider. Single sign-on covers the applications that were connected to it. The tools bought on a card by a team lead were never connected, so disabling the identity provider account does not close them.
• Privilege accumulation. Someone is granted admin rights for a migration and keeps them for three years. The principle of least privilege is easy to state and impossible to hold without a recurring review.
• OAuth grants nobody approved. An employee connects a note-taking assistant to the company calendar and mailbox. The grant is permanent, it survives the employee, and it does not appear in any licence list because it is free.

This is the concrete shape of the problem at APGAR, a 280-person consulting firm running more than 80 SaaS tools, which set out to increase its security posture by getting control of unauthorised applications and AI tools accessed through browsers. Its IT Manager and CISO, Jean-Marie Drucot, put it plainly: "Technically, I don't know how I would do my job today without Corma. Corma helps me enormously with all aspects of application detection and automatic management." (Corma customer story, APGAR).

Scale changes the arithmetic but not the mechanism. Brevo runs about 1,000 employees and more than 400 software assets, and automated over 400 onboardings and offboardings through Corma (Corma customer story, Brevo). At that volume, a manual joiner, mover and leaver process is not a risk to be monitored, it is a guaranteed backlog of open accounts.

If this is the section where you recognised your own environment, the practical starting point is the identity and access layer rather than a configuration scanner: see how Corma supports security teams on SaaS access and compliance.

The pillar the category has not caught up with: non-human identities

The five-pillar model was built for a stack where every account belonged to a person. That assumption broke in 2025 and 2026. Service accounts, API keys, integration users and now AI agents hold standing access to production data, and they are invisible to the controls designed for employees: they never appear in an HR system, they are not offboarded, and they do not consume a licence seat that finance would notice.

This is where the current SSPM content leaves buyers on their own. Measured by script on the rendered text of the five editorial pages ranking in the top 20 for this query in August 2026, shadow AI is mentioned on one page out of five and non-human identity on three, always in passing and never with a control to apply. Yet at APGAR the trigger for the whole posture project was AI tools reached through browsers, which evade traditional monitoring precisely because they create no account in any system of record.

Three controls apply here, and all three sit on the identity pillar rather than the configuration one:

• Inventory the non-human identities alongside the human ones, with an owner and an expiry date for each. An API key with no owner is an orphaned account with more privilege than most employees.
• Treat an AI assistant connection as an access grant, not as a productivity tool. When an assistant is connected to a mailbox or a document repository, it inherits that user's read scope permanently.
• Include agents in the access review. If the quarterly review only lists people, it certifies a fraction of the real access surface, and the certificate is misleading rather than incomplete.

Does your company actually need a dedicated SSPM?

Not necessarily, and the honest answer depends on two variables: how many applications hold regulated or sensitive data, and whether anyone owns their configuration.

A dedicated SSPM earns its place when you have a handful of deep, heavily customised applications, typically a CRM, an ERP and a collaboration suite, each with hundreds of security settings, and at least one person whose job includes acting on the alerts it produces. Below that, the alerts become a second inbox nobody reads, which is worse than no tool at all because it produces the paperwork of security without the effect.

Does Microsoft Defender already do this?

Partly, and this is the most frequent objection from teams running Microsoft 365. Microsoft Defender for Cloud Apps includes SaaS security posture management capabilities, and for a Microsoft-centric estate that covers the largest applications, it may be sufficient for the configuration pillar. What native tooling does not cover is the long tail: the apps bought outside IT, the free tools with corporate accounts, and the AI assistants connected by OAuth. That tail is precisely where shadow IT and shadow AI live, and it is invisible to a tool that only inspects applications it already knows about.

What SSPM does not do

Category pages rarely state the limits, so here they are:

• It does not discover applications it has no connector for. Coverage of your specific stack matters far more than the total connector count on a vendor's website.
• It does not decide who should have access. It reports the current state. The decision requires a named owner per application.
• It does not replace an identity provider, and it does not provision or deprovision users unless it also carries identity lifecycle features.
• It does not stop a valid user with valid credentials doing something harmful. That is detection and response, a different budget line.

What NIS2 and GDPR actually require of your SaaS posture

Search results on this topic are written for a United States buyer. Across the five editorial pages ranking in the top 20 for this query in August 2026, the terms NIS2, Europe and data residency appear zero times in total, measured by script on the rendered text. European buyers therefore receive an answer built for a different regulatory environment.

The regulation itself is more useful than the vendor content, and it never mentions SSPM. Article 21(2) of Directive (EU) 2022/2555 sets out minimum cybersecurity risk-management measures. Three of them land directly on SaaS posture.

There is a second European consideration that no vendor glossary raises, and it deserves a direct question during any evaluation. A posture management tool needs privileged, often admin-level API access to every application you connect to it. It therefore becomes one of the most sensitive processors in your estate, and under GDPR it is a sub-processor holding metadata about every employee and every application you run. Ask where that data is stored, under which jurisdiction, and what certification supports the answer. Corma runs its web servers and databases in data centres inside the European Union and is certified to ISO/IEC 27001:2022, audited annually by an independent third party.

If NIS2 is the reason this project landed on your desk, the NIS2 compliance checklist for IT teams covers the wider obligations beyond SaaS posture.

How to secure your SaaS security posture in six steps

This sequence assumes no dedicated tool at the start and works in the order that produces evidence fastest.

1. Build the real inventory. Not the list of apps IT knows about. The list derived from single sign-on logs, expense and card data, and browser-level discovery. Expect the true number to be two to three times the expected one.
2. Assign an owner per application. Every app gets a named business owner accountable for its settings and its user list. Without this, every later step has no addressee.
3. Set the identity baseline. For each application: is it behind single sign-on, is MFA enforced, who holds admin rights, and how are accounts closed at departure. Fix the top ten applications by data sensitivity first.
4. Review third-party grants. Pull the OAuth grants on your main identity and collaboration platforms, revoke what has no owner, and set an approval path so the next one is a decision rather than a discovery.
5. Run access reviews on a schedule. Quarterly for sensitive applications, at minimum annually elsewhere, delegated to the application owner rather than centralised on IT. See access review for the mechanics and automated and compliant access reviews for how to run them without spreadsheets.
6. Keep the evidence as a by-product. Each review should leave an exportable record of who reviewed what, when, and what was removed. Evidence assembled after the fact is the single most expensive part of an audit.

Steps one, two, three and five are achievable with a SaaS management and identity platform. Step four is partly covered by one. Configuration baselining across hundreds of settings per application is where a dedicated SSPM becomes the right instrument.

Where Corma fits, and where it does not

Corma is a European SaaS management and identity platform, not a configuration scanner. It covers the pillars that break first and produces the evidence auditors ask for, and it is honest about the boundary.

Three facts are worth checking against any alternative you evaluate. Corma exposes dedicated integration pages for 282 distinct applications on its public site, verified from the live sitemap on 16 August 2026, which is a more useful coverage signal than a rounded marketing number. It has been recognised in the Gartner Magic Quadrant for SaaS Management Platforms in 2026 for the second consecutive year, the same component Gartner places next to SSPM in its cloud security architecture. And it hosts data in the European Union under ISO/IEC 27001:2022 certification, which matters because the tool itself will hold an access map of your entire company.

Related capabilities: SaaS management, identity and access management, shadow AI discovery and automated identity governance. To see the access map of your own stack, request a demo.

Frequently asked questions

What is SSPM in simple terms?

SSPM is tooling that continuously checks how your SaaS applications are configured, who can access them and what those users can do, then flags what falls outside your policy. It applies to applications your employees use, not to cloud infrastructure your engineers deploy.

What is the difference between SSPM and CASB?

A CASB sits in or beside the network path and inspects data flowing to and from cloud services. An SSPM connects to each application through its API and inspects internal settings, permissions and connected apps. A CASB sees traffic, an SSPM sees configuration.

What is the difference between SSPM and CSPM?

CSPM secures infrastructure in IaaS and PaaS environments such as AWS, Azure and Google Cloud, covering resources like virtual machines, storage and networks. SSPM secures the SaaS applications your employees log into, covering settings, roles and permissions. Companies with little owned infrastructure usually need SSPM capability rather than CSPM.

Do small and mid-size companies need SSPM?

They need SaaS posture control, which is not the same as buying a dedicated SSPM product. Below roughly 500 employees, the highest-return work is a complete application inventory, an owner per application, MFA and single sign-on coverage, and recurring access reviews. A dedicated SSPM becomes worthwhile once several deeply customised applications hold sensitive data and someone owns the alerts.

Does NIS2 require an SSPM?

No. Directive (EU) 2022/2555 never names the category. Article 21(2) requires minimum measures including supply chain security, access control policies, asset management and multi-factor authentication. Those can be met with a SaaS management and identity platform, with a dedicated SSPM, or with documented manual process, provided the evidence exists.

Is SSPM the same as SaaS management?

No. Gartner lists SaaS security posture management and SaaS management platforms as two distinct components in its cloud security reference architecture. SSPM assesses application security risk and posture. A SaaS management platform governs the inventory, licences, spend and access lifecycle, and Gartner credits it with controlling security functions and ensuring consistent governance across providers.

How often should SaaS access reviews run?

Quarterly for applications holding sensitive or regulated data, and at least annually for the rest. ISO 27001 and SOC 2 auditors look for a documented cadence that was actually followed, with evidence of what was removed, rather than for a specific frequency.