SAMA Compliance Checklist for Fintech Apps 

A compliance lead at a Riyadh payments startup once showed us her audit preparation folder: 412 screenshots, no index, assembled over three late nights before a SAMA review. The review didn't go badly because controls were missing. It went badly because nothing could be produced on demand. That's the pattern with SAMA compliance generally: the Cyber Security Framework isn't intellectually hard, it's operationally relentless, and teams building fintech products for the Saudi market keep getting surprised by the same handful of requirements. This is the checklist version: the CSF domains that actually bite builders, what in-Kingdom data residency means in practice, and what auditors ask to see.

The Four CSF Domains, From a Builder's Seat

SAMA's Cyber Security Framework organizes its controls into four domains: leadership and governance, risk management and compliance, operations and technology, and third-party cyber security. Engineers tend to skim the first two as paperwork and camp on the third, which is a mistake in one specific way: governance controls generate evidence obligations that land on engineering anyway, like a maintained asset inventory and a named owner for every system. Operations and technology is where most of the control surface lives, covering identity and access management, change management, secure development, logging and monitoring, backup, and penetration testing. Third-party cyber security is the one that ambushes app teams, because every SDK, cloud service, and payment processor in your stack is a third party, and the framework expects you to know what each one touches and to have assessed it. If your dependency list lives only in package.json, that domain is currently failing.

Data Residency Means In-Kingdom, Including the Backups

SAMA expects financial data for Saudi customers to be hosted inside the Kingdom, and the trap isn't the primary database, which everyone remembers to put in a Saudi region. It's everything orbiting it: backups replicated to a cheaper region abroad, log aggregation shipping to an EU-hosted service, an analytics tool streaming events to US servers, a support desk storing ticket attachments wherever its vendor does. Each of those is customer data leaving the country. The workable pattern is a hard boundary: identifiable financial data stays in-Kingdom across primary, replica, backup, and log storage, and only anonymized aggregates cross the border, with the anonymization documented well enough to defend. Decide this before choosing infrastructure. Retrofitting residency into a running system means touching every service that stores or moves customer data, and it's among the most expensive compliance fixes we see.

Evidence Is the Product Auditors Actually Review

Auditors don't inspect your code; they inspect what you can prove about it. The requests are predictable: the access matrix and the record of the last quarterly access review, the approval trail for recent production deployments, incident records with timelines and root causes, key rotation logs, the latest penetration test report and what was remediated, and the audit log for any transaction they pick at random. Teams that pass calmly are the ones where this evidence is generated by the systems themselves: structured audit events from day one, deployments that record who approved them, access reviews that produce an artifact instead of a meeting. Built that way, compliance engineering costs a few percent of the build. Assembled by hand before each audit, it costs a week of panic every cycle, and reviewers can tell the difference within an hour.

The Checklist

• Host all identifiable customer financial data in-Kingdom: primary, replicas, backups, and logs
• Map every third party in the stack, including SDKs and analytics, and record what data each one touches
• Maintain an asset inventory with a named owner per system; auditors ask for it early
• Enforce role-based access on the minimum-necessary principle, with a quarterly review that produces a signed artifact
• Log every read and write of customer financial data to append-only storage, with actor, action, record, and timestamp
• Record deployment approvals in the pipeline itself, not in chat messages
• Rotate keys on a schedule through a managed KMS, and keep the rotation log
• Book an approved penetration testing firm about eight weeks before you need the report
• Run AML and sanctions screening in the transaction flow, not in a nightly batch
• Keep incident records with timelines, even for near-misses; an empty incident register reads as not looking

The Questions That Surprise First-Timers

A few audit requests reliably catch teams on their first regulated build. 'Show me every production access by an engineer this month' fails anyone who connects to servers with shared credentials. 'Walk me through this specific transaction end to end' fails systems that update balances in place instead of keeping an immutable ledger. 'Who approved this change, and where's the record' fails teams whose approvals live in a chat thread that auto-deleted at 90 days. And 'what did your last pen test find, and show me the remediation' fails teams who booked the test but never closed the findings. None of these are trick questions. They're the auditor checking whether the controls run continuously or were staged for the visit, and the staged version rarely survives a second question.

Where to Start

If you're earlier than all this, sequence it. Residency architecture first, because it constrains everything else. Audit logging and access control second, because they're brutal to retrofit. The evidence tooling third, because it makes every later step cheaper. The paperwork domains last, once there's a real system to describe. Budget compliance as engineering work, in the region of 20 to 30 percent of a first regulated build, rather than as a legal line item. And treat the checklist above as a floor, not the framework itself: SAMA publishes the CSF openly, and reading the actual control families once is worth more than any secondhand summary, including this one. The teams that do fine under SAMA aren't the ones with the thickest binders. They're the ones whose systems can answer questions about themselves on demand.