Trust

Our security status,
including what we do not have.

Most vendors show a row of certification logos here and hope nobody checks what they cover. We publish the whole list instead, including the lines where the answer today is no. If any of them is a blocker for you, it is better to find out here than in month two.

Status

The full list, with nothing left out.

Each status means what it says. By design means it is built into how the system works, not just written in a policy. Scheduled comes with a date. Not held means we do not have it.

Data residency
By design
Your system, its databases and its backups are in the European Union. Only the subprocessors listed below have access from outside the EU.
Per-person access
By design
No shared logins and no shared passwords. Roles are checked on the server, not only in the interface, so a script must obey them just like a person on screen.
Two-factor sign-in
Available
An authenticator app or a six-digit code by email, which each person turns on for themselves. A used code never works twice. An administrator sees who has it on and can reset it. It cannot yet be made compulsory for everyone. If your policy needs that, tell us when you send your requirements.
Audit trail
By design
Accounting entries are hash-chained: each entry is sealed to the one before it, so any changed figure shows up. Lock dates stop anyone rewriting a closed period.
Change control
By design
Every change is reviewed and must pass more than 10,000 automated checks (on the reference build and its foundation) before it reaches the live system. Every release records the version (commit) it published. A release that fails its health check puts the previous version back by itself.
Encryption in transit
In transit only
Connections use TLS 1.2 and 1.3 only. Secrets (passwords and keys) sit in environment files that only the administrator account (root) can read, never in the code repository. Full-disk encryption is not in place on our servers: our provider does not offer it on these machines, and we have not built it ourselves. We say so here so that this row does not suggest otherwise.
Backups
Restore tested
On 8 October 2026 we restored nine databases in full into empty databases: eight from the offsite copy of our stand and one from a client’s own server. There were no errors, and every table was present. On our stand, backups are made daily, checked by reading them back with the restore tool, and kept offsite for thirty days. The test found that they lacked the database roles a restore needs, and since then they include them. On a client’s own servers: a daily database dump and the provider’s daily image of the whole server, each kept for seven days, plus a dump before every release. The restore test is not yet on a schedule.
GDPR data processing agreement
Held
Signed with the contract, as its Annex C. Before that, the probe (our two-day look at your live systems) runs under the mutual NDA and its personal data terms. The company that signs is in the United Arab Emirates. So data transfers to it run under the EU standard contractual clauses (Module Two), as do transfers to any subprocessor that needs them.
Incident response procedure
Held
A named person on call. If a breach affects your data, we notify you without undue delay, and at the latest within 48 hours of becoming aware of it. A written incident report (post mortem) follows within five working days.
Third-party penetration test
Planned
Planned on the reference build, not done yet. When it is done, we will publish the summary on this page with its date, whatever it says.
Source escrow
In the contract
Your agreement provides source escrow: if we stop the service, the source code is released to you. The escrow agent is not named yet. This line will name it once the first deposit is made.
Exit
In the contract
You can have all of your data at any time, in open formats, free. After the agreement ends you have 90 days to take it out, and leaving costs nothing. A licence to run the system on your own server has a price fixed in your agreement and published on the pricing page.
ISO 27001
Planned
Planned, not held. We are a small engineering company and we are not certified yet. When the audit is booked, this line will show its date. It will not say Held until we have the certificate.
SOC 2 Type II
Not held
Not held and not planned. It is a standard used in North American purchasing, and none of our clients has asked for it. If your company needs it, tell us early, because it takes a year of work.
24/7 monitored SOC
Not held
We run health checks and alerts on every system we run, but not a staffed security operations centre (SOC).
Cyber liability insurance
Scheduled
Planned to start on 1 January 2027. Clients get the certificate once the policy is in force.
Your data

Three phases, and in the last one we hold none of your data.

While we move your work and while we run the system, your data is on our servers in the European Union, in a system of your own, under the DPA. When the agreement ends, you take your data out and we delete it.

Phase 1 · the move

While we move your work

Before you sign, we study your live systems under the mutual NDA to write the scope. Then we move your work into your own system on our servers, and your people sign in there.

Where
Our servers in the EU
What
Structure and volumes first, then your data
Who
Named engineers and your named users, listed in the DPA
Phase 2 · for as long as your agreement runs

While we run it for you

After acceptance, your system goes live. We run it, monitor it and update it every week. Your people use it.

Where
Our servers in the EU, in a system no other company shares
What
Your data, under the DPA
Who
Named engineers, and your users with their own access
Phase 3 · after the agreement ends

After you leave

You have 90 days to take your data out, in open formats, free. Then we delete it and sign a certificate of deletion.

Where
Yours alone
What
Nothing
Who
Nobody at a-systems

After you leave, your data is not on our infrastructure at all, and a signed certificate says so.

Controls

What actually prevents incidents.

Breaches are stopped by mechanisms, not by policies. These controls are built into the code and the release process, so nobody can forget them under deadline pressure.

