Scope and order of precedence
This Data Processing Addendum (DPA) forms part of the Terms of Service or other agreement between the Customer and [Legal entity name] (RegSignal) for the RegSignal Service (the Agreement). It applies whenever RegSignal processes Customer Personal Data in providing the Service.
If this DPA conflicts with the Agreement on the processing of personal data, this DPA prevails. If [Transfer mechanism] clauses are incorporated under section 12, they prevail over this DPA where they conflict.
Definitions
- Data Protection Laws: all laws on the processing of personal data that apply to a party's processing under the Agreement, which may include the EU GDPR, the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, and US state privacy laws such as the California Consumer Privacy Act.
- Customer Personal Data: personal data contained in Customer Data (as defined in the Terms) that RegSignal processes on the Customer's behalf.
- Controller, processor, data subject, personal data breach, processing and supervisory authority have the meanings given in the GDPR; service provider has the meaning given in the CCPA.
- Subprocessor: a third party RegSignal engages to process Customer Personal Data.
Roles of the parties
- For Customer Personal Data, the Customer is the controller (or a processor acting for its own controller) and RegSignal is the processor, and under the CCPA a service provider.
- RegSignal is an independent controller for account data, usage events, audit logs, billing data and feedback that it processes for its own purposes of operating, securing and billing the Service, as described in the Privacy Policy. This DPA does not apply to that processing.
- The public regulatory corpus is collected by RegSignal from official publishers and is not Customer Data.
Processing on instructions
- RegSignal processes Customer Personal Data only on the Customer's documented instructions. The Agreement, this DPA, and the Customer's configuration and use of the Service (for example ingesting a document, running an impact analysis, configuring a webhook or connector, or setting retention windows) are the Customer's complete instructions.
- RegSignal does not sell or share Customer Personal Data, does not retain, use or disclose it outside the direct business relationship with the Customer, does not combine it with personal data from other sources except as the Service requires, and does not use it to train or fine-tune machine learning models.
- RegSignal will tell the Customer if, in its opinion, an instruction infringes Data Protection Laws, and may suspend that processing until the instruction is confirmed or changed.
- If the law requires RegSignal to process Customer Personal Data other than on instructions, RegSignal will tell the Customer first unless the law prohibits it.
Personnel
RegSignal limits access to Customer Personal Data to personnel who need it to provide, support or secure the Service, who are bound by confidentiality obligations, and who have acknowledged RegSignal's internal acceptable use policy, which forbids reading customer documents except to do their job.
Security
RegSignal implements and maintains the technical and organizational measures in Annex 3. RegSignal may update those measures as long as the overall level of protection is not reduced.
Subprocessors
- The Customer gives RegSignal general authorization to engage the Subprocessors listed in Annex 2, which is maintained on the Subprocessors page.
- RegSignal will notify the Customer of any intended addition or replacement of a Subprocessor at least [Notice period for subprocessor changes] in advance by [Subprocessor change notification mechanism].
- The Customer may object in writing on reasonable data protection grounds within that notice period. The parties will discuss the objection in good faith; if they cannot resolve it, the Customer may terminate the affected part of the Service without penalty and receive a refund of prepaid fees for the unused period.
- RegSignal imposes data protection obligations on each Subprocessor that are no less protective than this DPA, and remains responsible for its Subprocessors' performance of those obligations.
Data subject requests and assistance
- The Service lets the Customer find, export and delete Customer Personal Data itself: internal signals, conversations, profiles, tasks and members can be deleted in the console or API, and data can be retrieved through the API.
- If RegSignal receives a request from a data subject about Customer Personal Data, it will direct the data subject to the Customer and will not respond itself except to confirm the referral, unless the Customer instructs otherwise.
- Taking into account the nature of the processing and the information available to it, RegSignal will provide reasonable assistance with data subject requests, data protection impact assessments and prior consultations with supervisory authorities. [Whether assistance beyond self-service tools is chargeable.]
Personal data breaches
- RegSignal will notify the Customer without undue delay, and in any event within [Breach notification period, 72 hours after confirmation proposed], after becoming aware of a personal data breach affecting Customer Personal Data.
- The notice will describe, as far as then known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. RegSignal will provide further information as it becomes available.
- Notice is sent to the organization owner's email address and any security contact the Customer has given. Notifying a breach is not an admission of fault.
Deletion and return of data
During the term. The Customer can delete Customer Data at any time and can set retention windows per data class. A nightly job deletes data older than each window. Every real run writes a retention.purged audit event and stores a deletion receipt, available to the owner in the console and through GET /v1/orgs/current/retention/receipt.
On termination. Before the Agreement ends, the Customer can retrieve Customer Data through the API for [Export window]. Within [Post-termination deletion period] after the Agreement ends, or at once if an owner deletes the organization first, RegSignal deletes the organization, which deletes every organization-scoped record from the primary database: internal signals and their chunks and embeddings, product profiles, impact matches, triage notes, tasks, conversations, saved filters, webhooks and deliveries, connector settings, API keys, memberships and audit events.
Backups. Deleted data leaves the daily database backups when the backup window rolls over, 7 days after deletion at the time of writing. Backups are not restored except for disaster recovery, and any data restored from them is deleted again.
Deletion receipt. RegSignal provides a deletion receipt stating what was deleted (data classes and row counts), when, and the date on which the deleted data leaves backups. Receipts for retention runs are generated automatically. For deletion of a whole organization on termination, RegSignal sends the receipt to the owner's email address within [Deletion receipt delivery period]. [Engineering: organization-deletion receipts are not yet generated automatically; confirm the process before general availability.]
Exceptions. RegSignal may keep Customer Personal Data where the law requires it, and billing records held by Stripe are kept as required for tax and accounting. Anything retained stays protected by this DPA and is used only for that purpose. Records at Subprocessors with fixed retention (error reports, email delivery logs, language-model provider logs) expire under the periods on the Privacy Policy.
Information and audits
- RegSignal will make available information reasonably necessary to demonstrate compliance with this DPA, including its security documentation and responses to a reasonable security questionnaire once per year.
- RegSignal's SOC 2 Type I (Security) is in progress. No SOC 2 report exists yet, and RegSignal holds no certification today. When a report is issued, RegSignal will make it available under confidentiality terms, and it will be the primary way RegSignal meets audit requests.
- Where the information above is not enough to meet a Customer obligation under Data Protection Laws, the Customer may request an audit on at least [Audit notice period] notice, no more than once in any twelve months, during business hours, at the Customer's cost, by an auditor bound by confidentiality. [Audit scope and cost terms to be confirmed by counsel.]
International transfers
Customer Personal Data is stored and processed in the United States (see Annex 1). Where Data Protection Laws require a transfer mechanism for data leaving the EEA, the UK or Switzerland, the parties rely on [Transfer mechanism, for example the EU Standard Contractual Clauses (Module Two, and Module Three where the Customer is a processor) with the UK International Data Transfer Addendum and Swiss amendments, to be confirmed by counsel], which are incorporated by reference with the details in Annexes 1 to 3.
Liability and term
Each party's liability under this DPA is subject to the limitation of liability in the Agreement [unless counsel decides that data protection liability is carved out]. This DPA lasts for as long as RegSignal processes Customer Personal Data and ends when deletion under section 10 is complete.
Annex 1: Details of processing
| Item | Details |
|---|---|
| Subject matter | Provision of the RegSignal regulatory intelligence Service to the Customer |
| Duration | The term of the Agreement plus the deletion period in section 10 |
| Nature of processing | Storage; text extraction and chunking; computing search embeddings with an open-source model inside RegSignal's services; classification, summarisation, impact assessment, question answering and translation by a language model; matching against product profiles; delivery to destinations the Customer configures; deletion |
| Purpose | To let the Customer detect regulatory change, understand its impact on the Customer's products and act on it, as the Customer directs through the Service |
| Categories of data subjects | The Customer's Users; individuals named in documents the Customer submits (for example supplier, regulator or staff contacts); individuals named in product profiles, questions, triage notes and tasks; recipients of notifications the Customer configures |
| Categories of personal data | Names, business contact details, job titles and any other personal data contained in submitted documents, profiles, questions, answers, notes and tasks; User identifiers and IP addresses recorded in the audit log in connection with Customer Data |
| Special categories | Not intended. The Customer agrees not to submit special categories of personal data or data about criminal convictions unless agreed in writing |
| Frequency | Continuous, for as long as the Customer uses the Service |
| Retention | Per the Customer's retention settings and section 10; defaults in the Privacy Policy |
| Location | United States: Supabase (AWS us-west-2, Oregon) for storage, Render (Oregon) for compute, Anthropic (US) for language-model processing |
| Customer contact | The organization owner, or [Customer data protection contact] |
| RegSignal contact | [Privacy contact email] |
Annex 2: Subprocessors
The current list of Subprocessors, with the purpose, data categories and location of each, is maintained on the Subprocessors page and is incorporated into this Annex. At the date of this DPA it names Supabase, Render, Anthropic, Sentry, Resend, Stripe (when billing is enabled), Jina, Exa, GitHub and Google Workspace. Of these, Jina, Exa and GitHub receive no Customer Personal Data.
Annex 3: Technical and organizational security measures
These measures describe the Service as operated at the date of this DPA. Measures that are still in progress are listed separately so that the Customer can see the current state.
| Area | Measures |
|---|---|
| Tenant isolation | Every customer object is scoped by organization id, and every query over the corpus passes through one scoping function. Internal documents are visible only to the submitting organization in the feed, search, Ask, impact matching and webhooks. The database's PostgREST interface is closed: row level security is enabled on every table with no policies and grants are revoked from public roles; all access goes through the API |
| Identity and access | Console sign-in through Supabase Auth with email magic link, Google, or SAML 2.0 single sign-on. Four roles (owner, admin, analyst, viewer) enforced by the API on every endpoint. API keys are random, stored only as a SHA-256 hash, shown once and revocable; creation and revocation are audited |
| Encryption | TLS for all traffic to the API, console and MCP server, with HSTS; TLS from services to the database; HTTPS for outbound webhook, email and language-model calls. Database, backups and authentication data encrypted at rest by Supabase on AWS; hosting disks and environment variables encrypted at rest by Render |
| Secrets | Production secrets held only in the hosting provider's environment groups and the operators' password manager, never in source code. Webhook signing secrets can be rotated per endpoint |
| Webhooks | Every delivery signed with HMAC-SHA256 over the timestamp and raw body, with a 300-second replay window; delivery attempts logged with status and response time |
| Logging and monitoring | Audit event written in the same transaction as every change (actor, action, target, metadata, client IP, request id). Error monitoring with personal data collection off, request bodies never attached and credential headers scrubbed. Operator alerts for failing sources and exhausted language-model budget. Request bodies, tokens and document text are not written to log lines |
| Application hardening | Security headers on API responses (nosniff, strict referrer policy, frame denial, permissions policy, no-store on API responses); request bodies capped at 2 MB; forwarded client IPs trusted only from configured proxies; explicit CORS allow-list; daily language-model spend ceiling |
| Change management | All changes through pull requests and CI (linting, tests, type checks, container builds, schema drift check); production releases deployed from pinned version tags; migrations run before deploy so a failed migration leaves the previous version serving |
| Backups and continuity | Automated daily database backups kept in the same region; infrastructure declared in code so the stack can be rebuilt on another provider or region |
| Data minimisation | No member identities or API keys placed in language-model prompts; search embeddings computed in RegSignal's own services; subprocessors receive only the data their function needs |
| Deletion | No soft delete for customer content; per-organization retention windows with a nightly purge and deletion receipts; organization deletion cascades to every organization-scoped table |
| Vendor management | Subprocessors assessed before use and annually; subprocessor list published |
| Area | Status |
|---|---|
| SOC 2 Type I (Security) | In progress, target Q1 2027. No report exists yet |
| Multi-factor authentication | Not yet enforced for console users; customers using SAML SSO inherit their identity provider's MFA |
| Content Security Policy | Deployed in report-only mode on the console; switching to enforcing is a tracked milestone |
| Point-in-time recovery and restore testing | Point-in-time recovery being enabled; first documented restore test scheduled |
| Field-level encryption of webhook secrets | On the roadmap |
| Branch protection with required reviews | Being enabled |
| External penetration test | Not yet performed; budgeted |