SaaS Penetration Testing: Rules and Tenant Scope

Organisations want assurance over the SaaS applications that hold their data, but a penetration test of a SaaS tenant can breach the provider's terms, touch other customers' data or test the wrong thing entirely. In SaaS the customer does not own the application, the servers or the network, only a tenant: its identities, configuration, integrations and data. What you may test, and what is worth testing, follows from that. This guide is for security managers, SaaS platform owners and assessors who commission or approve a test of a SaaS application the organisation buys, such as a Microsoft 365 tenant, an Atlassian Cloud site or an identity platform. It covers what is in and out of scope, how provider testing policies work, written authorisation, the scope areas that matter in a tenant, safety, and handling the results. It does not describe testing methods or tools. For infrastructure on AWS, Azure or Google Cloud see the Cloud Penetration Testing Guide; for testing a SaaS product you build, see the Multi-Tenant SaaS Architecture Security Guide.

Key takeaways

You can usually test your own tenant, never the platform. Provider policies allow customers to assess their own instance, subject to rules; the provider's shared infrastructure, corporate systems and other tenants are always out of scope.
Read the provider's policy before you scope. Policies differ on notice: some need none for testing your own instance, others need a request days in advance, and almost all prohibit denial of service, social engineering of provider staff and access to other customers' data.
Most SaaS risk is configuration and identity, not code. Sign-in policy, admin roles, external sharing, OAuth consent and integration tokens are where real SaaS compromises start, so scope the test around them.
A configuration assessment often beats a pentest. Baseline scanners such as CISA's ScubaGear and ScubaGoggles test hundreds of settings safely; keep penetration testing for attack paths that span settings, identities and integrations.
Findings in the provider's code go to the provider. Report suspected platform vulnerabilities through the provider's disclosure channel within its time limits, and treat results as confidential under its terms.

What you can and cannot test in a SaaS application

In SaaS the provider runs the application, platform and infrastructure. The customer's share is smaller but decisive: who can sign in, with what strength, what admins can do, what users can share, which apps are connected and what is logged. The SaaS Security Guide covers that shared responsibility in depth. A test scope follows the same line.

