Security & GDPR

An honest and complete account of how we handle your files, your account data and the data of the people who receive your downloads.

GDPR-compliant Storage in the EU (Amsterdam) TLS 1.3 in transit AES-256 at rest

Where are my files stored?

The specific location, the supplier, and how long they stay there.

Object storage

Files are stored on Backblaze B2, an S3-compatible object storage service in a European data centre (Amsterdam, the Netherlands). Backblaze is a US company, but our storage bucket is physically located in the EU and falls under European data sovereignty rules.

Your files are not stored or replicated outside the EU — they stay in the bucket in Amsterdam. The first three downloads of a transfer come straight from that bucket, and after that too as long as the free download traffic our storage provider gives us each month has not run out. Beyond that, and for the other downloads (such as from a shared folder), the file travels to the recipient via Cloudflare's network, through the server closest to them — and that server may be outside the EU. Cloudflare does not keep the files and does not cache them. In both cases the short-lived, signed link in the address is the only access: Cloudflare has no keys to the bucket. One exception to those first three: if the recipient's browser cannot build a zip of several files itself, our server in Frankfurt builds that zip, and it then also goes via Cloudflare.

Separate from your files: if you use one of our AI features, such as the weekly summary in the planning tool, we send the data you supply for it — and, for features that read a document for you, also the contents of that document — to Anthropic in the United States. We keep the response for at most thirty days, so the same question does not have to be asked twice. If you copy that response into something you keep yourself, it remains until you delete it.

Retention

For each upload you choose how long the link remains valid: 1, 3, 7, 14, 30, 60 or 90 days, or 'valid indefinitely'. On a free account 30 days is the maximum; 60 days, 90 days and 'indefinitely' belong to a paid plan or the one-off Pro trial, and on such a plan you can extend a package afterwards — via 'edit' or via the API — to up to 365 days. If the administrator of your business workspace has set their own maximum, that always takes precedence, even over 'indefinitely'. After this period, the files are physically deleted from the servers — not merely made inaccessible. A clean-up task sweeps through every few minutes, with an additional nightly check as a safety net. Along with the files, the package details, the recipients' email addresses and, as a rule, the download log of that package (time, IP address and browser of whoever downloaded) disappear too. Log entries containing an IP address that outlive the package — visits to the download page, blocked download attempts and download logs left behind during clean-up — are in any case kept for a maximum of 365 days. A link you have revoked yourself is not cleaned up automatically, so that you can undo it.

When a visitor opens an expired link, they see a tidy "expired" page. From that moment on, the site no longer issues any new download links, and nothing is left behind in a cache: our download proxy deliberately keeps no copies of files. One thing worth knowing: a direct download link fetched just before the expiry date remains valid until its own lifetime runs out — five minutes for a single file, up to six hours for "Download all" — and a download that has already started is allowed to finish. If you want a wrongly sent file shut down immediately, delete the package under "My uploads": we then remove the files from storage straight away, after which even a link already handed out yields nothing.

How are files protected?

Encryption, authentication and access control — specific, no marketing nonsense.

ComponentImplementation
Transport encryption TLS 1.3 (forced HTTPS, HSTS enabled, no TLS 1.0/1.1 allowed)
Encryption at rest AES-256 server-side encryption on the object storage
Download links Random token of 16 hex characters (64 bits), generated with secrets.token_hex(8). Older links with a 10-character token remain valid. The token is the access; in addition, a password and email verification of the recipient can be enabled per package.
Password hashing scrypt (n=32768, r=8, p=1) with a random salt per password. We store only the hash, never the password itself.
Password-protected downloads Optional per package. The password is hashed separately and checked server-side
Rate limiting Download and upload links: 30 failed attempts (unknown link or wrong password) per minute per IP, then no access for 5 min. Downloading and viewing online: each max. 60 times per minute per link + IP, then a 10 min pause. Logging in: 5 failed attempts per 5 min per IP, then locked for 15 min, plus a more generous counter per account.
Audit log All login events, password changes and account actions are logged with IP address and timestamp
CSRF protection Token-based on all state-changing endpoints
Session cookies HttpOnly, Secure, SameSite=Lax

Who can access my files?

The access model explained — who has technical and organisational access.

Your team

