Data processing addendum

This addendum forms part of the terms of service and applies wherever RFP.co processes personal data on a customer’s behalf. It is offered on these terms to every customer without negotiation, so that a small buyer gets the same protections as a large one. If you need it executed as a signed document, write to legal@rfp.co and we will countersign.

1. Roles and scope

The Customer is the controller of personal data contained in Customer Data. RFP.co is the processor. Where the Customer is itself a processor for a third party, RFP.co is a subprocessor and the Customer warrants it has the authority to appoint one.

This addendum applies to processing subject to the EU General Data Protection Regulation, the UK GDPR, the Swiss Federal Act on Data Protection, and U.S. state privacy laws, to the extent each applies. Defined terms not defined here take their meaning from the applicable law.

Data we hold as controller in our own right — account records, billing, support correspondence, website logs — is outside this addendum and is governed by the privacy policy.

2. Instructions

We process personal data only on the Customer’s documented instructions. The terms of service, this addendum, and the Customer’s own use of the platform’s features are those instructions. We will not process for any other purpose, and in particular we will not sell personal data, share it for cross-context behavioural advertising, or retain, use or disclose it outside the direct business relationship.

No model training. Customer Data is not used to train, fine-tune or improve any machine learning model, ours or a subprocessor’s. Where text is sent to a model provider to serve a request the Customer made, our agreement with that provider prohibits training on it.

If we believe an instruction infringes applicable data protection law, we will tell the Customer without undue delay and may pause the affected processing until it is resolved.

Where the law requires us to process for a purpose other than the Customer’s instructions, we will inform the Customer beforehand unless that law prohibits it on important grounds of public interest.

3. Confidentiality of personnel

Access to personal data is limited to personnel who need it to provide or support the platform. Every such person is bound by a written confidentiality obligation that survives their engagement, receives data protection and security training, and holds access under least-privilege, reviewed on a regular cycle and revoked promptly on role change or departure.

4. Security measures

We implement appropriate technical and organisational measures under Article 32 GDPR. The measures in force are set out in Annex II and are specific rather than generic, so that they can be assessed. We may change them, and will not materially reduce the overall level of security during a Customer’s term.

5. Subprocessors

The Customer gives general authorisation for us to engage subprocessors. The current list, with what each receives and where it processes, is at the subprocessor page.

We will give at least 30 days’ notice before adding or replacing a subprocessor, by email to the address a Customer subscribes with on that page. The Customer may object on reasonable data protection grounds within that period. If we cannot resolve the objection, the Customer may terminate the affected part of the service and receive a pro-rata refund of prepaid unused fees — which is the remedy that makes the objection real rather than a formality.

Each subprocessor is engaged under a written contract imposing obligations no less protective than these, and we remain fully liable to the Customer for its performance.

6. International transfers

Where processing involves a transfer of personal data out of the European Economic Area, the United Kingdom or Switzerland to a country without an adequacy decision, that transfer is made under the European Commission’s Standard Contractual Clauses (Decision 2021/914), which are incorporated into this addendum by reference:

• Module Two (controller to processor) where the Customer is a controller.
• Module Three (processor to processor) where the Customer is itself a processor.
• UK International Data Transfer Addendum where the UK GDPR applies.
• For Switzerland, the Clauses apply with references to the GDPR read as references to the FADP and the Federal Data Protection and Information Commissioner as supervisory authority.

For the purposes of the Clauses: Annex I is Annex I below; Annex II is Annex II below; the optional docking clause applies; the governing law is that of Ireland and the forum is the courts of Ireland where the Clauses require an EU member state, and clause 17 and 18 are completed accordingly. Where a Clause conflicts with this addendum, the Clause prevails.

Government access. If we receive a legally binding request from a public authority for personal data we process for a Customer, we will notify the Customer unless prohibited, challenge a request that appears unlawful or excessive, and provide only the minimum the request requires. We maintain no back door, have provided no government with direct or unfettered access to personal data, and will say so on request.

7. Assisting the Customer

Data subject requests. The platform gives the Customer the tools to access, correct, export and delete data in its workspace directly. Where a request cannot be answered that way, we will assist by appropriate technical and organisational measures at no additional charge for a reasonable volume. If a request reaches us directly, we will not respond substantively; we will forward it to the Customer without undue delay.

Impact assessments. We will provide reasonable assistance with data protection impact assessments and prior consultations, taking account of the information available to us.

8. Personal data breach

We will notify the Customer without undue delay, and in any event within 72 hours of becoming aware of a personal data breach affecting Customer Data. 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 — to the extent known at the time, updated as we learn more.

We will not delay a notification to complete an investigation first. Notification is not an admission of fault by either party.