Area	Usually in scope (your tenant)	Out of scope
Identity	Your users, groups, admin role assignments, SSO and MFA policy, conditional access rules, guest accounts	Other tenants' identities; provider staff accounts
Configuration	Tenant settings: sharing defaults, link expiry, forwarding, session length, app consent settings	Provider back-end configuration you cannot see or change
Integrations	OAuth apps you approved, API tokens and integration users you created, marketplace add-ons installed in your tenant (subject to the add-on vendor's own rules)	The third-party app vendor's own infrastructure, unless that vendor authorises it separately
Data	Your data, test records you create, permissions on your objects	Any other customer's data, even if a flaw exposes it
Custom code	Code you wrote that runs on the platform (scripts, low-code apps, custom pages), where the provider policy allows it	The provider's application code beyond what its policy permits
Availability	Nothing: load and stress testing follow a separate provider policy where one exists	Denial of service, flooding and volumetric testing

The NCSC notes that a penetration test only shows a system was not vulnerable to known issues on the day of testing, and that checking whether controls function is not a good use of test effort. That point is sharper in SaaS: many tenant checks are settings that can be read through admin APIs. Use the test for what only a human tester can do, such as chaining a weak guest policy, an over-permissioned integration and a sharing default into a real path to sensitive data.

Provider testing policies

Each provider publishes its own rules, usually as a penetration testing policy, rules of engagement or part of its vulnerability disclosure terms. The examples below show the range; they are listed alphabetically and were checked against each provider's published page in November 2026. Policies change, so read the current page for any application you plan to test.

Provider and policy	Notice	Scope rule	Prohibited (examples)	Reporting
Atlassian: Security testing for Cloud Products	Customers may test their own Cloud Products without prior approval	Only your own instances of eligible Cloud Products	Accessing other customers' data or credentials; social engineering, phishing or physical attacks on Atlassian; denial of service and flooding; untriaged scanner output	Report suspected flaws within 24 hours; request permission before public disclosure; results are Atlassian confidential information
Auth0 (Okta): Penetration Testing Policy	Request through the Support Center at least 7 days before the start date, with dates, scope, source IPs, tooling, request rate, tenants and two contacts; no testing during change freeze periods	Only your approved tenant(s); paid subscription required	Denial of service and volumetric attacks; testing of the management dashboard; tenants not approved	Discuss suspected findings with the Auth0 security team; report confirmed vulnerabilities under Okta's vulnerability reporting policy
Microsoft: Cloud Unified Penetration Testing Rules of Engagement	No prior notice described; testing must be in your own tenant or assets you are explicitly authorised to test	Your own tenant; test accounts and trial tenants may be created for cross-tenant scenarios, ideally with "MSOBB" in the name	Accessing other customers' data; using credentials that are not your own; denial of service; phishing Microsoft staff; post-exploitation such as pivoting or dumping secrets beyond proof of concept	Report vulnerabilities to MSRC immediately; on accidental access to data, stop, notify MSRC and delete it

Common threads run through all three: testing stays inside your own tenant, availability attacks are excluded, staff of the provider are not targets, and provider vulnerabilities are reported to the provider rather than published. Where a provider publishes no testing policy, do not assume silence is permission. Ask the provider in writing, record the answer, and limit the test to configuration review and read-only checks until you have one. Contracts for high-risk applications can include a right-to-test clause; the SaaS Application Security Review Checklist covers asking for it before purchase.

For the identity and tenant settings of each platform used above, see the independent Atlassian Cloud Security Guide, Auth0 Hardening Guide and Entra ID Security Guide.

Authorisation and rules of engagement

A provider policy permits testing; it does not authorise a particular test. That must come in writing from the person who owns the tenant and the data in it. Build the authorisation from the Penetration Test Scoping Checklist and add the SaaS-specific items below.

Tenant identifiers: the exact tenant ID, site URL, org ID or domain, and whether it is production or a sandbox. Name every one; "our Microsoft 365" is not a scope.
Provider policy reference: the policy URL, the version or date read, and any notice reference number where the provider requires a request.
Integrations in scope: each named OAuth app, integration user or API token, and a statement that the integration vendor's own systems are out of scope unless it has agreed in writing.
Test identities: the accounts issued to testers, their roles, licences and expiry dates (see the identity section below).
Data rules: which data testers may view, a ban on exporting real personal data, and what to do on finding another customer's data (stop, record, report to the provider, delete).
Time and source: test windows, time zone, change freeze dates and tester source IP addresses, so your monitoring and the provider can recognise the activity.
Stop conditions and contacts: named contacts on both sides reachable throughout, and the conditions that halt testing, such as service degradation, unexpected access to data outside scope or a provider warning.
Disclosure: who reports suspected platform flaws to the provider and within what time, given limits such as Atlassian's 24 hours.

Data protection law still applies inside your own tenant. Testers viewing personal data act for you, so the contract with the testing firm needs the same confidentiality and processing terms as any other supplier with access. Sandboxes and test tenants reduce the problem but must be configured like production to give meaningful results.

Scope areas that matter in a tenant

SaaS compromises rarely start with a flaw in the provider's code. They start with a valid session, token or consent. Ask testers to assess the paths below and report each as a chain from a starting position to an outcome.

Scope area	Questions the test should answer	Related guidance
Sign-in and session	Can legacy protocols or app passwords bypass MFA? Do conditional access exclusions leave gaps? How long do sessions and refresh tokens live?	SaaS Admin Account Protection
Admin roles	How many standing global admins exist? Can a lower role grant itself more? Are break-glass accounts protected and monitored?	SaaS Admin Account Protection
OAuth consent and apps	Can an ordinary user consent to a high-scope app? Which approved apps hold tenant-wide scopes, and who owns them?	SaaS and OAuth App Governance Guide
Integration identities and tokens	Which API tokens, service principals and integration users exist, what can each reach, do any never expire?	SaaS API Token Security Guide
External sharing and guests	Can a guest or an "anyone" link reach sensitive content? Do links expire? Can guests invite other guests?	Microsoft 365 Security Guide, Google Workspace Security Guide
Data exfiltration paths	Can mail auto-forward externally? Can bulk export or reporting APIs pull data without alerting?	SaaS Threat Detection Guide
Custom code on the platform	Do your scripts, low-code apps or custom pages enforce authorisation, and do they run with more privilege than the caller?	Plugin and Extension Architecture Security Guide for SaaS Builders
Detection	Did the tenant's audit logs and alerts record the test activity, and did anyone notice?	SaaS Audit Log Retention and Licensing Guide

The OAuth and token rows deserve the most time. Large SaaS data thefts of recent years used integration tokens or connected apps the victim had approved, as the OAuth and SaaS integration breaches lessons page sets out. A test that ignores integrations misses the path attackers actually used.

Configuration assessment or penetration test

For widely used suites, much of the tenant can be checked against published baselines. CISA's ScubaGear compares a Microsoft 365 tenant's settings with the SCuBA baselines for Entra ID, Exchange Online, SharePoint, Teams, Power Platform and others, and ScubaGoggles does the same for Google Workspace, using Open Policy Agent policies. CIS publishes the Microsoft 365 Foundations Benchmark. SaaS security posture management (SSPM) tools extend the same idea across many applications. The CISA SCuBA Baselines Guide covers the baselines.

Need	Better fit	Why
Are our settings aligned with a baseline?	Configuration assessment (ScubaGear, ScubaGoggles, SSPM, benchmark review)	Read-only, repeatable, covers every setting, no provider notice usually needed
Has the tenant drifted since last quarter?	Continuous posture monitoring	Drift is constant; an annual test misses it
Could a phished user or a compromised integration reach our crown jewels?	Penetration test or assumed-breach exercise	Needs judgement to chain identities, settings and integrations
Is our custom code on the platform safe?	Application security testing of that code, within provider rules	Code you own is your responsibility
Would we detect a tenant takeover?	Assumed-breach test with detection objectives	Measures logging and response, not just settings
Is the provider's platform secure?	Provider assurance: ISO/IEC 27001 certificate, SOC 2 Type II report, provider pentest summaries	You cannot and should not test the provider's platform yourself

A sensible order is configuration assessment first, fix the obvious, then a penetration test focused on paths. Testers then spend their days on chaining and impact rather than reporting settings a scanner would have found.

How to commission and run a SaaS tenant test

Pick the tenants. Start with Tier 1 applications under your SaaS Security Policy Template: identity providers, collaboration suites, CRM and anything holding source code or secrets.
Read each provider policy. Record notice requirements, lead times, change freezes and prohibited activities. Book any required notice; for Auth0 that is at least 7 days.
Run a baseline assessment. Use ScubaGear, ScubaGoggles, an SSPM or a benchmark review, and fix high-severity drift before testers arrive.
Write the authorisation. Tenant IDs, integrations, test identities, data rules, windows, source IPs, contacts, stop conditions and disclosure duty, signed by the tenant owner.
Issue test identities. Create labelled accounts with the agreed roles and expiry; tell the SOC the windows and source addresses so alerts are triaged, not suppressed.
Test in a sandbox where possible. Use a sandbox or test tenant configured like production for anything that writes data or changes settings; keep production work read-mostly.
Monitor during the test. Watch tenant audit logs for the test identities and confirm alerts fire; halt on any stop condition.
Close out. Disable test identities, revoke any tokens or app consents created, remove test data, report provider flaws through the provider's channel, and track tenant findings in the Penetration Test Remediation Tracker Template.

Rollback: any setting a tester changes must be listed with its original value so it can be restored; prefer testers who demonstrate a path from evidence rather than by changing production configuration. Back up tenant configuration first where a tool exists (see SaaS Configuration Backup and Recovery).

Where identity fits: test accounts and tokens

Test identities become a risk of their own if they outlive the test. Issue each tester a named account, never a shared one, with a recognisable label (Microsoft suggests "MSOBB" in account or tenant names for security testing). Give it the minimum role for the agreed scenario, a licence only if needed, MFA, and an expiry date. Any API token, app registration or OAuth consent created during the test is a non-human identity: record it, and revoke it at close. Rotate any real credential a tester saw, for example an integration secret found in a script. The SaaS deprovisioning guide covers removal across sessions and tokens, not just the user object.

Decision guidance

Small organisations: run the free baseline tools against Microsoft 365 or Google Workspace each quarter and fix what they find; commission a tenant-focused test only for the identity provider and main collaboration suite, perhaps every two years or after major change.
Large organisations: continuous posture monitoring across all Tier 1 applications, plus an annual assumed-breach test that starts from a compromised user or integration and has detection objectives.
Regulated sectors: where a regime expects threat-led testing, agree with the provider in advance how its platform will be treated; a customer test never replaces the provider's own assurance.
No provider policy: limit work to configuration review and read-only checks until the provider confirms in writing what is allowed.
Bug bounty in place: a provider's public programme is for researchers testing the provider. Your tenant test is a separate activity under the customer policy; do not mix them.

Detection and measurement

A tenant test is also a detection exercise. Ask the SOC to record which test actions produced alerts, using the SaaS audit sources described in the SaaS Threat Detection Guide.

Attack paths to sensitive data: number of complete paths found, and number still open 90 days after the report.
Detection rate: share of tester actions with a security impact that raised an alert within the agreed time.
Baseline conformance: share of baseline policies passing for each Tier 1 tenant before and after remediation.
Test identity hygiene: test accounts, tokens and consents still active seven days after close (target zero).
Provider policy conformance: tests run with policy check and notice completed (target 100 per cent).

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev 5	CA-8 Penetration Testing	Scoped, authorised testing of the tenant
NIST SP 800-53 Rev 5	SA-9 External System Services	Provider assurance and testing rights for external services
NIST SP 800-53 Rev 5	CM-6 Configuration Settings, CA-7 Continuous Monitoring	Baseline assessment and drift monitoring between tests
NIST CSF 2.0	ID.RA-01, ID.IM-02, GV.SC-05	Identifying vulnerabilities, improving from tests with suppliers, testing rights in contracts
CIS Controls v8.1	Control 18 Penetration Testing	Programme requirement; see the CIS Control 18 Penetration Testing Guide
ISO/IEC 27001:2022 Annex A	5.23 Information security for use of cloud services; 8.8 Management of technical vulnerabilities	Cloud service governance and vulnerability handling

Common failure patterns

Scoping the vendor, not the tenant: a scope that names only the product, such as "test the CRM", invites work against the provider's platform, which its terms prohibit. Scope your tenant and your configuration.
Skipping the provider policy: testing during a change freeze or without a required notice can lead to blocked IP addresses, suspended accounts or worse, and wastes the test window.
Paying testers to read settings: days spent reporting sharing defaults a free baseline tool would have flagged, and no time left for attack paths.
Ignoring integrations: tests that cover users and admins but not the OAuth apps, integration users and tokens attackers abuse in SaaS supply chain incidents.
Orphaned test access: tester accounts, app consents or tokens left active after the report, becoming exactly the dormant privileged identities the test was meant to find.
Publishing provider flaws: discussing a suspected platform vulnerability in a report shared widely, or publicly, before the provider has handled it, against its disclosure terms.

Practitioner checklist

List the exact tenant IDs, URLs and sandboxes in scope, with their owners.
Read and record each provider's testing policy, notice rules and change freezes.
Run a baseline configuration assessment and fix high-severity findings before the test.
Name every integration in scope and exclude integration vendors' own systems unless they agree in writing.
Get written authorisation from the tenant owner covering data rules, windows, source IPs and stop conditions.
Issue labelled, least-privilege, expiring test identities and tell the SOC.
Prioritise identity, OAuth consent, tokens, sharing and detection as scope areas.
Report provider flaws through the provider's channel within its time limit.
Revoke all test identities, tokens and consents and restore changed settings at close.
Track findings to closure and re-test the highest-risk paths.

Testing SaaS You Use: Penetration Testing Rules, Permissions and Tenant Scope