Security shouldn't be a black box

Our security philosophy

We believe three things:

1. Security is a baseline, not a feature. It shouldn't cost extra. It shouldn't be locked behind enterprise tiers. Every Droplana account - including the free tier - gets the same encryption, isolation, and access protections.

2. Your data is your data. We don't sell it. We don't train AI on it. We don't share it with third parties beyond the strict minimum needed to operate the service.

3. You should be able to leave. If you ever stop using Droplana, you should be able to take everything with you cleanly. We do not lock you in.

Everything below is the operational expression of those three principles.

Data encryption

In transit

All connections to Droplana use HTTPS with TLS 1.2 or 1.3, managed by Caddy with automatic certificate provisioning and renewal. HTTP requests are automatically redirected to HTTPS, and we set Strict-Transport-Security headers to enforce HTTPS for one year, including subdomains.

At rest

Files are stored in S3-compatible object storage on Hetzner infrastructure in Germany (EU). Each file is held under an opaque, randomly generated identifier (a GUID) - never under your client's name, the original filename, or anything derived from the file's contents - so a stored object's key reveals nothing about who it belongs to or what it contains. The storage platform distributes each object across multiple servers for redundancy, runs in physically secured, access-controlled data centers, and destroys decommissioned disks on site.

On top of that infrastructure-level protection, files are encrypted at rest with AES-256, using a key that is unique to each client. When you upload a file, it's encrypted with a key derived specifically for that client - not a single shared key for your whole account, and not one key for the whole platform. No two clients' files are protected by the same key.

We're direct about what this does and doesn't defend against: it protects against someone gaining access to the storage layer alone - a Hetzner-side compromise, a misdirected disk, a leaked bucket. It does not protect against a compromise of the application server itself, since that's where the master key used to derive each client's key lives, next to the credentials that already reach storage. We won't claim more than that.

The PostgreSQL database runs on the same Hetzner infrastructure in Germany, with access restricted at the network and application layers. The database, application configuration (including credentials and encryption keys), and application logs all live on LUKS-encrypted disk volumes - an additional layer that protects that data if a physical disk is ever lost, stolen, or improperly decommissioned. Like other disk-encryption schemes, LUKS protects data at rest on the disk; it doesn't change what a compromise of the running application server could reach, which is why we still won't claim protection against an app-host compromise above.

What this means in practice

Your files never leave the EU, and they are never exposed on the public internet - every download flows through Droplana's access checks over TLS. Each client's files are locked with a key that belongs only to that client, so encryption at rest follows the same per-client boundary as the rest of the system (see Per-client isolation below). The people who can reach the underlying storage are the same infrastructure operators bound by our data processing agreement, in access-controlled facilities where retired disks are physically destroyed rather than resold.

Per-client isolation

This is one of Droplana's foundational design decisions, not a feature.

Every client portal you create is isolated by design. Each client gets their own access token (one per client) and their own portal sessions. Clients cannot see each other. They cannot see other clients' files, messages, or even know that other clients exist. Your dashboard is the only place where multiple clients are visible - and only to you.

Behind the scenes, every database query that touches client data is scoped to your business ID, which we read from your authenticated session - never from request URLs or bodies. There is no shared workspace, no inherited permissions to misconfigure.

That same per-client boundary extends to encryption: files uploaded for one client are encrypted at rest with a key derived only for that client (see Data encryption - At rest above), so isolation isn't just an access-control rule, it's built into how the files themselves are protected.

For lawyers and accountants who handle multiple clients with conflicting interests, this is the most important property of the system - and this page is often what they cite as their GDPR evidence when a client or auditor asks how their documents are protected.

Access controls

Your account (the business side)