Users on your account (your subdomain) have access to:

  • Uploading from your subdomain (login required)
  • The overview of the whole team's packages via /uploads
  • Per package: copy the link, change the expiry period, delete
  • Anyone you make an administrator can additionally see, at /admin/inzicht, the download history of the entire account: for each download the time, the package and the file, the email address of the colleague who sent it, and the IP address and browser (user agent) of the recipient
  • That same administrator also sees the blocked download attempts there — time, package, sender, reason and the IP address — and can export the download history and the audit log as CSV; IP and user-agent appear as columns in that export

By default that overview shows the last 30 days and can be set from 1 to 365 days; the CSV export of one specific package contains the full download history of that package. Download and visit data containing an IP address is retained for a maximum of 365 days, after which it is erased automatically. The CSV export of the audit log also contains IP addresses: these are the login and account events of your own users, not of recipients. Bear this in mind when handing out administrator rights — an administrator can view the recipients of all colleagues on the account, not only those of their own packages.

Users of a different account (another Downloadlink customer) cannot see your files or packages. This does not work with a separate database per customer, but with a single database in which every package, file and piece of data is tied to the account that created it. Every query filters on that — including when editing and deleting, where we additionally check that the package really is yours. Guessing an id therefore gets you nowhere. What you share yourself is a different matter: anyone who has a download link from you can open that package — that is precisely what such a link is for.

One thing works differently, and we would rather tell you about it: if you use the AI features in the planning (the AI week overview and the AI planning proposal), we temporarily store the generated text in a cache that is not partitioned per account; anything older than 30 days is cleared out. A stored answer only comes back for exactly the same input — the same week, the same names, the same hours — so in practice only for your own planning. Your files and packages do not appear in it.

We (Downloadlink)

Technically, Downloadlink's administrators — currently one person — have access to:

  • The database (to manage accounts and to help with support questions)
  • The server logs (error diagnosis, security monitoring)
  • The object storage credentials — access, yes, but we do not open your files unless you yourself ask us to via support. A machine does read along with features you enable yourself: if you tick 'Cover note (AI)' on an upload, the file names and up to three PDFs from that package (up to 8 MB combined) are sent along; if you use the OCR tool, the pages you have recognised are sent along; and if you have the bookkeeping module, every receipt or invoice you upload or email in is read out automatically. That content goes to Anthropic in the United States, which reads it and returns the result. We store the cover note with the package and it disappears along with it, the data read from a receipt (supplier, date, amount, VAT, description) ends up in your own bookkeeping, and we keep none of the OCR text — it goes straight to your screen. If you do not use these features, nothing from your files goes to an AI party.

We are not in your files for any purpose other than that: no analytics on the content, no reselling. One exception, and it always starts with an action — by you, or by someone to whom you send a document for review. When an AI feature is used (the covering note with a package, the AI text check, recognising a scan (OCR), and in a business environment also the quotation assistant, the checking of calculations and the Word suggestions in a review), the content needed for it goes to Anthropic (Claude), with processing in the United States. Under Anthropic's terms, what we send via the API is not used to train AI models. We ourselves keep nothing extra from those features: the text check and scan recognition store nothing, and what the AI writes belongs to the piece it was made for — a covering note disappears with the package, a quotation with the quotation. Only the AI assistance in the planning (weekly summary and scheduling suggestions) has a cache: that response is kept by us for a maximum of 30 days. If no one touches an AI feature, nothing from your files goes to an AI party. This is set out in black and white in the privacy statement.

Sub-processors

To run the service we engage these sub-processors:

  • Render (application hosting, EU Frankfurt) — has no access to files, only to the application environment
  • Backblaze B2 (EU Central, Amsterdam) — object storage; files are encrypted at rest
  • Brevo (transactional email) — only for system messages (welcome, password reset, notifications); never the contents of packages
  • Cloudflare (network layer, global network) — protects the website against attacks and speeds it up, and passes on part of the downloads (see Object storage above); keeps no files and has no access to storage
  • Anthropic (AI processing, servers in the United States) — only comes into play with an AI feature you enable yourself; that feature does then get to see content