9. Audits

We will make available the information reasonably necessary to demonstrate compliance with this addendum, and will contribute to audits conducted by the Customer or an independent auditor it mandates.

In the first instance we will provide our then-current security documentation and answer a reasonable security questionnaire. Where that is genuinely insufficient for the Customer’s own compliance obligations, the Customer may audit on 30 days’ notice, no more than once a year except after a breach, during business hours, without unreasonable disruption, subject to confidentiality, and not in a way that would give access to another customer’s data. Each party bears its own costs.

10. Return and deletion

On termination the Customer may export Customer Data for 90 days. After that we delete it in the ordinary course. On written request we will delete sooner and confirm when it is done.

Backups are not surgically edited; deleted data leaves them as they expire on their own cycle, and remains subject to this addendum until it does. We may retain what law requires us to retain, for as long as it requires, and for no other purpose.

11. Liability and precedence

Each party’s liability under this addendum is subject to the limitations in the terms of service, except where applicable law does not permit that. Nothing here limits a data subject’s rights under the Standard Contractual Clauses.

In the event of a conflict, the Standard Contractual Clauses prevail over this addendum, and this addendum prevails over the terms of service. Otherwise this addendum is governed by the laws of the State of Arkansas, without regard to its conflict of law provisions, with venue in the state and federal courts located in Benton County, Arkansas, on the basis recited in §16 of the terms of service — RFP.co conducts business in Arkansas, and the parties agree that this agreement bears a reasonable relation to the State of Arkansas.

Annex I — description of processing

Annex II — technical and organisational measures

Stated as specific controls rather than as categories. “Industry standard security measures” is a phrase that survives every audit and answers no question.

Access control

• Passwords are stored as Argon2id hashes with parameters chosen to make verification deliberately expensive. Plaintext passwords are never stored or logged.
• Session tokens are opaque random values stored as keyed hashes, so a copy of the database is not a set of usable sessions. Revocation takes effect immediately — a password reset ejects a session already in flight.
• Sessions expire 30 days after issue and after 14 days of inactivity, whichever is first.
• Optional single sign-on with Google. Sign-in attempts are throttled in the database rather than per process, so the limit holds across every server.
• Role-based permissions are checked server-side on every request. Permissions are held in one catalogue rather than re-derived per route.

Tenant isolation

• Isolation is enforced at the query layer, not the route layer: a scoped database client cannot express an unscoped query, so a forgotten filter fails to return rows rather than returning another tenant’s.
• Every table in the schema is classified by tenancy mode, and a test fails when a new one is added without a classification.
• The isolation suite asks for another tenant’s rows by primary key on every operation — read, update, delete and bulk write — and asserts that each fails.

Encryption

• TLS 1.2 or above for all traffic, with HTTP Strict Transport Security.
• Encryption at rest for databases, object storage and backups.
• Secrets are held in the deployment’s secret store, never in source control.

Integrity and auditability

• Security-relevant actions are written to an append-only audit log that database triggers refuse to update.
• Approvals and content-state changes are recorded in an append-only workflow ledger, so who approved what, against which version, and when it stopped being true, is reconstructable.
• Raw source records and stored document bytes are append-only by trigger. Deletion requires an explicit, transaction-scoped purge mode used only by retention and erasure.

Uploads and content handling

• Uploads are size-checked before bytes are read, and the type is determined from the leading bytes rather than from what the browser claimed.
• Documents are scanned for malware before they are readable. An SVG carrying script, an event handler or an external reference is refused outright rather than sanitised.
• Rendered documents are served in a sandboxed frame with no script execution and no external requests.

Sharing outside the workspace

• A share link is a bearer credential: 256 bits of randomness, stored as a keyed hash, shown once and unrecoverable afterwards.
• Revocation, expiry, password and lockout are re-checked on every request rather than once at the gate, so a link revoked mid-session stops working on the next navigation.
• Never a signed storage URL, because a signed URL cannot be revoked.

Operations

• Separate development, staging and production environments with no shared credentials.
• Changes go through review, automated tests, type checking and linting before deploy.
• Dependencies are monitored for known vulnerabilities and patched on a risk-based cycle.
• Encrypted backups, taken regularly and restore-tested.
• Structured logging with credential redaction. URLs and secrets are redacted before a log line is written.
• A documented incident response process covering detection, containment, notification within the 72-hour window in §8, and post-incident review.

Vendor management

• Subprocessors are assessed before engagement and bound by written terms.
• The public subprocessor list is maintained as the authoritative record of who is engaged.

Contact

Data protection enquiries: privacy@rfp.co. Security: security@rfp.co. Notices: legal@rfp.co.