• Authentication: we do not use passwords. You sign in either with a one-time magic link sent to your email address (valid for 15 minutes, single-use), or by signing in with your Google or Microsoft account. Both methods rely on a verified email address; neither involves a password we store.
• Sign in with Google or Microsoft uses the standard OAuth authorization-code flow with PKCE. The provider verifies your identity and returns your verified email address to us so we can log you in - we never receive or store your provider password, and we never send your account data, your clients' data, or your files to Google or Microsoft. In this flow they act as independent identity providers under their own privacy policies, not as our sub-processors. We accept a Google login only when the email is provider-verified, and a Microsoft login only when the email's domain ownership is verified.
• Why no passwords? Passwords are the most common cause of account compromise. By not having them, we eliminate that entire attack surface. Whichever method you use, your email account (or your Google/Microsoft account) effectively serves as the authentication factor - protect it with a strong password and 2FA there.
• Magic link tokens are 32 random bytes, never logged in raw form, and stored only as SHA-256 hashes in our database. The link can only be consumed once - using it invalidates it.
• Sessions last 31 days, with sliding renewal on activity. They can be invalidated by logging out.
• CSRF protection uses a double-submit cookie pattern on every state-changing request.

Your clients (the portal side)

You choose one of three security levels that controls how clients access their portal. New accounts start at Strict by default - you can opt down if your work doesn't require it:

• Strict (default) - email magic links only. Clients enter their email address, receive a short-lived link, and click through to verify. No shareable links of any kind. Right for sensitive materials - legal documents, financial data, NDA-protected work.
• Controlled - permanent links are not available. One-time links and email magic links only. A good middle ground for moderately sensitive work or clients you don't know as well.
• Relaxed - all link types available: permanent links (no expiry), one-time links (single-use, 7-day window), and email magic links. Right for everyday client work where strict access control is not needed. You can still send a one-time or email link whenever a specific exchange calls for it - Relaxed doesn't limit your options, it just leaves all of them open.

In all three cases: clients don't create accounts or set passwords. After verifying by email, their browser is remembered for 90 days (device token) so they don't re-authenticate on the same device. The access token (if used) is exchanged for a session cookie on first visit and removed from the URL, protecting it from browser history and referrer headers. You can revoke a client's access at any time - immediately invalidates their token and any active portal sessions.

Clients can also choose to sign in with Google or Microsoft - but only into a portal whose email address you have already added for them. OAuth matches the client's verified provider email to an existing client record; it never creates a new client. As on the business side, we send Google and Microsoft none of your data or your clients' data - they only confirm the client's email so we can open the portal that already belongs to them.

What we don't currently support

• Enterprise SSO (SAML / directory provisioning). You can sign in with a Google or Microsoft account (see above), but we do not currently offer SAML-based enterprise single sign-on or SCIM directory provisioning.

Rate limiting

We rate-limit sensitive operations to prevent abuse:

• Magic link requests: 3 per email address per 15 minutes
• Portal token exchange: 20 per IP per minute

Audit logging

We keep an audit trail of security-relevant events so we can investigate incidents, answer support questions, and meet our compliance obligations.

What we record

Audit events are grouped into categories:

• Account and authentication - login requests, successful and failed logins, logouts, account deletion, and changes to account settings.
• Access and sharing - access-token creation and revocation, and portal access by clients.
• Files - file uploads, downloads, and deletions.
• Messages and approvals - comments added, approval requests, and approval status changes.
• Team - member invitations, additions, and removals.
• Billing - subscription and addon lifecycle events (linked, activated, canceled, updated, payment failed).
• Security - rate-limit events.

Each entry stores the event type, a timestamp, the relevant account and object identifiers, and the originating IP address and user agent.

What we never put in audit logs

File contents, message and comment text, passwords, and payment card data are never written to the audit log. Magic-link and portal access tokens are never logged in raw form - they appear only as redacted placeholders.

How they're stored and for how long

Audit logs are structured records written to files on disk (via Serilog) on our EU infrastructure at Hetzner in Germany - the same EU-only hosting as the rest of your data. Older log files are compressed automatically and retained for 24 months, then permanently deleted. Because audit logs are a security and legal-compliance record, they sit outside the account hard-delete: deleting your account removes your business and client data from the database and object storage immediately, while any audit entries already written age out on the 24-month schedule.

