S SignatureHub

Trust Center — security, privacy, compliance

100% data processing in Germany: dream-soft GmbH’s own hardware in the NTT data centre in Frankfurt am Main, backups replicated to a second German data centre. No third-country transfer. Mail content is not persisted. GDPR Art. 28 data processor, DPA and TOM catalogue on request. ISO 27001 ISMS in progress, regular penetration tests by our sister company CDH computing GmbH.

Answers to the questions security reviews ask

Is email content or are attachments stored or logged permanently?
No. The gateway accepts the message, parses it in memory, inserts the signature block into the MIME tree and passes it on; the representation is then discarded. SignatureHub has no table, no directory and no object store for message bodies or attachments. One limitation we state explicitly: when delivery runs through our own queue — which applies to the Microsoft 365 connector and to relay tenants in direct-MX mode — the message sits transiently in the local Postfix queue on the same German VM for the duration of delivery and is removed once handed over. Undeliverable mail expires after five days at the latest with a bounce. In smarthost mode, where we hand the message back to your own MTA, even that does not happen: processing in memory only.
Can content appear in backups, error logs or debug logs?
Database backups contain no mail content because the database contains none — there is no field it could end up in. A VM snapshot does technically capture a delivery queue that happens to be filled at snapshot time; those snapshots live exclusively in the two German dream-soft data centres and rotate. Our application logs are structured JSON events with message-id, sender, recipient count, size, rule and template id and status code — no subject, no body, no attachments. A debug level that would log message parts is not active in production and is not switched on for troubleshooting either; we reproduce with synthetic test mail. The MTA log records sender, recipient, message-id, size and delivery status like any mail server — no content — and is rotated on a schedule.
What metadata about sent email is stored, and for how long?
Per message: timestamp, tenant, message-id, sender address, recipient count, message size, the rule and template applied, and the processing status. Recipient addresses, subject and content are explicitly not included. This metadata is the evidence that a signature was applied correctly and is available to the tenant in the interface. It is retained for the term of the contract and deleted with the tenant; a shorter retention period can be agreed in the DPA.
Is email content or customer data used for analytics, training or AI purposes?
No — without qualification. SignatureHub integrates no AI service, neither for signature processing nor for analytics; there is no connection to any LLM or analytics provider anywhere in the production code. There is no cross-customer analysis, no profiling and no sharing with advertising or analytics services. Even the click statistics for signature banners are built so they cannot be traced back to individuals.
Can dream-soft staff technically view email content or attachments?
Not through the application: there is no feature, report or database content that would show message bodies or attachments — they simply are not stored anywhere. For support there is a support login that lets a super admin see a tenant's interface (templates, rules, user records — no mail content). That login expires after 15 minutes, carries the support engineer's real identity in the token, and writes an “admin.super_login” entry into the tenant's audit log, which the customer sees. What we will not claim: administrators with root access to the machine could technically tap a running process. That is true of every email provider and is bounded organisationally here — a named group of administrators, access via hardened SSH keys only, confidentiality obligations, and logged access.
Is two-factor authentication available for administrators?
Yes. All administration accounts — yours and ours — can enable TOTP 2FA (authenticator app, set up in account settings). It is enabled on the operations team's super admin accounts. A tenant-wide enforcement setting that lets you make 2FA mandatory for all your admins is in progress; until then, adoption can be tracked via role management.
Are security-relevant accesses and changes logged?
Yes, in the same audit log that records mail processing: logins, failed login attempts, role and permission changes, creation and revocation of credentials, changes to connectors, templates and rules, and every support login. Each entry carries a timestamp, the acting account and the tenant. Tenant admins can review and export the log — you do not depend on us for information about your own environment.
What protects against unauthorised access, data loss and account compromise?
Passwords are Argon2id-hashed; sessions run on short-lived RS256 JWTs. The SMTP gateway is protected against auth brute force by fail2ban, the reverse proxy by rate limits, mail processing by a per-tenant rate limit. The VM sits behind an nftables firewall with administrative access via SSH key only. Device passwords are issued per device and revoked individually — a lost phone costs one credential, not everyone's access. A device password is also bound to its user's sender address, so it cannot be used to send as colleagues. Against data loss there are the two backup layers described above, in two data centres.
Is there a defined retention and deletion policy?
Yes, tiered by data type. Mail content: not stored, transient delivery queue with a five-day expiry at most. Processing metadata and audit entries: term of the contract, deleted with the tenant, shorter periods can be agreed in the DPA. Database backups: 14 days rolling, then overwritten. Reports from the optional mail validator (test messages you deliberately send to a one-time address): archived after 14 days, hard-deleted after 28. Your employees' records persist for as long as you maintain them in SignatureHub — with directory sync from Microsoft 365 or Google Workspace they disappear automatically once the account is disabled there.
How do you ensure all our data is deleted when the contract ends?
At the end of the contract the tenant is deactivated; on your instruction — and no later than 30 days after the contract ends unless you ask otherwise — we delete it completely from the production database. Because every table hangs off a tenant-scoped foreign key chain, that single deletion removes domains, connectors, credentials, DKIM keys, user records, templates, rules and audit entries in one pass; leftovers in side tables cannot exist by construction. Existing backups then age out of the rotation window — after 14 days at the latest nothing remains there either. On request we confirm the deletion in writing, and we export your templates and audit log beforehand so you keep your records.
How will we be informed about a data breach or security incident?
We notify affected tenants without undue delay, at the latest within 24 hours of becoming aware, so you can meet your own 72-hour deadline towards the supervisory authority under Art. 33 GDPR. The notification goes to the contacts named in the DPA and covers the nature and time of the incident, the categories of data affected, the state of containment and our recommendation for your response. Once closed, you receive a post-mortem with root cause and remediation.
What availability is committed, and is there an SLA?
On the Pro plan we contractually commit to 99.9% availability on a monthly average; for enterprise customers we agree response times and maintenance windows individually. Monitoring runs continuously on Prometheus and Grafana (reachability, latency, error rate, queue length, certificate expiry) with alerting to the operations team. Recovery objectives after a total outage: RPO 24 hours, RTO 4 hours.
What happens to outgoing email if SignatureHub is down?
That depends on what submits the mail, so here is the honest distinction. If your own mail server submits — Exchange, Microsoft 365 with an outbound connector, Postfix as a smarthost — SignatureHub simply does not accept the message during an outage; your mail server keeps it in its queue and delivers automatically once we are back. Nothing is lost, it is only delayed. If instead your mail clients point directly at mx.signaturehub.de with a device password, there is no upstream queue: Outlook or Apple Mail will report “could not be sent” and keep the message in the outbox — it has to be sent again. If that matters to you, we recommend connecting via your own MTA. Once our side has accepted a message, delivery responsibility is ours and our queue retries with backoff before generating a non-delivery report.
Are there certifications, external audits or regular penetration tests?
We are not currently ISO 27001 certified and we do not claim to be. Across the group we are building an ISMS to ISO 27001 with certification as the goal; SignatureHub is inside that scope from the start. Regular testing already happens today: CDH computing GmbH — our sister company and an IT security provider with an in-house penetration tester — attacks the group's systems on a planned basis from an attacker's perspective, including the SignatureHub infrastructure. Testing is done by a team that does not develop the product; findings come back to engineering as prioritised tickets. In addition, a responsible disclosure channel runs at security@signaturehub.de. Summaries of internal test results are available to existing customers on request under NDA.