Data Processing Addendum
Effective date: 10 October 2026.
1. Parties and scope
This Data Processing Addendum (“DPA”) forms part of the agreement between Sam Mulliner, doing business as Valvayn (“Processor”, “we”) and the customer (“Customer”) for the Ward service (the “Agreement”). It applies when we process Customer Personal Data on the Customer’s behalf in providing the Service — in particular when we host the Ward control plane for the Customer, and when the Customer gives us access to its data for support.
Where the Customer hosts Ward on its own infrastructure, we do not process Customer Personal Data through the Service; this DPA then applies only to data the Customer chooses to share with us, for example in a support request.
2. Definitions
“Data Protection Law” means the EU General Data Protection Regulation 2016/679 (“GDPR”), the GDPR as retained in UK law (“UK GDPR”) with the UK Data Protection Act 2018, and other data protection laws that apply to the processing. “Customer Personal Data” means personal data we process on the Customer’s behalf under the Agreement. “Subprocessor” means a third party we engage to process Customer Personal Data. “Controller”, “processor”, “data subject”, “personal data breach” and “processing” have the meanings given in Data Protection Law.
3. Roles
The Customer is the controller of Customer Personal Data (or a processor acting for its affiliates, in which case we are its subprocessor). We are the processor. We act as an independent controller only for the limited data needed to manage our contract with the Customer and to secure our service, as described in our Privacy Policy.
4. Customer instructions
We process Customer Personal Data only on the Customer’s documented instructions. The Agreement, this DPA and the Customer’s configuration of the Service — its policies, detectors, integrations, data-collection settings and retention period — are the Customer’s instructions. We will tell the Customer if we believe an instruction infringes Data Protection Law. If the law requires us to process data otherwise, we will inform the Customer first unless the law prohibits it.
5. Customer responsibilities
The Customer is responsible for having a lawful basis for deploying Ward, for informing its users, for consulting employee representatives and carrying out a data protection impact assessment where the law requires it, and for choosing data-collection settings proportionate to its purposes. The Service offers settings that reduce collection: discovery limited to catalog applications, no account identifiers, no file names and no AI-prompt metadata.
6. Confidentiality
We ensure that personnel authorised to process Customer Personal Data are bound by confidentiality obligations and access it only as needed to provide, secure and support the Service.
7. Security
We implement the technical and organisational measures in Annex 2. We may update them provided the overall level of protection is not reduced.
8. Subprocessors
The Customer gives general authorisation for us to engage Subprocessors. The current list is published at /legal/subprocessors/. We will give at least 30 days' notice of a new Subprocessor; the Customer may object on reasonable data protection grounds, and if we cannot address the objection the Customer may terminate the affected part of the Service. We impose data protection terms on each Subprocessor that are no less protective than this DPA, and remain responsible for their performance.
9. International transfers
Where Customer Personal Data is transferred outside the UK or the European Economic Area to a country without an adequacy decision, the parties rely on the European Commission’s Standard Contractual Clauses (2021/914) and, for UK data, the UK International Data Transfer Addendum, which are incorporated by reference.
10. Assistance
Taking into account the nature of the processing, we assist the Customer with data subject requests, data protection impact assessments and prior consultations. Administrators can search and export event metadata in the console, which helps answer access requests; we forward to the Customer any data subject request we receive about Customer Personal Data.
11. Personal data breaches
We notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Personal Data, with the information the Customer reasonably needs to meet its own obligations, and we take reasonable steps to contain and remedy it.
12. Return and deletion
During the Agreement, Customer Personal Data is deleted according to the Customer’s retention settings (security events: 180 days by default). When the Agreement ends, we delete Customer Personal Data within 30 days, unless the law requires us to keep it. Before then the Customer may export its data using the console’s export features.
13. Audits
We make available the information reasonably necessary to demonstrate compliance with this DPA, including answers to security questionnaires. The Customer may conduct an audit, on reasonable notice and no more than once a year unless required by a supervisory authority or following a personal data breach, at its own cost and subject to confidentiality. We do not claim third-party certifications unless we state them in writing.
14. General
Liability under this DPA is subject to the limitations in the Agreement. If this DPA conflicts with the Agreement, this DPA prevails for the processing of Customer Personal Data. This DPA lasts as long as we process Customer Personal Data.
Annex 1 — Details of processing
| Item | Details |
|---|---|
| Subject matter | Providing the Ward browser security service |
| Duration | The term of the Agreement plus the deletion period in section 12 |
| Nature and purpose | Enforcing the Customer’s browser data-protection policy; recording and displaying security events; discovering applications and browser extensions in use; alerting; administration and audit |
| Data subjects | The Customer’s employees and contractors who use managed browsers with Ward (“end users”); the Customer’s administrators |
| End-user data | Browser profile email and, where configured, directory identifiers from Microsoft Entra ID (name, email/UPN, object ID, group memberships); account identifiers for corporate accounts (all, or none, if the Customer chooses) |
| Device and browser data | Device label, operating system, browser and extension versions, managed status, installed extensions and their permissions, policy status and heartbeat times |
| Security event metadata | Time, hostname, application and category, account type and domain, action, decision and outcome, policy, classification names and match counts, file name, type and size, business justification text typed by the user |
| Discovery data | Daily counts per application, user, device and account type |
| Administrator data | Name, email, role, password hash or Entra ID link, sessions, audit log entries |
| Not processed | Page contents, prompts, clipboard contents, typed text, form values, file contents, passwords, cookies, full URLs, and the matched sensitive values — these are inspected on the device and never sent |
| Special category data | Not intended. File names or justification text could incidentally reveal such data; the Service redacts values that look sensitive, and the Customer can turn off file-name collection |
| Retention | Set by the Customer; security events 180 days by default; raw upload batches are emptied as soon as processed |
Annex 2 — Technical and organisational measures
- Data minimisation by design: content is inspected on the device; the event schema has no field for content and unknown fields are rejected; allowed non-sensitive actions produce no event.
- Tenant isolation: row-level security enforced by the database for every tenant table; the application role cannot bypass it.
- Access control: five administrator roles enforced by the server; scrypt password hashing or Entra ID single sign-on; server-side sessions with idle and absolute timeouts; CSRF protection; rate-limited sign-in.
- Encryption: integration secrets encrypted with AES-256-GCM; tokens and device secrets stored as hashes; HTTPS required for the production API.
- Integrity: policies signed with ECDSA P-256 and verified by the extension; per-device credentials that rotate and can be revoked.
- Logging: append-only audit log of administrative actions; server logs redact credentials.
- Secure development: strict input validation, parameterised queries, bounded request sizes, automated tests for tenant isolation and for the absence of content in stored data and logs; security reviews with findings fixed and regression-tested.
- Hosting and operations: The control plane runs on hardware operated by Valvayn on a private network in Texas, United States, behind a reverse proxy and Cloudflare; it is reachable only over HTTPS. The database is not exposed to the internet. Production access is limited to the operator, over SSH. The database is backed up nightly and before every deployment, and backups are kept for 35 days on access-controlled storage. Stored secrets (policy-signing keys, integration credentials, webhook secrets) are encrypted at rest with a master key that is not stored in the database..