Hosting and infrastructure

Where your data lives

Droplana is hosted in the European Union. Our application servers, PostgreSQL database, and S3-compatible file storage are all hosted on Hetzner in Germany. Transactional email is sent via Brevo in France.

Why this matters

For European customers, data residency is a real concern under GDPR. Your data does not leave the EU.

For non-EU customers, EU hosting still provides strong privacy protections - generally stronger than the alternatives.

Backups

We rely on managed backups provided by Hetzner, our infrastructure host in Germany. Backups are used for disaster recovery only, are not user-accessible, and expire on the schedule defined by our host. Specific backup configuration details are available on request - please email security@droplana.com if you need detailed information for your own compliance review.

Uptime

We don't make a contractual SLA commitment at this stage. We monitor uptime continuously via a public health check and address issues quickly. As the service matures, we'll publish historical uptime numbers based on real data rather than aspirational targets.

Service monitoring

We log application activity using Serilog with daily log rotation. We expose a public health-check endpoint (/health) for uptime monitoring.

Privacy and your data

What we collect

We collect the minimum data needed to operate the service:

• Account information: your email address, your account slug, account creation timestamp.
• Files and messages: files you upload to client portals, comments between you and clients, and per-file status updates.
• Operational metadata: download events (when a client downloads a file), seen/unseen state of comments, and timestamps.
• Audit logs: security-relevant events across account, file, message, approval, team, and billing activity - for security and compliance purposes. Retained for 24 months. See Audit logging for the full list and what we never log.
• Billing information: processed by our payment provider (Creem), not stored on our servers. We receive only the metadata we need (subscription status, invoice IDs, etc.).

What we don't do

• We don't sell your data. Not to advertisers, not to data brokers, not to anyone.
• We don't train AI models on your data or your clients' data.
• We don't share your data with third parties for marketing purposes.
• We don't access customer content except where required for support with your explicit permission or legal obligation.
• We don't run external analytics or tracking scripts. No Google Analytics, no Hotjar, no third-party trackers - our only visibility into how the product is used comes from server logs needed to operate the service.
• We never log raw authentication tokens. Magic-link tokens and portal access tokens are logged only as redacted placeholders.

What third parties touch your data

A short list, kept current:

• Payment processing: Creem.io - Armitage Labs OÜ (Merchant of Record, Estonia EU). Creem handles all card processing, invoicing, VAT and sales tax compliance globally. They store customer billing data; we receive only the subscription/invoice metadata we need.
• Transactional email: Brevo (Sendinblue SAS, France). Used for sending magic links and account-related emails. They process email content in transit.
• Application server, database & file storage: Hetzner Online GmbH (Germany). Hosts our application, PostgreSQL database, and S3-compatible object storage in EU regions.
• Web infrastructure: Caddy reverse proxy with automatic TLS via Let's Encrypt.
• Code hosting: GitHub (US). Source code only - no customer data.

Each provider is selected for its own privacy posture and is bound by appropriate data processing terms.

Optional sign-in providers - Google and Microsoft - are not on this list, because they don't process your data. If you choose to sign in with Google or Microsoft, that provider verifies your identity and returns your verified email address to us. We send them none of your account data, your clients' data, or your files. They act as identity providers under their own privacy policies, not as sub-processors. Email magic-link sign-in remains available and involves no third-party identity provider at all.

Your rights (especially under GDPR)

You have the right to:

• Access the data we hold about you - exercised via Account → Export data, which provides a complete JSON export of your business, all clients, all files (with metadata, sizes, statuses), all comments and seen state, all download events, and all invoice records.
• Correct any inaccurate data - most fields are editable directly in the dashboard.
• Delete your account and your data - exercised via Account → Delete account. This performs an irreversible hard delete: all your business data, all client data, all files in object storage, comments, events, sessions, magic links, and subscription/invoice records are removed in a single operation.
• Export your data in a portable format (JSON).
• Object to processing in certain cases.

