Data Processing Addendum

1. Definitions

Words not defined here have the meaning given in the Agreement or in Data Protection Laws. “Controller”, “processor”, “data subject”, “personal data”, “processing” and “supervisory authority” have the meanings given in the GDPR.

• “Data Protection Laws” means the laws on personal data that apply to the processing under this DPA, including the EU General Data Protection Regulation 2016/679 (“GDPR”); the GDPR as it applies in the United Kingdom and the Data Protection Act 2018 (“UK GDPR”); the Swiss Federal Act on Data Protection (“FADP”); the Israeli Privacy Protection Law, 5741-1981, as amended (including Amendment 13), and its regulations, including the Privacy Protection (Data Security) Regulations, 5777-2017 (together, the “Israeli Privacy Law”); and the California Consumer Privacy Act, as amended by the California Privacy Rights Act (“CCPA”).
• “Customer Personal Data” means personal data within Customer Data that Stanch processes on the Customer’s behalf under the Agreement.
• “Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data processed by Stanch or its subprocessors.
• “Subprocessor” means a third party that Stanch engages to process Customer Personal Data.
• “Standard Contractual Clauses” means the clauses annexed to European Commission Implementing Decision (EU) 2021/914; “UK Addendum” means the International Data Transfer Addendum to them issued by the UK Information Commissioner.

2. Roles and scope

The Customer is the controller of Customer Personal Data, or a processor acting for its own controllers, and Stanch is its processor (or subprocessor). Under the Israeli Privacy Law, the Customer is the database controller and Stanch is a holder. Under the CCPA, the Customer is the business and Stanch is its service provider.

Annex 1 describes the processing. Stanch is an independent controller only for the personal data it needs to manage its relationship with the Customer, operate the accounts of Authorized Users, keep the Service secure and meet its legal duties, as its Privacy Policy describes; this DPA does not apply to that data.

3. The Customer’s instructions and responsibilities

Stanch processes Customer Personal Data only on the Customer’s documented instructions. The Agreement, the Customer’s configuration of the Service (such as its policies, channels, retention periods and evidence settings) and its use of the Service’s features are its complete instructions; further instructions must be in writing and consistent with the Agreement. Stanch will tell the Customer if, in its opinion, an instruction infringes Data Protection Laws, and may then decline to follow it.

If the law requires Stanch to process Customer Personal Data other than on the Customer’s instructions, Stanch will tell the Customer before doing so, unless the law prohibits that.

The Customer is responsible for the lawfulness of its instructions and of the processing, including having a lawful basis, giving notice to and obtaining any consent from Endpoint Users and other data subjects, and consulting employee representatives where required, as section 5 of the Terms of Service describes.

4. Confidentiality

Stanch ensures that everyone it authorises to process Customer Personal Data is bound by a duty of confidentiality, and gives access only to those who need it to provide the Service. Stanch personnel do not have standing access to the content of a customer’s account through the Service; access for support requires a session the Customer approves, as Annex 2 describes. A limited number of named Stanch administrators who maintain the hosting infrastructure can technically access Customer Personal Data stored on it; they do so only to operate, secure or restore the Service, and that access is logged.

5. Security

Stanch implements and maintains the technical and organisational measures in Annex 2, which are designed to protect Customer Personal Data against Personal Data Breaches and to ensure a level of security appropriate to the risk. Stanch may update these measures as technology and threats change, provided that the update does not materially reduce the overall protection of Customer Personal Data.

The Customer is responsible for the security settings it controls, such as user roles, two-step verification, retention periods and evidence access, and for the security of its own devices and networks.

6. Subprocessors

The Customer gives Stanch general authorisation to engage Subprocessors. The current list is on our Subprocessors page and in Annex 3.

Stanch will notify the Customer at least 30 days before a new Subprocessor begins to process Customer Personal Data, by email to the Customer’s account owners and by updating that page. Where an urgent change is needed to keep the Service secure or available, Stanch may give shorter notice and will notify the Customer as soon as reasonably possible.

The Customer may object to a new Subprocessor on reasonable data-protection grounds by writing to Stanch within the notice period. The parties will discuss the objection in good faith. If Stanch cannot reasonably accommodate it, the Customer may end the affected part of the Service by written notice, and Stanch will refund any prepaid Fees for the period after it ends.

