TL; DR
SAMA compliance in Saudi Arabia is not demonstrated by policies, frameworks, or security tools. It is proven through long-term, retrievable evidence. Regulators assess whether banks and financial institutions can produce complete, trustworthy records years after decisions were made, systems were changed, or platforms were retired.
This guide explains why SAMA compliance depends on formal record preservation, how maturity level expectations implicitly require structured archives, and what a SAMA-aligned archiving architecture must support to remain audit-ready, defensible, and compliant over time.
SAMA compliance does not fail because institutions lack policies, frameworks, or security tools. It fails when institutions cannot produce records.
During audits, supervisory reviews, investigations, or enforcement actions, regulators do not ask what systems you deployed or what policies you intended to follow. They ask for evidence – historical records, audit trails, transaction data, logs, decisions, etc. They ask for proof that controls were applied consistently over time.
When that evidence is missing, incomplete, altered, or locked inside retired systems, compliance breaks—regardless of how mature the cybersecurity program appears on paper.
SAMA compliance refers to the mandatory regulatory and governance requirements imposed on banks, insurers, financing companies, credit providers, fintechs, and other financial institutions operating in Saudi Arabia.
These requirements are enforced by the Saudi Central Bank, formerly the Saudi Arabian Monetary Authority (SAMA), and span cybersecurity, risk management, corporate governance, AML/CFT (Anti-Money Laundering, Combating the Financing of Terrorism), and operational controls.
What ties all of these areas together is accountability. Accountability under SAMA is proven through long-term evidence. Not intent! Not configuration! Not tooling! Evidence that can be retrieved years later, verified under scrutiny, and defended during audits, incidents, or legal review.
This is why SAMA compliance ultimately depends on long-term records, not just security controls.
This guide focuses on that reality. The focus here is regulatory survivability: how financial institutions meet SAMA compliance through long-term record preservation, evidence continuity, and institutional memory that does not disappear when platforms change or systems are retired.
If you cannot prove what happened, when it happened, who approved it, and how it was controlled years later, then you are not compliant.
Also read: How Saudi PDPL governs retention, access, and disposal of regulated data
What SAMA Compliance Means in Practice for Financial Institutions
The Saudi Central Bank acts as both regulator and stabilizer of the Kingdom’s financial system. Its role is not just to issue rules, but to ensure that banks, insurers, financing companies, payment providers, credit bureaus, and FinTechs operate in a way that protects financial stability, customer trust, and systemic resilience. That mandate shapes how compliance is defined and enforced.
In practice, SAMA compliance means three things:
1. Governance
- Clear board and senior management accountability
- Independent compliance and control functions
- Defined ownership of risk, controls, and decision-making
- Oversight that extends beyond IT and security teams
2. Controls
- SAMA frameworks cover cybersecurity, risk management, AML/CFT, outsourcing, cloud usage, and incident response
- These frameworks are principle-based, not checkbox-based
- SAMA does not approve tools or architectures
- Institutions are expected to interpret principles, apply controls proportionately, and justify their approach
3. Accountability over time
- SAMA compliance is not a one-time certification or an annual exercise; it is continuous
- Audits, supervisory reviews, and investigations often examine historical activity
- Regulators assess what controls existed and were followed at the time decisions were made
| What Regulators Actually Evaluate | What Regulators Do Not Accept |
|---|---|
| Demonstrable implementation of controls, not just documented policies | Policy documents without supporting records |
| Ability to produce historical records on demand | Dashboards without underlying evidence |
| Proof of integrity, completeness, and consistency of data over time | Retired systems without preserved data |
| Capability to reconstruct decisions, actions, and incidents after system changes | Claims of compliance that cannot be independently verified |
In financial regulation, compliance means being able to answer four questions at any point in time:
❔ What happened
❔ When it happened
❔ Who was responsible
❔ How risks were controlled
If those answers depend on systems that no longer exist, or data that was never preserved properly, then compliance breaks regardless of intent or tooling.
Understanding SAMA compliance this way reframes the problem. It shifts the focus from passing assessments to sustaining regulatory credibility.
And it makes clear why long-term record preservation sits at the center of compliance in Saudi Arabia, even when the discussion starts with cybersecurity or governance.
Further Read: Financial Services Archiving: How to Protect Sensitive Data
The Five Pillars of SAMA Compliance — And Where Data Sits
SAMA compliance is often described as a set of separate regulatory domains. These domains are tightly connected by one common dependency: data that can be trusted over time.
Each pillar below only works if the underlying records are preserved, complete, and retrievable long after they are created.
1. Cybersecurity & IT Governance
- Protection of sensitive records from unauthorized access
- Integrity of data so records cannot be altered without detection
- Availability of records when required for audits, incidents, or supervision
2. Risk Management
- Access to historical data used for risk identification and assessment
- Evidence of how risks were evaluated at specific points in time
- Trend analysis that demonstrates how risks evolved and were managed
3. Corporate Governance
- Records of decisions, approvals, and escalations
- Evidence of board and senior management oversight
- Documentation showing how governance frameworks were applied in practice
4. Anti-Money Laundering / Combating the Financing of Terrorism
- Long-term retention of transaction records
- Preserved customer due diligence and KYC documentation
- Historical investigation records, alerts, and case outcomes
5. Operational Controls & Auditing
- Verifiable audit trails across systems and processes
- Documentation that supports supervisory reviews and audits
- Evidence that controls were monitored and enforced consistently
SAMA’s Evidence-first Regulatory Philosophy
Across SAMA Compliance’s Cyber Security Framework and compliance control expectations, three concepts appear repeatedly. They translate directly into how records must behave over time.
Confidentiality → Controlled historical access
- Access to records must be restricted, role-based, and auditable
- Sensitive data must remain protected even years after creation
- Regulators expect proof of who accessed what, when, and under what authority
Integrity → Immutability and non-repudiation
- Records must not be alterable without detection
- Changes, corrections, and annotations must be traceable
- Audit trails must show how data evolved, not overwrite history
Availability → Long-term retrievability
- Records must be retrievable during audits, incidents, and investigations
- Retrieval must be timely, complete, and independent of retired systems
- Availability is measured over years, not operational uptime
Records that Fall Under SAMA Long-term Retention
Below is the regulator-aligned view of what must be preserved long term.
| Record category | What must be preserved | Why it matters under SAMA |
|---|---|---|
| Core banking and financial transactions | Transaction records, account movements, settlements, reconciliations, postings, balance histories | These records are the factual basis for audits, dispute resolution, financial integrity verification, and supervisory reviews. If transactions cannot be reconstructed years later, compliance cannot be demonstrated. |
| Customer account data and KYC records | Customer profiles, onboarding documents, identity verification, risk ratings, & account changes | Supports data protection obligations, customer due diligence, AML requirements, and regulatory investigations into account activity or misconduct. |
| AML / CFT monitoring and investigation evidence | Monitoring outputs, alerts, case files, investigation notes, decisions, escalations, outcomes | SAMA AML/CFT expectations require proof of how alerts were handled, why decisions were made, and how risks were managed. |
| Compliance reports and supervisory evidence | Regulatory submissions, internal compliance reports, self-assessments, remediation plans, supervisory correspondence | Demonstrates how the institution interpreted regulations, responded to findings, and managed compliance obligations over time. |
| Audit trails and access logs | System access logs, privileged activity, configuration changes, control execution evidence | Underpins integrity, non-repudiation, and accountability. These records are critical during audits, investigations, and control testing. |
| Incident, investigation, and forensic records | Security incidents, operational failures, fraud cases, root-cause analyses, corrective actions | Required for incident reporting, root-cause analysis, legal defensibility, and retrospective regulatory scrutiny, often long after the event. |
| Outsourced and third-party managed data | Records generated or stored by vendors, cloud providers, or service partners | Data remains in regulatory scope regardless of location. SAMA oversight extends to outsourced operations, cloud-hosted systems, and external service providers. |
If these records are fragmented across systems, lost during migrations, or inaccessible after outsourcing or system retirement, compliance gaps are created retroactively. From a regulatory standpoint, missing historical records are a failure of control.
Why SAMA Maturity Levels Implicitly Require Formal Archives
Once institutions aim for maturity level 3 and above, informal data handling stops being defensible, even if controls exist. Here’s why.
Note: In SAMA’s maturity model, higher maturity levels indicate increasing consistency, evidence, and repeatability of control implementation. Level 3 marks the shift from policy existence to provable execution.
What maturity level 3 actually requires in practice:
- Documented controls: Policies, standards, and procedures must exist, be approved, and remain accessible over time. If historical versions are lost or overwritten, documentation cannot be proven.
- Demonstrable implementation: Institutions must show when they were implemented, where they applied, and how they operated at a given point in time. That proof comes from preserved records, not system screenshots.
- Monitored compliance: Logs, reports, exceptions, and follow-ups must be retained, so compliance can be evaluated retrospectively and not just in the present.
- Repeatable audits: SAMA assessments are not one-off events. The same evidence is often requested across multiple reviews, sometimes years apart. Evidence that cannot be reliably reproduced is treated as non-existent.
This is where weak archival approaches quietly fail.
Why informal storage breaks under maturity expectations:
- Exports are point-in-time snapshots with no chain of custody
- Evidence is scattered across live systems, retired platforms, and ad-hoc files
- Each audit becomes a reconstruction exercise instead of a retrieval exercise
- System migrations silently destroy historical context
- Time-to-response increases, escalating regulatory risk
- File shares allow uncontrolled modification and duplication
- Backups are designed for recovery, not regulatory evidence
- Metadata, context, and audit trails are routinely lost
- There is no consistent way to prove completeness or integrity
💡Enterprises archiving if treated as an afterthought will experience maturity stagnation. Institutions that formalize record preservation remove friction from every future audit, review, and supervisory interaction.
How Archon Supports SAMA-Aligned Long-Term Record Preservation
If SAMA compliance is ultimately proven through evidence, then the archive is not a storage layer. It is a regulatory control. A SAMA-aligned long-term archiving architecture must meet the following requirements.
- Independence from source systems: Records must not depend on the continued operation of the systems that created them. Core banking platforms, AML engines, case management tools, and reporting systems will be replaced over time. The archive must preserve records in a form that remains accessible and verifiable after those systems are retired.
- Immutability or full change traceability: Records must either be immutable or maintain a complete, tamper-evident history of every change. Overwrites, silent edits, or destructive updates undermine evidentiary value. Regulators expect institutions to prove not just what data exists, but how it has (or has not) changed over time.
- Searchable and audit-ready access: Archived records must be searchable, filterable, and retrievable in a way that supports audits, investigations, and supervisory reviews. An archive that requires manual reconstruction or bulk restores to answer regulatory questions does not meet audit-readiness expectations.
- Retention enforcement independent of policy documents: Retention periods must be enforced by the system, not just described in policy. The architecture must prevent premature deletion, support legally mandated retention windows, and allow retention rules to persist across migrations and organizational change.
- Secure, controlled access for compliance functions: Compliance, audit, and risk teams must be able to access records without depending on operational system owners. Access must be role-based, logged, and auditable, preserving confidentiality while enabling regulatory response.
- Survivability across time, audits, and change: The archive must withstand years of audits, incident reviews, system migrations, vendor transitions, and organizational turnover. Its integrity and accessibility cannot degrade as technology stacks evolve.
A compliant archiving architecture is designed to preserve institutional memory in a form regulator can trust, years after the original systems, teams, and contexts are gone. This is where Archon fits not as software to “solve compliance,” but as infrastructure that supports a compliant operating model.
Archon is designed around three regulatory realities that SAMA enforces implicitly.
Ingestion from regulated systems
- Data is ingested from core banking platforms, payment systems, AML/CFT engines, compliance tools, and other regulated sources
- Ingestion does not require replacing or disrupting existing systems
- Records are captured in a way that preserves context, structure, and lineage
Preservation as a regulatory control
- Records are preserved independently of source systems
- Retention is enforced at the preservation layer, not left to application behavior
- Integrity is maintained through immutability or full change traceability
- Historical versions remain accessible even after systems are retired
Access for audits, investigations, and supervision
- Compliance, audit, and risk teams can access records without relying on operational systems
- Searches and retrievals are audit-ready, not reconstruction-driven
- Access is controlled, logged, and reviewable
SAMA Compliance is Proven in Retrieval, Not Policy
SAMA compliance is not demonstrated by frameworks, tools, or written intent. It is demonstrated when a regulator asks for evidence, and the institution can produce complete, trustworthy records years after the fact.
This is what separates stated compliance from actual compliance. Policies describe what should happen. Controls describe how it should happen. But regulators evaluate what can be proven to have happened.
Long-term accountability is the real obligation. Records must survive audits, incidents, system replacements, organizational change, and time itself. They must remain intact, accessible, and defensible long after the teams, platforms, and vendors that created them are gone.
This is why institutions should adopt formal record preservation operating models such as Archon to ensure that compliance is sustained as infrastructure, not managed as an ongoing firefight.
In the end, SAMA compliance is not tested when systems are running smoothly. It is tested when pressure is applied, and only records that can be reliably retrieved pass that test.
For institutions evaluating how to operationalize long-term, SAMA-aligned record preservation, Archon provides a structured approach designed for audit continuity and regulatory survivability. Contact us today to book a demo!