We respond to GDPR requests within 30 days, as required by the regulation.

Personal data and download events

Per GDPR, file download events linked to a client's portal session count as personal data. We include them in your data export and delete them entirely when you delete an account or a client.

Compliance

GDPR

We are GDPR-compliant in our handling of EU data. Key compliance practices:

• EU data residency (Germany)
• No third-party analytics or marketing tracking tools
• Data subject rights honored within 30 days
• Hard-delete on account deletion - no soft-delete trash
• Structured JSON export available on demand
• Item events (downloads) treated as personal data in exports and deletions
• Clear list of subprocessors in this document

Our Data Processing Agreement (DPA) is published in full. Customers with formal procurement processes can also request a counter-signed copy at security@droplana.com.

What we don't (yet) have

We're transparent about this:

• We are not currently SOC 2 certified. Common for early-stage SaaS; on the roadmap as we grow.
• We are not currently ISO 27001 certified. Same.
• We are not HIPAA-certified. Droplana is not appropriate for protected health information (PHI) - please use a HIPAA-compliant tool for that work.
• We are not specifically certified for FINRA or other US financial regulatory frameworks.

For regulated industries

If your work requires specific certifications (HIPAA in US healthcare, FINRA in US finance, certain bar association requirements for legal record-keeping, etc.), please confirm Droplana fits your specific obligations before signing up. Contact us and we'll walk through what we do (and don't) do - honestly, before you commit.

What you can do to protect your account

Security is a shared responsibility. Here's how to maximize the security of your Droplana account:

• Protect your email account. Because we use magic-link authentication, your email account is your authentication. Make sure it has a strong password and 2FA enabled.
• Don't share your email login credentials. If a colleague needs to co-manage your Droplana workspace, invite them as a team member from the Team page - that's what it's for. Team access is available on the Practice and Studio plans.
• Match your security level to the sensitivity of the work. Your account starts at Strict (email-only), which ensures only the verified email holder can access the portal. If your work is less sensitive, you can switch to Controlled (one-time and email links, no permanent links) or Relaxed (all link types) from your account settings.
• Revoke and regenerate portal tokens when needed. If you suspect a portal link has been compromised, you can revoke and regenerate it from the client's share page. The old link will stop working immediately.
• Delete clients you no longer work with. Cleaner than leaving stale portals. The full delete removes all their files, comments, events, and access tokens.
• Review your client list regularly. Once a quarter, scan and clean up.

Legal requests and law enforcement

We comply with valid legal process - court orders, subpoenas, and law enforcement requests - under Croatian and applicable EU law.

What we do:

• Where legally permitted, we notify the affected account holder before disclosing their data.
• We disclose only what the legal process specifically requires - no more.
• We will challenge requests we believe are overbroad, legally deficient, or not supported by applicable law.
• All law enforcement requests are handled by Ubique d.o.o. under Croatian jurisdiction, consistent with GDPR Article 6(1)(c) (compliance with a legal obligation).

What this means for you:

• We do not voluntarily share your data with governments or law enforcement absent a valid legal order.
• We keep records of legal requests we receive, to the extent we are legally permitted to do so.
• We do not provide back doors, encryption key access, or live surveillance of user activity to any party.

Law enforcement requests should be sent to legal@droplana.com and must identify the specific account, the legal authority, and the precise data sought.

Reporting abuse or illegal content

If you become aware of illegal content or misuse of the Service - including child sexual abuse material, fraud, phishing content, or malware - report it immediately to abuse@droplana.com.

We act on all abuse reports without delay. Where required by law, we report illegal content to relevant authorities.

Reporting a security issue

If you believe you've found a security vulnerability in Droplana, please email security@droplana.com with details. We take all reports seriously and aim to respond within 72 hours.

We do not currently offer a paid bug bounty, but we deeply appreciate responsible disclosure and will publicly credit researchers who report valid issues (with their permission).