Stanch imposes on each Subprocessor, by written contract, data-protection obligations that protect Customer Personal Data to the standard of this DPA, and remains responsible to the Customer for its Subprocessors’ performance of those obligations.

7. Data subject requests

If Stanch receives a request from a data subject about Customer Personal Data, it will forward it to the Customer without undue delay and will not answer it except to refer the data subject to the Customer, unless the law requires otherwise.

The Service lets the Customer find and export Customer Personal Data and set retention periods, after which data is deleted. To delete the Customer Personal Data about a particular person sooner, the Customer asks Stanch support; Stanch deletes it from the Service and confirms the deletion in writing. Where the Customer cannot answer a request with these features, Stanch will provide reasonable assistance, taking into account the nature of the processing.

8. Personal Data Breaches

Stanch will notify the Customer without undue delay after becoming aware of a Personal Data Breach, by email to the Customer’s account owners and security contacts on record. 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. Stanch will provide further information as it becomes available.

Stanch will take reasonable steps to contain and investigate the breach and to reduce its effects, and will cooperate with the Customer so that it can meet its own duties to notify supervisory authorities, including the Israeli Privacy Protection Authority, and data subjects. Notifying a breach is not an admission of fault or liability.

9. Assistance, records and audits

Taking into account the nature of the processing and the information available to it, Stanch will provide reasonable assistance with the Customer’s data-protection impact assessments and prior consultations with supervisory authorities concerning the Service.

Stanch will make available the information reasonably necessary to demonstrate its compliance with this DPA. On request, and no more than once a year, Stanch will answer the Customer’s reasonable written security questionnaire and provide a written report on how it meets its obligations under this DPA, including those of a holder under the Israeli Privacy Law.

If that information is not enough to demonstrate compliance, or a supervisory authority requires it, the Customer may audit Stanch’s compliance, itself or through an independent auditor bound by confidentiality who is not a competitor of Stanch. Audits are limited to once a year (unless following a Personal Data Breach or a regulator’s request), require at least 30 days’ written notice and an agreed scope, take place during business hours without unreasonably disrupting Stanch’s operations, and may not give access to other customers’ data. The Customer bears its own audit costs.

10. International transfers

Stanch hosts Customer Personal Data in the European Union: the Service runs on Google Cloud in Germany, with backups in the Netherlands. Stanch personnel may access it from Israel, which is the subject of adequacy decisions of the European Commission and the United Kingdom. Subprocessors may process it in the locations listed in Annex 3.

Where processing under this DPA involves a transfer of personal data from the European Economic Area to a country that is not subject to an adequacy decision, the Standard Contractual Clauses are incorporated into this DPA: Module Two (controller to processor) where the Customer is a controller, and Module Three (processor to processor) where it is a processor. In them: the optional docking clause (clause 7) applies; under clause 9, option 2 (general written authorisation) applies, with the notice period in section 6; the optional wording in clause 11 does not apply; under clause 13, the supervisory authority is the one competent for the Customer; under clauses 17 and 18, the clauses are governed by the law of, and disputes are resolved by the courts of, the EU member state in which the Customer is established or, failing that, Ireland. Annexes 1, 2 and 3 of this DPA complete Annexes I, II and III of the clauses.

For transfers from the United Kingdom, the Standard Contractual Clauses apply as amended by the UK Addendum, whose tables are completed with the information in this DPA, and either party may end the UK Addendum as its section 19 allows. For transfers from Switzerland, the Standard Contractual Clauses apply with the changes the FADP requires, the Swiss Federal Data Protection and Information Commissioner being the competent authority for those transfers. Transfers of personal data out of Israel are made in accordance with the Israeli rules on the transfer of data to databases abroad.

Where Stanch engages a Subprocessor that processes Customer Personal Data outside the European Economic Area, it puts in place an appropriate transfer mechanism, such as the Standard Contractual Clauses (Module Three). If a transfer mechanism is invalidated or replaced, the parties will cooperate to put in place a valid alternative. If the Standard Contractual Clauses conflict with this DPA, the clauses prevail.

11. Return and deletion

During the Agreement, the Customer controls retention and deletion of Customer Personal Data through the Service, including its retention periods and the export features of the console, and through requests to Stanch support to delete the data about a particular person (section 7).

