Compliance archives in Saudi Arabia: how long, and where the data can live

Every company in the Kingdom is required to keep records for years, and most of the advice online about where those records may sit is wrong, out of date, or written by someone selling storage. So we read the primary sources. Here is what Saudi law actually says about retention periods and data residency, and what separates an archive that survives an audit from one that just survives.

By Abdennour T Bada, Pulsar Network, writing from Saudi Arabia. We operate 12 pNodes and accept XAND delegation at 10% commission, so we profit if decentralized storage grows. Read the recommendations near the end with that in mind.

Nobody keeps records because they want to

Compliance archives are the least glamorous data in any company. They are also the data with the longest, most legally enforceable lifespan, which makes them the one workload where the question "who will still be holding this in ten years" has an actual legal answer.

In Saudi Arabia that question has become sharper for a boring reason: e-invoicing. Since ZATCA's Fatoora rollout, invoices are not paper anymore, they are structured XML with cryptographic stamps, generated by software, and legally required to be preserved and producible on demand. Digitisation moved the retention obligation from a storeroom to a storage system, and most companies never revisited the architecture question that came with it.

How long, exactly

There is no single Saudi retention law. There is a stack, and the durations differ by regulator. These are from the primary texts, not from summaries:

Sourcing note: the VAT rows link to ZATCA's published Implementing Regulations in the sources below. The Commercial Books, AML, CMA, SAMA and Income Tax figures come from Arabic primary texts and regulator circulars, several of which have no stable public English URL. Verify any row you intend to rely on with a Saudi adviser.

Two corrections worth knowing, because both circulate widely and both are wrong. First, the Companies Law does not set a retention period. The 2022 law requires accounting records to be kept and criminalises failing to keep them, but the ten-year figure people attribute to it actually comes from the Law of Commercial Books. Second, the frequently repeated "eleven years for real property" understates it: the immovable-asset adjustment period is ten years, so with the additional five the real outer limit is fifteen.

One more detail that catches foreign-run businesses: records must be in Arabic, and tax invoices must be issued in Arabic even when another language appears alongside as a translation.

Where the data may actually live

This is where most vendor material falls apart, usually in the direction that sells more local hosting. The honest position is that Saudi Arabia has targeted localization, not blanket localization.

For ordinary private companies: access, not location

The VAT rule is explicit and more flexible than its reputation. Records must be kept in the Kingdom either physically or electronically through access to the relevant server or database via a terminal or access point in the Kingdom. ZATCA's own guidance accepts on-premises servers or cloud. The obligation attaches to producibility, in Arabic, on request, with documented systems and protection against tampering, not to the geographic coordinates of a disk. A non-resident taxable person without a tax representative does have to appoint a third party established in the Kingdom to maintain records.

Where localization genuinely binds

• Government data. The MCIT Cloud First policy states that all data in the Government Cloud and the Commercial Governmental Cloud should be located geographically inside Saudi borders. It binds government entities, with carve-outs for SAMA, Defence, Interior, State Security and the NCA, and is only "highly recommended" for the private sector.
• Saudi government data at providers. Under the CST cloud framework, providers and customers must ensure Saudi government data is not transferred outside the Kingdom, permanently or temporarily, unless a Saudi law or regulation expressly permits it. CST also registers providers in classes that gate which classifications they may host.
• Financial institutions: two gates, not one. SAMA's Cyber Security Framework requires a member organization to obtain SAMA approval before using any hybrid or public cloud service or signing the provider contract, and separately states that in principle only cloud located in Saudi Arabia should be used, with explicit approval required to place it abroad. An in-Kingdom deployment still needs approval to exist; going offshore needs a second one. Private cloud sits outside that control, and the separate outsourcing rules require written no-objection and guaranteed SAMA access rather than a residency mandate.
• Personal data anywhere. The PDPL contains no localization mandate. Transfers abroad are permitted for defined purposes, subject to no prejudice to national security, adequate protection, and data minimisation, using Saudi standard contractual clauses, binding common rules or an accreditation certificate. A documented transfer risk assessment is required whenever you rely on one of those safeguards, and again whenever sensitive data moves continuously or at scale. Since SDAIA has not published an adequacy list, in practice almost every transfer out of the Kingdom needs both a safeguard and an assessment. Penalties reach SAR 5 million for general violations and SAR 3 million with up to two years' imprisonment for intentional sensitive-data disclosure.

So the practical answer for a normal Saudi business archiving invoices, contracts and books: your records can live in the cloud, they must be reachable and producible from inside the Kingdom in Arabic, and if they contain personal data you need the PDPL transfer machinery in place before any of it leaves.

What makes an archive defensible

