Dropwarden

Legal and security documents

DRAFT — requires lawyer review. Not legal advice.

Dropwarden Security Overview

Last updated: TBD

This page describes how we protect your files and account data. It is written to be accurate rather than impressive: where we have not built something yet, we say so. For contract terms, see the Data Processing Addendum, whose Annex II lists the same measures.

Security questions or questionnaires: [email protected]. Vulnerability reports: [email protected] (see our Responsible Disclosure Policy).

Architecture in one paragraph

Dropwarden runs on a single compute instance in Oracle Cloud Infrastructure, region us-sanjose-1. That instance runs the SFTP/FTPS server, the portal and web file client, the API, the notification engine, the malware scanner and the database. Files are stored in Cloudflare R2 object storage, never on the instance's disk except while a large web upload is being assembled. Card payments are handled entirely by Stripe. Emails are sent through Amazon SES. The full list of providers is on our Subprocessors page.

Availability: what to expect

  • We operate the Service with a 99.5% uptime target (no high availability).
  • There is one compute instance. If it fails, the Service is down until it is repaired or rebuilt. Our documented rebuild procedure targets restoring service in under one hour, and we rehearse it.
  • Your files are stored in object storage, separate from the compute instance, so an instance failure does not lose stored files.
  • We patch the operating system in a monthly maintenance window, which may cause a short interruption. Urgent security patches are applied sooner.
  • Live status and incident history: https://status.dropwarden.com.
  • We publish the static IP address of the Service so you can allowlist it, and give at least 90 days' notice before changing it.

If your use case needs redundant infrastructure, ask us about a dedicated instance.

Encryption

  • In transit: HTTPS with TLS 1.2 or later only. SSH with modern key-exchange algorithms and ciphers only; user keys must be ed25519 or RSA with at least 3072 bits. FTPS uses explicit TLS only, and plain FTP is disabled.
  • At rest: all stored files are encrypted by the storage provider. Block volumes are encrypted. Sensitive fields in our database (for example 2FA secrets, webhook URLs and signing secrets, and third-party credentials) are additionally encrypted by our application with envelope encryption. Platform secrets are kept in Oracle Cloud Infrastructure Vault.
  • Backups: nightly database backups are encrypted before they leave the instance and stored in a separate bucket with a separate credential. The decryption key is kept offline.

Tenant isolation

  • Each organization's files live under their own storage prefix (or their own bucket, for organizations with S3 API access). Users are confined to their organization and to the folders they are granted.
  • Every request is authorized twice: by our control plane and again by the file server's own permission configuration. The portal is never trusted on its own.
  • An automated test suite tries to read, write and list another organization's files over SFTP, FTPS, the web client and the API. It must pass before every release.

Identity and access

  • Your users: roles (owner, admin, member, partner, viewer) and per-folder permissions; SSH keys (recommended) or passwords if your organization allows them; TOTP two-factor authentication, which owners can make mandatory; sign-in with Google or Microsoft; single sign-on on plans that include it; IP allowlists on plans that include network rules.
  • API keys: scoped to one organization, revocable, shown once and stored only as a hash.
  • Brute-force protection: repeated failed logins lead to automatic IP bans; APIs are rate-limited.
  • Our staff: multi-factor authentication is mandatory. Access is least-privilege and reviewed every quarter. Support staff see account metadata only. They can see file contents only inside a support session that an owner of your organization grants, which lasts at most 7 days, can be revoked at any time, and is recorded in your audit log.
  • Administrative access to servers goes through a managed bastion. Internal services and the file server's admin interface are never exposed to the internet.

Audit log and privacy by design

  • Every upload, download, delete, rename, folder creation, login (successful or failed) and administrative change is written to an append-only audit log with who, what, when, IP address and protocol. The application cannot edit or delete audit entries; they are removed only when your plan's retention period ends or your organization is deleted.
  • A "read" means a completed download. SFTP has no "opened" or "viewed" event, and directory listings are not recorded as reads.
  • We never log file contents.
  • You can turn on filename redaction so that notification emails, chat messages and webhooks do not include file names.
  • Audit logs can be exported as CSV, and on plans that include it, streamed to your own systems.

Notifications and webhooks

  • Outbound webhooks are signed with HMAC-SHA256 and a timestamp so you can verify them.
  • Webhook destinations must use HTTPS. We block private, loopback, link-local and cloud metadata addresses, do not follow redirects, and send from our published static IP.

Malware and abuse

  • Uploaded files are scanned for known malware automatically. Matches are quarantined and organization admins are notified. Very large files may not be scanned; scanning is not a guarantee.
  • We can freeze an organization that is used for abuse. See the Acceptable Use Policy.

Data retention and deletion

  • Trial organizations that do not subscribe are locked after 7 days and permanently deleted 90 days after the lock. Locked paid organizations are deleted 90 days after the lock. Owners receive warning emails before deletion and a confirmation afterwards.
  • Deletion removes files, versions, users, credentials, rules and audit log. Encrypted database backups expire within 35 days.
  • Owners can export organization data, the audit log and files at any time, including while locked.

Secure development and operations

  • Every change goes through a reviewed pull request. Automated checks run on every change, including secret scanning. Changes to authentication, storage paths, billing or deletion require an additional security review.
  • Dependencies and container images are scanned weekly.
  • We maintain written security policies (access control, change management, incident response, backup and continuity, vendor management, encryption, logging, vulnerability management and others) and keep evidence of the controls they describe.
  • Incidents follow a documented response plan. If a security incident affects your data, we notify your organization's owners without undue delay, as set out in our DPA.

Compliance status

  • GDPR and UK GDPR: GDPR-ready, DPA available. Our DPA includes the EU Standard Contractual Clauses and the UK Addendum. Organizations can be configured to store files in the EU (see the Subprocessors page for what that covers).
  • CCPA/CPRA: we act as a service provider for customer data and do not sell or share personal information.
  • Accounting and tax firms: see how the Service helps you meet the FTC Safeguards Rule on our Safeguards Rule support page.
  • Payments: card payments are handled by Stripe. We never see or store card numbers.
  • Certifications and audits: We do not currently hold a SOC 2 report or an ISO 27001 certification. We maintain policies and evidence aligned with common frameworks and can answer standard security questionnaires.
  • Health data: We do not currently sign Business Associate Agreements (BAAs) under HIPAA, so do not store protected health information in the Service.
  • Cardholder data: the Service must not be used to store payment card numbers (see the Acceptable Use Policy).