When the Agreement ends, the Customer may export Customer Personal Data through the console for 30 days, during which access remains available read-only for that purpose. After that period, Stanch deletes the Customer’s account and Customer Personal Data from the Service. Copies in backups are deleted as the backups expire, within 90 days. Stanch may keep Customer Personal Data where the law requires, and then only for that purpose and protected under this DPA. On request, Stanch will confirm the deletion in writing.

12. California

Where the CCPA applies, Stanch will process personal information only for the business purposes described in the Agreement, and will not: sell or share it (as the CCPA defines those terms); retain, use or disclose it outside the direct business relationship with the Customer or for any purpose other than those business purposes; or combine it with personal information it receives from others, except as the CCPA permits. Stanch will comply with the CCPA, provide the same level of privacy protection the CCPA requires of businesses, and notify the Customer if it can no longer meet its obligations. The Customer may take reasonable steps to stop and remedy unauthorised use of personal information. Stanch certifies that it understands these restrictions.

13. Liability and general terms

Each party’s liability under this DPA is subject to the limitations and exclusions of the Agreement, except where Data Protection Laws or the Standard Contractual Clauses do not allow them to be limited.

This DPA lasts for as long as Stanch processes Customer Personal Data under the Agreement. If this DPA conflicts with the Agreement on the processing of personal data, this DPA prevails. This DPA is governed by the law that governs the Agreement, except where the Standard Contractual Clauses or Data Protection Laws require otherwise. Stanch may update this DPA to reflect changes in Data Protection Laws or in the Service, provided that the update does not materially reduce the protection of Customer Personal Data; other changes take effect as the Agreement describes.

Annex 1: Details of the processing

Categories of personal data

• Device and identity: the device name, operating system and version, Software versions, time-zone offset and protection status; the username signed in on the device and its operating-system identifier; and, if the Customer connects its directory, directory attributes such as name, email address and group membership.
• Security events: date and time; channel; application or process (name, path and file hash); destination (host name, and the form of the web address with identifiers removed); AI service and model; the policy, action and outcome; detector, category, severity and confidence; tenant-keyed one-way fingerprints and redacted previews of detected values (never the values themselves); file names and sizes; for printing, the printer, document title and page count; for removable storage, the vendor, product and a hashed serial number; for sync folders, the client and account type; and the Endpoint User’s choice after a warning.
• AI usage metadata: for each request to an AI service, whether or not anything is found: the device user and application, the AI provider, model and destination host, and byte and token counts (never prompt or response text); AI applications and tools found on the device, with the names, never the values, of keys configured for them.
• Evidence (only if the Customer turns on evidence collection): for the actions and channels the Customer selects, the content behind an incident, such as the text an Endpoint User sent, a file’s extracted text or, on the endpoint proxy, the file itself.
• Console users: name, work email, job title, role, password hash, two-step verification secrets (encrypted) and passkey public keys, session IP address and user agent, audit-log entries, notification settings, and Stanch Agent conversations if the Customer enables it.
• Customer-registered detection data: values and documents the Customer registers for detection, stored only as keyed hashes; dictionary terms and custom patterns, stored as written; and the case notes the Customer’s analysts write.

Special categories of data

The Service does not require special categories of personal data. Information that Endpoint Users send may contain any kind of data, including special categories; the Service stores it only as fingerprints and redacted previews, unless the Customer turns on evidence collection, in which case the content of the incidents it selects is stored encrypted, with access restricted as Annex 2 describes. The Customer decides whether evidence collection is justified.

Retention

Retention follows the Customer’s settings. For customers provisioned with the current defaults, security events and AI usage records are kept 30 days, and the console’s audit log for the period the Customer sets in its retention settings; where no period is set, data is kept until the Customer sets one or the Agreement ends. Evidence is kept for the period the Customer sets for it. Stanch Agent conversations are kept 30 days by default (the Customer can shorten this). Enforcement receipts expire after 7 days, discovered processes 14 days after they were last seen, queued alerts after 7 days, and the Service’s operational logs after about 14 days. Accounts, devices and configuration are kept until the Customer deletes them or the Agreement ends. Backups expire within 90 days.

Annex 2: Technical and organisational security measures

