Why Rust: the architecture of Tarleaks ERP, and why it fits government and critical-infrastructure tenders in the Gulf

Tarleaks ERP is built in Rust, a programming language that prevents the memory errors behind most security flaws in older software. Each company gets its own database, the database itself records every change, and the system runs in Arabic and English, on our cloud or on your own servers. Here is how that design meets Gulf tender questions.

What changed. 31 October 2026: first version.

The short answer

Government and critical-infrastructure buyers in the Gulf ask the same four questions of any business system. Is the software built safely? Is our data kept apart from everyone else's? Can we see who did what? Can the data stay where our rules say it must?

Tarleaks answers the first with its language. Our own code is memory-safe by construction, with one documented and reviewed unsafe block. It answers the second with a separate database for each company, the third with a change history the database itself writes, and the fourth by letting you choose where the system and its data run.

None of this is a certificate. It is evidence you can test, and the rest of this guide shows what it is, where it comes from, and how it maps to the controls named in Saudi and UAE tenders.

Why memory safety matters to a government buyer

Most large software in use today is written in C or C++. These languages let a programme read or write memory it should not, and when that happens by mistake an attacker can often turn it into a way in. These are memory-safety errors, and the numbers on them are large.

• Microsoft. About 70% of the vulnerabilities Microsoft assigns a CVE each year are memory-safety issues (MSRC, 16 July 2019).
• Google Android. Memory-safety issues were 76% of Android's vulnerabilities in 2019 and 24% in 2024, as new code moved to memory-safe languages (Google, 25 September 2024). In November 2025 Google reported that the share had fallen below 20% for the first time.
• Rust against C and C++ at Google. Google estimates Android's Rust code at about 0.2 vulnerabilities per million lines, against close to 1,000 memory-safety vulnerabilities per million lines in its C and C++ code, a 1000x reduction. Rust changes were also rolled back about 4x less often and spent about 25% less time in code review (Google, 13 November 2025).
• Government guidance. On 24 June 2025 the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) published a joint guide, Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development. It says adopting memory-safe languages "offers the most comprehensive mitigation against this class of vulnerabilities" (CISA).

For a ministry, a utility or a bank, this matters because an ERP holds salaries, bank details, identity documents, contracts and invoices. A whole class of attack that never gets a foothold is a class you do not have to patch, monitor or explain to an auditor.

Memory safety is not the whole of security, and we do not present it that way. It does not choose good passwords, set the right permissions or configure a firewall. Those need their own controls, and the sections below cover the ones an ERP is responsible for.

What "one documented and reviewed unsafe block" means

Rust checks memory safety when the code is compiled. A programmer can switch that check off for a few lines by marking them unsafe, which is sometimes needed to talk to the operating system or to hardware. Inside such a block the programmer, not the compiler, is responsible for safety.

In the code we ship there is exactly one such block. It opens the file the website-analytics service uses to turn an internet address into a country, as a read-only memory map. Above it sits a written safety argument: the file is written before the service starts and is never changed while it runs, which is the only case the library warns about. It went through code review like every other change.

A sentence like ours is easy to make and easy to break, so we made it testable. An automated check runs on every change to the code. It lists every unsafe in the repository with its reason, requires the written safety argument on any in shipped code, and fails the build if a new one appears unlisted, or if the shipped count stops matching the number in this article. Test helpers and developer examples are listed too, but they are never built into the product.

One more honest note. Like every Rust program, ours uses open-source libraries, and some of them contain low-level code of their own that our count does not cover. We pin every library version with its checksum and check the list against the public advisory database for Rust.

The architecture in five parts

1. Every module is its own service

Tarleaks is made of more than 40 separate Rust services: HR, payroll, accounting, CRM, inventory, documents and the rest. Each runs as its own programme with its own section of the database. Modules never reach into each other's tables. When payroll posts a run to the ledger, it sends a message, and accounting records a balanced entry once, even if the message arrives twice.

Every request passes two gates. The gateway checks that the company's licence includes the module, then the service checks the user's permission for that exact action, such as "approve a payroll run". A screen that hides a button is a convenience. The server's refusal is the control.

2. One database for each company

Each company's business records live in a database of their own, not in shared tables with a company label. A mistake in one report cannot show another company's rows, because they are not there. On top of the sign-in, every request is checked against the company address it came from, so a valid login used on another company's address is refused and recorded.

This also makes the hard questions simple. Backing up, restoring, moving or deleting one company's business data is an operation on one database, not a filter across everyone's.

3. A record of every change

The database itself records the old and new value of each field that changes, and a full copy of any row added or deleted, on every tracked table. It does not depend on each screen remembering to log: changes from screens, imports and scripts are all captured on tracked tables. Every entry has its time and the value before and after. It names the person wherever the application passes their identity, which covers most changes made in the app; otherwise it falls back to who created or last updated the row, and where neither is known it says so rather than guess.

