"Take a backup" is advice everyone agrees with and nobody schedules, because it comes with no deadline and no duration. The law supplies both. If you are VAT-registered in Saudi Arabia you must keep your invoices and records for at least six years, and keep them inside the Kingdom. If you are a taxpayer in Egypt the period is five years following the tax period covered by the return. Pulling the other way, the Saudi Personal Data Protection Law requires you to destroy a customer's data once the purpose for collecting it has ended, and to destroy every copy of it, backups included.
Those two duties point in opposite directions, and a backup that keeps everything forever breaks both. This article turns the published periods into design decisions for website and system backups: what you keep, where, for how long, and what you delete on schedule.
The retention periods that actually bind you
Every row below comes from the text of an article, not from common practice or an accountant's rule of thumb.
| Obligation | Period | Text |
|---|---|---|
| Saudi Arabia: invoices, records and accounting documents | At least six years from the end of the relevant tax period | VAT Implementing Regulations, art. 66(1) |
| Saudi Arabia: capital-asset records | The asset's adjustment period plus five years from its purchase date; the adjustment period is six years for movable assets and ten for immovable ones | Same regulations, art. 66(1) with art. 52(2) |
| Saudi Arabia: commercial books, correspondence and documents | At least ten years | Commercial Books Law, art. 8, quoted in Qadha Journal, issue 31, Saudi Ministry of Justice |
| Egypt: records, books and documents including invoice copies | Five years following the tax period covered by the return | Unified Tax Procedures Law 206/2020, art. 38 |
| Egypt: commercial books and the documents supporting their entries | Five years from the endorsement marking the book finished or closed | Commercial Law 17/1999, art. 26(1) |
| Egypt: copies of correspondence and telegrams | Five years from the date sent or received | Commercial Law 17/1999, art. 26(2) |
| Saudi Arabia: record of personal data processing activities | For as long as processing continues, plus five years from the date the activity ends | PDPL Implementing Regulations, art. 33 |
Three observations about this table will change your plan more than the periods themselves.
The longest period governs. A Saudi merchant who is also VAT-registered faces six years on one side and ten on the other, over overlapping documents. A blanket "six years for everything" policy leaves you with incomplete books in year seven.
E-invoicing did not create a new period. The ZATCA resolution on controls and technical requirements refers storage explicitly back to "the record-keeping requirements set forth under Article (66) of the VAT Implementing Regulation". The six years are the same; what the resolution adds is the format invoices are stored in, and a prohibition on invoicing systems that allow issued invoices to be altered or deleted. If you are preparing your system for integration, the detail is in ZATCA e-invoicing phase two, and for Egypt in connecting your system to the ETA.
In Egypt, a cancelled invoice is kept along with its copies. Article 37 of Law 206 requires the taxpayer, where an invoice or receipt is cancelled, to keep the original cancelled document and all copies of it. Which means the cancellation path in your system cannot be a DELETE.
Article 38 was amended in 2026 in the part governing who must keep books. Confirm the wording in force with your accountant before you build a scheduled deletion job on top of it.
The other duty: the law also requires you to delete
Here the rule inverts. Article 18 of the Saudi Personal Data Protection Law opens by requiring the controller to destroy personal data without delay once the purpose of collection has ended, then carves out two cases: a statutory justification that requires retention for a specified period, and data closely connected to a case before a judicial body. For the first case the article settles the conflict in one phrase: the data is destroyed after that period ends or after the purpose ends, whichever is longer.
The Implementing Regulations push this down into your architecture. Article 8 requires the controller, when destroying personal data, to destroy every copy held in its systems "including backups", while observing the relevant statutory requirements. Backups are named, and statutory requirements are named, in the same sentence.
Egypt reaches the same place from another direction. Storage limitation is one of the processing principles, and the Personal Data Protection Centre's record of processing activities guideline requires each activity's entry to state "the retention period or the criteria of determining it", "the data disposal measure(s)", and "the data hosting location: inside or outside the Arab Republic of Egypt". What that means inside your database is covered in customer data protection in Egypt and Saudi Arabia.
The practical consequence: "how long do we keep backups" has no single answer for your whole project. It has one answer per data category.
What this looks like inside your database
Take an online store serving both markets. A customer asks for their account to be deleted. What goes, and what stays?
| What you hold | Decision | Why |
|---|---|---|
| Profile, address, saved cart, preferences | Delete | The purpose has ended and no statutory basis applies |
| Newsletter subscription and ad-tracking history | Delete | Consent withdrawn and the purpose is purely marketing |
| Tax invoices, their line items and amounts | Keep until the tax period expires | Statutory basis in article 66 or article 38 |
| Their name, phone and address inside the invoice itself | Stays inside the invoice only | The invoice is a document that may not be altered or deleted, and those fields are part of its mandatory content |
| Last night's database snapshot, which contains their profile | Rotates out on schedule | Operational snapshots are short-lived; the long period belongs to the financial archive, not the nightly image |
That last row is the hinge. Anyone who takes a full nightly database snapshot and keeps it for six years has manufactured six years of personal-data copies in the name of a tax obligation, when the tax obligation covers invoices, books and the documents supporting them. Separating a long-lived financial archive from short-lived operational snapshots resolves the conflict without either side losing.
In-country storage is a constraint on where the copy lives
Article 66(3) of the Saudi regulations requires invoices, documents and records to be kept in the Kingdom, on paper or electronically through access to the servers or databases holding them via a terminal or terminal connection inside the Kingdom.
That narrows your archive options. The cheapest bucket in a European region may be the wrong call for this class of document specifically, even while it remains perfectly sensible for product images and development snapshots. In practice the rule splits your copies into two groups with two destinations. If you are reviewing your infrastructure from scratch, the clauses to put to a provider are collected in how to choose web hosting.
What does not count as a backup
A copy on the same server. It saves you from deleting a file by mistake. It does not save you from losing the server, from your account being suspended, or from an attacker who gained root.
RAID. It protects against a failed disk, and it writes a deletion or a malicious encryption across every disk at the same instant, because it mirrors what is happening rather than what happened before.
Sync. The CISA #StopRansomware Guide warns that automated cloud backups may not be sufficient, because if local files are encrypted by an attacker those files will be synced to the cloud and may overwrite unaffected data. Sync carries the current state, disaster included.
Provider-supplied backups on their own. They answer hosting problems, not a deletion inside your application, and not the loss of your account with that provider.
The reference rule here is old and still sound. CISA's Data Backup Options puts it in three numbers: three copies of any important file, on two different media types, with one copy offsite. Add what the same agency recommends alongside it: an offline, encrypted copy, because ransomware actors hunt for backups and delete or encrypt them so that restoration is impossible without paying. The credentials they use to reach the backup system usually come from the environment itself, which is a separate door covered in common web vulnerabilities.
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
Immutable storage: a safeguard with a price
The common advice is to switch on Object Lock so nobody can delete your backups. The advice is right in its place, and dangerous applied to everything.
AWS documentation for Object Lock describes two modes. Governance mode blocks deletion for most users, and anyone holding the s3:BypassGovernanceRetention permission can override it. In compliance mode nobody can delete a protected object version or shorten its retention period, "including the root user in your AWS account", and the documentation adds that the only way to delete such an object before its retention date expires is to delete the associated AWS account.
Put that next to article 8 of the Saudi regulations, which requires backups to be destroyed on a valid destruction request, and the problem is visible: locking six years in compliance mode over a store containing personal data means you have built your own obstacle to another obligation. This is not a theoretical worry. The CISA guide itself cautions that immutable storage "does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost".
Read practically: hard locks belong on the archive of financial documents the law already requires you to keep. Operational database snapshots hold data that must remain deletable, and governance mode with an override permission held by two named people plus an audit log is closer to what you need.
RPO and RTO: the two numbers that decide the design
Before choosing a tool or a schedule, fix two numbers. The clearest definitions are the ones in NIST SP 800-34 Rev. 1:
- Recovery Point Objective (RPO) is the point in time, prior to a disruption, to which business process data can be recovered given the most recent backup. In other words, how much data loss your operation can absorb.
- Recovery Time Objective (RTO) is the maximum time a resource can remain unavailable before the impact becomes unacceptable.
- The guide adds a third concept that usually gets dropped: Maximum Tolerable Downtime (MTD), what the system owner will actually accept for a process outage. RTO must normally be shorter than MTD, because reprocessing data after you come back consumes time that has to fit inside the same limit.
Translated directly: RPO decides how often you take a copy, RTO decides what kind. A store handling a hundred orders a day with a one-hour RPO will not be served by a single nightly snapshot; it needs continuous archiving of the database transaction log alongside the full image. A brochure site updated once a month has an RPO of a week, and a nightly snapshot is a luxury.
To compute both for your project, write down three answers. First, the number of transactions entering your system per hour at your daily peak. Second, whether you could rebuild the last hour of transactions from another source, such as payment gateway records or confirmation emails. Third, what one hour of downtime costs you. The last answer is what decides how much the architecture deserves to cost.
Testing is not an administrative nicety
A backup nobody has tried to restore is not a backup, and that is more than a slogan. CISA recommends testing "the availability and integrity of backups in a disaster recovery scenario" on a regular basis, rather than confirming that a file exists.
Egyptian law makes the same point from an unexpected angle. Article 26 of the Commercial Law allows a merchant to keep reduced copies (microfilm) instead of originals, and gives those copies the evidentiary weight of the original if the rules governing their creation, storage and retrieval have been observed. Retrieval sits in the text next to creation and storage. A copy that cannot be retrieved does not perform its legal function, whatever its size.
A paper published in Qadha Journal, issued by the Saudi Ministry of Justice, shows how this plays out in litigation. In a published case, a defendant explained that he destroyed his documents every year; the court treated that as a breach of the Commercial Books Law provisions requiring retention for at least ten years, and the point counted against him rather than for him.
A reasonable restore test takes an hour a quarter: spin up a temporary server, restore the latest database and files to it, start the application, sign in, open an old invoice, and record how long the whole thing took. That number is your real RTO, not the one written in the plan.
What does six years of archive cost?
The prices below come from the providers' official pricing pages. They are US-dollar list prices, correct as reviewed in September 2026 and subject to change.
| Provider and class | Storage price | Published notes |
|---|---|---|
| Amazon S3 Standard in Bahrain | $0.025 per GB-month (first 50 TB) | Operational class, not archival |
| S3 Glacier Deep Archive in Bahrain | $0.0018 per GB-month | 180-day minimum storage duration; earlier deletion is charged pro rata |
| S3 Glacier Deep Archive in N. Virginia | $0.00099 per GB-month | For comparison only: about 45% below the Bahrain price |
| Deep Archive retrieval in Bahrain | $0.0033 per GB bulk, $0.022 per GB standard | Paid on retrieval, not on storage |
| Backblaze B2 | $6.95 per TB per 30 days | Egress above three times monthly average storage is $0.01 per GB |
| Cloudflare R2 | $0.015 per GB-month standard, $0.01 infrequent access | No egress charges; infrequent access adds $0.01 per GB retrieval and a 30-day minimum |
A hypothetical example for sizing: a store whose database occupies 20 GB and whose files occupy 80 GB. A full nightly snapshot retained for 30 days comes to roughly 3 TB in the operational class, and that is the line that eats the bill. The financial-document archive that has to live for six years is usually measured in gigabytes rather than terabytes, because it is invoices and records rather than product images. That gap is why separating the two tracks saves more than negotiating the per-gigabyte rate.
Note the difference between the two Deep Archive rows. The in-Kingdom storage requirement closes off the cheapest option for this class of document, and that is a real compliance cost worth showing in your estimate from the start instead of discovering it at review time.
Where to start this week
- Write one page listing your data categories, and against each one the retention period, the article that supports it, and what happens to it when the period ends. That page is the nucleus of the processing-activities record both regimes already ask for.
- Separate the financial-document archive from operational database snapshots, and give each its own period and storage destination.
- Fix RPO and RTO as two written numbers, then check whether your current backup schedule actually meets them.
- Confirm that at least one copy lives outside your hosting account, and that the key used to reach it has no delete permission.
- Run a full restore on a temporary server, record how long it took, and put the next date in the calendar.
- Review your deletion policy: what is deleted automatically today when a period expires? If the answer is "nothing", that is action item one.
The periods quoted here are taken from published texts and are material for an engineering decision, not a substitute for your accountant's or lawyer's view of your own company's position.
If your system today keeps everything forever and drops nothing on schedule, the fix starts at the design level rather than the scheduler. Describe your current setup on the custom systems page and within 24 hours you will have an outline of what needs to change, with an estimate of duration and cost, at no charge and with nothing owed.
Sources
All links below were accessed on 21 September 2026.
- VAT Implementing Regulations, Zakat, Tax and Customs Authority, articles 52 and 66.
- Resolution on controls, requirements, technical specifications and procedural rules for implementing the E-Invoicing Regulation, ZATCA, clause Fifth and the prohibited-functionalities annex.
- Personal Data Protection Law (art. 18) and its Implementing Regulations (arts. 8 and 33), SDAIA.
- Unified Tax Procedures Law 206 of 2020, Egyptian Official Gazette, issue 42 bis (C), 19 October 2020, articles 37 and 38.
- Egyptian Commercial Law 17 of 1999, article 26.
- The evidentiary weight of commercial books, Qadha Journal, Saudi Ministry of Justice, issue 31, quoting article 8 of the Commercial Books Law.
- Record of Processing Activities guideline, Personal Data Protection Centre, Egypt.
- NIST SP 800-34 Rev. 1, definitions of MTD, RTO and RPO.
- #StopRansomware Guide and Data Backup Options, CISA.
- Locking objects with Object Lock, AWS documentation.
- Official pricing pages: Amazon S3, Backblaze B2 and Cloudflare R2.
Frequently asked questions
How many years must e-invoices be kept in Saudi Arabia?
At least six years from the end of the relevant tax period, under article 66 of the VAT Implementing Regulations. The e-invoicing resolution adds no separate period; it refers storage back to that same article. Capital-asset records run longer: the asset's adjustment period plus five years.
May I store a copy of my Saudi invoices on a server outside the Kingdom?
Article 66(3) requires invoices, documents and records to be kept in the Kingdom, on paper or electronically through access to the servers or databases from a terminal inside the Kingdom. The financial archive therefore needs different treatment from product images or a development environment, and possibly a different storage destination.
If a customer asks for their data to be deleted, must I delete it from old backups?
Article 8 of the Saudi PDPL Implementing Regulations requires the controller to destroy every copy held in its systems, backups included, while observing the relevant statutory requirements. In practice that means a short rotation for operational snapshots so they age out on their own, while whatever the law requires you to keep lives in the financial archive alone.
What is the difference between RPO and RTO?
RPO is how much data you can afford to lose, and it sets how often you take a copy. RTO is the maximum acceptable downtime, and it sets what kind of copy and restore path you need. NIST adds MTD, the outage the system owner will actually accept; RTO has to be shorter than it, because reprocessing data after you return consumes extra time.
