Technical and organisational measures

1. Hosting and physical access control

The application, the database and the files run on a server of STRATO GmbH in Germany. Physical access to the data centre is controlled by STRATO. A data processing agreement pursuant to Art. 28 GDPR exists with STRATO; for the data centre, network and hardware, the technical and organisational measures of STRATO laid down in that agreement apply.

2. Access control

• Only the reverse proxy (Caddy) is reachable from the internet (ports 80 and 443). The application port is only bound to the server itself; the database is only reachable in the internal container network.
• The application runs in the container as an unprivileged user.
• Users sign in with e-mail address and password. Passwords are stored as salted hashes and are checked against rules for minimum length and common passwords. Registration and password reset are protected by a captcha.
• API keys are only stored as a hash and can be given an expiry date; API requests are rate-limited.
• Invoice files are never delivered directly by the web server, but only through download views that check the ownership, or through links that are bound to the document and the owner and are valid for five minutes.
• Administrative access to the application is restricted to staff accounts of the provider.
• SSH access to the server is only possible with a key.

3. Encryption

• All connections to the website and the API are encrypted with TLS (certificate from Let's Encrypt). HTTP is redirected to HTTPS; the browser is instructed to use only HTTPS for one year (HSTS). Session and CSRF cookies are only sent over HTTPS.
• Data at rest (database, files on the server) is not additionally encrypted by the application.

4. Separation of customer data

Customer data is separated logically: every invoice and every file is assigned to a customer account, and the application only shows and delivers data of the signed-in account. Generated files are stored under paths per customer and invoice. Download responses must not be cached and are delivered without a referrer.

5. Input control and logging

• Changes to the status and payments of an invoice are recorded in an audit log with time and acting user.
• Validations are logged with time and file name to count the quota.
• The access log of the web server is kept for 7 days and then deleted (rotation).
• Container logs (application and error messages) are rotated by size: at most 5 files of 20 MB each are kept, the oldest file is deleted.

6. Availability and backup

• The database and the invoice files are backed up together daily on the server. Each backup is checked (database dump, archive, checksums) before it is completed; backups are kept for 14 days. The restore procedure is documented.
• Additional encrypted backups at an external storage location are planned.
• The services restart automatically after a failure or a server restart. No specific availability is promised.

7. Deletion

Customers can delete individual invoices at any time. When a customer account is deleted, all invoices including their files, party templates and management data are deleted. Deleted data remains in the backups until they are deleted in the course of the rotation after 14 days.

8. Procedures for regular review

Changes to the application are made through reviewed change requests with automated tests. The measures are reviewed when the infrastructure changes and updated in this annex.