Security

The platform runs with established cloud providers. Processing and storage of your accounting material take place within the EU/EEA, and AI models are run within the EU. A small number of sub-processors may process data outside the EU/EEA; which ones, and on what transfer basis, appears in Annex C of the data processing agreement.

Data is encrypted at rest. For the most sensitive categories — bank connections, access credentials for the systems you connect, bank transactions, booking cases and commerce data — we use keys to which Storebook controls access itself, so that a key can be revoked independently of the underlying storage. The platform's other data is encrypted with keys managed by the cloud provider. Voucher files are encrypted in object storage.

The platform's automated workflows leave an execution history containing the data each individual run processed, which may therefore include bank and accounting data. The history sits in a private network with no access from the internet, is encrypted at rest, and is deleted automatically after 30 days.

All communication with the platform from outside takes place over TLS. Internal traffic between the platform's components runs within a private network with no access from the internet.

Each environment is separated, and production data is not used in development or test environments.

User authentication is handled by a dedicated identity service with support for two-factor authentication. Passwords are not stored in clear text.

Internal access is granted on a least-privilege basis and reviewed periodically. Each of the platform's components has its own permissions and can reach only the resources that particular component needs.

Access to the production environment is restricted to named employees with an operational need.

Access rights are reviewed every quarter, and any access no longer justified by an operational need is withdrawn.

Access keys, tokens and other secrets are held in a dedicated secret store and are never kept in ordinary application data or in source code.

Customer data is logically separated, and access to data is tied to each company's identity. The interfaces enforce this separation, so that a user cannot access another company's material.

We log security-relevant events and operational data, and monitor the platform for errors and abnormal behaviour.

Alerts are sent to an internal operations team. Log data is used for operation, troubleshooting and security — not for profiling.

Log data in production is retained for three months.

Regular backups are taken of production data, and stateful production resources are protected against accidental deletion. A prepared but not yet activated recovery configuration will copy protected database and object data daily to a separate account in another EU region and rotate the copies after 35 days.

For the production databases, continuous recovery is enabled: a recovery window of 35 days with a recovery point objective (RPO) of approximately five minutes. After the recovery configuration is activated, the regional copy will provide a nominal RPO of at most 24 hours plus copy completion time. A full recovery exercise has not yet been carried out, so we do not state a tested recovery time objective (RTO).

We have an established procedure for handling security incidents, covering containment, investigation, remediation and follow-up review.

If we become aware of a personal data breach concerning data for which Storebook is itself the data controller, we notify Datatilsynet (the Danish Data Protection Agency) within 72 hours where the GDPR requires it.

Where we act as your data processor, we notify you without undue delay after becoming aware of the breach, so that you can meet your own obligations. In that situation we do not report the breach to Datatilsynet and do not notify data subjects on your behalf — the assessment and the notification are your responsibility as data controller, unless otherwise separately agreed. See the personal data breach section of the data processing agreement.

Storebook uses sub-processors to provide the platform. The complete and binding list appears in Annex C of the data processing agreement, which states, for each one, the name, the purpose of the processing, the location and the basis for any transfer to a third country.

Sub-processors are used only under a written agreement imposing data protection obligations equivalent to our own. Material changes are announced in accordance with the data processing agreement.

Your own connected business systems are not sub-processors for Storebook. That applies to the accounting system e-conomic and to commerce platforms such as Shopify. The system is your own, under your own agreement with the provider in question, and Storebook accesses it as your agent, under your instructions. You can withdraw access at any time by disconnecting the connection in the portal. See Annex C of the data processing agreement.

Changes are reviewed before being deployed to production, and automated checks run on every change.

If you have found a security vulnerability, we would welcome hearing from you at philip@storebook.dk before the matter is disclosed publicly.

We confirm receipt within two business days and keep you updated until the matter is closed. We will not pursue legal action against individuals who, in good faith, investigate and report vulnerabilities without accessing other people's data or disrupting operations.