Data Processing Agreement
This Data Processing Agreement ("DPA") applies where you use Castrix in a business capacity and, in doing so, put personal data or confidential material into the service. It forms part of the Terms of Service between you ("Customer") and Jason Aron Media, operator of Castrix ("Castrix," "we," "us"). Where this DPA and the Terms conflict on the handling of personal data, this DPA wins.
If you are a broadcaster, agency, production company or corporate team putting unreleased scripts into Castrix, this is the document your legal or procurement team is looking for. If you need it countersigned, or on your own paper, email jason@jasonamedia.com and we will sign.
We have written this in plain English rather than in the usual register. It is intended to be legally operative, not decorative, and every commitment in it is one we intend to be held to. Where a commitment is not yet fully automated, we say so in an orange box rather than leaving you to discover it.
1. Who is who
Customer content — you are the controller, we are the processor. Your scripts, their contents, and any personal data inside them (names, quotes, attributions, contact details in a rundown) belong to you. We process them only on your instructions.
Account data — we are the controller. The name, email, password hash, plan and billing status attached to your Castrix account are processed by us for our own purposes of running and billing the service, and are covered by our Privacy Policy rather than by this DPA.
"Personal data," "processing," "controller," "processor," "data subject" and "supervisory authority" have the meanings given in the UK GDPR and the EU GDPR (Regulation (EU) 2016/679). Where the CCPA/CPRA applies, we act as a "service provider" and not as a "third party": we do not sell or share your data, and we do not retain, use or disclose it for any purpose other than performing the service.
2. What we process, and why
| Item | Detail |
|---|---|
| Subject matter | Providing the Castrix teleprompter service: storing, retrieving, displaying and synchronising Customer scripts across the Customer's devices. |
| Duration | For as long as the Customer's account is open, plus the deletion windows in section 9 — including the 30-day window that runs if the Customer moves down to the Individual plan. |
| Nature and purpose | Storage, retrieval, transmission between the Customer's own devices, backup, and technical support. We do not analyse, mine, index for search, monetise, or use Customer content to train any machine-learning model. |
| Categories of data subject | The Customer's staff and authorised users; any individual whose personal data the Customer chooses to put into a script (for example a named interviewee, an executive being quoted, or a contributor in a rundown). |
| Categories of personal data | Whatever the Customer puts in a script. Typically names and job titles; potentially anything, because a script is free text. Also the account identifiers of the Customer's users, and the IP addresses of devices they pair. |
| Special category data | Castrix is not designed for special category data (health, biometrics, political or religious belief, sexual orientation, trade union membership) or for criminal-offence data. The Customer should not put it in scripts. If the Customer does, the Customer is responsible for the additional obligations that attracts. |
| Confidential but non-personal content | Much of what customers store — unreleased broadcast copy, embargoed announcements, earnings statements — is commercially confidential without being personal data. Section 4 covers it as confidential information regardless of whether data-protection law applies to it. |
3. Our obligations as processor
- We process only on your documented instructions. Your use of the service is the instruction. We will not process Customer content for any other purpose unless the law requires it, in which case we will tell you first unless the law forbids us to.
- We will tell you if an instruction looks unlawful. If we think something you ask us to do breaches data-protection law, we will say so rather than quietly do it.
- Confidentiality of personnel. Everyone with access to Customer content is bound by a duty of confidence. Today that population is one person — the operator of Jason Aron Media — plus the subprocessors in Annex B. If that changes, anyone added will be under a written confidentiality obligation before they get access.
- We will help you meet your own obligations under Articles 32 to 36 — security, breach notification, data protection impact assessments and prior consultation — to the extent the help is proportionate to the information available to us.
4. Confidentiality of your scripts
We treat the contents of your scripts as your confidential information. We will not disclose them to any third party other than the subprocessors listed in Annex B, will not use them for any purpose other than operating the service for you, and will not read them except where you have asked us to help with a specific problem, where we must to investigate a security incident or abuse of the service, or where we are legally compelled and permitted to comply.
These obligations survive the end of your subscription and are not limited to personal data.
Partly built. Every export and every deletion of a script library is now logged — who, what, when, outcome and counts, kept for 12 months. What is still not logged is an administrator reading script content, so we cannot yet produce a record proving when, or whether, an administrator opened a particular script. Read logging is a committed build item. Until it exists, this section is a policy commitment backed by a very small number of people for reads, and by an inspectable record for exports and deletions.
5. Security measures
Annex A lists the technical and organisational measures in force. We may change them, but not in a way that materially reduces the overall level of security. Annex A is written to be accurate rather than impressive; it names what is missing as well as what is present, because a security annex you cannot rely on is worse than none.
6. Subprocessors
You give us general authorisation to use the subprocessors listed in Annex B. We remain fully liable to you for their acts and omissions, and each is engaged under a written contract imposing data-protection obligations equivalent to those in this DPA.
Before we add or replace a subprocessor that handles Customer content, we will give you at least 30 days' notice by email to the account address and publish the change on this page. If you reasonably object on data-protection grounds within that period, you may terminate your subscription for the affected service and we will refund the unused portion of anything you have prepaid. That is the remedy — we are not able to run a separate processing arrangement for one customer.
Not yet built: there is no mechanism to bulk-email account holders. Honouring the 30-day subprocessor notice today means sending the emails by hand, which is workable at current customer numbers and stops being workable well before it stops being an obligation. A notification list is a committed build item.
7. Personal data breaches
If we become aware of a personal data breach affecting Customer content, we will notify you without undue delay, and in any event within 72 hours of becoming aware, at the email address on your account. The notification will describe the nature of the breach, the categories and approximate volume of data and data subjects affected, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of that at once, we will give it in phases as it becomes available rather than delay the first notification.
We will not make any public statement identifying you as affected without consulting you first, except where we are legally required to.
Partly built. The 72-hour clock runs from when we become aware, and today our ability to become aware is limited: there is no intrusion detection, no alerting on anomalous data access, and — apart from exports and deletions, which are logged — no audit log from which the scope of a breach could be reconstructed. We would most likely learn of a breach from a customer, a provider, or a public disclosure. Breach detection, access logging and a notification path are committed build items. We would rather state this than let you assume a monitoring capability that is not there.
8. Data subject requests and assistance
If a data subject contacts us directly about Customer content, we will not respond substantively; we will pass the request to you and let the individual know we have. Taking into account the nature of the processing, we will assist you with appropriate technical and organisational measures in meeting requests for access, correction, deletion, restriction, portability or objection.
In practice: on request from an authorised contact on your account we will retrieve, export or delete specified scripts within 10 business days, at no charge for reasonable volumes.
Partly built. A verified export-and-delete route for a whole script library exists on the server: it produces one self-contained file containing every script, and it will not report a download as complete until the server has cryptographically verified that every byte reached the requesting browser. What is not yet built is the button inside Castrix that drives it, so today we run it for you on request rather than you running it yourself. There is also still no administrative tool for locating content by data subject — finding every script mentioning a named individual is a manual search. Both are committed build items; the in-app export button is the higher priority.
9. Deletion and return
- While your account is open, you can delete any script yourself. Deleting a script removes its text immediately. A record of the deletion — name, size and date, but not the text — is retained so your other devices do not re-upload it, and is cleared approximately 90 days later.
- On termination, at your choice we will return your content in a machine-readable format, or delete it. Tell us which within 30 days of termination. If you tell us nothing, we retain it for 90 days so you can change your mind, then delete it.
- On a downgrade to the Individual plan, which is a single-machine plan with no cloud library, the stored library is retained for 30 days from the day the plan takes effect and is then permanently deleted. Twelve reminder emails run across that window, each naming the exact deletion date, and the final warning and the deletion receipt are sent regardless of any email preference. If the library is downloaded and the download is cryptographically verified, it may be deleted sooner at your request. This is the one deletion Castrix performs on a timer rather than on your instruction, and it is why a business customer should downgrade deliberately rather than incidentally.
- Deletion means removing your account record, all scripts and deletion records in your library, the library usage cache and key material, device-pairing data, sessions, sign-up entries and sync-relay contents, completed within 30 days of your request, with written confirmation to you.
- What we keep after a library deletion: a content-free deletion receipt — dates, counts, the device label given at download, and a one-way digest, with no script names, identifiers or text — kept as proof of what was deleted and when; and the 12-month export/deletion log in Annex A. Both go when the account itself is deleted.
- What we keep anyway: payment and tax records where law requires, and records needed for an active dispute. Backups held by our hosting provider are overwritten on that provider's own cycle; content in a backup is not restored to live service after deletion.
Partly built. Deleting a script library is now a single verified operation: a two-pass sweep across every affected key prefix, re-enumerated until empty, logged, and receipted. Deleting a whole account is not — the administrative delete removes only the primary account record and the pairing index, and removing the rest (sessions, reset indexes, billing indexes, sign-up entry, team membership) is still a manual multi-step procedure against a written runbook. Wrapping the verified library sweep in a single account-level purge is a committed build item and the one we regard as most urgent.
10. Audit
On reasonable written request, no more than once a year (and additionally after a breach affecting you), we will make available the information necessary to demonstrate compliance with this DPA, and will answer a reasonable security questionnaire. We do not hold a SOC 2 report, an ISO 27001 certificate or a current third-party penetration test, and we would rather tell you that up front than have it emerge in your vendor review.
Where your regulator or your own compliance obligations require an inspection that goes beyond documentation, we will discuss it in good faith and in most cases will accommodate it, at your cost, on 30 days' notice, subject to confidentiality and to not disrupting other customers. On-site inspection of our hosting provider's facilities is not in our gift; we will pass through what that provider makes available.
11. International transfers
Customer content is stored and processed in the United States, in the AWS us-east-2 region (Ohio), and our subprocessors are US-based. Where you are established in the UK, EU or EEA, this is a restricted transfer.
For those transfers, the parties agree that the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Two (controller to processor), are incorporated into this DPA and take effect on your acceptance of it, with Annex A as Annex II, Annex B as Annex III, and the details in section 2 as Annex I. The governing law is the law of Ireland and the forum is the courts of Ireland for the purposes of those clauses only. For UK transfers the UK International Data Transfer Addendum (version B1.0) applies to the same clauses, with the ICO as the relevant authority. We rely additionally on our subprocessors' own transfer safeguards, including Stripe's and Netlify's standard contractual clauses.
Needs a lawyer's eye before you rely on it. Incorporating the SCCs by reference on a web page is common practice, but whether it is effective, and whether the Module Two annexes above are complete enough for your regulator, is a question for a qualified data-protection lawyer. If your legal team wants signed SCCs with completed annexes rather than incorporation by reference, ask and we will execute them.
12. Liability and precedence
Each party's liability under this DPA is subject to the limitations in the Terms of Service, except where the law does not permit those limitations to apply — notably to claims by data subjects under Article 82 GDPR, which are not capped by contract between us. Nothing in this DPA reduces any statutory right of a data subject.
Order of precedence: the Standard Contractual Clauses, then this DPA, then the Terms of Service.
13. How to accept this DPA
This DPA applies automatically to any customer using Castrix in a business capacity — you do not need to sign anything for it to be in force. If your organisation requires an executed copy, or requires it on your own template, email jason@jasonamedia.com with the document and we will review and sign it. We would rather answer a procurement questionnaire than lose a deal to a missing PDF.
Annex A — Technical and organisational measures
In force today
- Encryption in transit. HTTPS enforced across castrix.app, including all API traffic and the sync relay.
- Encryption at rest. Provided by our storage provider for all stored data.
- Authentication. Passwords stored only as salted PBKDF2 hashes. Sessions are HTTP-only, Secure, SameSite cookies with a 30-day lifetime and a per-account epoch that invalidates all sessions on demand.
- Tenant isolation. Every script record and every sync mailbox is namespaced to the owning account. The server derives that namespace from the authenticated caller, never from anything the caller supplies, and re-checks ownership on every read. Knowing another customer's pairing code does not reach their data.
- Authorisation at every endpoint. Each API function authorises for itself rather than trusting an upstream gate. Device pairing credentials are restricted to the sync endpoint and cannot read or write a script library.
- Content sanitisation. Script markup received over the sync channel is sanitised to an allow-list before display, so a hostile script cannot execute code on a paired device.
- Cross-site request protection. Write endpoints require a JSON content type, which cannot be produced by a cross-site form post and forces a preflight that never returns credentials.
- No third-party code at runtime. A Content Security Policy is enforced on every response, written deny-by-default: scripts, styles and images may load only from castrix.app, and outbound connections are restricted to castrix.app and the peer signalling service. The browser libraries the app needs are self-hosted from our own origin rather than fetched from a public CDN, so no third party can inject code into a session or observe who is using the product.
- Bounded retention. Sync relay mailboxes hold at most 80 messages and stop serving anything 12 hours after last use; deletion records are cleared after 90 days; a cloud library retained after a downgrade is deleted 30 days after the plan changes. The first two are cleared on next access rather than by a timer — see the limitation below. The third is performed by a scheduled daily job.
- Verified deletion. Deleting a library is a two-pass sweep across every affected key prefix — script records, deletion records, the usage cache, library key material and the account's sync mailboxes — followed by a re-enumeration that must come back empty before the deletion is recorded as complete. A partial sweep is never reported as done; it is retried until it is. Nothing is skipped for being unrecognised.
- Export and deletion logging. Every export and every deletion of a script library is written to a separate append-only log — actor, action, target, timestamp, outcome and counts, never script content — retained for 12 months.
- Deletion cannot be triggered by a device credential. Export and deletion require a full session. A pairing credential — the kind printed under a QR code on an operator's screen — is refused outright and can reach only the sync endpoint.
- Least data. No third-party analytics, no advertising trackers, no session recording, no profiling. Card data never touches our systems.
- Change control. All source is version-controlled with a written record of security-affecting changes.
Not in force — stated so you can price the risk
- No audit logging of administrative reads of Customer content. Exports and deletions are logged (above); an administrator opening a single script to answer a support ticket is not, so we cannot yet produce a record proving whether a particular script was read.
- No intrusion detection or anomalous-access alerting.
- No rate limiting or lockout on sign-in attempts.
- No SOC 2, ISO 27001, or third-party penetration test.
- No formal business continuity or disaster recovery plan; recovery depends on our hosting provider's own durability.
- Data is held in a single region with no independent backup outside that provider.
- No dedicated security personnel; Castrix is operated by one person.
- No handling of email bounces or spam complaints; a permanently undeliverable address is retried rather than suppressed.
- Expiry is enforced on access rather than by a scheduled job, except for the 30-day library window, which a daily job performs. An abandoned sync mailbox or an abandoned library's deletion records are never served once expired, but the underlying storage is only cleared the next time that mailbox or library is touched, or when the library is deleted. A general scheduled sweep is a committed build item.
Annex B — Subprocessors
| Subprocessor | Purpose | Location | Touches script content? |
|---|---|---|---|
| Netlify, Inc. | Hosting, compute, storage of scripts and account records, sync relay | United States (AWS us-east-2) | Yes |
| Amazon Web Services, Inc. | Underlying infrastructure for Netlify storage | United States (us-east-2, Ohio) | Yes |
| Stripe, Inc. | Payment and subscription processing | United States / Ireland | No |
| Resend (Plus Five Five, Inc.) | Transactional email delivery | United States | No |
| PeerJS public signalling service and public STUN servers, including Google | Helps a customer's own devices establish a direct connection; sees pairing codes and device IP addresses | United States and global | No |
Last updated 14 August 2026. Changes are notified under section 6.
Annex C — Contact
Data protection contact for Castrix: jason@jasonamedia.com. We have not appointed a Data Protection Officer, and on our current scale and processing we do not believe Article 37 requires one. We have not appointed an Article 27 representative in the EU or UK; if your compliance review requires one, tell us and we will address it.