Security policy

This policy describes the technical and organisational measures by which the operator protects personal data and the other data in the service under Article 32 GDPR. It is the annex of the data processing agreement and part of the terms of service.

The data processing agreement is on the page Data processing agreement.

The service runs in Microsoft Azure: the application in Azure App Service, the database in Azure SQL and files in Azure Storage. The data and its backups are stored in Microsoft Azure, region West Europe (the Netherlands); geo-redundant backups in North Europe (Ireland). Microsoft is our processor under the data processing agreement.

The application accepts HTTPS connections only and tells browsers to connect to it only encrypted for a year (HSTS, subdomains included). The application's connection to the database is encrypted, and the database accepts TLS 1.2 at least.

Every record that belongs to an account carries its identifier. The application reads only the data of the account the user works in, and the database enforces it itself by row-level security: a query with no account set sees nothing and writes nothing.

Database triggers protect issued documents and their files from being changed or deleted.

• Users sign in through Microsoft Entra External ID and may turn on two-step sign-in; its secret is stored encrypted and recovery codes only as hashes.
• The sign-in is held by a cookie only the server can read (HttpOnly).
• An account has the roles owner, write and read, read only and accountant; a person can be limited to some sections.
• The operator looks into an account only with support access its owner grants, for 7 days at most and read-only; every look is written to the account's audit log.
• The administration of the service opens only to a person with the operator role given in the application's registration at the sign-in provider.
• Only a Microsoft Entra ID identity signs in to the database, never a password. The application may only read its own secrets from the key vault and use its own key.

Passwords, keys and credentials for other services are kept in Azure Key Vault, never in the source code; the application reads them from there at run time. The key by which the application protects its data is in Key Vault too.

Every response carries security headers: a Content Security Policy with a one-time key for scripts, no framing by another page, no guessing of content types, a limited referrer and no camera, microphone or location.

Public links to documents, receiving e-mail, delivery reports, the price list, events from the payment platform and the registration of API applications limit the number of requests from one address. The API has the request limits its documentation states.

Every account has an audit log: who issued, changed or sent what, and when. Technical records of operation and errors are kept 30 days.

The database is backed up continuously to geo-redundant storage and can be restored to any moment of the last 7 days. Files are kept in geo-redundant storage with versions: a file's previous version is deleted 30 days after that version was written, and a deleted file can be restored for 7 days. Before every change of the database's structure, the moment to restore it to is recorded.

We notify the owners of the account concerned of a breach of personal data we process for users without undue delay, within 48 hours of discovering it at the latest. Where we are the controller, we notify the Czech Office for Personal Data Protection within 72 hours, unless the breach is unlikely to result in a risk to people's rights.

The list of sub-processors and how it changes are in the data processing agreement and the privacy policy.

We update this policy when the measures change; the version with the effective date above applies.