Please do not publicly disclose vulnerabilities before we've had a reasonable opportunity to fix them.

Frequently asked questions

Is Droplana suitable for highly sensitive work (legal, financial, medical)? For sensitive document work - contracts, financial statements, NDA materials, case documents - use the Strict security level: clients access their portal only via email-verified magic link, with no shareable links of any kind. This ties access to email inbox control. For specifically regulated work requiring certified record-keeping (e.g., HIPAA-protected health information, SEC-regulated financial communications), please confirm your specific obligations before signing up - we're happy to walk through what Droplana does and doesn't do.

Can I delete my data? Yes. You can delete individual files, delete entire client portals, or delete your full account at any time. Account deletion is irreversible - we do an immediate, complete hard delete: all files in object storage, all comments, all download events, all sessions, all subscription metadata. There is no "deleted accounts" trash.

Can I export my data? Yes. The Account page includes "Export data", which produces a complete JSON export of your business, all clients, all files (with metadata, sizes, statuses), all comments and seen state, all download events, and all invoices. This is available on every plan, including Free.

What happens if I stop paying? When a paid subscription is canceled (by you, or due to repeated payment failure), you keep full access until the end of your billing period plus a 15-day grace period. After that, you return to free-tier limits - your account stays open, but you'll be limited to your free-tier client count. If you're over the limit at that point, we keep your most recently created client and remove the rest.

Do you have a Data Processing Agreement (DPA)? Yes - see the DPA linked under Compliance above. A counter-signed copy is available on request - email security@droplana.com.

Are clients' files visible to other clients? No. Each client portal is isolated by architecture. There is no shared workspace model. Each business has its own subdomain (yourname.droplana.com), so portal session cookies are domain-scoped at the browser level - a session for one business cannot reach another. As an additional layer, we verify client ownership on every portal request so that even within a subdomain, one client's session cannot access another client's files.

Are files encrypted at rest, not just in transit? Yes. Beyond TLS in transit, files are encrypted at rest with AES-256, using a key that's unique to each client - derived specifically for that client, not shared across your account or the platform. The database, application configuration, and logs also sit on LUKS-encrypted storage. We're upfront that the per-client file encryption defends against a storage-layer compromise, not an app-host compromise - see Data encryption above for the full picture.

Where is my data stored? In the European Union - on Hetzner infrastructure in Germany. Application servers, PostgreSQL database, and S3-compatible file storage all reside in EU regions. Transactional email is delivered via Brevo (France).

Do you sell my data? No. Never.

Do you train AI models on my data? No.

Do you use Google Analytics or other tracking? No. Droplana does not run external analytics scripts or trackers. Our only product-usage visibility comes from server logs needed to operate and secure the service.

If I sign in with Google or Microsoft, do you share my data with them? No. Signing in with Google or Microsoft is an optional alternative to the email magic link. When you use it, you authenticate directly with that provider and it returns your verified email address so we can log you in. We never send your account data, your clients' data, or your files to Google or Microsoft, and they are not sub-processors of your data - they are identity providers acting under their own privacy policies. You can always use email magic-link sign-in instead, which involves no third-party provider.

What audit logging do you keep? We log security-relevant events using structured logs: account and authentication events (login requests, successful and failed logins, logouts, account deletion, settings changes), access and sharing events (token creation and revocation, portal access), file events (upload, download, deletion), message and approval events, team-member changes, billing lifecycle events, and rate-limit hits. We never log file contents, message text, passwords, or raw tokens. These logs are retained for 24 months and are for our internal security and incident response - not currently exposed in the user dashboard, but available on request if you have a specific compliance need. See the Audit logging section above for full detail.

One more thing

Security pages tend to be either reassuring fluff or impenetrable jargon. We've tried to write something honest, plain, and useful - closer to how we'd explain it on a call than how legal would write it.

If you have specific questions this page doesn't answer, email us at security@droplana.com. A real person will respond.

Trust isn't built by claiming everything. It's built by being clear about what's true.