SAMA CSF for Cloud Data Teams: A Working Checklist

SAMA CSF is written in the language of risk and governance. Cloud-native data teams operate in the language of pipelines, IAM policies, and replication topologies. Translating between the two is most of the work of compliance for engineering teams in regulated Saudi institutions.

This checklist walks the six SAMA CSF domains that matter most to a cloud-native data team and translates each one into specific operating decisions. It is intended for engineering managers and data platform leads, not auditors. For the broader compliance-vs-resilience framing that sits behind this work, see our SAMA CSF maturity ladder. For the architectural context, see our cloud DR in the GCC pillar.

A note before the checklist

Most SAMA CSF requirements describe outcomes, not implementations. "Adequate access controls" and "appropriate encryption" leave room for interpretation, and the interpretation is where engineering teams have to make calls. The items below are what I'd consider defensible interpretations for a cloud-native data team after the March 2026 Gulf cloud incident. They are stricter than the framework strictly requires in places, and that's deliberate. The bar for "adequate" has moved.

1. Cybersecurity leadership and governance

The framework requires a formal governance structure with board accountability. For a data team, the practical translation:

Assign a named data security owner. Not "the security team." One person whose name appears on the data platform's risk register. This person owns the answer to "who decides if we move that dataset cross-region?"

Maintain a written data classification. Each material dataset belongs to a tier (Tier 0 core banking, Tier 1 customer-facing, Tier 2 internal). The classification drives every downstream control: where the data may be stored, how it is encrypted, who can query it, and what the recovery target is. The most common gap I see is teams that have a classification document but cannot answer the question "is this dataset Tier 0 or Tier 1" without consulting it.

Board reporting that is legible. The data security risk register should be readable by a director, not a security architect. If the board cannot tell from the report whether the team is closer to Level 1 or Level 3 of the maturity ladder, the report needs rewriting.

2. Cybersecurity risk management

Risk management at the data layer is the discipline of being honest about what you don't know.

Document data flow boundaries. For each Tier 0 and Tier 1 dataset: where does it originate, where does it land, what services touch it, what's the retention, what's the access pattern. This is not a one-time exercise; it has to be maintained. Most data flow diagrams I've reviewed are 6–18 months out of date.

Run a quarterly third-party risk review for material data dependencies. Cloud providers, SaaS analytics, AI/ML platforms, data brokers. Each one's incident in the last quarter, each one's geographic exposure, each one's BCDR posture. Most institutions assess third parties at procurement and then never re-assess.

Maintain a residual-risk log. The risks you've accepted, with the named accepter, the date, and the conditions under which you'd revisit. After March 2026, residual-risk acceptances around "single-region cloud deployment" are the ones that need re-examination first.

3. Cybersecurity operations and technology

This is where most of the engineering work lives.

Encryption: at rest, in transit, and on backup paths. Cloud-managed KMS keys for routine data; customer-managed keys (CMK) for Tier 0 with a documented key recovery process. The key recovery process is the part that fails in real incidents. Test it.

IAM that respects least privilege. Service accounts have the minimum scope to do their job and no more. Human access goes through SSO with MFA. Privileged access goes through a just-in-time elevation system with audit. Standing administrator credentials in production are an anti-pattern; SAMA CSF reviewers increasingly look for them and ask hard questions.

Observability that survives the incident. The metrics, logs, and traces you'd need to debug a Tier 0 outage cannot be hosted only on the system that failed. Observability infrastructure for Tier 0 data systems should be cross-region, with alerting paths that don't depend on the primary region's network.

Data quality validation in the pipeline, not just at the warehouse. Schema checks, row-count anomaly detection, cross-source reconciliation, and freshness monitors should run continuously. For the BCDR-specific case, see our post on data quality after failover.

4. Third-party cybersecurity

SLA review with BCDR specifics. Generic uptime SLAs are not BCDR commitments. For each Tier 0 third-party dependency, you need a written answer to: where is the data physically stored, what is the provider's stated RTO and RPO for this service, what is the provider's recovery path if the primary region is destroyed, and what is your contractual remedy if those targets are missed.

Contract clauses that name the regions. Geographic specificity matters. "Within the EEA" or "within the GCC region" is too loose; specific regions should be named, with notification requirements before changes.

Exit plans that are realistic. If your provider's posture changes, can you migrate? How long would it take? Is there a contractual obligation on the provider to assist with extraction? Most exit plans are theoretical; the realistic ones have been tested with non-production data at least once.

5. Business continuity and disaster recovery

The substantive content here is in our dedicated SAMA CSF post; the checklist version:

Tier classification of data systems. Each system mapped to RTO and RPO targets driven by business impact, not by the engineering team's preference.

A pattern matched to each tier. Tier 0 in Pattern B (or C where mandated), Tier 1 in Pattern A, Tier 2 in cross-region backup. See our pattern decision guide.

Verified restorability for backups. Automated weekly restore-to-ephemeral for Tier 0 and Tier 1 backups, with functional smoke tests on the restored system. See our backup guide.

An annual Level 3 test for one Tier 0 workload. Component-level tests are not enough after March 2026. At least one full regional failover per year, in production, for the highest-priority Tier 0 system.

A documented and rehearsed Window 2 decision authority. Who calls failover, with what trigger, when the named decision-maker is unreachable. See our operational lessons post for why this matters.

6. Incident and threat management

Detection that doesn't depend solely on cloud-provider tooling. CloudTrail and equivalent are essential and not sufficient. Independent log aggregation in a separate account, anomaly detection on data-pipeline behavior, and out-of-band monitoring for the most critical data systems.

Documented containment procedures for compromised credentials. What happens when a service account or human credential with access to Tier 0 data is suspected compromised? The procedure should be sub-minute for revocation and well-tested. Most institutions have the procedure documented; few have rehearsed it.

Communication channels that survive the incident. If your incident communication runs on Slack, and Slack runs on a cloud region that just failed, you have a problem. Tier 0 incident response should have a documented fallback channel that operates independently of the primary region.

Regulator notification timelines, written down and rehearsed. SAMA, NCA, and sectoral regulators have notification windows. The team that has not rehearsed who calls the regulator within those windows is going to be improvising during an incident.

Tradeoffs and honest limitations

This checklist is stricter than SAMA CSF strictly requires in places. That's intentional. The framework is the floor; the items above are what I'd consider defensible operating practice for a cloud-native data team in 2026. Auditors may accept less. Real incidents will not.

Implementation order matters. Doing all of the above at once is unrealistic for most teams. The highest-leverage place to start is sections 1 (governance), 5 (BCDR), and 4 (third-party). Sections 2, 3, and 6 build on those.

Definitions vary across regulators. If your institution falls under both SAMA CSF and NCA ECC-2, satisfy the more stringent requirement in each domain. The two frameworks are largely complementary, but the wording differs and the auditors do read carefully.

A practical takeaway

The most useful artifact a data team can produce against this checklist is a one-page status sheet: each of the six domains with a current state ("in place," "partial," "gap"), a named owner, and a 90-day target. Hand it to your security or risk leadership. The conversations that follow are usually more productive than the ones that come from the auditor's report.

For the broader BCDR context, see our cloud DR in the GCC pillar. For BCDR-specific terminology, see our glossary. If you'd like help running this checklist against your data platform, Dataring's resilience practice does this engagement regularly. Get in touch.