Security, access and data handling

Security at a glance

Droplana is a client document portal for professional service businesses. Each client gets a private portal for two-way file exchange, with per-file comments and PDF signing. Encryption, client isolation and the access levels are the same on every plan, including Free. We don't sell your data or train AI models on it, and you can export your data and leave at any time. The table shows what each protection covers and where it stops.

Check	What Droplana provides	Boundary
Storage	Files, comments and metadata on Hetzner infrastructure in Germany; EU operator Ubique d.o.o.	Client downloads and independent identity, email, payment and font requests are separate data flows.
Encryption	TLS in transit and AES-256 file encryption with a key derived per file	Not end-to-end encryption; an app-host compromise can reach the master key.
Access	Separate client portals and verified access by default	Your business team shares client access; multiple contacts on one client share its documents.
Records	File exchange, an owner-exportable activity trail and signing records	Not certified record keeping, a legal hold or a permanent archive.
Contract	A published DPA on every plan	Hosting and a DPA do not establish that your entire workflow meets its legal obligations.

The DPA defines processing terms and excluded uses. The Privacy Policy explains personal-data handling. The Cookie Policy covers cookies and browser storage. These documents should be read together.

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 file. When you upload a file, it's encrypted with a key derived specifically for that file - not a single shared key for your whole account, and not one key for the whole platform. No two files are protected by the same key, so no two clients' are either. Files uploaded before September 2026 use a key derived per client by the same method, which is the same guarantee at a coarser grain.

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 file'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

Stored files remain on Hetzner infrastructure in Germany. Authorized downloads use access checks and HTTPS; the recipient can then keep a copy wherever they work. EU storage does not mean every subsequent use of a downloaded file stays in the EU. Each file is locked with its own key, so encryption at rest is at least as fine-grained as the per-client boundary the rest of the system uses (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

A client session can access its own portal, not other clients' files or comments. This is a client boundary, not a separate permission setting for each document.

Person	Access
Business owner	The business's clients and documents, billing, team administration and activity export.
Business team member	Shared access to the business's clients, files, comments and statuses; no billing or team administration.
Authorized client contact	That client's portal, including documents shared with other contacts of the same client.
Another client	No access to this client's portal.

Practice supports 5 seats including the owner; Studio supports unlimited seats. Free and Solo have only the owner's seat. Droplana has no per-member client assignments, ethical walls, restricted matter teams or per-file access rules. If those are required, client isolation alone is insufficient.

For workflow examples with these boundaries, see legal document exchange and accounting document collection.

The application scopes access to the authenticated business and client. File encryption uses a key derived per file, as described under encryption at rest.

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. Neither involves a password we store.
• Sign in with Google or Microsoft uses the standard OAuth authorization-code flow with PKCE. The provider authenticates its account and tells us which account signed in - we never receive or store your provider password, and the sign-in flow does not send your stored client documents to Google or Microsoft. Their handling of sign-in requests is governed by their own privacy policies. We accept a Google login only when the email is provider-verified, and match it to your account by that email. A Microsoft login is never matched by the email address the Microsoft account shows: we recognise the Microsoft account itself (its issuer and account identifier). The first time, you connect it to your Droplana email address by typing a 6-digit code we send to that address, in the same browser. After that, the Microsoft account opens everything that address has on Droplana, as Google or an emailed link does, and we email you each time a Microsoft account is connected to your address. Personal, work and school Microsoft accounts are accepted.
• Why no passwords? Droplana does not store a password for you to reuse or reset. Sign-in still depends on protecting your email and identity-provider access. 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) - clients verify an authorized email on a new device. Email magic links, verified Google access and connected Microsoft access support an identified session. Permanent and one-time bearer access links are not available. This verifies access to an authorized address, not the person's real-world identity or permission to process any category of document.
• Controlled - permanent links are not available. One-time links and email magic links only. An option 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 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 that already exists for them. Google matches the client's verified email to an address you have already added for them. A Microsoft account works for a client only after it was connected once: the client confirms one of the addresses you added for them with an emailed 6-digit code. The portal then keeps identifying them by that address, including for signing. Neither method ever 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 who signed in 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:

• Business magic link requests: 3 per email address per 15 minutes, and 5 per IP address per hour
• Client portal magic link requests: 3 per email address and 5 per IP address per 15 minutes
• Portal token exchange: 20 per IP address 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.
• Comments 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, 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.

Your own exportable activity trail

The audit log above is our internal security record, not something you browse yourself. Separately, as the business owner you can view and export your own activity trail - logins, portal visits, uploads, downloads, deletions, comments and approvals across your account - from Account → Activity, as a CSV, scoped to your own business only.

Hosting and infrastructure

Where your data lives

Application servers, the PostgreSQL database, files, comments and metadata are hosted on Hetzner infrastructure in Germany. Ubique d.o.o., Croatia, operates Droplana. Brevo in France handles transactional email; Creem, an Estonian Merchant of Record, handles billing.

Why this matters

Hosting location, company location and the processing of individual requests are different questions. Client downloads, sign-in providers, payment services, email delivery and browser font requests have their own data flows. Do not read Germany hosting as a guarantee that no request ever reaches a provider elsewhere. The current processor and transfer terms are in the DPA provider annex and Privacy Policy.

