SaaS Security Assessment

The app supports SSO with SAML 2.0 or OpenID Connect on the plan we buy (or will buy).

SSO puts sign-in, MFA and leaver handling under your identity provider instead of one more password store.

Password sign-in can be turned off for SSO users, with a small, controlled set of break-glass accounts.

If local passwords keep working, SSO and its MFA can simply be bypassed.

MFA can be enforced for every user by an admin setting (directly or through SSO), not left to each user.

Optional MFA leaves the accounts least likely to turn it on unprotected.

Phishing-resistant MFA (security keys or passkeys) is supported, at least for admins.

One-time codes and push approvals can be phished or fatigued; admin accounts are the prize.

Users are provisioned and deprovisioned automatically with SCIM from our identity provider.

Without automatic deprovisioning, leavers keep access until someone remembers to remove them.

Deprovisioning ends active sessions and revokes the user’s API tokens and personal access tokens.

A disabled account with a live session or token still has access.

There are granular admin roles, so we can give people only the admin rights they need.

If the only choice is full admin, every helper becomes a full admin.

Audit logs record sign-ins, admin changes, permission changes and data exports.

In an investigation, the first questions are who signed in, what they changed and what they took.

Audit log retention is stated and long enough for our investigations and obligations.

Incidents are often found weeks or months later; short retention erases the evidence.

Audit logs can be exported or streamed by API to our SIEM or log store.

Logs you can only see in the vendor’s console are hard to alert on or keep.

We can choose, or at least know, the region where our data is stored and processed.

Residency affects your legal obligations and your customers’ contracts.

Data is encrypted in transit and at rest, and the vendor documents how.

Encryption is a baseline expectation; documented detail shows it is real.

Customer-managed keys (BYOK) are available if we need them.

Holding the keys lets you cut off access to sensitive data yourself; it matters most for regulated data.

We can export all of our data in a usable, documented format, at any time.

An export is your exit plan and your last backup if the vendor fails.

The vendor states how it backs up our data and how we can restore deleted or overwritten data.

Ransomware, a bad sync or a malicious admin can delete data inside the app itself.

The contract says how and when our data is deleted when we leave.

Data that outlives the contract is still your risk.

Admins can control which third-party apps and OAuth grants users can approve.

Connected apps with broad scopes can read your data through the front door, without a password.

We can list every connected app, OAuth grant and API token with its scopes, and revoke them.

You cannot remove access you cannot see.

The contract commits the vendor to notify us of a security incident affecting our data within a stated time.

Your own notification deadlines start when you know; a vague clause can leave you late.

The vendor has a named security contact and a published way to report vulnerabilities.

You need someone to call during an incident, and a vendor that takes reports seriously.

A current SOC 2 Type II report covering this service is available to us, and someone has read it.

A Type II report tests whether controls operated over a period, not just whether they existed on one day; exceptions and complementary user entity controls are in the detail.

The vendor holds ISO/IEC 27001 certification whose scope includes this service.

A certificate that covers a different product or office tells you little about this one.

The vendor publishes its subprocessors and tells us before adding new ones.

Your data goes wherever the vendor’s suppliers go.

The vendor documents a shared-responsibility model: which controls it runs and which are ours.

Most SaaS incidents involve controls on the customer side, such as access, configuration and integrations.

Each customer-side control (users, MFA, settings, integrations, logs, exports) has a named owner on our side.

A control everybody assumes someone else configured is a control nobody configured.