Sunset Docs
PricingSecurityBlogSign inStart trialENESFRDEIT
Security

How Sunset Docs protects documents

Last updated: 15 August 2026

Sunset Docs is designed to reduce unnecessary document copies and limit how long active files remain available. This page describes the controls we use and their practical limits. It is not a certification or a guarantee that every threat can be prevented.

Contents

  1. 1. Shared responsibility
  2. 2. Accounts and workspace access
  3. 3. Encryption and storage
  4. 4. File intake and malware checks
  5. 5. Viewer and download boundaries
  6. 6. Scheduled and manual deletion
  7. 7. Backups and recovery
  8. 8. Operational controls
  9. 9. Security incidents
  10. 10. Limits outside Sunset Docs
  11. 11. Report a vulnerability

1. Shared responsibility

Sunset Docs protects the service and the data it processes. Customers remain responsible for having a lawful reason to collect each document, choosing an appropriate deletion date, controlling workspace membership, and protecting copies downloaded or kept outside the service.

Using Sunset Docs does not by itself make a customer compliant with the GDPR or another legal or industry requirement.

2. Accounts and workspace access

Every document request is checked against the signed-in user's workspace membership. Workspace owners control member access and original-download permissions. Two-step verification is available to every account and is required at sign-in after it has been enabled.

Passwords are hashed with Argon2id. Sessions expire after seven days and use Secure, SameSite cookies, CSRF protection, and server-side revocation. Password reset revokes existing sessions.

3. Encryption and storage

Document originals, previews, and generated copies are encrypted by the application with AES-256-GCM before storage. Each document has its own data key, and the key is wrapped separately with the service master key.

Active encrypted objects are held on private Hetzner infrastructure and mirrored to a private Cloudflare R2 bucket. Public object URLs are not used, and storage paths do not contain customer filenames. TLS protects data in transit.

4. File intake and malware checks

Supported files are checked by content, placed in quarantine, and scanned before they become available. Password-protected, malformed, unsupported, or suspicious files are rejected. Quarantine files are not served by the web application.

Malware scanning and validation reduce risk but cannot detect every harmful file. A successful scan is not proof that a file is safe or genuine.

5. Viewer and download boundaries

View-only mode serves generated page images rather than the original file. Page, print, and original requests use short-lived signed authorisation and restrictive cache headers. Viewer watermarks identify the signed-in user and time.

Anyone who can see a document may still photograph or capture the screen. Printing may create another copy. Workspace owners can separately allow original downloads.

6. Scheduled and manual deletion

Every document has a deletion date. Scheduled or authorised manual deletion removes active originals, previews, temporary print output, wrapped keys, filenames, sender details, and other sensitive metadata from local storage and R2.

A minimal non-content record remains for 12 months. It records that deletion occurred but does not keep the document, filename, or sender identity.

7. Backups and recovery

Encrypted database backups are isolated from ordinary application access and expire within 30 days. If deleted data remains in a protected backup residual, it is not restored for ordinary customer access and expires with that backup.

The R2 object lifecycle is a safety limit. The application deletion job is responsible for enforcing each document's exact deletion date.

8. Operational controls

The application runs behind a reverse proxy, document storage sits outside the public web root, and material document actions are logged. Production access is restricted to people who need it to operate or secure the service and who are subject to confidentiality duties.

Transactional emails contain no document attachments, filenames, previews, sender identity, or links that grant document access. Inbound document email is received directly by Sunset Docs and attachments are removed from mail processing after intake.

9. Security incidents

We investigate suspected incidents, contain confirmed issues, preserve the evidence needed for the investigation, and notify affected customers without undue delay where customer personal data is involved. We provide information in phases if all details are not yet available.

10. Limits outside Sunset Docs

Email intake cannot remove copies already held in a sender's Sent folder, mail server, backup, or another external system. Deleting a document from Sunset Docs does not delete copies that a customer or another person downloaded, printed, photographed, or stored elsewhere.

11. Report a vulnerability

Send security reports to [email protected]. Do not include personal documents or customer information. Do not access data that is not your own, disrupt the service, or use social engineering. If you encounter customer data, stop and report only the minimum information needed for us to investigate.

Related documents

Privacy · Terms · DPA · Subprocessors · Security

Sunset Docs

Temporary intake for sensitive documents.

BlogSupportPrivacyDPASubprocessorsTermsRefundsCookiesLegal noticeSecurity