Annex 1: Technical and organisational measures

Measures pursuant to Art. 32 GDPR, forming part of the Data Processing Agreement. Version 1.0, as of 2026-08-07. This describes the instance operated by Fade Media GmbH at https://postomnia.de.

1. Confidentiality

1.1 Physical access control

The application runs in a Hetzner Online GmbH data centre in Germany. Physical access, video surveillance, visitor logging and entry control are the data centre operator's responsibility and are certified to ISO/IEC 27001. No own hardware is operated.

1.2 System access control

Server access exclusively via SSH public-key authentication; password login is disabled.
Administrative access to the application server is limited to named individuals of the processor.
Application login via email and password; passwords are stored only as salted hashes, never in clear text.
Brute-force protection: an email address is locked for 15 minutes after five failed attempts, plus IP-based rate limiting on all authentication routes.
Two-factor authentication (TOTP) for administrator accounts.
Sessions use random bearer tokens; a password reset invalidates all existing sessions, AI connections and the previous API key.

1.3 Data access control

All resources – accounts, posts, media, invoices, bio pages – belong to a workspace and are strictly isolated from one another; every read and write is checked server-side against the workspace context.
Role model owner / admin / member with graduated permissions; plan and role checks are enforced server-side, not in the interface.
Automations (MCP, REST actions) run through a dedicated, audited capability dispatcher subject to the same role and approval rules.
Security-relevant operations – deletions, billing changes, email dispatch, public links – require an explicit approval before execution.

1.4 Separation control

Tenant separation is logical, based on the workspace reference on every resource. Production, test and development environments are separated; production data is not copied into test or development environments.

1.5 Pseudonymisation and encryption

In transit: TLS (HTTPS) only, with automatic certificate renewal; HTTP is redirected to HTTPS. Strict Content Security Policy and security headers.
At rest: credentials of connected social media accounts as well as OAuth access and refresh tokens are stored encrypted with AES-256-GCM (dedicated key, random initialisation vector per record).
Backups: symmetrically encrypted before leaving the server; the storage location never receives readable personal data.
Logs: secrets are masked automatically.

2. Integrity

2.1 Transfer control

Transmission to social media platforms happens only for the accounts selected and content approved by the controller. Outbound fetches of external URLs (media import, previews) pass through an SSRF check that blocks access to internal network ranges. Data can be exported as JSON at any time; secrets are masked in the export.

2.2 Input control

Security-relevant actions are recorded in an audit log with timestamp, acting account and target object (logins, account connections, publications, deletions, billing changes, approvals). The log is visible to workspace administrators.

3. Availability and resilience

Nightly automated database backup, encrypted, to a location separate from the production server. The last 30 backups are retained (rotation).
Recovery objectives: RPO 24 hours (state of the last nightly backup), RTO 4 hours from detection of the outage.
Restore tests are performed and documented at least every six months.
Monitoring via Prometheus metrics (requests, errors, failed logins, publications) and structured JSON logs; public operating status at /status.
Failed publications are retried only for the affected channels – an outage on one channel never causes a duplicate post on the others.

4. Procedures for regular review

An automated test suite and static checks run on every code change; nothing is deployed unless they pass.
Automated dependency scanning for known vulnerabilities in the supply chain.
Reporting channel for security vulnerabilities and response times: /sicherheit.html.
Data protection incidents are reported to the controller without undue delay and no later than 48 hours after becoming aware of them (§ 10 DPA).
This annex is reviewed and updated annually and whenever material changes occur.

5. Sub-processor control

Sub-processors are engaged only in accordance with § 7 of the DPA and are bound to an equivalent level of protection. The current list is in Annex 2; changes are announced 30 days in advance.

Version 1.0 · As of 2026-08-07