A SaaS security review should answer whether the proposed service, configuration and operating boundary manage the buyer's important risks. A certification badge or security page is a starting claim, not the decision.
Map responsibilities first. Then request current evidence scoped to the service and period, inspect exceptions and connect every gap to an owner, condition or risk decision. Do not collect documents that nobody can interpret.
Begin with service boundary and risk
Name the proposed product, edition, hosting model, regions, integrations, identity, data types, administrators and subcontractors. Identify the business activities that depend on it and the consequences of unauthorised access, incorrect change, loss or unavailability.
This prevents a broad questionnaire from treating every control as equally important. It also reveals when an assessment covers a corporate system but not the SaaS service being purchased.
Map shared responsibility
For identity, configuration, endpoints, data, logging, backup, incident response and user behavior, record supplier and buyer responsibilities plus the evidence each party must operate. The NCSC's shared-responsibility guidance notes that the division changes by cloud service model.
Mark responsibilities that neither party clearly owns. A supplier control can work while the buyer's configuration leaves the service exposed.
Build an evidence ledger
| Risk or control | Evidence requested | Scope check | Status |
|---|---|---|---|
| Privileged access | role model, approval, review and log sample | support and subcontractor access included | verified / gap |
| Secure change | development and release controls, vulnerability process | proposed service and components | conditional |
| Recovery | targets, restoration test and unresolved findings | data and configuration included | verify |
| Incident | severity, notification, evidence and escalation process | contract aligns with operating need | verified |
Record document date, assessment period, assessor, exclusions and owner. Expired or mismatched evidence is not automatically useless, but its limitation must be decided.
Review identity and privileged operations
Verify supported authentication, lifecycle provisioning, role granularity, privileged administration, emergency access and review. Ask how supplier support access is authorised, restricted, logged and revoked. Test one joiner, role change and leaver scenario.
Confirm which logs the buyer receives, their retention and whether alerts can reach the buyer's monitoring process. A screenshot of a role page is weaker than an observed scenario and retained record.
Inspect secure development and vulnerability handling
Request the process for design review, dependency management, testing, vulnerability reporting, prioritisation, remediation and customer notification. Determine which components and delivery partners are inside the process. CISA's Secure by Design guidance emphasises making secure outcomes a core product responsibility rather than transferring avoidable burden to customers.
Do not demand sensitive exploit detail during procurement. Ask for governance, time-bounded evidence, material exceptions and how a buyer is informed and protected.
Test data protection and lifecycle
Map collection, processing locations, encryption, key responsibilities, backup, retention, export and deletion. Include support access, telemetry, logs and derived data. Verify how tenant separation is designed and independently assessed where relevant.
Run an export and deletion scenario using representative test data. Contract wording and technical behavior should agree.
Evaluate resilience through restoration evidence
Availability history and architecture diagrams do not prove recoverability. Request recovery objectives, last test scope, result, exceptions and improvement ownership. Trace dependencies on identity, region, network, integration and supplier staff.
Ask what the buyer must do during recovery and how data is reconciled afterward. An excluded dependency can determine the real outage.
Read independent reports critically
Check entity, service, location, period, control objectives, testing method, exceptions and complementary customer controls. A report can provide strong evidence within its scope without proving every configuration or future period.
Map relevant controls to the ledger rather than marking the supplier "certified" and closing the review. NCSC's cloud security principles provide a useful outcome-oriented structure for questions.
Trace evidence into the contract and implementation
A procurement response is useful only if the promised boundary survives signature and configuration. Map decision-critical commitments—notification times, recovery objectives, data locations, subcontractor change, export, deletion and support access—to the contract, service description or implementation acceptance plan.
Where the buyer must configure a control, create an implementation task and test. For example, support for single sign-on does not prove that every privileged path uses it or that emergency accounts are reviewed. Retain the evidence link and owner beside the test.
Set expiry and review triggers
Security evidence ages. Record the next independent assessment period, contract renewal, architecture change, material incident, new region, sensitive dataset or critical integration that reopens the review. Ask suppliers how customers receive updated reports and material exception notices.
Do not rerun the entire questionnaire for every minor release. Reassess the affected risks and confirm that baseline evidence remains applicable.
Convert gaps into decisions
Classify each item as verified, conditional, gap, not applicable or not tested. For a condition, record the buyer configuration, contract term, implementation action or dated supplier evidence required. Assign an owner and acceptance point.
A missing document does not always reject a service; a severe unowned risk can. The final record should state residual risk, compensating action, evidence expiry and review trigger. Security review is complete when the decision boundary is understood—not when the questionnaire is full.
Avoid four review anti-patterns
- Document counting: more files do not compensate for unclear scope.
- Badge inheritance: a corporate certification may not cover the product, region or period proposed.
- Questionnaire certainty: a yes/no response is weaker than observed control evidence and an accountable commitment.
- Supplier-only ownership: buyer identity, configuration, endpoint and response duties remain part of the risk.
Use the smallest evidence set that supports the material decisions, and state what remains uncertain.
Assemble the security decision pack
Keep the service boundary, data-flow and responsibility maps; risk and evidence ledger; assessment scope and exceptions; implementation conditions; contractual commitments; residual-risk approval; evidence expiry; and review triggers under one version. Link each condition to an owner and acceptance date.
The pack should let a future reviewer explain why the service was accepted and which facts would reopen the decision. It also prevents renewal from starting with a blank questionnaire while material architecture or evidence changes go unnoticed.