Security misses during SaaS procurement

SaaS procurement looks easier than traditional software purchasing. There is no capex approval for infrastructure, no data center planning, and a subscription model that appears budget-friendly. For small teams or departmental purchases, this can indeed move quickly. For the bigger entities, as they say, the devil is in the details. While there are other challenges like vendor risk, challenges with integrations, stakeholder and contract management, we will strictly focus on the security aspect, or rather, the blind spots that can trip up the client companies.  

Certification is not enough

Two certifications are essential for every SaaS procurement:  ISO 27001 certification for systematic information security management and SOC 2 certification for strict customer data controls. However, a potential blind spot is what comes after. The certifications themselves do not ensure that everything is ready to go. These are just the historical snapshots of the vendor’s internal processes. Do they account for how the vendor secures the client’s specific instance or how they handle data once it leaves their primary environment? Not looking for the answers to these questions invites the danger of creating a false sense of security. Compliant is not the same as hardened. Many SaaS tools ship with default settings that require manual configuration to secure. Ignoring them means dealing with insecure, wide-open settings that are a ticking time bomb, but you cannot see how much time is left on the clock.

Don’t SCIM the surface!

Zombies ARE dangerous, just ask Hershel Greene or Captain Henry Rhodes. Similarly, zombie accounts are bad for security. A security team might be satisfied that a tool supports Okta or Azure AD, but if it lacks System for Cross-domain Identity Management (SCIM), it cannot automate user deprovisioning. This means when an employee leaves the company and is disabled in the central directory, their local account within the SaaS tool might remain active and accessible and turn into a zombie account.  It also helps mitigate the risk associated with SaaS-to-SaaS connections, where the primary tool allows users to install third-party plugins or marketplace apps. These 4th-party integrations often request broad “read/write” OAuth permissions that bypass traditional perimeter defenses and remain active even if passwords are changed. SCIM sends a deactivate or delete command to the vendor’s API, and deactivates means to access like OAuth tokens and PATs. 

Andrew Aken, AVP-Research, QKS Group, sums up the situation: “Security blind spots in SaaS procurement often emerge from the gap between vendor assurances and operational reality. Certifications, SSO/SCIM support, or ‘enterprise’ feature labels can create a perception of security maturity, but the real risk lies in identity lifecycle automation, audit log fidelity, and data recovery capabilities. Organizations should also account for the hidden total cost of ownership – especially data storage, log retention, and integration overhead – which often sits outside the base subscription price but becomes critical for security visibility and compliance.”

Now, inclusion of SCIM is where things get more nuanced beyond accidental overlook. SCIM is almost exclusively bundled into the Enterprise tier. It is rarely offered as a standalone “add-on” that you can buy to avoid upgrading. So, it may be out of reach for teams that are bootstrapped or have a lower OpEx appetite. Here is how much the price jumps with some popular apps.

At the cost of deviating from the main cost of accidental oversight, such clients can opt for a workaround like group-based gating. Instead of individual access, manage access through a central “Security Group” in your SSO. When the user is removed from the group, they lose the ability to log in, even if their account hasn’t been deleted by the vendor yet. To put it in zombie terms, there will be nothing to “turn”. Coming to the risk of SaaS-to-SaaS connections, a single SSPM or SaaS Management tool like Wing Security, Lumos, or AppOmni can work, or simply disabling the setting that allows users to “auto-approve” third-party apps in platforms like Slack, GitHub, or Salesforce is a good option. Coming back to the discussion about inadvertent blind spots, let us look at the next: responsibility.

Who is responsible for responsibility?

While providers like Salesforce or Microsoft ensure the service stays up, the customer remains the sole owner and protector of their own data. This means that if an internal admin accidentally deletes a critical database or a ransomware attack encrypts your SaaS files, the vendor is under no contractual obligation to provide a point-in-time recovery. Without a third-party backup service or a specific data-protection add-on, that data could be permanently lost, as standard SaaS “availability” is not the same as a functional “data backup.”

Compounding this risk is the issue of inconsistent logging and monitoring across different SaaS tiers. Not all “Enterprise” packages are created equal. Two vendors might both claim to offer “Audit Logs,” but their depth, retention, and accessibility can vary wildly. Many vendors treat high-fidelity security logs as a premium feature, offering only basic activity tracking or limiting retention to 30 days on lower-tier plans. This creates a forensic blind spot during an incident investigation, as by the time a breach is discovered, the logs showing who accessed a specific file or changed a critical configuration may have already been purged. Furthermore, if the logs are provided in a proprietary format that cannot be easily ingested by SIEM (Security Information and Event Management) tools like Sentinel or Splunk, the security team may find themselves unable to correlate SaaS activity with the rest of your network, leaving a significant gap in your overall threat detection capabilities.