Draft. Not reviewed by a lawyer. Do not show this to a customer.
This was written by the engineer who built the software, by reading the code. It has not been reviewed by anybody qualified to review it. It is published here so that it can be read, checked and corrected — not so that it can be relied on. Nothing in it is an offer, a contract or legal advice, and it must not be linked from a signup flow or signed by anybody until a lawyer has read it.
All three documents · 15 unfilled markers in this document
Data Processing Agreement
Draft — not reviewed by a lawyer
This document was drafted by the engineer who built the software. It has not been reviewed by a lawyer. It must not be put in front of a customer, linked from a signup flow, or signed by anybody until a qualified person has read it. A data processing agreement is the document a buyer's legal team reads most carefully, and an engineer's draft of one is a starting point for a lawyer, not a substitute for one. Every [NEEDS ZACH: ...] marker below is a fact only Zach can supply, and a marker that is still showing means this document is unfinished.
1. What this is, and when it applies
This agreement governs our handling of personal data that a customer puts into the Platform, or that the Platform collects on the customer's instructions. It forms part of the Terms of Service.
- Controller: the customer. The restoration, roofing, HVAC, plumbing or other trades business that licenses the Platform.
- Processor: us, [NEEDS ZACH: the legal entity name, exactly as registered], of [NEEDS ZACH: the registered business address].
The customer decides who goes into the system, what is done with them and when to stop. We hold and process that data to run the Platform and for nothing else.
[NEEDS ZACH: which legal regime this agreement is written to satisfy. A GDPR Article 28 processor agreement, a CCPA/CPRA service-provider agreement and a plain commercial confidentiality agreement are three different documents with three different mandatory clause lists. This draft covers the substance common to all three; a lawyer has to pick the regime and add the clauses that regime makes compulsory, including whether Standard Contractual Clauses are needed at all.]
2. Subject matter, duration, nature and purpose
Subject matter. Business development for a trades company: finding commercial accounts, generating outreach to them, keeping existing clients warm, and recording what happened.
Duration. For as long as the customer's licence is live, plus the deletion windows in section 8.
Nature and purpose of the processing. Storage, organisation, retrieval, scoring, text generation, and transmission of commercial messages that the customer's own people have approved individually.
Categories of data subject.
| Category | Who they are |
|---|---|
| Customer staff | The owner, managers and sales reps with accounts |
| Business contacts | Facilities, property and general managers, and other decision makers at commercial premises |
| Networking contacts | Members of referral groups, chambers and trade associations |
| Named individuals in jobs | People connected with a property where work was done |
Categories of personal data. Names, job titles, business email addresses, business phone numbers, employer, business addresses, the pipeline status and free-text notes a rep types, the full text of commercial messages written to that person, networking-group membership and referral history, and — for customer staff only — a password hash, a sign-in history and IP addresses.
Special category data. None is asked for and none is needed. The Platform has no field for health, biometric, racial, political, religious or trade union data. It cannot stop a rep typing something into a free-text note. The contact notes field and the draft message body are free text and we do not inspect them, so a rep who types a sensitive fact about a person has put special category data into the system. That is a risk the controller carries, and it belongs in a staff training note rather than in code.
Children's data. None. The Platform is for contacting people in their professional capacity and is not directed at children.
3. Our obligations as processor
We will:
- Process personal data only on the customer's documented instructions, which for ordinary use means the customer's use of the Platform itself.
- Not sell, rent, share or disclose it to anybody except the sub-processors listed in section 5, and never use one customer's data for the benefit of another or for our own purposes.
- Not use it to train, fine-tune or evaluate any machine-learning model.
- Keep it confidential, and bind everybody with access to the same.
- Implement the technical and organisational measures in section 6.
- Help the customer answer a data subject's request, and tell them promptly if one reaches us directly.
- Tell the customer about a personal data breach affecting their data. [NEEDS ZACH: within how many hours. GDPR gives the controller 72 hours to notify a regulator, so a processor usually commits to 24 or 48 hours to leave the customer time to act. Pick a number you can actually meet given that there is one person on call.]
- Delete or return the data at the end of the licence, as section 8 says.
- Make available the information needed to show that these obligations are met, and allow an audit. [NEEDS ZACH: on what terms. An unqualified "the customer may audit us at any time" is a commitment a one-person company cannot absorb. The usual compromise is one audit a year, on 30 days' notice, at the customer's cost, under confidentiality — but it has to be your decision.]
4. The customer's obligations as controller
The customer:
- Decides who goes into the Platform and is responsible for being entitled to hold them.
- Is responsible for the lawfulness of their outreach, including commercial email rules, honouring a request to stop, and any notice owed to a person whose details were collected without their knowledge — including from public map data.
- Manages their own users' access, and removes an account when somebody leaves. The Platform makes this one switch, and ends the person's open session on their next request.
- Instructs us only to do things that are lawful for us to do.
This is the clause a lawyer should look at hardest. The Platform's purpose is cold commercial outreach to people who did not ask for it, and the legal basis for that sits entirely with the controller. Our part — generating a draft and queuing it for a human — does not create a basis where none exists.
5. Sub-processors
The customer authorises the sub-processors below. We will give notice before adding one and the customer may object.
| Sub-processor | Role | Location |
|---|---|---|
| Railway | Application hosting and the PostgreSQL database | [NEEDS ZACH: the Railway region the project runs in] |
That is the complete current list: one entry. Three more are planned and are not authorised by this agreement until they are named here and notice has been given:
- A transactional email provider, for password resets, the weekly management report and inbound email-to-lead. [NEEDS ZACH: not yet chosen — item 3 in ROADMAP.md]
- A payment provider. [NEEDS ZACH: Stripe account not yet created — item 5]
- A contact-enrichment provider, which would receive property records in order to look up a facilities manager. [NEEDS ZACH: not yet chosen. This is the one worth the most legal attention of the three, because it means sending data out in order to get personal data back.]
[NEEDS ZACH: how much notice before a new sub-processor, and what happens if a customer objects — do they get to terminate, and do they get a refund? Thirty days' notice with a right to terminate is the common shape.]
6. Technical and organisational measures
Specific, because a list of adjectives is not a security measure. Everything here is implemented today and can be demonstrated.
Separation between customers. Every record carries the identifier of the company it belongs to. Every read goes through a single function that filters on it, and the database session refuses to write a record that is not stamped with one. A request for another company's record is answered "not found" rather than "not allowed", so the response cannot be used to confirm that a record exists.
Separation inside a customer. A manager or owner sees the company's data; a sales rep sees the contacts they own and the drafts they wrote. A colleague's IP address is visible to managers only.
Authentication. Passwords are hashed with PBKDF2-SHA256 at 600,000 iterations with a per-password salt, and are never stored or logged in a readable form. Repeated failures lock an address, and separately lock a source IP address at a higher threshold. Counters live in the database, not in process memory, so several application workers cannot be used to multiply the allowance.
Session handling. Sessions last twelve hours. The cookie is HttpOnly, SameSite=Lax and Secure when served over HTTPS. There is no "remember me" cookie. Deactivating a user ends their open session on their next request.
Request integrity. Every state-changing request must carry a one-time token tied to the session, compared in constant time.
Browser-enforced controls. Every response carries a Content-Security-Policy that allows scripts and styles only from the Platform itself and forbids inline script outright, so text typed into a contact's name cannot execute in a colleague's browser. Framing is denied, MIME sniffing is denied, every unused browser capability is switched off, and pages carrying customer data are marked not to be stored by the browser.
Transport. HTTPS. In staging and production a Strict-Transport-Security header with a one-year lifetime, sent only when the request actually arrived over HTTPS.
Outbound controls. The one setting that turns into a network request to an address a customer typed — the news feed list — is validated when it is saved and again at the moment of the request, refusing anything that is not an ordinary public web address. Messages can only be delivered to approved destinations, and in every environment other than production they can only reach a reserved test domain.
Accountability. An append-only audit trail of every action worth answering for, with who, what, when and from which IP address. Nothing in the Platform updates or deletes a row in it. Payloads are scrubbed of anything whose field name looks like a credential before they are written.
Backups and recovery. Backups are taken with a manifest recording the schema, the migration revision and a row count for every table and every company. A restore is verified by rebuilding the database into a scratch instance and checking the restored rows, the sequences, the schema and that customer separation still holds in the restored data — not by checking that the backup command exited cleanly. Backup files are written with owner-only permissions and retained for 14 days, with the three most recent always kept.
[NEEDS ZACH: whether Railway encrypts the database volume at rest, in writing. Until they confirm it, this section must not claim it.]
[NEEDS ZACH: the organisational half. Who has administrator access, what device they use, whether that device is encrypted and has a screen lock, and whether you want multi-factor authentication on the Railway and GitHub accounts — which a buyer's questionnaire will ask about before it asks about anything in the product. The technical measures above are real; the organisational ones are a question about how you work.]
7. International transfers
[NEEDS ZACH: whether any transfer out of the customer's own country happens at all. It depends entirely on the Railway region, which is why the region is asked for in section 5. If everything stays in the United States and every customer is in the United States, this section is one sentence saying so. If not, the lawyer needs to add the appropriate transfer mechanism, and that is a substantially longer document.]
8. Deletion and return
During the licence. The customer can delete any record from inside the Platform. It goes to a bin, out of every screen and every export immediately, and is recoverable for 30 days. After that a scheduled job removes it permanently, along with everything written about that person: the drafts and sent messages, the tags, the group memberships and the referral records. The audit trail keeps the record that a message was sent; the text of it does not survive.
Export. The customer can export their contacts and jobs to CSV at any time while the account is open, including after giving notice. Exported files are written so that a value beginning with =, +, - or @ cannot be executed as a formula when the file is opened in a spreadsheet.
At the end of the licence. We delete the customer's data. [NEEDS ZACH: on what timetable, and whether the customer gets a window to export first. A common shape is "exportable for 30 days, deleted at 60". Whatever is chosen, I will build it, because nothing enforces it today.]
Backups. A deleted record can persist inside a backup for up to 14 further days before the backup itself is pruned. This is stated rather than hidden because it is true of every system that takes backups and is routinely left out of agreements that promise immediate deletion.
9. Liability, and the limits of this document
[NEEDS ZACH: the liability position, which has to match the Terms of Service, and the insurance position — errors and omissions, and cyber liability. A buyer with an IT department asks for certificates. "None" is a legitimate answer for a first beta customer but it has to be a decision, and it is part of NEEDS ZACH item 7.]
[NEEDS ZACH: the governing law and the courts, matching the Terms of Service.]
Last revised 8 October 2026. This is a draft. It has not been reviewed by a lawyer.