SSPM Rollout Playbook: Phased Implementation

An SSPM rollout succeeds or fails on two things the product cannot decide for you: how much access its connectors are given to your SaaS tenants, and whether anyone owns the hundreds of findings it produces in the first week. SaaS security posture management (SSPM) tools connect to each application's admin APIs, read configuration, users, admin roles and integrations, compare them to a policy set and alert on drift. This playbook covers rolling one out after purchase: phases and exit criteria, connector identity design, baselining, finding ownership and triage, moving from report-only to remediation with testing and rollback, and the metrics that show progress. It is vendor-neutral and draws on the CISA SCuBA baselines and tools, the CSA SaaS Security Capability Framework (SSCF) and platform documentation for connector credentials; Google Workspace and Microsoft 365 are used, alphabetically, only as connector examples. It is for SaaS security, identity and platform teams. For selection see the SaaS Security Buyer's Guide; for the wider programme see the SaaS Security Guide.

Key takeaways

The connectors are the riskiest part of the deployment. Each one is a non-human identity with broad read access, and sometimes write access, to a tier 1 tenant. Design them before connecting anything.
Baseline before you alert. Run read-only for a full cycle, sort every failure into fix, accept with expiry or not applicable, then switch on drift alerts so people only see change.
Findings need owners outside security. Most fixes are made by application admins. Agree owners, service levels and an exception path before findings reach them.
Remediation is a separate, later decision. Automated fixes need a separate identity with write rights, an approval step, a test tenant and a rollback plan.
Free baselines set the floor. CISA's ScubaGear and ScubaGoggles results give an independent reference to reconcile the tool against for the two productivity suites.

The rollout at a glance

The phases and durations below are our recommendation for an estate of five to fifteen tier 1 applications; smaller estates compress them.

Phase	Main work	Security built in	Exit criteria
0. Scope and owners	Tier 1 app list, tenants (including test and secondary), licence tiers, app owners, baseline choice	Data handling of configuration snapshots agreed	Every in-scope tenant has a named admin owner
1. Platform setup	SSO and MFA for the console, roles, SIEM and ticketing integrations	Console admin roles separated; audit log exported	Platform security review passed
2. Connect read-only	Dedicated connector identities per tenant, least-privilege scopes	Certificate or federated credentials; inventory with owner and expiry	All tier 1 tenants connected; permissions recorded
3. Baseline	First full scan, reconciliation with SCuBA results, triage of every failure	Exceptions carry owner and expiry	Every failed check is fix, accept or not applicable
4. Drift and routing	Scheduled scans, diffs, alerts on pass-to-fail, tickets to app owners	High-severity drift to the SOC	Service levels met for one month
5. Remediation (optional)	Guided fixes, then selected automated fixes in a test tenant	Separate write identity, approval, change log	Rollback tested for each automated fix
6. Extend	Further apps, integration inventory reviews, detection use cases	Connector permissions re-reviewed quarterly	Coverage target met

Phase 0 and 1: scope, owners and the platform itself

Tier the estate: start with the identity provider, the productivity suite, CRM, ITSM, code hosting and the data warehouse. Include test and secondary tenants; they are often the least configured. See the Shadow SaaS and Unsanctioned App Discovery Guide for finding the rest.
Record licence tiers: some checks and many audit log sources depend on the SaaS licence, so note what each tenant can expose. See the SaaS Audit Log Retention and Licensing Guide.
Choose baselines: CISA SCuBA secure configuration baselines for the productivity suites, vendor hardening guides and your own policies. The CSA SSCF (v1.0.1) lists customer-facing SaaS security capabilities and is a useful cross-check for the remaining apps. See the CISA SCuBA Baselines Guide.
Name owners: one admin owner per tenant who receives findings and can approve exceptions, plus a security reviewer for high-severity items.
Secure the console: SSO with phishing-resistant MFA, separate roles for platform admin, connector management, analysts and read-only reporting, and the platform's audit log in the SIEM. The tool will hold a configuration map of every tenant. See SaaS Security Guide.

Phase 2: connector identities

Treat each connector as a privileged service identity: dedicated, least privilege, strong authentication, owned and inventoried. CISA's own tool shows the scale of read access posture checks need. Run unattended against Microsoft 365, ScubaGear uses a service principal authenticated only by certificate, with Microsoft Graph permissions such as Directory.Read.All, Policy.Read.All and RoleManagement.Read.Directory, Exchange.ManageAsApp with the Global Reader role, and Sites.FullControl.All for SharePoint; CISA notes that some listed permissions carry write privileges because of platform API limitations. ScubaGoggles uses a Google Cloud service account with domain-wide delegation, a setting only a super administrator can grant and which reaches the data of all users, so Google advises narrow scopes and regular review.

Design point	What to do (our recommendation)
Identity per tenant	One dedicated connector identity per tenant and per purpose (read, write-back), never a named person's account or a shared admin
Authentication	Certificate or federated credentials where the platform supports them. Microsoft guidance for app registrations is to avoid client secrets, prefer managed identity or workload identity federation, and store certificates in a vault
Permissions	The minimum read scopes the vendor documents for each check family; record each permission and the checks that depend on it, and drop permissions for checks you have disabled
Admin roles	Reader roles (for example Global Reader in Microsoft 365) instead of global or super admin roles wherever the API allows
Network restriction	Restrict connector sign-in to the vendor's published egress addresses where the SaaS app supports IP restrictions
Ownership and review	Minimal owner list on each app registration or service account, reviewed quarterly; credentials rotated on a schedule and removed at contract end
Inventory	Tenant, identity, scopes, authentication type, credential expiry, owner, last successful scan