Retention is only half the obligation. The other half is proving the record you produce in year nine is the record you created in year one. Start with an honest caveat: no Saudi regulator publishes a technical archive standard comparable to the American rules below. ZATCA requires documented systems, protection against tampering and producibility in Arabic; SAMA and the CMA require controls and access. What follows is the international benchmark that local auditors and vendors tend to reason from by analogy, not by rule. That benchmark is US SEC Rule 17a-4, and it changed meaningfully in 2022: a firm can now satisfy it either with the classic non-rewriteable, non-erasable format, or with a complete time-stamped audit trail capturing every modification and deletion, when it happened and who did it, plus the ability to recreate the original record. That either/or covers the storage format only: the rule's other conditions, including verification, indexing, download on demand, and a designated third party or executive officer undertaking, apply either way. FINRA Rule 4511(c) is what pulls these storage rules onto member firms, and 4511(b) sets a six-year default for anything without its own period, a neat coincidence with the Saudi VAT term.

In practice this is implemented with object-lock storage. Two details separate a real archive from a checkbox:

• Compliance mode versus governance mode. In compliance mode a locked object cannot be overwritten or deleted by anyone, including the account root user, and the period cannot be shortened. One caveat the vendors skip: AWS documents that the only way to remove a compliance-mode object before expiry is to delete the account it lives in, which protects you against a bad API call but not against losing the account, which is exactly the failure mode in the next section. Governance mode can be bypassed by a privileged user sending an explicit override header. Independent assessment covers both modes against the non-rewriteable requirement, but the governance-mode opinion leans on procedural controls over whoever holds the bypass permission. Only compliance mode resists an insider with credentials by design rather than by policy.
• Locks apply to versions, not names. A retention lock protects a specific object version. It does not prevent new versions or delete markers being written on top. Archives get quietly broken by teams who assume the bucket is frozen because the objects are.

Cryptographic hashing and trusted timestamps sit alongside this rather than replacing it. In US federal court, FRE 902(14) lets data copied from a device be authenticated by hash with a certification from a qualified person, provided the other side gets advance written notice and access, which removes the need for a live witness without by itself making the record admissible; in the EU, qualified electronic timestamps carry a legal presumption of integrity, and the 2024 eIDAS update went further by recognising qualified electronic archiving services, which carry a presumption of the integrity and origin of preserved data, and qualified electronic ledgers, which carry a presumption of integrity and of unique sequential ordering. That is the closest any major regulator has come to blessing blockchain-style anchoring. What no regulator we reviewed accepts is a bare hash log as a substitute for controlled retention: the SEC's audit-trail alternative and the eIDAS qualified services both carry control and certification requirements a plain hash chain does not meet. A hash proves a file did not change. It does not prove the archive is complete, retained for the full term, or producible.

The failure mode nobody budgets for

Regulators are not the main threat to a ten-year archive. Concentration is.

In May 2024 a misconfiguration at Google Cloud deleted one of an Australian pension fund's private cloud subscriptions, taking out both zones it was duplicated across. Recovery leaned on two things: backups sitting in Google Cloud Storage outside the deleted environment, which survived, and backups the fund held with an additional provider. The lesson is narrower than the headlines suggested, and more useful: duplication inside a single subscription is not independence, because when the deletion happens at the subscription layer everything inside it goes at once. Copies that live outside the blast radius survive, whoever hosts them. Ransomware crews learned the same lesson from the other side and now target backup repositories specifically, and the history of the industry includes providers giving petabyte-scale customers a matter of weeks to evacuate before shutting down.

This is why serious archive designs are boring and plural: a compliant primary archive with locked retention, plus at least one independent copy whose survival does not depend on the same vendor relationship, credentials or billing account.

It is worth being explicit about what that second copy usually is today, because the honest answer is not exotic: a second commercial cloud under a separate contract and billing entity, offline or air-gapped tape, or an on-premises WORM appliance. Those are the defaults, they are well understood by auditors, and they are what any newer option has to beat rather than merely join.

Where decentralized storage fits, honestly

We operate storage nodes, so this is the part to read most sceptically. Decentralized storage is not ready to be the primary compliance archive for a regulated Saudi business, and anyone telling you otherwise is selling something. Of the networks we have looked at closely (Xandeum, which we operate on, plus Filecoin, Arweave and Storj as of July 2026), none offers an accountable provider you could register with CST, a SOC 2 or ISO certificate to hand an auditor, a retrieval service commitment, or control over which country a replica lands in. Those are not small gaps.

The role sometimes proposed instead is narrower: the independent second copy, an archive layer outside your cloud provider's account boundary whose integrity can be proven cryptographically rather than asserted. We think that is the most plausible future fit. It is also, today, unproven, and it inherits most of the same problems:

• If replicas can land anywhere, every copy containing personal data drags in the PDPL transfer machinery above, with no adequacy list to lean on.
• No retrieval service commitment, and no guarantee a record comes back producible, in Arabic, on demand, in year nine.
• No accountable entity to answer an examiner, and as far as we know no Saudi regulated firm doing this today.
• It swaps one correlated risk for another. A single provider can delete your account; a young network can fail as a whole through a protocol bug, token-economics collapse or operator churn. If the network stops before your retention period ends, the archive is gone in a different way. Six to fifteen years is a long bet on any infrastructure, and decentralized networks have shorter track records than the tape in your basement.

For that role to become real here it would need in-country nodes, an accountable entity, certifications, and a retrieval guarantee. None of that exists yet on any network we have reviewed. We publish live usage data for the one we operate on precisely so nobody has to take our word about how early it is.