Legal
Data Processing Agreement
1. Roles and scope
1.1 The customer is the controller, and we are its processor, for personal data the customer's people put into SignedOffBy or that the service creates about them (Annex 1).
1.2 We are a controller only for our own account and billing contacts, and for keeping the service secure.
1.3 This agreement lasts as long as we process personal data for the customer. Words such as personal data, processing and personal data breach have their UK GDPR meanings.
2. Our obligations as processor
We will:
- process personal data, including any transfer of it outside the UK, only on the customer's documented instructions, which are this agreement, the Terms and the customer's use of the service; if the law requires other processing we will tell the customer first unless the law forbids it, and we will tell the customer if we think an instruction breaks data protection law;
- make sure everyone with access to it is bound by confidentiality;
- keep the security measures in Annex 3 in place, and not reduce them materially;
- use subprocessors only as section 3 allows;
- help the customer, as far as we reasonably can, to answer requests from people exercising their rights, and with security, breach notification, impact assessments and consultation with the ICO;
- delete or return personal data when the agreement ends (section 5);
- give the customer the information it needs to show compliance, and allow audits (section 5).
3. Subprocessors and where data goes
3.1 The customer authorises the subprocessors in Annex 2. We will give at least 30 days' notice by email of a new subprocessor; the customer may object on reasonable data protection grounds and, if we cannot resolve it, end the agreement.
3.2 Each subprocessor is bound by data protection terms no less protective than these, and we remain responsible for it.
3.3 We store customer data in the EU (Amsterdam, the Netherlands). Our hosting provider, Railway Corporation, is based in the US and may access data from there to run its platform. That transfer relies on the UK Extension to the EU–US Data Privacy Framework or, where it does not apply, the EU Standard Contractual Clauses with the UK Addendum, under Railway's DPA.
3.4 Anthropic is not our subprocessor. When a customer runs an assisted pass, we send the brief and the relevant vendor guidance to Anthropic using the customer's own API key, on the customer's instruction. Anthropic processes that data under the customer's own agreement with Anthropic, and the customer is responsible for that relationship and any transfer it involves.
3.5 When the customer creates a share link, whoever holds the link can read that one sign-off record until the link expires or is revoked. The customer decides who receives links.
4. Personal data breaches
4.1 We will tell the customer without undue delay, and within 48 hours of becoming aware, of a personal data breach affecting its data.
4.2 The notice will say what we know at the time: what happened, the data and people likely affected, the likely consequences, and what we are doing about it. We will add details as we learn them.
4.3 Notifying the ICO and affected people is the customer's decision as controller; we will help it do so.
5. Deletion, return and audits
5.1 An owner can export plans and passes at any time and can delete the whole workspace in Settings, which removes its data from the live service at once. When the agreement ends, the customer may export its records for 30 days; we then delete the workspace's personal data. Copies leave our backups as they expire. The law may require us to keep some data, such as invoices, for longer.
5.2 Sealed records cannot be edited inside the service. Deletion uses a single procedure that may override that protection only for the whole of one workspace, and each deletion is recorded in our own operations log.
5.3 Once a year, or after a personal data breach, the customer may audit our compliance on 30 days' notice, at its own cost, during working hours and subject to confidentiality. We will first answer written questions and share evidence, which may make an inspection unnecessary. Subprocessors are audited through the reports they publish.
Annex 1: details of the processing
| Item | Detail |
|---|---|
| Subject matter | Providing SignedOffBy: planning, AI-assisted proposals, named sign-off and sealed records |
| Duration | The term of the agreement, then up to 30 days for export and deletion, plus backup expiry |
| Purpose | Running the customer's workspace, recording who did what, and keeping the service secure |
| People concerned | The customer's staff and contractors who use the service; anyone the customer names in a brief |
| Personal data | Name, work email, job title, role, password hash, sign-in session records, audit trail entries (who did what and when), IP addresses in hosting logs; any personal data the customer puts in a brief or note |
| Special category data | None intended. The Terms ask customers not to put it in |
| Where it is stored | EU West, Amsterdam, the Netherlands (Railway) |
| Retention | As section 5; audit trail entries are kept as long as the workspace exists |
Annex 2: subprocessors and other recipients
| Recipient | Role | What it receives | Location | Safeguard |
|---|---|---|---|---|
| Railway Corporation | Subprocessor: hosts the application and its database | All customer data, encrypted in transit | Data stored in Amsterdam, the Netherlands; company in San Francisco, US | Railway DPA; Data Privacy Framework (UK Extension) or SCCs with UK Addendum |
| Anthropic | Not a subprocessor: the customer's own model provider, used with the customer's own key | The brief and relevant vendor guidance, during a pass the customer starts | Per the customer's agreement with Anthropic | The customer's own agreement with Anthropic |
No other third party receives customer data. Fonts and page assets are served from our own server, so visitors' browsers contact no font or analytics provider. Our source code is kept on GitHub; it holds no customer data. Railway's own subprocessors are listed at trust.railway.com.
Annex 3: security measures
| Area | Measure |
|---|---|
| Transport | HTTPS only, with HTTP Strict Transport Security |
| Passwords | Hashed with scrypt; never stored or logged in plain text |
| Sessions | Random tokens stored only as SHA-256 hashes; cookies are HttpOnly, Secure and SameSite; 14-day expiry; every form a signed-in user submits carries an anti-forgery token |
| Sign-in | Repeated sign-in attempts are limited per address and per email |
| Model keys | Encrypted with AES-256-GCM under a key held outside the database; shown to users only as a short hint |
| Separation | Every query is scoped to the signed-in user's workspace; an account belongs to one firm; automated tests check that one workspace cannot see another's data |
| Roles | Only owners and specialists can sign off or share; by default the person who started a pass cannot sign it off |
| Integrity | The content of plans, and all proposals, sign-offs, agreements and audit events, cannot be changed once written, enforced in the database; each workspace's audit trail is chained with HMAC-SHA256, so an edited, removed or reordered earlier event is detectable by anyone outside SignedOffBy |
| Share links | Random tokens stored only as hashes; expire within at most 365 days; revocable; views counted; not indexed by search engines |
| Browser | No scripts run on any page; a Content Security Policy that blocks all scripts; pages cannot be framed |
| Hosting | EU data centre (Amsterdam); production access limited to named administrators using two-factor authentication |
| Backups | Daily database backups kept 6 days, weekly kept 1 month. Being switched on during the pilot; not yet active |
| Change control | Code in a private repository; an automated test suite, run against a real database, is run before each release |