Technical and organisational measures
Draft, not verified legal information: this text hasn't been reviewed by a lawyer, and the operating company hasn't been confirmed yet. Open items are marked.
Status
This annex to the DPA describes the measures implemented in CastTool's code. So far they have been checked with automated tests in a local environment. Checks on a staging environment, an external penetration test, a load test and a restore drill are still due before launch. Organisational measures haven't been described yet and are marked.
Separating customers
- All customers share one database. Every row belongs to exactly one customer, and the database itself only allows rows of that customer (row level security, enforced even for the table owner).
- The application works with its own database roles that have no right to bypass these rules. If its role had that right, it would not start.
- For every table, an automated test with two customers checks that neither can see the other's data. It blocks any change that breaks this.
- Files are stored under a separate path for each customer.
Access and permissions
- Accounts are only created through sign-up with a confirmed email address or through an invitation. Invitations are valid for 7 days and once, and only their hash is stored in the database.
- Passwords have at least 12 characters and are only stored as a hash. A second factor is available and mandatory for platform staff.
- Roles per customer: owner, admin, model and client. A model only sees themselves, a client only their own lists and inquiries.
- The session only applies on app.casttool.net and never reaches customer websites. Every request that changes something checks its origin.
- The platform only accesses an account through a dedicated feature: with a second factor, for at most one hour, with a visible notice. Platform interventions are logged with the person and the target.
- For every interface it is defined who may call it. An automated test calls each one with the session of another customer.
Files
- Originals, documents and invoices are kept in private storage. Only what the customer has approved is public, and only a processed version of it.
- Uploads go into quarantine first. The content of the file is checked, not its extension. SVG is rejected.
- Metadata such as GPS is removed from images and videos before anything becomes public.
- Documents are only available through a short-lived download link, shorter for minors than for adults.
Transmission
- All connections are encrypted over HTTPS, between Cloudflare and the server with a verified certificate, TLS 1.2 or higher.
- Each surface has its own security headers and its own content security policy.
- Links in emails that trigger something are signed, expire and only take effect after confirmation on the page.
Protecting public forms
- Every public action has a limit per IP address and, where it makes sense, per email address. All that is stored for this is a key from which the address can't be worked out.
- Forms check on the server that a person submitted them (Cloudflare Turnstile).
- Emails to addresses from public forms contain no text from the form, so nobody can use them to write to strangers.
Traceability
- Model consents and parental approvals are recorded with the version of the text and the time in a log that only grows.
- Every version of the legal texts stays in the archive.
- Every outgoing email is logged, including every failed attempt.
Availability and recovery
- According to the operations documentation, the database is backed up daily and the files with restic, to a Hetzner Storage Box.
- A restore of the files was successfully tested on 2026-10-19.
- Up to 24 hours of data loss is possible. Recovery to any point in time is planned and not yet in place.
- open: location and encryption of backups, retention, restore drill for the database
Regular review
- Every change to the code goes through automated tests, including customer separation, the permissions of every interface and a scan for secrets in the code.
- An external penetration test is planned before launch. open: provider, timing, repetition
Organisational measures
open: commitment to confidentiality, who has access to servers and the database, handling of credentials, response to security incidents, protection of premises and data centres