Where your data lives, and who can see it

What the product stores

A workspace stores what you type into it: aggregate figures for a filing (compensation totals, spend totals, depreciation amounts by asset class), your company's identity facts (legal name, registration numbers, business activities), its subsidiaries and largest customers as organisation names, and the appendix figures of the official form.

An account is a name and an email address, plus what signing in needs: expiring login codes and session tokens, both stored hashed, and the public half of a passkey if you add one. No password, no phone number, no other personal field.

A saved import mapping stores which columns of your own file to read: header names and sheet choices only, never a row of the file, never a name, never an amount.

What it never stores

No table or column may hold an individual employee's name, identity number or salary. That rule is written into the database schema, and an automated test scans every database migration and the live database's own catalogue for forbidden column patterns; if one ever appears, the tests fail and the deployment stops.

That rule polices the database's structure, not what people type: it cannot stop someone putting personal text into a free-text field. So the screens ask only for aggregates and say so where it matters; the labour section asks for compensation totals, never an individual's salary.

The official form's contact person (a name, an email address, two phone numbers) is deliberately never stored. You type it when you print or export, it goes onto the document, and it is remembered only in your own browser. Automated tests watch every network request while an export runs, signed in and as a guest, and fail if any request carries a contact value.

Files you upload

Uploaded files are read inside your browser. What leaves your device is the aggregate figures you approve and, if you save a mapping, column headers; the file itself is never transmitted.

An automated test runs a real import in a real browser and inspects every network request it makes: none carries a row of the file, and only the expected endpoints are touched.

A payroll-shaped file is refused on the supplier import path before anything is mapped or sent: sheet headers are matched, in English and Arabic, against identity and pay words (iqama, national ID, employee name, salary and more), and a strong match blocks with no override.

That guard matches known words, so a file whose headers have been renamed to words it does not know will pass it. This is why the preview shows every value that is about to be written before anything is sent, and nothing is transmitted until you confirm.

Who can see a workspace

Every table that holds workspace data carries the workspace's identifier, and PostgreSQL row-level security makes rows of other workspaces invisible and unwritable at the database layer; the application's database role cannot bypass it. An automated test connects as one workspace and attacks another with raw SQL: it reads zero rows, and its inserts, updates and deletes are refused by the database itself.

Within a workspace, a Preparer edits and a Reviewer reads. The roles are enforced at the API, not just on screen, and an automated test proves a Reviewer's write is refused with the stored values untouched.

The platform operator can suspend a workspace. Suspension deletes nothing: the data stays intact, the members are emailed about it (a failed send is shown to the operator, not swallowed), and the action can be reversed at any time. Both actions are recorded in the workspace's audit log.

Guest mode

Without an account, scenarios live in your browser's own storage. Typing, calculating and the Excel export all happen on your device, and the export produces its file without a single application request; an automated test watches the network while it runs and fails on any transmission.

One caveat: the print summary and the filing pack carry the scenario's random identifier in their page address, and because the app preloads the pages behind links, your browser can request that address before you click. That identifier therefore reaches the server. The scenario's name and its figures do not.

Where it runs

The product runs on AWS in Frankfurt (eu-central-1). It is not hosted in the Gulf today: the Middle East regions could not be used end to end from the deployment pipeline, and the infrastructure is written region-agnostic, so a move, including to the AWS Saudi region once usable, is a configuration change rather than a rebuild.

Traffic is served over HTTPS with a certificate managed in the same infrastructure. The database is reachable only from inside the private network, never from the internet.

Encryption and backups

The database is encrypted at rest with its own dedicated key.

Automated backups are kept for seven days, and a daily snapshot is additionally copied to a backup vault in a second European region. All of these copies live inside the same cloud account: there is no copy outside AWS and no copy with a second provider.

The database cannot be deleted casually: deletion protection is switched on, and even a deliberate removal of the infrastructure keeps a final snapshot.

The audit log

Each workspace keeps an audit log: who created, edited, renamed, deleted, exported, imported or approved which scenario and when, plus suspension and reactivation. It records names of scenarios, the actor's name and the time; it does not record reads, so viewing a screen leaves no trace, and it holds no figures.

How this page stays true

The product deploys through a single pipeline, and the automated tests described above run first: if any of them fails, the deployment does not happen. This page carries no certification and claims none: it describes what the code does, and the code is the evidence.