Data Processing Addendum.
What we process, and what never reaches us.
01 · Scope, roles and the boundary between them
This Data Processing Addendum (the “Addendum”) is entered into between the customer identified in the main agreement (the “Customer”), acting as controller, and Registered company name — to be completed , Legal form — to be completed , of Registered address — to be completed , tax identification number CIF/NIF — to be completed (“RERUN”), acting as processor. It forms part of the RERUN Terms of Service — or of the signed enterprise agreement that replaces them, where one exists — and takes effect for a Customer on the date that agreement does. It governs any processing of personal data carried out by RERUN on the Customer's behalf under that agreement.
Where this Addendum conflicts with another document, the order of precedence is: the Standard Contractual Clauses first, where they apply; then a signed enterprise agreement, to the extent it expressly addresses the point; then this Addendum; then the Terms of Service. On any question of data protection, this Addendum prevails over the Terms of Service. Liability under this Addendum is subject to the limitations and exclusions of the main agreement, which apply to both documents in aggregate rather than separately, and is capped at Liability cap — to be completed . That cap does not limit any liability the GDPR or other applicable law does not permit to be limited, including a data subject's right to compensation under Article 82. This Addendum is governed by the law of Spain, and the competent courts are Competent courts — to be completed .
1.1 Three distinct positions, not one
RERUN is an unusual case for a data processing addendum, because the product splits into two planes that never exchange the data that matters most. Getting the roles right therefore means distinguishing three positions rather than assuming a single one applies throughout.
| Data | Where it lives | RERUN's role |
|---|---|---|
| Account identity, organization records, subscription and entitlement state, device activation records, portal session and audit records | The RERUN licence control plane (this service) | Processor, on the Customer's documented instructions. The Customer is the controller. |
| Test evidence: URLs under test, flows, DOM snapshots, screenshots, cookies, browser session state, run results, AI provider keys | Only the Customer's own Mac | Neither controller nor processor. RERUN never receives this data — see 1.3. |
| Records RERUN keeps for its own purposes: invoicing and accounting records, service security and abuse-prevention logs | The RERUN licence control plane and its sub-processors | Controller in its own right, for the limited purposes set out in the Privacy Policy. |
1.2 Where RERUN is a processor
The licence control plane holds the commercial relationship: verified accounts, organizations and seats, the one-time seven-day trial, annual Stripe subscriptions, device activation, signed device entitlements and release metadata. The personal data in those records belongs to the Customer's own staff, and RERUN processes it solely to operate the licence for the Customer. Annex I describes that processing in full.
1.3 Where RERUN is neither controller nor processor
This is the crux of the document, so it is stated plainly. RERUN is a local-first desktop runtime. Recording, replay and evidence all execute on the machine the Customer controls. There is no hosted execution backend, and the licence control plane deliberately exposes no endpoint for browser URLs, flows, DOM, screenshots, cookies, browser session state, run evidence or AI provider keys.
In consequence, for the personal data that may appear inside the Customer's test evidence — the contents of the applications the Customer tests, the accounts it tests with, and anything those pages display — RERUN is neither controller nor processor. RERUN does not determine the purposes or means of that processing, and it does not process that data on the Customer's behalf, because it never receives it in the first place. RERUN's position is that of a software supplier whose product the Customer operates on its own equipment; the Customer is the sole controller of that data and its processing is outside the scope of this Addendum.
Two honest consequences follow, and they cut both ways:
- RERUN cannot help with what it cannot see. RERUN cannot search, export, correct, produce or delete test evidence, because it holds none. Sections 07 and 09 are limited accordingly.
- Support channels are the exception to watch. A support process that invites customers to send diagnostic bundles, screen recordings or evidence directories would move that data across the boundary. RERUN's support runs by email at Support email — to be completed : there is no diagnostic upload endpoint, no crash-report collector and no telemetry, and RERUN does not ask for evidence directories, run artefacts or screen recordings. If a Customer attaches one anyway, it is treated as the Customer's confidential information, used only to answer that ticket, not copied into any other system, and deleted when the ticket is closed. A Customer that needs this never to happen should redact or withhold the attachment.
1.4 AI providers are the Customer's own relationship
AI is off unless a flow contains an explicit AI step, and AI interaction is experimental and requires an internal opt-in the shipped application does not enable. Where the Customer does enable an AI step, the request goes from the Customer's machine to the Customer's own provider account under the Customer's own API key — OpenAI or Anthropic — carrying bounded, redacted context for that single assertion. It does not pass through RERUN's servers. RERUN is neither controller nor processor for that egress, and it is neither a sub-processor of the Customer's model provider nor a party to the Customer's contract with it. The Customer's agreement with its provider governs that processing, and the Customer should assess it separately.
Local orchestration that calls a remote model is still remote inference and is not described here as on-device AI.
1.5 Privacy contact
Requests, notices and questions under this Addendum go to Privacy contact email — to be completed . No Data Protection Officer has been appointed: this processing does not meet the Article 37 criteria that would require one. No Article 27 representative is appointed either, because RERUN is established in the European Union and Article 27 does not apply to it.
02 · Subject matter, duration, nature and purpose
The following describes the processing RERUN carries out as processor. It is derived from the control plane's actual database schema, not from a template; the field-level detail is in Annex I.
2.1 Subject matter and duration
Subject matter: operation of the RERUN commercial control plane — accounts, organizations, seats, trials, annual subscriptions, device activation, signed licence entitlements and release access.
Duration: for the term of the Customer's subscription or trial, and thereafter until the account, licence and device records are deleted — 30 days from termination — save for records RERUN must retain to meet its own legal obligations, principally invoicing and accounting records, which are kept for the statutory retention period for accounting records.
2.2 Nature and purpose
- Creating and authenticating accounts, including signed email verification and password reset.
- Maintaining organizations, roles, seat limits and signed seven-day Team invitations.
- Starting and tracking the one-time seven-day trial per organization.
- Creating annual Stripe Checkout and Billing Portal sessions and projecting the resulting subscription, invoice, dispute and refund events onto licence state.
- Registering devices, issuing and refreshing Ed25519-signed, device-bound entitlements, and revoking them on deactivation.
- Serving signed macOS release metadata and short-lived, organization-bound update capabilities.
- Keeping an audit trail of the account, membership, device and billing actions listed in Annex I, and applying rate limits and abuse controls.
The control plane performs no profiling, no automated decision-making producing legal effects, no advertising and no analytics on this data.
2.3 Categories of data subjects
- The Customer's own staff who register or are invited to the Customer's organization and hold a seat — owners, administrators and members.
- People the Customer has invited who have not yet accepted, whose work email address is held while the invitation is pending.
- The Customer's billing contact, to the extent that person is identifiable from the Stripe customer record.
The control plane holds no data about the Customer's end users, customers or test subjects. It has no route by which such data could arrive.
2.4 Categories of personal data
- Identity: name, work email address, email verification timestamp, and the password stored only as a one-way hash (bcrypt under the default configuration). The clear-text password is never stored and is never returned by the portal or the API.
- Membership: organization name and slug, the person's role in that organization, invitation email, inviting user, and invitation expiry, acceptance or revocation timestamps.
- Device identifiers: an installation UUID, a device label supplied by the desktop application at activation, platform, application version, the device's public key and its SHA-256 hash, and activation, last-seen and revocation timestamps. Single-use activation nonces are held briefly to prevent replay.
- Entitlement records: lease identifiers, a hash of the signed claims, and issue, refresh, expiry and revocation timestamps.
- Authentication artefacts: scoped desktop API tokens stored as hashes with their abilities and last-used timestamp, and browser session records containing the user identifier, IP address, user agent and last-activity timestamp.
- Commercial records: plan, licence status, seat limit, devices per seat, trial, subscription-period and grace timestamps, the Stripe customer, subscription, price, product, invoice and event identifiers, and the payment method's brand and last four digits. The organization's licence key is held as a SHA-256 hash plus an application-encrypted ciphertext.
- Audit records: actor, organization, action, subject and bounded metadata (for example the device platform and application version, or the source of a deactivation) with timestamps.
Not processed: no special categories of personal data under Article 9, no criminal-offence data under Article 10, and no children's data — the service is sold to organizations for professional use. No payment card numbers: card details are entered only in Stripe-hosted Checkout and Portal pages and never reach RERUN's servers. And, as set out in section 01, no test evidence of any kind.
03 · Processing on documented instructions
RERUN processes personal data only on the Customer's documented instructions, including as to international transfers, unless required to do otherwise by Union or Member State law. Where such a legal requirement applies, RERUN will inform the Customer of it before processing, unless that law prohibits the notification on important grounds of public interest.
The Customer's documented instructions consist of this Addendum, the main agreement, and the
Customer's use of the documented product surface: the browser portal, the desktop application
and the /api/v1 endpoints. Configuration choices the Customer makes through those
surfaces — inviting a member, removing a member, deactivating a device, starting an annual
checkout — are instructions. Any additional instruction outside that surface must be agreed in
writing and may be subject to a charge if it requires work RERUN does not otherwise perform.
RERUN will inform the Customer if, in its opinion, an instruction infringes the GDPR or other applicable data protection law. RERUN does not sell personal data, does not use it for its own marketing, and does not use control-plane personal data to train machine-learning models.
04 · Confidentiality of personnel
RERUN ensures that persons authorised to process the personal data covered by this Addendum have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is limited to those who need it to operate, support and secure the service.
In practice: everyone with access to the control plane is bound by a written confidentiality undertaking in their employment or contractor agreement, and that obligation survives the end of the engagement. Administrative access to production infrastructure, to the database and to the secret store is granted to named individuals only, is protected by multi-factor authentication, uses no shared administrator account, is limited to what the person's role requires, and is withdrawn when they change role or leave. RERUN does not operate a certified security-awareness training programme or a background-check regime, and claims neither.
05 · Security of processing — and its limits
RERUN implements appropriate technical and organisational measures under Article 32. Annex II lists them measure by measure, and each entry describes something that exists in the product today rather than an aspiration. The summary below is the shape of it.
5.1 What is implemented
- In transit: the service is served over a canonical HTTPS origin with canonical-host enforcement; production sends HSTS and a restrictive Content-Security-Policy, and session cookies are secure, HTTP-only and SameSite-constrained. A production boot fails closed if these are not configured.
- Credentials: passwords are stored as one-way hashes and hidden from serialization; desktop API tokens are scoped and stored hashed; the organization licence key is stored as a hash plus application-encrypted ciphertext.
- Provider keys on the desktop: a configured AI provider key is protected by the operating system's secure storage through Electron
safeStorageand is never returned to the renderer process. - Signed entitlements: device entitlements are Ed25519-signed and device-bound, with bounded offline leases, revocation, and a monotonic high-water timestamp on the client so moving the clock backwards cannot revive an expired lease. Signing private keys live in the deployment's secret store and never in the desktop build, CI artefacts or source control.
- Evidence on the Customer's machine: run directories use owner-only permissions (
0700) and artefact files0600where the platform supports it; privacy mode is on by default and masks form fields and editable regions in screenshots and DOM snapshots, removes fill and select values from results, and redacts common bearer, API-key, JWT, email, secret-assignment and sensitive-query patterns; Playwright trace capture is off by default because a trace can preserve authenticated session state. - Integrity of the commercial state: Stripe webhook signatures are verified, event identifiers are recorded and licence transitions applied idempotently with reordered-event protection; account, membership, device and billing actions are recorded as audit events.
- Abuse resistance: CSRF and session protection on the portal, endpoint-specific throttling, and single-use device nonces.
5.2 What RERUN does not claim
A DPA that overstates security is worse than one that is candid, so the limitations are stated here rather than buried:
- RERUN does not encrypt the evidence store. Evidence at rest on the Customer's machine relies on the operating system and on the Customer's own full-disk encryption. Evidence encryption independent of the operating system is not a feature of the Service.
- RERUN holds no security certification. No ISO 27001, SOC 2, HIPAA or equivalent certification or attestation is held or claimed, and none is implied by this Addendum. No external security review of the application has been completed.
- No air-gap, no Zero Data Retention, no tamper-proof artefacts. The embedded browser and Playwright still contact the application under test and its dependencies; “local-first” describes the RERUN control plane, not an air-gapped browser.
- Redaction is defence in depth, not a guarantee. Privacy mode cannot guarantee that arbitrary page content contains no sensitive information. Full traces and runs with privacy mode disabled should be treated as sensitive by the Customer.
- Some capabilities are outside the scope of the Service. Managed secret vaults, MDM packages, scheduled runs, team sync and signed reports are not features of RERUN, and nothing in this Addendum should be read as offering them.
- Resilience commitments are not implied. Database backups are taken and rotated by the hosting provider named in Annex III, on that provider's own schedule, and their encryption at rest is whatever that platform provides. RERUN commits to no backup frequency, no retention window and no restore guarantee. There is no documented disaster recovery plan, no recovery time objective and no recovery point objective, and none is offered under this Addendum — a Customer that needs contractual resilience commitments should not read them into this document.
5.3 Data minimisation as an architectural measure
The most consequential security measure in this Addendum is the absence of an endpoint. Because the control plane has no API for flows, URLs, DOM, screenshots, cookies or provider keys, a compromise of RERUN's servers would not expose the Customer's test evidence, session state or model keys. That is a design property of the system, and it is verifiable in the source.
06 · Sub-processors
The Customer grants RERUN general written authorisation to engage sub-processors. RERUN imposes on each sub-processor data protection obligations no less protective than those in this Addendum and remains fully liable to the Customer for their performance.
The sub-processors actually used are the payment processor, the infrastructure host and the transactional email provider. They are identified in Annex III, which is the authoritative list.
RERUN will inform the Customer of any intended addition or replacement of a sub-processor by email to the administrative contact on record, at least 30 days before that sub-processor begins processing, giving the Customer the opportunity to object on reasonable data protection grounds. An objection is made in writing within that period, with its reasons. RERUN will work with the Customer in good faith to address it — by proposing an alternative or a change to the arrangement — and where no reasonable resolution is found, the Customer may terminate the affected subscription and receive a refund of fees prepaid for the unused remainder of the term. That is the Customer's remedy for an unresolved objection.
For the avoidance of doubt, and as set out in section 1.4, an AI model provider the Customer chooses to use is not a RERUN sub-processor. That request originates on the Customer's machine, under the Customer's own account and API key, and never passes through RERUN's infrastructure.
07 · Assistance with data subject requests
Taking into account the nature of the processing, RERUN assists the Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling the Customer's obligation to respond to requests to exercise rights under Chapter III of the GDPR.
Much of that capability is in the Customer's own hands already. Through the portal, an organization owner or administrator can review members and pending invitations, revoke an invitation, remove a member — which also revokes that person's organization devices and leases — and deactivate a device. Each account holder can view and correct their own name and email and change their password.
Where a request cannot be satisfied through those controls, RERUN will assist on the Customer's documented instruction within ten business days of receiving it, and sooner where the Customer's own one-month deadline under Article 12(3) requires it and the Customer says so. Assistance of this kind carries no charge unless a request is manifestly unfounded, excessive or repetitive. If a data subject contacts RERUN directly about processing carried out for the Customer, RERUN will not respond on the substance and will refer the request to the Customer without undue delay.
RERUN also assists the Customer, taking into account the nature of the processing and the information available to it, with the Customer's obligations under Articles 32 to 36 — security, breach notification and data protection impact assessments. The limit is the boundary described in section 01: RERUN cannot assist with access, rectification, erasure or portability requests concerning test evidence, because it holds none. Those requests are executed by the Customer on its own machines, using the application's local retention and evidence controls.
08 · Personal data breach
RERUN notifies the Customer without undue delay, and in any event 72 hours from becoming aware of a personal data breach affecting personal data processed under this Addendum. Notification goes to the Customer's administrative contact on record.
The notification describes, to the extent available at the time and supplemented as further information emerges: the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point for further information. RERUN does not notify the supervisory authority or data subjects on the Customer's behalf unless instructed to do so in writing.
The Customer may report a suspected security issue to Security contact email — to be completed . Reports are acknowledged and the reporter is kept informed while the issue is investigated. There is no bug bounty and no formal vulnerability disclosure programme.
A breach of the Customer's own machines, network or test environments — including the evidence directories the desktop application writes — is not a breach of RERUN's processing, because that data is never in RERUN's custody. RERUN will nevertheless assist the Customer's investigation as far as the information available to it allows.
09 · Deletion and return on termination
On termination or expiry of the main agreement, and at the Customer's choice, RERUN deletes or returns the personal data it processes on the Customer's behalf, and deletes existing copies, within 30 days from termination. A return is made as a structured, machine-readable export — JSON or CSV — of the account, organization, membership, device activation, entitlement and audit records held for that Customer, and must be requested in writing before that period ends. Deletion takes effect in live systems on execution and works out of backups as they rotate. All of this is subject to Union or Member State law requiring continued storage. Where such a requirement applies — principally invoicing and accounting records — RERUN retains only what that law requires, for the statutory retention period for accounting records, and continues to protect it under this Addendum.
On termination, licence leases and device entitlements are revoked, which is what causes the desktop application to fail closed once its bounded offline lease expires.
The honest note. RERUN cannot delete or return the Customer's test evidence, recorded flows, session state or provider keys, because they were never in RERUN's possession. They are on the Customer's machines and remain there after termination, under the Customer's exclusive control. Deleting them is the Customer's operation, performed with the application's local retention controls, the evidence dossier or the Customer's own tooling. Stripe also retains billing records under its own legal obligations as described in Annex III.
10 · Audits and information
RERUN makes available to the Customer the information necessary to demonstrate compliance with Article 28 and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates. The terms are these: one audit in any twelve-month period, on at least 30 days' written notice, during business hours, conducted without unreasonable disruption to the service and under a confidentiality undertaking covering everything it discloses. Its scope is the processing described in this Addendum; it does not extend to another customer's data, to RERUN's own commercial records, or to infrastructure operated by a sub-processor, for which that sub-processor's own audit materials are made available instead. Each party bears its own costs, save that the Customer reimburses RERUN's reasonable costs for a repeat audit in the same period, and RERUN bears its own where an audit finds material non-compliance. A supervisory authority exercising its own powers is not limited by this paragraph.
In the first instance RERUN satisfies information requests through this Addendum and its annexes, the published technical documentation describing the data boundary, and written responses to the Customer's security questionnaires. RERUN holds no third-party certification or audit report — no ISO 27001 certificate, no SOC 2 report — and cannot offer one in place of an audit. Where a Customer requires independent assurance, the honest answer is that RERUN has not committed to obtaining a third-party audit or certification and gives no date for one. A Customer whose own compliance programme depends on such a report should treat that as an open gap and rely on the audit right above instead.
11 · International transfers
RERUN does not transfer personal data processed under this Addendum outside the European Economic Area except in accordance with Chapter V of the GDPR. Where such a transfer occurs and no adequacy decision covers it, it is made under the Standard Contractual Clauses of Implementing Decision (EU) 2021/914 — Module Two (controller to processor) between the Customer and RERUN, and Module Three (processor to processor) between RERUN and a sub-processor — incorporated into this Addendum by reference, completed by Annex I and Annex II, with the docking clause in Clause 7 applying and option 2 of Clause 9(a) selected for sub-processor authorisation. Where United Kingdom or Swiss data is involved, the UK International Data Transfer Addendum and the Swiss adaptations respectively apply to those Clauses.
The transfers that can arise in practice are determined by the sub-processors named in Annex III and their processing locations; the control plane itself is hosted by DigitalOcean in Frankfurt, Germany (EU). Support and administration of the control plane are carried out from within the European Economic Area: there is no routine administrative access from outside it, and this Addendum is updated before any such arrangement changes.
RERUN carries out and documents a transfer impact assessment where one is required, and will provide it to the Customer on request. Note again that the Customer's test evidence never crosses a border because of RERUN — it does not leave the machine that produced it. Where the Customer enables an AI step, any transfer to the Customer's chosen model provider is governed by the Customer's own agreement with that provider, not by this Addendum.
12 · Language of this Addendum
This Addendum, including its annexes, is published in English and in Spanish. Both versions state the same obligations. Where a discrepancy between them changes the meaning of a provision, the version that prevails is Prevailing language — to be completed , and the other is read as a translation of it. Where the Standard Contractual Clauses apply, the Clauses themselves are governed by the official language versions of Implementing Decision (EU) 2021/914, and this paragraph does not displace them. Nothing here removes a data subject's right to be given information in a language they understand.
Annex I — Description of the processing
Part A · The parties
| Role | Party | Details |
|---|---|---|
| Controller / data exporter | The Customer | The Customer as identified in the main agreement: its legal name and registered address, and the administrative contact recorded on the account, who acts as the Customer's contact person for this Addendum. Acceptance of the main agreement is the Customer's signature for these purposes. |
| Processor / data importer | RERUN | Registered company name — to be completed , Legal form — to be completed , of Registered address — to be completed , tax identification number CIF/NIF — to be completed . Contact for this Addendum: Privacy contact email — to be completed . Role: processor and, where the Clauses apply, data importer. Acceptance of the main agreement is RERUN's signature for these purposes. |
Part B · Description of the processing
| Item | Description |
|---|---|
| Categories of data subjects | The Customer's own staff holding a seat in the Customer's organization (owners, administrators, members); people invited by the Customer whose invitation is still pending; the Customer's billing contact. |
| Categories of personal data | Identity (name, work email, email verification timestamp, hashed password). Membership (organization, role, invitation email and state). Device identifiers (installation UUID, device label, platform, application version, device public key and its SHA-256 hash, activation, last-seen and revocation timestamps, single-use nonces). Entitlement records (lease identifiers, claims hash, issue/refresh/expiry/revocation timestamps). Authentication artefacts (hashed scoped API tokens and their abilities; browser session records with user identifier, IP address, user agent and last activity). Commercial records (plan, licence status, seat limit, devices per seat, trial and subscription timestamps, Stripe customer/subscription/price/product/invoice/event identifiers, payment method brand and last four digits, hashed and encrypted licence key). Audit records (actor, organization, action, subject, bounded metadata, timestamp). |
| Sensitive data | None. No Article 9 special categories, no Article 10 criminal-offence data, no children's data, no payment card numbers, and no test evidence. |
| Frequency of the processing | Continuous for the duration of the subscription or trial: on account and portal use, on device activation and periodic lease refresh, and on receipt of Stripe billing events. |
| Nature of the processing | Collection, storage, organisation, consultation, use, transmission to the sub-processors in Annex III, restriction, erasure and destruction — by automated means. |
| Purpose of the processing | Operating the licence control plane: account creation and authentication, organization and seat administration, trial administration, annual subscription billing, device activation and signed entitlement issuance and revocation, release access, audit logging, and security and abuse prevention. |
| Duration of the processing | The term of the subscription or trial, plus 30 days from termination for the account, licence and device records, plus the statutory retention period for accounting records for the accounting records RERUN must retain by law. |
| Processing by sub-processors | As stated for each sub-processor in Annex III, for the duration of RERUN's contract with that sub-processor and no longer than the retention above. |
| Expressly outside this description | URLs under test, recorded flows, DOM snapshots, screenshots, cookies, browser session state, run evidence and AI provider keys. The control plane has no endpoint that can receive them and they remain on the Customer's machines. |
Part C · Competent supervisory authority
For RERUN as processor and data importer, the competent supervisory authority is the Agencia Española de Protección de Datos (AEPD), www.aepd.es. For the Customer as controller and data exporter, it is the authority of the Member State in which the Customer is established or, where the Customer is not established in the Union but the Clauses apply, the authority of the Member State in which its Article 27 representative is established.
Annex II — Technical and organisational measures
Each measure below is implemented in the product today. The third column records the limit of the measure, because a measure described without its boundary is a claim rather than a control.
| Measure | How it is implemented | Limit |
|---|---|---|
| Minimisation by architecture | The control plane exposes no endpoint for flows, URLs, DOM, screenshots, cookies, browser session state or provider keys. Execution has no hosted backend. | The embedded browser and Playwright still contact the application under test and its dependencies. |
| Encryption in transit | Canonical HTTPS origin with canonical-host enforcement; HSTS in production; secure, HTTP-only, SameSite-constrained session cookies; production boot fails closed without them. | — |
| Encryption and hashing at rest | Passwords stored as one-way hashes and hidden from serialization; desktop API tokens stored hashed; licence key stored as SHA-256 hash plus application-encrypted ciphertext; checkout URLs encrypted at the application layer. | Database-level and disk-level encryption are whatever the hosting platform named in Annex III provides for its managed storage and its backups. RERUN adds no encryption layer of its own across the database as a whole, and does not claim one. |
| Provider key protection on the desktop | An AI provider key is stored through Electron safeStorage, which uses the operating system's secure storage, and is never returned to the renderer process. |
Protection is that of the operating system keychain on the Customer's machine. |
| Device entitlement integrity | Ed25519-signed, device-bound entitlements; bounded offline leases; revocation on deactivation; a monotonic high-water timestamp on the client so a backwards clock cannot revive an expired lease; signed release manifests and five-minute organization- and version-bound update capabilities. | Signing keys must be escrowed and rotated by the operator; loss prevents new leases and leakage requires immediate rotation. |
| Key custody | Licence signing private keys live only in the deployment's secret store. Only the HTTPS origin, public keys and key identifiers are embedded in the signed desktop build. Rotation publishes an overlapping public-key ring before the new key identifier is issued. | Custody of the secret store is an operational control: the keys live in the deployment platform's encrypted environment configuration, and administrative access to it is limited to named operators using multi-factor authentication. |
| Application hardening | Restrictive Content-Security-Policy with a nonce rather than unsafe-inline, frame-ancestors 'none', nosniff, X-Frame-Options: DENY, a strict Referrer-Policy, a Permissions-Policy denying camera, microphone and geolocation, and Cache-Control: no-store on portal responses. |
— |
| Access control and authentication | Verified email before a trial can start; session and CSRF protection on the portal; scoped Sanctum tokens for the desktop; role-based organization membership with owner-only administration; single-use device nonces; endpoint-specific rate limiting on authentication, registration, activation and licence endpoints. | Administrative access to the production environment itself is granted to named individuals with multi-factor authentication, with no shared administrator account, and is withdrawn on a change of role or departure, as described in section 04. |
| Billing integrity | Card data is entered only in Stripe-hosted Checkout and Portal. Webhook signatures are verified, event identifiers recorded, and licence transitions applied idempotently with reordered-event protection. | — |
| Logging and traceability | Audit events for registration, password reset, device activation and deactivation, invitation creation, acceptance and revocation, member removal, checkout start and Stripe-driven billing transitions. | Audit events are kept for the life of the organization and deleted with it; application logs and browser session records are kept only as long as they are useful for security and troubleshooting, and are rotated on the hosting platform's schedule. |
| Evidence protection on the Customer's machine | Privacy mode on by default: masked form fields and editable regions in screenshots and DOM snapshots, fill and select values removed from results, redaction of common bearer, API-key, JWT, email, secret-assignment and sensitive-query patterns including nested frames; owner-only run directories (0700) and artefacts (0600); Playwright trace capture off unless explicitly enabled. |
The evidence store is not encrypted by RERUN; it relies on the operating system and the Customer's disk encryption. Redaction is defence in depth, not a guarantee. |
| Bounded AI egress | AI is off unless a flow contains an explicit AI step; commercial AI steps are single assertions over bounded redacted context, with no silent provider fallback, a local egress receipt recording provider, model, field categories, redaction policy and latency, and page network egress blocked from the start of the action until the isolated context closes. | Egress goes to the Customer's own provider account under the Customer's own key. AI interaction is experimental and requires an internal opt-in the shipped application does not enable. |
| Supply chain and build integrity | Packaged builds ignore runtime origin and public-key overrides and fail closed unless a production service URL and trusted Ed25519 keys were embedded at packaging; releases are notarized and pinned to a specific Developer ID Team; updates are disabled for development builds, inactive licences, apps running from /Volumes and non-writable bundles. |
— |
| Testing and verification | Automated suites covering authenticated loopback access, privacy-mode artefacts across nested frames, trace opt-in, bounded AI assertions and receipts, DOM race protection and immediate, deferred and WebSocket AI-network escape attempts; static analysis, style gates and dependency auditing on both the desktop application and the control plane. | No external security review has been completed. No certification is held or claimed. |
| Availability and resilience | Alerting on webhook delivery failures, mail failures, queue backlog and failed jobs, repeated activation throttles, licence-signing failures and health-check failures. | Backups are taken and rotated by the hosting provider on its own schedule; RERUN commits to no frequency, retention window or restore guarantee. No disaster recovery plan, recovery time objective or recovery point objective is committed. No uptime SLA is offered unless one is stated in the main agreement. |
Annex III — Sub-processors
The Customer authorises the sub-processors below. The list is short because the control plane holds little: identity, billing and entitlement state, and nothing from the execution plane.
| Sub-processor | Purpose | Personal data disclosed | Entity and processing location |
|---|---|---|---|
| Stripe Payments Europe, Ltd. | Payments, tax calculation and billing portal | Billing contact identity and email, organization name, Stripe customer, subscription, invoice and event identifiers, payment method brand and last four digits. Card numbers are collected by Stripe directly and never by RERUN. | Ireland (EU) |
| DigitalOcean, LLC | Hosting of the licence control plane | All control-plane data described in Annex I Part B, at rest and in processing. | Frankfurt, Germany (EU) |
| Provider — to be selected | Transactional email delivery | Recipient name and email address, organization name, and the content of the message. | Processing location — to be confirmed |
Not sub-processors. An AI model provider used by the Customer (OpenAI, Anthropic) is engaged by the Customer under its own account and API key, from the Customer's own machine. RERUN neither contracts with that provider on the Customer's behalf nor receives the data sent to it.
Changes to this Annex are notified as described in section 06. This Addendum needs no separate signature: it is incorporated by reference into the main agreement and takes effect for a Customer when that agreement is accepted, which is the point at which processing on that Customer's behalf begins. A Customer whose procurement process requires a counter-signed copy can request one from Legal contact email — to be completed , and RERUN will execute it against this text — a signed copy changes the formality, not the terms.