Testing SaaS Platforms and the Shared Responsibility Model

You can't hack infrastructure you don't own.

A financial services firm runs its CRM on Salesforce, its email and collaboration on Microsoft 365, its HR management on Workday, and its customer support on Zendesk. The CISO commissions an annual penetration test. The scope document lists the firm's IP ranges, its custom-built web applications, and its internal network — the same scope as every previous year.

The pen test comes back clean. The custom applications are well-written. The internal network has been progressively hardened. But the test never examined whether the Salesforce instance exposes customer data through misconfigured sharing rules. It never checked whether Microsoft 365 allows external forwarding of email to personal accounts. It never tested whether the Zendesk API exposes tickets from other tenants through predictable identifiers. And it never verified whether the Workday integration service account has permissions to export the entire employee database.

The firm's most sensitive data — customer records, employee PII, financial communications, support interactions — lives in platforms that were never tested. Not because the CISO doesn't care, but because the traditional pen test model doesn't know how to assess platforms you can't scan, can't exploit at the infrastructure level, and don't control.

A different model from IaaS — and less understood.

The shared responsibility model is well-established for IaaS (AWS, Azure, GCP) — the provider secures the infrastructure, the customer secures what they build on it. SaaS adds another layer: the provider also builds and secures the application. The customer's responsibility shrinks, but it doesn't disappear — and the residual responsibility is where almost all SaaS breaches originate.

The customer's responsibility in a SaaS model is smaller in scope but no less critical. It's concentrated in the areas that determine who can access what: identity, permissions, sharing, integrations, and configuration. These are precisely the areas that a SaaS security assessment must target.

The SaaS attack surface your organisation controls.

A SaaS security assessment doesn't scan ports or exploit buffer overflows. It systematically examines every configuration decision the organisation has made — or failed to make — within the platform. The attack surface is entirely configuration and integration driven.

The boundary that must never break.

In a multi-tenant SaaS platform, your data sits alongside every other customer's data — separated by logical controls, not physical infrastructure. Tenant isolation is the set of mechanisms that prevent Customer A from accessing Customer B's data. It's the most critical security property of any SaaS platform, and it's the one that, when it fails, produces the most catastrophic outcomes.

Tenant isolation failures are rare in mature platforms like Microsoft 365 and Salesforce — these providers invest enormously in multi-tenant security. But they do occur, particularly in smaller SaaS providers, rapidly-growing platforms, and custom-built multi-tenant applications.

For organisations using SaaS, tenant isolation is the provider's responsibility. For organisations building SaaS, it's theirs — and it should be the highest-priority target of every security assessment. A tenant isolation failure isn't one customer's data breach; it's every customer's data breach simultaneously.

A worked example of SaaS configuration assessment.

Microsoft 365 is the most widely deployed SaaS platform in the enterprise. It's also the one where we most frequently find configuration-level weaknesses — not because Microsoft's security is poor, but because the platform's flexibility creates a configuration surface that most organisations haven't fully secured.

Eighteen findings. Every one a configuration decision — not a software vulnerability. Every one within the organisation's responsibility column. Every one invisible to a traditional penetration test that scans IP ranges and probes exposed services. And finding F-011 — unrestricted external mail forwarding — is the single most commonly exploited post-compromise technique in business email compromise attacks.

The mindset shift from exploitation to configuration analysis.

Traditional penetration testing is adversarial: the tester attacks the system, looking for vulnerabilities that allow them to break in, escalate privileges, and access data. SaaS assessment is analytical: the tester examines the configuration, looking for decisions that create unintended access, excessive sharing, or absent controls.

This doesn't mean SaaS assessment is easier than traditional pen testing — it requires a different expertise. Understanding Salesforce's sharing model, Microsoft 365's conditional access policy engine, or the nuances of OAuth scope inheritance requires deep, platform-specific knowledge that general-purpose pen testers often don't possess.

Why your SaaS provider's SOC 2 isn't your security.

When organisations ask whether their SaaS platforms have been penetration tested, the answer is usually: "Yes — the provider has a SOC 2 Type II report, which includes evidence of regular pen testing." This is accurate — and almost entirely irrelevant to the organisation's actual risk.

A SOC 2 report tells you the building is structurally sound. It doesn't tell you whether you've left the windows open. Both matter — but only one is within your control to fix, and only one is within your responsibility to assess.

When you're the provider — and the customer.

For organisations that build SaaS platforms — rather than just use them — the security assessment model is fundamentally different. You own the application code, the infrastructure, and the multi-tenant architecture. Every layer of the shared responsibility model is your responsibility, and the testing must cover all of them.

Securing the platforms you use and the platforms you build.

The bottom line.

SaaS security is not infrastructure security. You can't exploit Salesforce. You can't port-scan Microsoft 365. The provider secures the platform; you secure your configuration of it. And configuration — permissions, sharing rules, authentication settings, integration scopes, audit logging — is where SaaS breaches originate.

A traditional pen test that scans IP ranges and probes services will never discover that your SharePoint site shares HR documents with "anyone with the link," that your Salesforce sharing rules expose all customer records to all users, or that a departed employee's OAuth grant gives a third-party app full read-write access to every mailbox in your organisation.

The shift from infrastructure exploitation to configuration analysis isn't a weakening of the assessment — it's a refocusing on where the risk actually lives. Your most sensitive data is in SaaS platforms. The security of that data depends entirely on how those platforms are configured. And the only way to know whether the configuration is correct is to test it — with platform-specific expertise, against your specific business context, with the same rigour you'd apply to any other critical asset.