See the SaaS API Token Security Guide and the Google Workspace Domain-Wide Delegation Security Guide.

Phase 3: baselining and triage

Run ScubaGear and ScubaGoggles against the productivity suite tenants and keep the output as the reference result.
Run the first full SSPM scan read-only and export it as the dated baseline.
Reconcile: every SCuBA failure should appear in the SSPM result or have a documented reason; investigate gaps with the vendor.
Triage every failed check with the tenant owner: fix (with a due date by severity), accept (owner, reason, compensating control, expiry) or not applicable (reason). See the Security Exceptions and Risk Acceptance Guide.
Fix identity first: super admin counts, local accounts that bypass SSO, admins without MFA, broad OAuth grants and dormant integration users. See the SaaS Admin Account Protection guide and the SaaS and OAuth App Governance Guide.
Tune: disable checks that do not apply, adjust severities to your policy and record why, so the next scan shows only real drift.

Phase 4 and 5: drift, routing and remediation

Schedule: daily scans for tier 1 tenants (our recommendation), with each run stored so results are diffs, not fresh reports.
Alert on change: a high-severity check that flips from pass to fail goes to the SOC; others create tickets for the tenant owner with a service level.
Watch new features: review SaaS release notes monthly for settings enabled by default, especially AI assistants and sharing options, and confirm the tool has checks for them.
Guided before automated: start with fixes an admin applies from the tool's instructions. Automate only repeatable, low-impact fixes.
Write access is separate: automated fixes use a different connector identity with only the write scopes needed, approval before execution and a change record. Disable it when not in use if the tool allows.
Test and roll back: run each automated fix first in a test tenant, snapshot the setting before change (ScubaGear output can serve as a record), apply to one production tenant, and keep the documented revert step for every fix.

Decision guidance

Situation	Approach
One productivity suite and a CRM	Scheduled SCuBA tool runs and the CRM's own health check may be enough; adopt SSPM when the number of tier 1 apps or admin teams grows
Many tier 1 apps, several admin teams	SSPM with ticket routing to app owners; central team owns baselines and exceptions
Regulated, needs continuous evidence	Keep scan history and exception records for the audit period; export to the GRC platform
Strict change control	Report-only plus guided fixes; no automated remediation
Mergers and new tenants	Add tenants through the same phase 2 and 3 steps; never connect with an inherited admin account

Detection and measurement

Monitor the tool and its connectors as well as what they find. Alert on connector permission changes, new connector identities, credential expiry, failed scans, console admin role changes and bulk export of findings. In each SaaS tenant, watch sign-ins and API use by the connector identity from addresses outside the vendor's ranges; ATT&CK tracks token theft as T1528 Steal Application Access Token and integration abuse as T1671 Cloud Application Integration. Metrics:

Coverage: tier 1 tenants connected and scanning successfully.
Baseline pass rate: high-severity checks passing, by tenant, over time.
Time to remediate drift: median time from pass-to-fail to fixed or accepted.
Exception health: accepted findings past their expiry date.
Connector hygiene: connectors with an owner, read-only scope and certificate or federated authentication.
Identity risk: super admins per tenant and local accounts bypassing SSO.

Common failure patterns

Connecting with a super admin: the quickest way to finish phase 2, and it leaves the tool holding the most powerful account in each tenant.
Alerting before baselining: hundreds of first-day findings sent to app owners who then ignore every later alert.
No owner outside security: findings sit in the console because nobody with admin rights receives them.
Exceptions without expiry: accepted deviations that become permanent.
Automated fixes in production first: a sharing or sign-in change that breaks a business integration with no recorded previous value.
Forgotten connectors: credentials left in place after a tenant is retired or the contract ends.

Framework mapping

Rollout area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Baselines and drift	PR.PS-01	CM-2, CM-2(2), CM-6, CA-7
Connector identities	PR.AA-01, PR.AA-05	AC-6, IA-5
Monitoring tenants and connectors	DE.CM-09	SI-4, AU-6
Exceptions and remediation	ID.RA-01	CA-5, CM-3
The SSPM provider	GV.SC-07	SA-9

Practitioner checklist

Tier 1 tenants listed with owners, licence tiers and test tenants.
Console protected with SSO, phishing-resistant MFA, separated roles and audit log export.
One dedicated connector identity per tenant, read-only, certificate or federated where supported, inventoried with expiry.
SCuBA reference results captured and reconciled with the first SSPM scan.
Every failed check triaged as fix, accept with expiry, or not applicable.
Drift alerts limited to pass-to-fail changes, routed to owners with service levels.
Any automated remediation uses a separate write identity, approval and a tested rollback.
Connector permissions and owners reviewed quarterly and removed at contract end.

SSPM rollout playbook: phased implementation with security built in