Trust

Security

Version 0.3 (draft) · Last updated 4 October 2026

Documents carry the things companies care about most: invoices, contracts, customer data. This page describes how we protect them, what we do not yet have, and how to report a problem.

1. How your data is handled

• Transport is encrypted with TLS 1.2 or higher; files, databases and backups are encrypted at rest.
• Generated files are delivered through signed URLs that expire [TO CONFIRM: default 1 hour]. Anyone holding the link can open the file until it expires — treat links as secrets.
• Files are deleted automatically at the end of your retention window; the windows are listed in the Terms of Service, section 11.
• Request payloads are not logged by default. You can switch logging on per workspace if you need it for debugging.
• Workspaces are separated logically at the data layer, with automated tests that check the separation holds.
• We do not use your content to train machine-learning models.
• Customer Content is stored and rendered in the European Union, on servers in Germany.

2. Isolation of the renderer

Rendering executes input we cannot vouch for — your HTML, your CSS, and, in the URL endpoints, a third party’s web page. Each render therefore runs in a sandbox with no access to other customers’ data and with restricted outbound network access. Requests to private, internal and loopback addresses are blocked, which is also why the Acceptable Use Policy forbids trying. [TO CONFIRM: sandbox technology and egress proxy as implemented.]

3. Access and keys

• Staff access follows least privilege, requires multi-factor authentication and individual accounts, and is logged and reviewed.
• API keys are stored as hashes; we cannot show you a key again after creation. Keys can be scoped and rotated [TO CONFIRM: scopes available?].
• Customer accounts support multi-factor authentication [TO CONFIRM], and administrative actions appear in an audit log.

4. Availability and backups

Backups are encrypted, taken regularly and restore-tested [TO CONFIRM: frequency of backups and of restore tests]. Availability commitments are in the SLA. A status page shows current and past incidents [TO CONFIRM: exists].

5. Development and change management

Changes go through code review and automated tests before release. Continuous integration scans dependencies and looks for leaked secrets. Development and production are separated, and production data is not used for development. [TO CONFIRM: as implemented.]

6. Incidents

We have a documented incident process with defined roles. If a breach affects personal data we process for you, we notify you within [TO CONFIRM: 48] hours of becoming aware, as set out in section 10 of the DPA. Security-relevant service incidents are published on the status page.

7. What we can give your procurement team

• Annex 2 of the Data Processing Agreement — the measures on this page as a binding contractual commitment, not a marketing claim.
• Written answers to your security questionnaire, once a year and free of charge.
• A signed copy of the DPA, including the Standard Contractual Clauses, on request.

External certifications such as SOC 2 or ISO 27001 are not in place. [TO CONFIRM: if you intend to pursue one, name it and the target date here — but only a date you will keep. A missed public date costs more than an empty roadmap.]

8. Reporting a vulnerability

If you find a security problem, tell us at security@dynamicdocumentapi.com. Include steps to reproduce and what you think the impact is. We confirm receipt within [TO CONFIRM: 2 business days], keep you posted, and will credit you when the issue is fixed if you want that.

Please test only against your own workspace, do not access other people’s data, do not run denial-of-service or spam tests, and give us reasonable time to fix things before publishing. We will not pursue researchers who follow these rules. [TO CONFIRM: is there a bounty? If not, say so instead of implying one.]

Change history