Data minimisation by design

• Inspection runs on the device; the content inspected is not sent to the Service by default.
• Detected sensitive values are never stored: the Service keeps tenant-keyed HMAC-SHA256 fingerprints and redacted previews instead. Each customer has its own fingerprint key, so values cannot be correlated across customers.
• Records of AI usage are limited by a strict schema with no field for prompts, responses or tool contents.
• Each request to an AI service is recorded as AI usage metadata (Annex 1), whether or not anything is found; other activity with no finding and no enforcement is not stored.
• The optional text-recognition and audio-transcription components run on the device.

Encryption

• All connections to the Service use TLS; plain HTTP is redirected to HTTPS in production, and the console sends HTTP Strict Transport Security.
• Data is stored on Google Cloud, which encrypts disks, snapshots and storage buckets at rest.
• Two-step verification secrets, single sign-on client secrets and alert-channel credentials are additionally encrypted by the application with AES-256-GCM.
• Evidence content is encrypted with AES-256-GCM under per-customer keys derived from a dedicated root key, and each object is bound to its customer and record.

Customer separation and access control

• Every customer’s records carry its organisation identifier, and PostgreSQL row-level security enforces separation in the database, in addition to checks in the application.
• Console access uses roles (owner, admin, analyst, viewer). Passwords are stored as scrypt hashes; two-step verification (an authenticator app or a passkey) is required for owners and admins, and the Customer can require it for everyone; sessions expire after 12 hours; repeated sign-in failures are rate-limited and lead to a temporary lockout.
• Sensitive changes, such as retention and evidence settings, require a fresh second factor.
• Evidence can be opened only by people the Customer’s owner grants it to, for at most 30 days at a time, with a fresh second factor and a stated reason for each access, and every access is logged.
• API keys and device enrolment tokens are stored only as hashes.

Stanch personnel

• Stanch operators act through a separate platform organisation with explicit roles; every role grant needs approval by a second person, and platform accounts require two-step verification.
• No platform role can read a customer’s records. Access for support requires a session that the Customer’s owner approves; it is read-only, time-limited, tied to one named operator, shown on every page and recorded in both the customer’s and the platform’s audit logs.
• Access to the hosting infrastructure, and so to the data stored on it, is limited to named Stanch administrators, goes through Google’s identity-aware proxy and OS Login, is used only to operate, secure or restore the Service, and is logged.
• Ending a customer’s account follows a two-person procedure that is recorded in the platform audit log.

Endpoints

• Each enrolled device has its own key pair and signs what it sends; the Service binds reports to the device and the customer.
• Software updates are accepted only when their signature verifies against a key built into the agent, and older versions are refused.
• Keys and queued records on the device are readable only by the operating system and administrators; the agent’s logs are redacted; the local queue is bounded.

Infrastructure and operations

• The Service runs on a hardened Google Cloud virtual machine in Germany: Shielded VM (secure boot, virtual TPM, integrity monitoring), no public SSH access (administrative access through Google’s identity-aware proxy and OS Login), a firewall that opens only the web ports to the internet, and automatic security updates.
• Core secrets (database credentials, encryption and fingerprint keys) are held in Google Secret Manager and read by a least-privilege service account; other service credentials are kept in files on the server readable only by its administrators.
• The application sends security headers on every response, including a restrictive Content Security Policy.
• Administrative actions in the console are recorded in an audit log that the application cannot delete; it is removed only under the Customer’s retention setting.

Backups, monitoring and continuity

• The database is backed up daily to private, versioned storage buckets in the Netherlands with public access prevented. Daily backups are kept 30 days and weekly backups eight weeks, and the server’s disk is also snapshotted daily.
• Server health and resource use are monitored, with alerts to the operations team.

Secure development

• Changes are tested automatically, including tests of customer separation under row-level security.
• Dependencies are pinned and checked for known vulnerabilities, and container images are scanned for known vulnerabilities before they are published.

Incidents and vulnerabilities

• Stanch investigates suspected security incidents and notifies customers of Personal Data Breaches as section 8 describes. Vulnerabilities can be reported privately to security@stanch.ai under the policy on our Security page.

Annex 3: Subprocessors

Stanch uses the following Subprocessors. The current list is kept on our Subprocessors page.