Privacy and GDPR
Privacy compliance is partly a property of the software and partly a set of obligations that the law places on whoever runs the site. Confusing the two is how organisations end up exposed. This page draws the line clearly: what CTXR does for you, and what remains yours to handle.
Who is responsible for what
Under the GDPR, CTXR is a processor and your organisation is the controller. The platform stores and serves data on your instructions; you decide what data is collected and why. That distinction is not a formality — the controller carries the bulk of the legal duties.
In practice, being the controller means you should have these in place:
| Your responsibility as controller | Why |
|---|---|
| A data processing agreement with CTXR | Documents the processor relationship; we countersign the standard template |
| A record of processing activities | Required for most organisations handling personal data |
| A privacy policy | Covers visits to your space and any data you collect |
| Retention periods | How long content and editor accounts are kept |
| A process for data subject requests | How you handle access and deletion requests from individuals |
| A data-breach procedure | Who acts, and within what window, if something leaks |
CTXR cooperates on the platform-held data it touches — editor email addresses, display names, and expiring session records — and can export or delete those on request. It sets no tracking cookies, profiles no visitors, and shares nothing with third parties. For procurement, you can ask in writing for confirmation of where your space is hosted and for the current list of sub-processors. Because a space runs only on the platform’s engines — in the EU by default, with no self-hosting; a custom domain is just a CNAME pointing at the platform — the one part of “where data goes” that is genuinely your decision is integrations. Any connector you switch on (an AI provider, a payment processor, a future export) sends data outward by your choice, and its handling falls in your column, not the platform’s — the same line that applies to any third-party integration you adopt.
The weak link is email
Because editors sign in with a code sent to their inbox, the inbox is the credential. Anyone who can read an editor’s mail can request a code and sign in. The magic-link flow is already two-factor in spirit, but that second factor is only as strong as the mailbox behind it.
The single most impactful thing you can do for your space is therefore outside the platform: require multi-factor authentication on every editor’s email account. Treat it as mandatory, not advisory.
Operational hygiene
A few habits keep a space clean over time:
- Uploads are public by design. Set roles and permissions deliberately, following least privilege — does this editor truly need
publish, or onlywrite? - Rotate API keys periodically. A WebAPI key is a long-lived credential; replace it on a schedule and immediately if it is ever exposed.
- Keep the actor list tidy. Remove people the day they leave and keys the day an integration retires; the platform does not expire them for you.
Uploaded files are publicly reachable. CTXR is not encrypted private storage and must not be used as a document vault. Never upload contracts, medical information, identity documents, or other sensitive files — link out to a dedicated secure service instead. View gating restricts the pages of a space, not raw uploaded files.
Privacy by architecture
Three structural traits work in your favour. First, pull, not push: spaces expose their data and others read it on request rather than having it pushed into them, so data does not spread sideways across the platform without an explicit, auditable read. This is described in what an account is. Second, soft-delete with a retention window gives you a grace period to recover an accidental deletion — but treat it as a safety net, not a retention policy. Defining how long you actually keep personal data is a controller decision the platform cannot make for you. Third, identity is minimal by default: a visitor can install a space’s app and get notifications or location-aware prompts completely anonymously (see Reach); following and collecting content needs only an email-keyed account; and only someone who wants to publish ever creates a space. Each role asks for the least identity it needs — so for most people there is no personal data in your space to retain in the first place.