Separately, every change to personal data writes an audit entry with its purpose, its legal basis, whose data it touched, the country and when the entry may be destroyed. For a request from a person about their own data, HR lists the audit entries recorded against that person. An optional tamper-evident chain links each audit entry to the one before it, so a deleted or inserted row shows up.

4. Arabic and English, built in

The interface is available in Arabic and English, right to left in Arabic, and each user picks a language. Permissions, approvals and the audit trail are the same in both, and the built-in assistant can be set to answer in Arabic for the whole company.

5. You choose where it runs

You can use our cloud, connect your own storage bucket for files, place the business data in your own PostgreSQL database when the workspace is set up, or install the whole system on your own servers. On our cloud, sign-in accounts, settings, the licence and the audit trail stay on our servers; only an installation on your own servers keeps all of it with you. Backups are on by default, taken daily and kept for 30 days in the storage the company connects; until storage is connected each run is recorded as failed, not skipped in silence. An administrator can take a backup at any time and download a copy. Employee document retention follows the country, for example five years for UAE and Saudi records.

How the design maps to Gulf tender requirements

Tender documents in the region often name a national control set. Here is how the design above gives you evidence for the controls an ERP touches. The controls apply to the government entity or operator; the right column is what Tarleaks lets that entity show.

Three details from the official texts are worth knowing before you write or answer a tender.

• Saudi Arabia. ECC-2:2024 applies to government agencies, their affiliated companies, and private entities that own, operate or host Critical National Infrastructure. In this version the sub-control that required hosting and storage inside the Kingdom (4-2-3-3) was deleted, and data localisation controls moved to the National Data Management Office at SDAIA. Ask which data-classification and localisation rules your project follows, not only which ECC controls.
• UAE. The UAE Information Assurance Regulation (TDRA, version 1.1, March 2020) obliges all UAE government entities and entities identified as critical, and recommends it to everyone else. The UAE Cyber Security Council also publishes a UAE Information Assurance Standard. Check which document and version your tender names.
• Personal data. The UAE's Federal Decree-Law No. 45 of 2021 covers personal data processed wholly or partly by electronic systems, sets consent and rights, and sets rules for transfer abroad. The Saudi Personal Data Protection Law came into force on 14 September 2023, and its one-year grace period ended on 14 September 2024. Free zones such as DIFC have their own data protection law.

What we do not claim

We do not claim that Tarleaks is certified against NCA ECC, the UAE Information Assurance Regulation or any data-protection law, and no software can make a buyer compliant by itself. Compliance is a property of the organisation: its policies, people, network and suppliers, assessed together. What a vendor can do is answer each question with something you can check. That is the standard we hold ourselves to here, and it is the standard you should hold every bidder to.

Questions to ask any ERP vendor in a tender

These work for any bidder, us included. Ask for a written answer and a way to verify it.

• Which programming languages is the product written in, and how much of the shipped code switches off the language's safety checks? Ask for the list.
• Is each customer's data in its own database, or in shared tables with a customer column?
• Does the change history record the value before and after, and is it written by the application or by the database?
• Can you run the system on our servers, or keep the data in our own database? What does that change in support?
• How do we get all of our data back, in a usable format, if we leave?
• Which control set and version did you map your answers to, and who checked the mapping?

How Tarleaks helps

Tarleaks offers Gulf public bodies and infrastructure operators an ERP that is memory-safe by design, separates each company's business data into its own database, records every change in the database itself, and runs in Arabic and English on our cloud or your own servers. The security and data protection guide lists each control with its status. For a tender, we answer your questionnaire with this evidence and show it working in a live demo.

What to do next

• Read the security and data protection features with the status of each one.
• Choosing a system now? Use our 15 questions for the demo, and add the six above.
• If your finance team also faces e-invoicing deadlines, read the UAE e-invoicing timeline.
• Book a demo and bring your tender's security questionnaire.

Questions people ask

Is Tarleaks ERP certified against NCA ECC or the UAE Information Assurance Regulation?

No. Those controls apply to the government entity or operator, and only an assessment of that entity decides compliance. Tarleaks gives you evidence for the questions they raise: how data is separated, logged, kept and returned, and how the software is built.

What does memory-safe mean for an ERP system?

The programming language prevents a whole class of errors in which software reads or writes memory it should not. That class is behind about 70% of the vulnerabilities Microsoft assigns a CVE each year. Tarleaks is written in Rust, which rules these errors out at compile time outside code marked unsafe.

Can Tarleaks keep our data inside Saudi Arabia or the UAE?

Yes, by choosing where it runs. To keep everything in the country, install the system on your own servers there. On our cloud, files can go to your own storage bucket and the business data to your own PostgreSQL database chosen at setup, while sign-in accounts, settings, the licence and the audit trail stay on our servers.

Does Tarleaks work in Arabic?

Yes. The interface is available in Arabic and English, right to left in Arabic, and each user picks a language. The same records, permissions and audit trail apply in both.

---

General information, not legal or compliance advice. Checked against the official sources listed on this page on 31 October 2026. Control sets and laws change: confirm your own obligations with the regulator named in your tender or with your adviser.