The merge gate

Nobody can change the main code directly, including us. A change goes in only after review, and only when every automated check passes: code style (lint), types, database schema, the full test suite and the build.

10,000+ checks · enforced by the platform, not left to people

Tests that can actually fail

We write the tests for money, tax and stock logic before the code. We also check that the tests can fail. A test suite that can never fail is worse than none, because people trust it.

Business rules tested, not only API endpoints

Every deploy records what it shipped

The deploy script records the exact version (commit) it published and reads it back on the next run. So anyone can see what is running without logging in to the server. To roll back, the same script redeploys a recorded earlier version. If the project’s own roadmap does not mark a release as shipped, the deploy stops until someone names it.

Releases through one script, never typed by hand on the server

Roles on the server

The person’s role is checked on the server, not only in the interface. So a restriction applies to a script just as it does to a person on screen.

Checked on the server · every change tied to a name

Integrations start in test mode

Every external connection has a real mode and a test mode (a sandbox), and a new environment starts in test mode. So loading your real customer addresses cannot accidentally send them emails or shipments.

Channels stay off until you switch them on

Secrets never go into the code

Passwords and keys are stored in settings on the server, with restricted access. The code records where a secret is kept, never the secret itself.

Scanned on every change

A failed release undoes itself

If a new release fails its health check, the deploy puts back the version that was running a minute earlier and stops with an error. On a client’s system, the database is backed up before every release, so the data can be restored too.

On every system since 19 September 2026

Your own AI, with one person’s rights

Your own assistant (Claude, ChatGPT, Claude Code or Codex) connects through MCP and signs in with OAuth. It works as the person who connected it, through the same server checks as that person’s screens, and only in the areas the person allowed: off, read, or read and change. Confirming an order or a purchase, winning a deal and posting an invoice wait for the person’s click in the system. Payments, stock moves, e-mail, deleting and settings are never open to it. It stays off until your administrator turns it on.

120 calls and 30 changes a minute at most, 500 changes a day
Subprocessors

Every company that could access your data.

This list applies for as long as we run your system. Services your business already uses, such as a courier, a tax service or a marketplace, connect with your own credentials and stay yours. So does the AI assistant you connect: it works under your own terms with its provider.

ProviderPurposeRegionHolds your business data
Hetzner OnlineServers and storage for your system, and the offsite copy of its backupsEUYes
Google WorkspaceThe alex@a-systems.pro mailbox, and since 25 September 2026 the service that sends the system’s own emailsGlobalWhat you send us by mail or at /start/, and the mail the system sends
ResendSends the scope read from /start/ by email, and is a backup sender for the system’s emailsUSAddresses and the emails themselves: a scope read, questionnaire answers and files
GitHubCode storage and the merge gateEU / USNo, code only
AnthropicWriting and testing code, and reading the requirements sent for a scope read at /start/USAs the purpose states

On the last row: the model is Anthropic’s Claude. It writes and tests the code, and it reads the requirements you send through the scope read at /start/, which are deleted after 30 days. If your policy restricts the use of AI tools, tell us at the first call.

Documentation

How the system is built, in one document.

For the engineer who reviews us before you sign. The architecture, the stack and the way out of each part, speed measured on real volumes, how data stays correct, security, AI access and the release process. We update it every month.

Technical overview
  • Architecture: one way in, and screens that never touch the database
  • One shared foundation, and a system of its own for each client
  • Speed measured on more than a million rows
  • Ledger rules the database itself enforces
  • Security, AI access, and how a change reaches production
Download the PDF Read it online English · A4 · updated every month
Shared responsibility

What we sign, and what we need from you.

We run the system, so most of the duties are ours. A few stay yours, and it is better to name them now than to discover them during an incident.

Ours

  • The mutual NDA, signed before we look at your systems: sign it here. It takes a minute, and our signature is already on it. The GDPR data processing agreement is signed with the contract, and you get the draft before that: ask for it
  • The servers your system runs on, their patching and their access list
  • The controls above, built into the system
  • Monitoring, backups and the weekly updates
  • Notice within 48 hours of becoming aware of a breach, and a written incident report within five working days
  • At the end, 90 days for you to take your data out, then its deletion and a signed certificate

Yours

  • Who has an account, and removing people when they leave
  • The devices and networks your people sign in from
  • Accepting the system against your scope, after the real working day

Send this page
to your toughest critic.

Ideally someone who has had a bad experience with a vendor. If they have a question this page does not answer, tell us, and we will add it.

Sign the mutual NDA Book a technical review The Project Engineer answers, not a help desk. The NDA takes a minute, and we have already signed it. The GDPR data processing agreement is signed with the contract. You get the draft at the call or by writing to alex@a-systems.pro.

Which business should the demo show?

Each one opens in a new tab. The data is invented and rebuilt every few hours. No call, no card.

Next: clinic groups and schools, on the same foundation.