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.
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
Two 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.