Security

Everything on this page is a description of what the system does today, not an aspiration. Where we have not done something, it says so. Last updated 8 September 2026.

Your documents

• Uploaded files are encrypted at rest with AES-256-GCM, an authenticated cipher, so a modified file fails to decrypt rather than decrypting to something wrong.
• Files are stored under random identifiers, never under a name that reveals the document or the customer.
• Every request is served over HTTPS with HSTS, so a browser will not fall back to an unencrypted connection.

Accounts

• Passwords are stored as Argon2 hashes. We cannot see your password, and neither can anyone who obtains the database.
• Two-factor authentication (TOTP) is available on every plan at no extra cost.
• Each customer’s data is separated at the query layer, and that separation has its own automated test so a future change cannot quietly remove it.

Signing links

A recipient signs through a single-use link tied to that document and that person, with an expiry. There is no account to create and no password for them to lose. The link stops working once it has been used or has expired.

The evidence trail

Each event on a document - created, opened, signed - records who, when, from what IP address, an approximate location and the browser used. Every event carries the hash of the one before it, so altering any historical event breaks the chain visibly. The chain is verified before a document is sealed, and it is embedded in the evidence certificate the recipient receives.

Location is derived on our own server from a local database. No IP address is sent to a third party to be geolocated.

The seal

A signed document gets a PAdES signature (RSA-3072 with SHA-256) and an RFC 3161 timestamp. Change one byte of a sealed PDF and verification fails. Verification checks our seal specifically, by name - a document that arrived already signed by another party is reported separately, so another company’s signature can never be mistaken for ours.

A sealed document remains verifiable without us. If Pixasign disappeared tomorrow, the signature and its timestamp are still in the file and still checkable with standard tools. That is deliberate.

Backups

The database and the document storage are backed up nightly to Reykjavík, Iceland - a different provider, a different country and a different power grid from the live system, so one incident cannot take both. Both blobs are encrypted with a public key on our server before they leave it, and the private key that would decrypt them is never present on the backup host. The people storing your backups cannot read them.

Backups cover the document files as well as the database. A database restore on its own would give you a catalogue of documents that no longer exist, which is the sort of thing you discover at the worst possible moment.

Where it runs, and why there

Pixacomms Ltd is a UK company and Pixasign is built in the UK. It runs on Hetzner Online GmbH in Nuremberg, Germany, whose data centres are certified to ISO/IEC 27001:2022 (audited by SOCOTEC, scope covering Nuremberg). Backups sit in Iceland. Both are in the EEA, which the UK recognises as adequate.

Nothing is held in the United States, and that is on purpose. The US CLOUD Act lets US authorities compel a US-headquartered provider to produce data it holds anywhere in the world, regardless of where the server sits. Every major e-signature platform is a US company. Ours is not, and neither is our infrastructure, so that route does not exist. If you are a solicitor, accountant or agent who has ever had to answer a client asking where their documents live, that is the answer.

Sub-processors are listed in full in the data processing agreement.

What we do not claim

We would rather tell you this than have you find out during procurement.

• Pixacomms Ltd itself holds no ISO 27001 or SOC 2 certification. Our data centres are ISO 27001 certified, as above, but that is our host’s certification and not ours, and we will not present it as though it were. We are a small UK company and have not been audited against either standard.
• No contractual uptime guarantee on current plans.
• No penetration test by a third party yet.
• The signature is a advanced electronic signature, not a qualified one under eIDAS. A qualified signature requires a qualified trust service provider and identity verification to a prescribed standard. For the overwhelming majority of commercial documents an advanced signature with a strong evidence trail is what is needed and what stands up.

Telling us about a problem

If you find a security issue, email security@pixacomms.com. We will acknowledge within two working days. Please give us a reasonable chance to fix it before publishing, and please do not access anybody else’s data while testing.