Data Flows & Trust Boundaries
The auditor-facing view. Same system as System Context, organised by where data goes and who can see it rather than by component.Trust zones
Inbound data
Personal data enters at the customer and address steps. Everything downstream is financial.Outbound data
Only four paths send data out of CONA. Each is a deliberate, user-initiated or user-configured action.
DATEV is not on this list. The DATEV export generates files the user downloads; no
CONA code calls a DATEV API.
Subprocessors
Third parties that process customer or financial data.
Providers connected by a customer (Shopify, Amazon, Stripe, …) are data sources, not
subprocessors — CONA reads from them under the customer’s own credentials.
Personal data
Postal codes are used as the portal’s second authentication factor —
verifyEntityPlz
compares against the entity’s stored address.
Deletion and retention
The three Shopify GDPR webhooks are the mandated endpoints, verified by HMAC and sitting
outside the auth proxy. See Ingress.
Organisation deletion is triggered from the Console
and executed by a Temporal workflow.
Tenant isolation
Isolation is byorg_id in application queries, not by database-level row security.
Controls at the edge
Notes
Workers have no inbound public surface. The:8080/health endpoint is an internal Fly
Machine check, not behind Fly Proxy.
Secrets are not in the repository. NEXT_PUBLIC_AXIOM_TOKEN, UPLOADTHING_TOKEN, and
ENCRYPTION_KEY are documented in fly.prod.toml as fly secrets set values.
Everything runs in the EU. Fly workers are pinned to fra.