That last one differs from the other four and deserves explanation. If you switch on Cover note (AI) when sending, the names of your files are sent along plus up to three PDFs from the package — small files in full, only the first pages of large ones. If you have a scan read out in the PDF tools (OCR), the image of that page is sent along. If you use the AI assistance in the planning tool (weekly summary or planning proposal), the weekly figures are sent along: names of employees, their discipline and their hours. And in the business environment with document review, the pages to be reviewed or the text taken from them are sent along. If you use no AI feature at all, nothing goes to Anthropic and your content is stored only in the EU.

This is a transfer outside the EU. The same safeguards apply as for the other sub-processors — a data processing agreement with EU model clauses — and under Anthropic's commercial API terms your data is not used to train AI models. We ourselves keep only the result, not what we sent: a covering letter belongs to the package and disappears with it on the expiry date; we keep nothing from a scan that has been read; AI answers for the planning go into a cache that we keep to 30 days — with each new AI answer we delete whatever is older.

There are also parties that are independent controllers — they process data under their own privacy terms, not on our behalf:

  • Mollie and (for existing subscriptions) PayPal — payments
  • Google — only if you choose "sign in with Google", or if you arrived via a Google ad (cookieless conversion measurement: only a click ID and timestamp, no name or email address)

We conclude a data processing agreement with all of these parties. For your own records we can send you a data processing agreement between Downloadlink and your company — request one via contact.

What do we do — and what do we not do?

Managing expectations. No false promises, no concealed shortcomings.

What we do:

  • Encrypt files in transit (TLS 1.3) and at rest (AES-256)
  • Delete files automatically after the agreed period
  • Audit-log who logged in, when and to what
  • Rate limiting on brute-force login attempts and download attempts
  • HTTPS-only with HSTS (one year, including subdomains), strong ciphers
  • Offer a security.txt contact for responsible disclosure
  • Python libraries pinned to an exact, tested version, so that a deploy never silently brings in a new version; every change automatically runs through the test suite and a lint check. We update when a security advisory or a new feature calls for it — there is no fixed update schedule
  • Automated database backups (configurable per deployment, 14 days retention by default)

What we do not (yet) do:

  • Two-factor authentication — we do not offer it, and we are not putting a date on it. Signing in is done with an email address and password (at least 10 characters), and after too many failed attempts we block it temporarily — both per IP address and per account. Those who sign in with Google rely on the two-factor protection of that Google account; we do not offer that step ourselves. The email code a recipient sometimes receives for a download secures that one download, not your account
  • End-to-end encryption — we protect the entire transport chain, but technically we do have access to the files (as does every SaaS). E2E would make the tool unusable for your customers
  • SOC 2 / ISO 27001 certification — expensive for a small SaaS; we do implement the relevant security practices ourselves
  • Antivirus scanning on uploads — we do not block file types; responsibility lies with the recipient

GDPR: rights of data subjects

How you handle data requests from your customers to you (and your requests to us).

As the controller for your customer communications, you have rights and obligations under the GDPR. What we do to help you:

  • Access: you can view your own account data at any time via /account
  • Rectification: you change your email address and password yourself via /account
  • Erasure: you can delete your account via /account/delete — your account is deactivated immediately and your packages and files become unreachable; within 30 days everything is erased permanently. Exceptions: we keep invoices and payment data because of the statutory tax retention period (7 years) and security logs for no longer than 12 months
  • Portability: files can always be downloaded via the original links (as long as they have not expired); we supply account data in JSON format on request
  • Objection: stop using the service; you can cancel at any time via /account — your plan continues until the end of the paid period, after which you automatically fall back to the free 50 GB plan and your files simply stay where they are

For requests that are not self-service: email Patricklankhorst@hotmail.com. We respond within 5 working days, well inside the GDPR limit of 30 days.

Data breach procedure

What if something goes wrong — our duty and yours.

If a security researcher finds a vulnerability, or if we detect a data breach, we:

  • The vulnerability is closed or mitigated within 24 hours of discovery
  • You as the customer are informed by email within 72 hours about the impact and the data affected
  • Report to the Dutch Data Protection Authority where the GDPR requires it
  • Give you a report of what happened, how we resolved it, and what we are doing to prevent a recurrence

Security researchers can report vulnerabilities safely via the address in security.txt (RFC 9116).

Questions about security?

For IT coordinators, procurement or compliance people: ask your questions directly.

Mail security@

For responsible disclosure: see security.txt