Start with the service, not the provider label
Define the service that will run: its users, data categories, integration points, availability target, recovery objective and expected operating owner. A provider can be suitable for one workload and unsuitable for another, so compare the actual service boundary rather than a marketing category.
Create a one-page workload record before meetings begin. Include whether the service processes personal data, depends on third parties, or requires high availability. This record becomes the basis for technical, contractual and regulatory questions.
Build a data and contract evidence pack
Ask for a clear description of customer and provider responsibilities, subcontractors, support access, incident process, backup location, retention, return of data and deletion at contract end. Record the response as evidence, not as an assumption based on a product name.
For personal data, identify the controller and processor roles, data categories and proposed processing locations. The Saudi PDPL guidance is a starting point, not legal advice or a current applicability determination.
Test resilience as an operating claim
Request diagrams that identify the availability boundary, shared dependencies, failover design, recovery objectives and testing frequency. A multi-zone statement is not evidence that an application can recover if identity, data stores, network paths or procedures remain shared.
Ask for relevant test evidence: a recovery exercise summary, sample incident communication process and maintenance-window approach. Define which evidence must be refreshed before renewal or expansion.
Separate applicable controls from useful benchmarks
The NCA Essential Cybersecurity Controls include applicability information for organizations in scope and cloud or hosting use cases. Do not label a provider compliant based only on a brochure; determine what applies to the buyer, provider and workload with qualified advisers.
Even where a control is not a direct obligation, its topics can structure questions about governance, access management, logging, incident response, suppliers and continuity. State whether each item is a legal requirement, contractual commitment or voluntary benchmark.
Plan the exit before the first deployment
An exit plan should cover data export formats, transfer bandwidth, deletion confirmation, key ownership, DNS and identity changes, replacement connectivity, runbooks and support responsibilities. Test a small migration path early rather than discovering dependencies during an urgent exit.
Keep an audit trail: workload record, requirements, provider responses, exceptions, evidence dates, risk owner and next review date. This makes the decision repeatable when the service changes.
FAQ
Does this guide determine compliance?
No. It structures an evidence review; regulatory, legal and contractual applicability must be determined for the exact service.