Backups

Infrastructure backups are for disaster recovery, not a user-accessible file archive. Their expiry follows the infrastructure-defined schedule. For backup configuration evidence relevant to your review, contact security@droplana.com. Keep independent records when your work requires them.

Uptime

Droplana does not make a contractual uptime SLA commitment at this stage.

Service monitoring

Application logs and the public /health endpoint support service monitoring. A healthy endpoint is not a certification or guarantee about a particular document.

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.
• Client details: the names and email addresses you add for your clients.
• Files and comments: files you and your clients upload, comments between you and clients, per-file status updates, and document checklists.
• Signing records: for each PDF signature, the typed name, the email address the signer signed in with, IP address, time and a hash of the signed file. The public verification page shows the entered signer name, business name, time and verification ID. It does not display the PDF, login email or IP address. A browser-side file-hash check can compare a selected PDF to the stored record; matching bytes do not establish real-world identity or legal effect.
• 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, comment, 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.
• No marketing tracking cookies or visitor profiling. Marketing pages record pageviews with a first-party beacon, store nothing in the browser and make no requests to third parties. The sign-in pages and the application load their fonts from Google's font service; see the Cookie Policy.
• 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. GitHub processes no Customer Personal Data, so it is not a sub-processor under GDPR.

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

Optional Google and Microsoft sign-in sends authentication requests to the provider you choose. Google returns a verified email; Microsoft identifies its account, which must be connected to a Droplana email by an emailed code. Stored client documents are not sent as part of this sign-in flow. Email magic-link access avoids that optional identity-provider flow, but still uses email delivery. Font requests from the sign-in pages and the application to Google's font service are separate from sign-in.

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 irreversibly removes active account data, stored files and signature records. Public signature verification does not survive account deletion. Security logs, infrastructure backups and billing-provider records have separate retention purposes; the active-account deletion does not mean every historical record disappears at once.
• Export your data in a portable format (JSON).
• Object to processing in certain cases.

The full details are in our Privacy Policy, and the cookies the app uses are listed in the Cookie Policy.

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-aligned in our handling of EU data. Whether your business's overall handling of client data is compliant depends on more than any one tool. Our guide to what GDPR requires when you share files with clients covers the rest. Key practices:

• EU data residency (Germany)
• No marketing tracking cookies or visitor profiling; browser storage and provider requests are disclosed separately
• 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 and applies on every plan. A countersigned copy is included on Practice and Studio; request it at dpa@droplana.com.

What we don't (yet) have

We're transparent about this:

• We are not currently SOC 2 certified.
• We are not currently ISO 27001 certified.
• HIPAA-regulated protected health information is excluded under the DPA.
• We are not specifically certified for FINRA or other US financial regulatory frameworks.

For regulated industries

The DPA excludes HIPAA-regulated protected health information and uses requiring regulatory certifications Droplana does not hold. The Terms and Fair Use Policy also restrict content. A legal or financial audience page does not override those exclusions.

For other professional uses, assess your required access rules, retention, signing method and record-keeping before uploading. Strict access and Germany hosting do not supply ethical walls, certified archiving or a qualified signature. Send product-security questions to security@droplana.com.

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, which requires an identified session tied to an authorized address. 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 access when needed. If you suspect a portal link has been compromised, use "Revoke all access" in the client's share access panel. Every link, remembered device and open portal session for that client stops working immediately. Sending the client a new link restores access.
• Delete clients you no longer work with. Cleaner than leaving stale portals. The full delete removes all their files, comments, signatures, 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 and lawful requests from competent authorities - 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

Are files encrypted at rest?

Yes. Files use AES-256 encryption with a key derived per file. The database, application configuration and logs also use encrypted disk storage. This protects against a storage-only breach, not compromise of the app host holding the master key. It is not end-to-end encryption.

Can team members see every client?

Business team members share access to the business’s clients, files, comments and statuses. Droplana has no per-member client assignments or ethical walls. Each client is isolated from other clients, but multiple contacts authorized for one client share that client’s portal.

Does Germany hosting make my workflow GDPR compliant?

Hosting is one part of the assessment. Droplana stores files, comments and metadata on Hetzner infrastructure in Germany and publishes a DPA on every plan. Your purposes, access choices, document categories and retention obligations still need their own assessment.

What survives account deletion?

Account deletion removes active account data, files and signature records, so public signature verification does not survive it. Operator security logs, infrastructure backups and billing-provider records have separate retention purposes. The policies describe those boundaries.

Can I use Droplana for any sensitive document?

No. The Terms, Fair Use Policy and DPA restrict content and uses. HIPAA-regulated protected health information and uses requiring certifications Droplana lacks are excluded. Strict access, professional use or a legal audience page does not override those exclusions.

For file lifetimes and cancellation rules, see pricing. For access, exports and first-client steps, see the instructions.

Security questions

For a product-security question, email security@droplana.com. Name the control or evidence you need, such as access scope, retention or the DPA. Avoid sending client documents in the initial request. A real person will respond.