Legal

Data processing agreement

Version 1.14, 15 October 2026

The previous version (v1.11) stays available until 14 November 2026.

Sub-processors are listed in Annex III and on the Caspian Trust Center.

How this DPA is formed. Caspian's Terms of Service incorporate this DPA by reference, and the current version of this DPA is published at getcaspian.io/dpa and linked from the Terms. The Customer accepts this DPA (a) by accepting the Terms when an Authorised User signs in to the Services ("By signing in, you agree to our Terms and Privacy Policy"), or (b) by signature. If the Parties sign a separate DPA, that signed DPA prevails over this one. Caspian records, the first time an Owner or Admin of the workspace signs in after a version is published, the version and its hash, the workspace, that user, the time, and the IP address and browser user agent of the request (the "Effective Date" is the earlier of that record and the date of signature). On request Caspian provides a counter-signed PDF bearing the Effective Date. This DPA is never backdated. Creating a workspace does not require any further step.

Part 1: Base DPA

1. Parties and scope

1.1 This DPA is between Caspian BV, Brusselsesteenweg 6 bus 104, 9050 Ledeberg (Ghent), Belgium, enterprise number (KBO) 1042.322.507 ("Caspian"), and the customer that accepts it ("Customer").

1.2 It applies whenever Caspian processes Customer Personal Data to provide the Services under the Customer's agreement with Caspian (the master agreement, order form or terms of service, the "Agreement").

1.3 It consists of this Part 1, Annexes I–III, and the Schedules that apply:

Part 2 (Hosting models) always applies and forms part of this base DPA. Part 2A (Caspian-hosted) applies to every workspace unless Part 2B (Customer-hosted data) applies to it.
Schedule B (Device Management) applies from the moment device management is enabled for a workspace. It is not available for workspaces under Part 2B.
Schedule C (US State Privacy) applies where US state privacy law covers Customer Personal Data.
Schedule E (EU-Region Addendum) applies when an order designates it.

A UK addendum is available on request where the UK GDPR covers Customer Personal Data.

1.4 Affiliates. The Customer accepts this DPA for itself and for each of its Affiliates whose personal data Caspian processes under the Agreement. The Customer is the single point of contact for Caspian for itself and its Affiliates: it gives all instructions, receives all notices and exercises all rights under this DPA on their behalf, and confirms that it is authorised to do so. An Affiliate cannot enforce this DPA directly against Caspian, except where Data Protection Law gives it that right; any such claim is brought through the Customer and counts towards the Data Protection Cap in section 16.2. "Affiliate" means an entity that controls, is controlled by or is under common control with the Customer.

2. Definitions

Terms defined in the GDPR (Regulation (EU) 2016/679) have the same meaning here. In addition:

"Authorised User" means a person the Customer allows to use the Services.
"Business Day" means a day other than a Saturday, Sunday or public holiday in Belgium.
"Customer Personal Data" means personal data that Caspian processes for the Customer under the Agreement.
"Data Protection Law" means the GDPR, Belgian data protection law and, where a Schedule applies, the laws named in it.
"EEA" means the European Economic Area.
"Personal Data Breach" has the GDPR meaning. It does not include unsuccessful attempts that do not compromise Customer Personal Data, such as blocked log-ins, port scans or denied requests.
"Privacy Contact" and "Security Contact" mean the contacts the Customer names in the order form or in the Services, or failing that the account Owner.
"SCCs" means the standard contractual clauses in Commission Implementing Decision (EU) 2021/914.
"Services" means the Caspian services provided under the Agreement.
"Sub-processor" means a third party Caspian engages to process Customer Personal Data.
"Trust Center" means Caspian's public trust page at trust.getcaspian.io.
"Trust Center technical annex" means the technical and operational description of the Services published on the Trust Center, which Caspian may update from time to time. Section 7.2 applies to any update that reduces the protection of Customer Personal Data.
"Affiliate" has the meaning in section 1.4.

3. Roles

3.1 The Customer is the controller of Customer Personal Data. Caspian processes it as the Customer's processor. Where the Customer is itself a processor, it confirms that its controller has authorised Caspian's appointment, and Caspian acts as its sub-processor.

3.2 Caspian is a separate controller only for (a) account, billing and contact data of the Customer's administrators, (b) logs of access to the Services, used only to secure the Services and kept no longer than 12 months (load-balancer and web-firewall logs: 90 days online, with an evidence copy kept no longer than 12 months in total), (c) data it must keep by law, and (d) the creation of the anonymous data described in section 3.4. Caspian does not use product analytics or session-recording software in the Services. Caspian uses these only for those purposes and handles them under its privacy notice.

3.3 Caspian does not use Customer Personal Data for its own purposes. In particular it does not use it to develop or improve its products, to train or fine-tune any AI model, for advertising, or for benchmarking, and it does not sell it. The only exception is the anonymous data described in section 3.4. If Caspian determined the purposes or means of processing in breach of this DPA, it would be a controller for that processing (Art. 28(10) GDPR).

3.4 Anonymous aggregated data. Caspian may derive from Customer Personal Data, and build and use for the Services:

(a) a shared software catalogue: the names, domains and vendors of software applications, with no information about people; and
(b) aggregate statistics about software use (for example how many organisations use an application), but only where at least five different customers contribute to each figure, with no personal data and no figures about any single customer.

Caspian processes Customer Personal Data for this purpose only as far as needed to produce these results, which are then anonymous within the meaning of recital 26 GDPR. Caspian does not sell this data or the catalogue, does not try to re-identify any person or customer, and does not disclose a figure to which fewer than five customers contribute. Shared catalogue entries contributed before this version were cleaned once, by a one-off migration, of any customer identifier and personal data. Caspian determines the purposes and means of creating this anonymous data and is responsible for that processing as a separate controller (section 3.2(d)). (Planned: Caspian's privacy notice describes this processing.) For a workspace under Part 2B, an Owner can switch off contributions to the shared catalogue (section 2B.4(d)).

4. Precedence

If documents conflict, this order applies: (1) the SCCs, where they apply between the parties (section 14.4); (2) this DPA, for anything about the processing of Customer Personal Data; (3) the Agreement for everything else. Section 16 replaces the Agreement's limitation of liability for the claims it covers. A Schedule prevails over Part 1 on the matters it covers, subject to the SCCs. Customer purchase-order terms do not apply to the processing of Customer Personal Data.

5. Instructions

5.1 Caspian processes Customer Personal Data only on the Customer's documented instructions, including on transfers to third countries. The Customer's instructions are: this DPA, the Agreement, the configuration the Customer chooses in the Services (connectors, policies, automations, retention settings) and actions taken by Authorised Users in the Services, including approvals and standing permissions given for AI features under section 15.4. Further instructions must be in writing and consistent with the Agreement.

5.2 If EU or Member State law requires Caspian to process Customer Personal Data in another way, Caspian tells the Customer first, unless that law forbids it on important public-interest grounds.

5.3 Unlawful instructions. If Caspian believes an instruction breaches Data Protection Law, it tells the Customer immediately. Caspian may suspend that instruction until the Customer confirms or changes it. If the Customer maintains an instruction that Caspian reasonably considers unlawful, either party may terminate the affected Service on written notice. If Caspian terminates, it refunds any prepaid fees for the unused period of that Service; if the Customer terminates, no refund is due. Caspian is not liable for processing it carries out in line with the Customer's instructions.

5.4 The Customer is responsible for the lawfulness of its instructions, for having a legal basis for the processing, for informing data subjects, and for any works-council information or consultation and employee notice that the Services require (section 9.4).

6. Confidentiality

6.1 Caspian gives access to Customer Personal Data only to people who need it to provide the Services. Today these are Caspian's two founders.

6.2 Everyone with access to Customer Personal Data, including any employee, contractor or adviser Caspian authorises later, is bound by a written non-disclosure agreement or confidentiality undertaking before access is given. The obligation survives the end of their engagement. People without access to Customer Personal Data are outside this clause.

6.3 Caspian does not use Customer Personal Data in development or testing environments.

6.4 Caspian ensures that anyone acting under its authority who has access to Customer Personal Data processes it only on the Customer's instructions, unless EU or Member State law requires otherwise (Arts. 29 and 32(4) GDPR).

7. Security

7.1 Caspian implements the technical and organisational measures in Annex II. They take into account the state of the art, cost, and the nature, scope, context and purposes of the processing, and the risks to data subjects (Art. 32 GDPR).

7.2 Caspian may update Annex II if the overall level of protection is not materially reduced. It announces material changes on the Trust Center and by email at least 30 days in advance. If the Customer reasonably shows that a change materially reduces the protection of Customer Personal Data, Caspian either reverses the change for the Customer or the Customer may terminate the affected Service with a pro-rata refund of prepaid fees.

7.3 The Customer is responsible for the security of its own accounts, credentials, devices and connected systems, and for the roles it gives Authorised Users.

8. Sub-processors

8.1 General authorisation. The Customer authorises Caspian to engage the Sub-processors listed in Annex III, which is also published on the Trust Center. If the Trust Center and Annex III differ, the more recent dated list on the Trust Center applies.

8.2 Notice. Caspian gives at least 30 days' notice before a new Sub-processor starts processing Customer Personal Data. Notice is given by email to the Privacy Contact, on the Trust Center and through its RSS feed. The notice states the Sub-processor's name, location, the processing it will do and the transfer mechanism. Caspian links on the Trust Center the published sub-processor lists of its own Sub-processors; changes to those lists are notified by those providers under their terms.

8.3 Emergency replacement. If a Sub-processor must be replaced urgently to keep the Services secure or available, Caspian may give shorter notice and will explain why.

8.4 Objection. The Customer may object on reasonable data-protection grounds within 15 days of the notice. The parties then discuss the objection in good faith, for example whether Caspian can offer a configuration that avoids the new Sub-processor. Caspian may start using the new Sub-processor at the end of the notice period. If the objection is not resolved within 30 days after it was made, the Customer may terminate the affected Service on written notice and receive a pro-rata refund of prepaid fees for it. This right to terminate is the Customer's specific remedy for an unresolved objection; it does not limit the Customer's remedies for Caspian's breach of this DPA. A pause of the new Sub-processor for the Customer's data is available only where agreed in an order.

8.5 Flow-down. Caspian imposes on each Sub-processor, by written contract, data protection obligations that offer a level of protection equivalent to this DPA, including sufficient guarantees on security. On request Caspian provides a copy of the data-protection terms of a Sub-processor contract (commercial terms may be redacted, and standard public terms may be provided as a link). Caspian notifies the Customer if it learns that a Sub-processor has failed to meet those terms in a way that affects Customer Personal Data. Caspian remains fully liable to the Customer for its Sub-processors' performance (Art. 28(4) GDPR).

8.6 If Caspian ceases to trade or becomes insolvent, it will instruct its Sub-processors to delete or return Customer Personal Data in line with section 12. Where a Sub-processor's terms allow it, the Customer may give that instruction directly.

9. Assistance

9.1 Taking into account the nature of the processing, Caspian assists the Customer with:

(a) data subject requests, by manual help and through self-service tools in the Services to search, export and erase a person's records (corrections are made in the Customer's source systems). Erasing a person deletes that person's personal data. The Customer's audit log, the record of access granted or removed and the record of acceptance of this DPA are kept as evidence for their retention period (Annex I part H) and are not used for any other purpose; wherever they are shown or exported, the erased person is masked as described in the Trust Center technical annex. An erased person is not imported again from the Customer's connected systems on later syncs. How the self-service tools work, and the limits of the masking, are described in the Trust Center technical annex;
(b) security, breach notification, data protection impact assessments and prior consultation (Arts. 32–36 GDPR). Caspian provides a DPIA-support pack describing what the Services collect, the controls available to the Customer, and the employee-notice options.

9.2 If Caspian receives a request directly from a data subject, it refers the person to the Customer, promptly forwards the request to the Customer, and does not respond itself unless the Customer instructs it to.

9.3 Assistance is free within reason: Caspian does not charge for normal volumes of requests or for the standard DPIA-support pack. If the Customer asks for assistance that is exceptional in volume or requires custom work, Caspian may charge its then-current rates after telling the Customer the estimate in advance. Caspian never charges for assistance needed because of its own breach of this DPA.

9.4 Employee monitoring. This section applies to the browser extension, the endpoint agent, AI-tool discovery and device management.

(a) Aggregated by default. Collection starts when the Customer deploys the browser extension or endpoint agent, and is on by default from then; the Customer can switch it off per workspace. While per-person views are off, the Services show only aggregates, without names, for shadow-AI findings, risks, application user lists, access cells, access reviews and browser and endpoint telemetry. Exception: the device and endpoint-agent inventory always shows, per installation, the OS user name and when it was last seen, because the Customer needs it for IT asset management. Per-person views are off until an Owner of the Customer's workspace switches them on, confirming that staff have been told individual activity is visible. Once on, they are visible to the workspace's Owners and Admins only. The switch, who used it and when are recorded in the audit log, and while the switch is on, each per-person read is recorded in the audit log.
(b) Customer's legal obligations. The Customer remains responsible for its own legal obligations when it uses these features, including under employment law and collective labour agreements. Caspian provides the controls described in (a); the Customer decides when and how to use them. Every per-person view is recorded in an audit log available to the Customer.
(c) Information to staff. Before enabling collection, the Customer informs and, where required, consults its staff and their representatives as applicable law requires. Caspian provides an information pack for this: features, data collected, purposes, retention, and who can see per-person data.

10. Personal Data Breach

10.1 Caspian notifies the Customer without undue delay and at the latest 48 hours after becoming aware of a Personal Data Breach affecting Customer Personal Data, including when it learns of the breach from a Sub-processor.

10.2 The notice goes to the Security Contact by email and, where available, by phone. It contains at least, to the extent then known:

(a) the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned;
(b) the name and contact details of Caspian's contact point;
(c) the likely consequences;
(d) the measures taken or proposed to address the breach and limit its effects;
(e) the time Caspian became aware and the time the breach occurred, if known.

Where not all information is available, Caspian provides it in phases as it becomes available, without undue further delay.

10.3 Caspian contains the breach, investigates it, keeps a record of it, and cooperates with the Customer's notification to authorities and data subjects. Caspian does not notify a supervisory authority or data subjects on the Customer's behalf unless the Customer instructs it to or the law requires it.

10.4 A notice is not an admission of fault or liability.

10.5 Caspian's breach and security contact is security@getcaspian.io (monitored by the founders). It is published in a security.txt file (RFC 9116) at getcaspian.io and app.getcaspian.io.

11. Retention during the term

Caspian keeps Customer Personal Data only as long as needed for the Services. The retention periods in Annex I part H apply, unless the Customer sets shorter periods in the Services.

12. Export and deletion at the end

12.1 Export. During the term and for 30 days after the Agreement ends (the "Export Period"), an Owner or Admin can export all Customer Personal Data of the workspace in one click from Settings → Data & Privacy (a ZIP of CSV files with the uploaded files and a description of each file; secrets and credentials are excluded). The export is prepared in the background and the download link is emailed to the workspace Owners. On request during the Export Period, Caspian provides the export to the Customer instead.

12.1a Deleting a workspace. Only an Owner can ask to delete the workspace (an Admin can export but not delete). The deletion takes effect 30 days after the request, not at once. During those 30 days the one-click export in section 12.1 remains available, and an Owner can cancel the deletion; a cancellation is refused from day 30. When an Owner cancels, the workspace returns as it was, the cancellation is recorded in the audit log and all Owners are emailed. How Owners export and cancel during those 30 days is described in the Trust Center technical annex. Section 12.2 then applies from the end of those 30 days.

12.2 Deletion. Within 30 days after the end of the Export Period (or earlier on the Customer's written instruction), Caspian deletes the Customer Personal Data it holds: for a workspace under Part 2A, all Customer Personal Data in Caspian's production environment; for a workspace under Part 2B, the items Caspian keeps under section 2B.4, and the Customer Personal Data in the Customer's own cloud as section 2B.8 sets out. In both cases Caspian also deletes the Customer's records in its central services (authentication records and transactional-email logs; for each Authorised User who belongs to no other workspace, the user, session, linked-account, identity and verification records (planned); records of membership removals are kept until this purge) and sends the Customer a written deletion certificate. Caspian does not delete anything during the Export Period unless the Customer instructs it to.

12.3 Backups. Backups of Caspian's production environment and central services are not restored to make deletion happen faster; they roll off within 35 days after deletion and are not used in the meantime except to recover from an incident. Backups in the Customer's own cloud under Part 2B are under the Customer's control.

12.3a Timeline in short. Day 0: the Agreement ends. Days 0–30: Export Period. By day 60: Caspian's deletion done (section 12.2). By day 95: gone from Caspian's backups. The deletion certificate is sent within 5 Business Days after Caspian's deletion.

12.4 Support email exception. Support correspondence is kept in Caspian's Google Workspace mailbox. Caspian deletes it within the period in 12.2. Google may then take up to 180 days to remove deleted items from its systems; during that time the data is not further processed and remains confidential.

12.5 Caspian may keep Customer Personal Data longer only where EU or Member State law requires it. Caspian then keeps it isolated, protects it under this DPA and uses it for no other purpose.

12.6 Section 2B.8 and Schedule B set out which party deletes what in those cases.

13. Audits and information

13.1 Reports first. Caspian makes available on request, under confidentiality:

(a) its Trust Center, including this DPA's Annexes and the Sub-processor list;
(b) its current independent audit reports. Caspian's ISO/IEC 27001 certification and SOC 2 Type II examination are audit in progress with A-LIGN; status and dates are on the Trust Center. Until the certificate and report are issued, Caspian provides a status letter from the auditor where available;
(c) a summary of its most recent independent security test. Today this is an external, unauthenticated black-box test by Workstreet (19 August 2026) of the sign-in page at app.getcaspian.io, run against the hosting environment Caspian used before it moved to its current production account on 26 September 2026: no critical, high or medium findings, 4 low and 3 informational. The signed-in product and the current production environment have not yet been tested by an independent tester. Internal assessments, including AI-assisted code reviews, are not independent tests and are not provided under this item;
(d) answers to one reasonable security questionnaire per 12 months;
(e) the audit reports of its Sub-processors, to the extent their terms allow Caspian to share them.

13.2 Audit. If the Customer reasonably considers that this information does not demonstrate compliance, the Customer, or an independent auditor it appoints that is bound by confidentiality and is not a Caspian competitor, may audit Caspian, including by inspection:

(a) once in any 12 months, on 30 days' written notice, with an agreed scope, during Business Days, and remotely unless an on-site visit is needed for the scope. An on-site visit is at the Customer's cost under section 13.4;
(b) in addition, once per Personal Data Breach affecting the Customer, limited to that breach, or where a supervisory authority asks for it.

13.3 An audit must not unreasonably disrupt Caspian's operations and may not give access to other customers' data or to information protected by law or confidentiality to third parties.

13.4 Costs. The Customer bears its own costs and the reasonable costs of Caspian's time. If the audit finds that Caspian materially breached this DPA, Caspian bears its own costs and reimburses the Customer's reasonable audit costs, and remedies the breach.

13.5 Nothing in this section limits the powers of a supervisory authority.

14. Data location and transfers

14.1 Location. Caspian stores and processes Customer Personal Data in the European Union. For a workspace under Part 2A, storage and processing take place in Caspian's production environment in AWS eu-central-1 (Frankfurt), with backup copies in AWS eu-west-1 (Ireland). For a workspace under Part 2B, Customer Personal Data is stored in the Customer's own cloud, in the EU region chosen during set-up, and processed in Caspian's production environment in AWS eu-central-1. In both cases Caspian's central services (authentication and transactional email) run in AWS eu-central-1; replicas of Caspian's security and infrastructure logs (AWS CloudTrail, AWS Config, load-balancer access logs) are kept in AWS eu-west-1 (Ireland); and AI inference runs in AWS EU regions (section 15). The only exceptions are those listed in Annex III: Caspian's support mailbox (Google Workspace) and support access by Sub-processors' personnel. Caspian does not move hosting outside the EU without 30 days' notice and the Customer's right to terminate the affected Service with a pro-rata refund. Schedule E narrows these locations further where it applies.

14.2 Customers in the EEA. Where the Customer is established in the EEA, Caspian's processing is processing by an EU processor subject to the GDPR. It is not a transfer to a third country, and the parties do not need SCCs between them.

14.3 Onward transfers by Caspian. Where a Sub-processor, or a Sub-processor's own sub-processor, outside the EEA in a country without an adequacy decision processes or accesses Customer Personal Data, Caspian ensures that the SCCs, Module 3 (processor to processor), or the Sub-processor's certification under the EU-US Data Privacy Framework, or another Chapter V mechanism stated in Annex III, is in place: in Caspian's own contract where Caspian engages a non-EEA Sub-processor, and in the Sub-processor's data processing terms for its onward transfers. Caspian provides a copy of the relevant clauses on request (commercial terms redacted) and, on request, a summary of its transfer impact assessment for each third country involved.

14.4 Customers outside the EEA (Module 4). Where the Customer is established outside the EEA and is not subject to the GDPR for the processing, the SCCs, Module 4 (processor to controller), are incorporated into this DPA, with Caspian as data exporter and the Customer as data importer:

Clause 7 (docking): included;
Clause 11: the optional language does not apply;
Clause 17: Belgian law;
Clause 18: the courts of Ghent, Belgium;
Annex I of the SCCs = Annex I of this DPA; Annex II = Annex II.

Nothing in this DPA or the Agreement limits either party's liability under Clause 12 of those SCCs towards data subjects, or between the parties to the extent Clause 12 requires.

14.5 Customers outside the EEA subject to the GDPR. Where the Customer is established outside the EEA but is subject to the GDPR for the processing under Art. 3(2), no SCCs are incorporated. The parties will incorporate the standard contractual clauses the Commission adopts for that case once they are in force; until then this DPA applies.

14.6 Requests from public authorities. If Caspian receives a legally binding request from a public authority for Customer Personal Data, it tells the Customer promptly unless the law prohibits it, challenges a request it reasonably considers unlawful, and discloses no more than the request requires.

15. AI features

15.1 The Services include optional AI features (assistant chat, Slack/Teams bot, access suggestions, import mapping, contract analysis, policy-check generation and software classification). They run on Amazon Bedrock, called only through EU geographic inference profiles, which route requests only to AWS EU regions (Frankfurt, Ireland, Paris, Stockholm, Milan, Spain), or through in-region model IDs in eu-central-1 (Frankfurt).

15.2 No training. Caspian does not use Customer Personal Data, prompts or outputs to train, fine-tune or improve any model. Under AWS's terms, Bedrock does not use them to train models and model providers have no access to them.

15.3 No retention, and what happens if AWS changes its list. Caspian uses only Bedrock models for which AWS states that it does not store inputs or outputs, and does not use models on AWS's abuse-detection retention list. Caspian checks that list at least monthly. If AWS adds a model Caspian uses for the Customer to that list, Caspian either (a) switches the affected features to another model outside the list within 10 Business Days, or (b) notifies the Customer under section 8.2 before continuing, with the Customer's objection right under section 8.4; until the notice period ends, Caspian switches the feature to another model or turns it off for the Customer. Caspian has not enabled Bedrock model-invocation logging, and an AWS organisation policy blocks enabling it. Caspian does not cache prompts.

15.4 Human approval and standing permissions. AI features act only within the permissions of the Authorised User who uses them. Caspian classifies every action an AI feature can take by risk, and labels each tool on its MCP interface as read-only, destructive or idempotent so that external AI clients can ask for confirmation themselves.

(a) High-risk actions are actions that change access, offboarding evidence, workflows, policies, device management or stored credentials. The list of high-risk tools is published in the Trust Center technical annex and in the Services' documentation. Caspian may add tools to this list without notice; removing one is an update under section 20. In Caspian's own chat and bots such an action runs only after the Authorised User approves it on a confirmation card ("Allow once", "Always allow for me" or "Reject"). "Always allow for me" applies only to that Authorised User and that tool.
(b) No standing permission for the most severe actions. Decommissioning a device, deleting a credential, deleting a policy and deleting a workflow always need approval of that single action. (Erasing a device is governed by Schedule B5.)
(c) Other actions (reading data and low-risk changes) run on the Authorised User's request without a card and are recorded in the audit log.
(d) Customer policy. An Owner can set, per high-risk tool and for the whole workspace, whether an action needs a card ("Ask first", the default) or may be allowed always. The tools in (b) can never be allowed always, by a user or by an Owner. Owners can revoke a standing permission at any time.
(d1) External AI clients. When the Customer connects its own AI client (section 15.6), the confirmation for a high-risk action that is not destructive is the client's own: the client asks the Authorised User to confirm, and Caspian records that request as the instruction before the action runs. Destructive high-risk actions, as marked in the Trust Center technical annex, still need a card in the Services. Caspian does not control or verify the client's confirmation step.
(e) Documented instruction. Before an action runs, Caspian records the Authorised User who requested it and the approval, standing permission, Owner policy or external-client request that allowed it, with the time; if that record cannot be written, the action does not run. The outcome is recorded afterwards. That record is the Customer's documented instruction under section 5.1.

15.5 Transparency and use restriction. The bot tells users they are talking to an AI system. While per-person views are off (section 9.4), the AI features receive and show only aggregates for monitoring data, the same as the rest of the Services. The Customer will not use the AI features to evaluate, rank or monitor the performance or behaviour of individual workers.

15.6 If the Customer connects its own AI client to Caspian's MCP interface, data leaving Caspian through that client goes to a recipient the Customer chose. That recipient is not Caspian's Sub-processor.

16. Liability

16.1 One cap for data protection. Each party's total aggregate liability arising out of or in connection with this DPA and Data Protection Law ("Data Protection Claims") is limited only by the Data Protection Cap in 16.2. For Data Protection Claims the Data Protection Cap replaces the limitation of liability in the Agreement. The two caps are never added together: Data Protection Claims do not count towards the Agreement's cap, and other claims do not count towards the Data Protection Cap.

16.2 Data Protection Cap. The higher of (a) EUR 500,000 and (b) three (3) times the fees paid by the Customer in the 12 months before the claim, in aggregate for all Data Protection Claims.

16.3 Gross negligence. Liability for gross negligence (zware fout / faute lourde) is not excluded. The parties expressly agree that it falls under the Data Protection Cap (Art. 5.89 Civil Code), and section 16.5 does not apply to it.

16.4 Not limited by any cap or exclusion:

(a) the rights of data subjects under Art. 82 GDPR, and either party's right of recourse under Art. 82(5) GDPR for the share of compensation corresponding to the other party's responsibility;
(b) liability under Clause 12 of the SCCs, where SCCs apply between the parties (section 14.4), to the extent that Clause requires;
(c) liability for wilful misconduct (opzet) or fraud of a party itself or of its employees (Art. 5.89 Civil Code). Wilful misconduct or fraud of a Sub-processor falls under the Data Protection Cap;
(d) liability for death or personal injury.

16.5 Indirect and consequential loss remains excluded as in the Agreement. The reasonable, documented and legally required costs of notifying authorities and data subjects, and of forensic investigation, caused by Caspian's breach of this DPA are direct loss.

16.6 No indemnity for fines. Neither party indemnifies the other for administrative fines or penalties imposed on it. Each party bears its own fines.

16.7 The exclusions and limits in this section also benefit each party's employees, auxiliaries, sub-processors and contractors, except as section 16.4 provides.

16.8 Part 2B and Schedule B add specific allocations for key revocation and device commands.

17. Insurance

17.1 Caspian will take out, with a reputable insurer, professional (IT) liability insurance and cyber liability insurance covering its liability under this DPA, with cover of at least EUR 1,000,000, by 31 December 2026 at the latest. This is a target: until that cover starts, Caspian holds no such insurance.

17.2 Once the cover has started, Caspian provides a certificate of insurance on request, and once a year if the Customer asks, and notifies the Customer within 30 days if the cover is cancelled or materially reduced.

18. Term, termination and survival

18.1 This DPA runs from the Effective Date as long as Caspian processes Customer Personal Data under the Agreement.

18.2 Sections 6, 9, 10, 12, 13, 14.4–14.6, 16 and 19 and section 2B.8 and Schedule B9 survive for as long as Caspian holds Customer Personal Data or a claim can be made.

18.3 Termination for Caspian's breach. If Caspian materially breaches this DPA or Data Protection Law and does not cure the breach within 30 days of written notice, or does not comply with a binding decision of a competent court or supervisory authority about the processing, the Customer may suspend the affected processing and, if the breach is not cured, terminate the affected Service with a pro-rata refund of prepaid fees.

19. Governing law and jurisdiction

19.1 This DPA, and the SCCs where they apply between the parties, are governed by Belgian law.

19.2 The courts of Ghent, Belgium have exclusive jurisdiction, without prejudice to data subjects' rights under Art. 79(2) GDPR and, where Module 4 applies, SCC Clause 18.

20. Changes

Caspian may update this DPA only to reflect changes in law, regulator guidance or the Sub-processor list (section 8), and never so as to reduce the protection of Customer Personal Data. It gives 30 days' notice by email and on the Trust Center. If the Customer reasonably shows that an update reduces that protection, Caspian keeps the previous version for the Customer or the Customer may terminate the affected Service with a pro-rata refund. Any other change needs both parties' agreement.

Annex I: Description of the processing

A. Parties. Controller: the Customer (contact in the order form). Processor: Caspian BV, contact simon@getcaspian.io. Role: processor, or sub-processor where the Customer is itself a processor (Art. 28(4) GDPR). Where Module 4 applies (section 14.4): data exporter Caspian, data importer the Customer.

B. Subject matter. Caspian provides a SaaS platform for IT operations and access governance: discovering the software used in the Customer's organisation, mapping who has access to it, managing joiners, movers and leavers, managing enrolled company devices (Schedule B), and analysing software spend.

C. Nature of the processing. Collection through connectors the Customer authorises and through the browser extension and endpoint agent the Customer deploys; storage; matching accounts to people; analysis, including with AI (section 15); display; export; and actions in the Customer's systems on the Customer's instruction or according to rules the Customer configures: creating, suspending, deleting and reactivating accounts; changing group, licence and role membership; transferring a leaver's data; revoking sessions and OAuth grants; locking, erasing or configuring enrolled devices and installing software on them (Schedule B); and sending messages by email, Slack and Microsoft Teams. Email may be sent as the Customer's own mailbox (for example Gmail "send as" an IT address), using the authority the Customer grants. Steps the Customer marks as automatic run without a person approving each one, at the time the Customer's rules set; in particular, a leaver's access is removed at the termination date and time recorded in the Customer's HR or directory system. The Customer chooses which steps are automatic, and Caspian records each action in the audit log. Browser, endpoint and AI-tool data are shown to the Customer in aggregated form by default (section 9.4).

D. Specific business purposes.

Inventory of the software in use and who uses it (shadow-IT and shadow-AI discovery).
Access management: requests, approvals, provisioning, access reviews and policy enforcement.
Onboarding and offboarding driven by HR and directory data, including timed removal of access at the termination date.
Device management and security posture of company devices.
Software spend and licence optimisation.
Security and compliance evidence (audit trail, exports, risk reports), including detection of company files moved to unapproved destinations.
IT help desk and support, including the AI assistant.

E. Data subjects.

The Customer's employees, contractors and interns.
Former employees, for the offboarding period and the retention below.
External collaborators and guest users present in the Customer's tools.
The Customer's administrators and other Authorised Users.
Vendor contacts named in contracts or invoices the Customer uploads.

F. Categories of personal data.

Identity and contact: name, work email, user IDs in each connected tool, profile picture, phone number if present in a tool profile.
Employment: department, job title, employee type, office or work location, legal entity, manager, start date, termination date, employment status, and HR custom fields only where the Customer allow-lists them.
Access: accounts, licences, groups, roles, entitlements, OAuth grants, access requests and approvals with their reasons, access-review decisions.
Software usage:
- the domain names of recognised business software visited in the browser, with timestamps and the policy outcome (allowed, warned, blocked);
- sign-in events from the Customer's identity provider: time, application, outcome, MFA method, and the IP address truncated before storage (IPv4 to /24, IPv6 to /48). No sign-in location is stored;
- per-person daily activity counts for Google Workspace services;
- AI tools in use and the email domain class (company or personal) of the account used;
- personal AI-tool accounts linked to an employee in a shadow-AI finding: the account's email domain (*@domain), plan and organisation of that AI tool; and, from the endpoint agent, the logged-in OS user name and the AI coding tool in use (no command-line arguments);
- network identifiers: browser-discovery and endpoint-agent reports contain a website or software domain and no user or device identifiers. The employee's source IP address is processed transiently for transport and abuse protection; Caspian does not store or log it at the application layer, and where a network identifier is kept for rate limiting, only a truncated prefix (IPv4 /24, IPv6 /48) is kept. The data is minimised, not anonymous: AWS load-balancer and firewall logs record the source IP for up to 90 days for security, and any archived copy holds only the truncated prefix;
- file transfers to other web destinations, only where file-movement detection is switched on (off by default for workspaces created after this feature was introduced; workspaces that existed before keep their previous setting, and the Customer can switch it off at any time): file name, file size, source and destination domain, destination account or workspace name, and a file hash and similarity fingerprint (no file content).
Device (company devices only): serial number, hardware UUID, hostname, MAC address, the IP address the device reports (usually a local network address), OS and version, installed software, security posture (disk encryption, firewall, system protections), OS user name of the logged-in user, assigned owner; device asset location and travel notes as entered by the Customer's administrators.
Communications: messages users send to the Caspian assistant, IT help-desk threads and comments, and messages Caspian sends on the Customer's behalf.
Financial: software invoices, licence costs and contract terms the Customer uploads.
Authentication of Authorised Users: name, email, organisation membership, sign-in time and IP. Caspian's own self-hosted authentication service in AWS eu-central-1 stores them (no third-party authentication provider is used), together with the full IP address and browser user agent on every session record, and uses the IP address to rate-limit sign-in; and, where the Authorised User signs in with Google or Microsoft, that provider's OAuth tokens, encrypted.
Credentials: OAuth tokens and API credentials for the Customer's tools, always encrypted. Where a connector needs a broad scope because the provider offers no narrower one (Google Drive drive, Jira read:jira-work), Caspian uses it only for the features listed in part D.

What Caspian does not collect

no keystroke content, screenshots, screen recordings or clipboard content;
no full URLs, page titles, page content or browser history leave the device: the extension classifies pages locally on the device and sends only the domain of recognised business software;
no content of messages, prompts, emails or files in the Customer's tools;
no location of people or devices: no GPS, no Lost Mode location and no sign-in location. Only the truncated sign-in IP address, the IP address a device reports, and the asset location the Customer's administrators enter, as listed above;
no command-line arguments of applications.

G. Special categories. None are intended. Some HR systems return more fields than Caspian asks for (Rippling's API offers no field selection). Caspian discards every field not listed above, including any special-category data, in memory as soon as the response is read, before any logging or storage, so it does not store special-category data from HR systems. Free-text fields (help-desk messages, device notes) could incidentally contain such data; the Customer should not ask users to put it there.

H. Retention within the term (unless the Customer sets shorter periods). For a workspace under Part 2B these periods apply to the data in the Customer's own cloud, and section 2B.4 lists what Caspian keeps on its side:

Data	Retention
Assistant conversation history	1 hour
Raw connector records	while the record exists in the Customer's connected system; deleted 90 days after it is removed there
Audit log of workspace activity	term of the Agreement, then section 12
Browser and endpoint events (raw), including file-transfer events	90 days
Usage aggregates	13 months
Access events, action and device history	400 days
IT help-desk messages	24 months
Leaver records	24 months after offboarding closes
Workflow state	7 days
Application logs (redacted of personal data)	1 day for backend, workflow, integration-engine and workflow-scheduler logs; 30 days for front-end logs
Audit logs in account 511 (AWS CloudTrail, VPC flow logs, database audit log, canary)	365 days
Sessions, verification codes and rate-limit records of Authorised Users	deleted 1 day after they expire (unverified)
MCP access tokens	deleted 1 day after expiry or revocation (unverified)
Encrypted Google and Microsoft OAuth tokens of Authorised Users	as long as the user account exists
Records of removed workspace memberships	until the workspace is purged (section 12.2) (unverified)
Security and access logs (no payloads)	12 months
Everything else	term of the Agreement, then section 12

I. Frequency. Continuous: scheduled syncs, webhooks and endpoint telemetry.

J. Duration. The term of the Agreement plus the periods in section 12.

K. Location. Part 2A: Caspian's production environment in AWS eu-central-1, with backup copies in eu-west-1. Part 2B: the Customer's own cloud in the EU region chosen at set-up, with processing in Caspian's production environment in AWS eu-central-1. Caspian's central services in eu-central-1; security-log replicas in eu-west-1. AI inference: AWS EU regions. Exceptions: Annex III. Schedule E, where it applies.

L. Competent supervisory authority. For the Customer, the supervisory authority competent under the GDPR. For Caspian, the Belgian Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données). SCC Clause 13 does not apply to Module 4.

Annex II: Technical and organisational measures

Each measure is in place on the date this DPA is accepted. Numbers are commitments.

1. Governance. Caspian runs an information security management system aligned with ISO/IEC 27001:2022 and the SOC 2 criteria, owned by the CEO, with management-approved policies and a risk register. ISO 27001 certification and the SOC 2 Type II examination are audit in progress with A-LIGN.

2. Encryption.

In transit: TLS 1.2 or 1.3 only on every external endpoint; HTTP redirected to HTTPS; HSTS for 2 years; TLS required to the database, cache and object storage.
At rest (Part 2A and Caspian's central services): databases, cache, object storage, logs, secrets and backups encrypted with AES-256 under AWS KMS keys that Caspian manages, one per class of data, rotated automatically every year; the eu-west-1 backup copies use a separate key. For Part 2B, see section 2B.3.
Credentials: OAuth tokens and integration credentials additionally encrypted in the application with AES-256-GCM under a dedicated KMS-backed key with a key identifier; API keys stored only as hashes.
Production refuses to start without explicit production configuration and accepts only OAuth sign-in; development authentication modes are technically disabled.

3. Access control.

Authorised Users sign in through Caspian's authentication service. This is Caspian's own self-hosted authentication service in AWS eu-central-1, which delegates sign-in to the Customer's Google or Microsoft identity provider, where the Customer's MFA policy applies, with server-side sessions that end after 15 minutes of inactivity and at most 7 days after sign-in. No third-party authentication provider is used. Roles: owner, admin, member.
Staff: production access is limited to the founders. MFA is enforced on every staff account with production access, including AWS root users, which are not used for routine work. GitHub requires 2FA for all organisation members. Access is reviewed quarterly and removed within 24 business hours of a role change.

4. Tenant isolation. Part 2A: all Caspian-hosted workspaces share one production database; every record is tied to its workspace, every request is scoped to the authenticated workspace, and row-level security in the database enforces that scope. Part 2B: the workspace's data sits in its own database and storage in the Customer's cloud, holding one workspace only; Caspian's access to it is bound to that workspace (section 2B.3). The shared software catalogue and aggregate statistics (section 3.4) contain no Customer Personal Data. Production runs in AWS accounts separate from development.

5. Logging and monitoring.

Append-only audit log of workspace activity.
AWS CloudTrail (multi-region), AWS Config, VPC flow logs and GuardDuty enabled.
Application logs are automatically redacted of personal data, credentials and request bodies. Integration credentials never appear in logs.
Workflow events carry identifiers only; workflow state is encrypted and kept 7 days.
Database audit logs record schema and role changes, not data values.
Retention: security and access logs 12 months; application logs 1 day (front-end logs 30 days); audit logs in 511 (CloudTrail, VPC flow logs, database audit log) 365 days; load-balancer and web-firewall logs 90 days, with an evidence copy kept no longer than 12 months in total, with query strings and forwarding headers redacted from firewall logs and client IPs truncated to /24 or /48 in the evidence copy; no client IP in application logs.
Security alerts are delivered to an on-call founder; alerts exist for root sign-in, IAM changes and CloudTrail changes.

6. Vulnerability management. Dependency, container and secret scans on every change. Container images are also scanned when pushed to Caspian's image registry. Independent testing to date is limited to the external, unauthenticated black-box test of the sign-in page described in section 13.1(c), which ran against Caspian's previous hosting environment; the signed-in product has not yet been tested by an independent tester. Caspian commissions an independent security test at least once a year. (Planned: an independent, authenticated test of the signed-in product in the current production environment, date to be set.) Remediation targets: critical 30 days, high 60, medium 120.

7. Secure development. Changes reach production through CI with required checks and pinned actions; infrastructure as code (Terraform) deployed with short-lived OIDC credentials; founder review required for infrastructure, authentication and device-management code.

8. Availability and backup. AWS eu-central-1 across multiple Availability Zones.

(a) Caspian-hosted data (Part 2A workspaces and Caspian's central services, including authentication): backed up every 12 hours by AWS Backup and kept 35 days, with each backup copied to AWS eu-west-1 (Ireland), plus 14 days of point-in-time recovery for the production database. Targets: RPO 24 hours, RTO 72 hours, including for the loss of the whole eu-central-1 region. A restore test of the production database is carried out at least once a year; the first test in the current production account, a restore into eu-west-1, was performed on 4 October 2026.
(b) Customer-hosted data (Part 2B): backup, retention and disaster recovery of the database and storage in the Customer's own cloud are the Customer's choice and responsibility. Once those resources are available again, Caspian resumes the Services for the workspace.

9. Incident response. Documented incident response plan with severity levels; tested by tabletop at least once a year; breach notice per section 10.

10. Personnel. Founders bound by signed confidentiality undertakings and screened (Belgian criminal-record extract). Anyone else with access to Customer Personal Data signs an NDA first. Security awareness training at onboarding and every year, with completion recorded.

11. Physical and endpoint security. No servers on Caspian premises; physical security by AWS. The founders work on Macs they own personally and use for company work; these are not under device management today. Each must meet Caspian's signed device baseline: FileVault full-disk encryption, screen lock after at most 5 minutes of inactivity, automatic security updates, firewall on, and a password manager as the only store of company credentials. The founders attest to the baseline, and an agent of Caspian's compliance platform checks disk encryption, screen lock, the password manager and anti-malware on each Mac. (Planned: enrolment of these Macs in device management.)

12. Minimisation. The browser extension reads page addresses and page structure on the device to classify sites locally, and sends Caspian only domains of recognised business software; HR connectors keep only the fields in Annex I and drop the rest in memory (Annex I.G); sign-in IPs are truncated and no sign-in location is stored; retention per Annex I part H. IP minimisation: no client IP in application logs or databases for extension, agent and catalog intake; IPs truncated to /24 (IPv4) or /48 (IPv6) wherever a network identifier is kept for those intakes (sign-in sessions of Authorised Users are the exception, Annex I.F.8), and before load-balancer and firewall logs are archived; firewall logs exclude catalog intake and redact forwarding headers; live load-balancer and firewall logs kept 90 days. This is minimisation, not anonymisation. The extension's cookie permission is used only to read cookie names to recognise sign-in state, never values.

13. AI. Bedrock EU geographic profiles or eu-central-1 in-region models only, as configured in Caspian's infrastructure code; model-invocation logging not enabled (section 15). AWS organisation policies block use of other regions and changes to invocation logging. Risk-tiered approvals and an audit record per action (section 15.4).

14. Deletion. A workspace deletion request takes effect after 30 days, during which a one-click export is available (section 12.1a); deletion then removes the Customer Personal Data Caspian holds (section 12.2); a scheduled job enforces the deadline in section 12.2; Caspian's backups expire after 35 days; a deletion certificate is issued.

15. Customer controls. The Customer can disconnect any connector (revoking its token), disable browser and endpoint collection per workspace, set shorter retention, export all workspace data in one click, run data subject searches, exports and erasures as background jobs, and delete the workspace (Owners only; export by Owners and Admins). Per-person views of monitoring data are off by default (section 9.4).

Annex III: Sub-processors

III.1 Sub-processors

Sub-processor	Service	Data	Location	Transfer mechanism
Amazon Web Services EMEA SARL (Luxembourg)	Caspian's production environment (storage of Customer Personal Data for Part 2A workspaces; compute and in-memory processing for all workspaces; the items Caspian keeps for Part 2B workspaces) and Caspian's central services; Amazon Bedrock (AI inference; models by Anthropic, OpenAI open-weight, Qwen and Amazon); Amazon SES (transactional email)	All categories in Annex I	eu-central-1, eu-west-1 (backup copies and log replicas); Bedrock: AWS EU regions via EU profiles; SES: eu-central-1	EU entity, EU processing. Remote support access from outside the EEA: SCCs Module 3 under the AWS DPA (AWS's onward transfers)
Google Ireland Ltd (Google Workspace)	Caspian's support mailbox	Support correspondence: names, emails, message content the Customer sends	EU and global (Google data centres)	EU entity. Google's onward transfers: SCCs Module 3 under Google's data processing terms; DPF certification of Google LLC (supplementary)

III.2 The Customer's own cloud (Part 2B)

For a workspace under Part 2B, the database, storage and keys in the Customer's own cloud (Amazon Web Services, Google Cloud or Microsoft Azure) are provided to the Customer under its own contract with that cloud provider. That provider is not Caspian's Sub-processor.

III.3 Not sub-processors (for transparency)

Apple Inc. When the Customer uses device management (Schedule B), the Customer holds its own Apple Push Notification certificate and Apple Business Manager account. Apple acts for the Customer under the Customer's own agreement with Apple and is the Customer's recipient, not Caspian's sub-processor. Push messages carry a device token and topic, not command content.
Inngest Inc. (USA) processed workflow data for Caspian until 18 September 2026. It is no longer used (the workflow engine is self-hosted) and deletion of that history has been requested.
Cloudflare provides DNS only, has always done so, and receives no Customer Personal Data. Caspian does not route Services traffic through Cloudflare.
Self-hosted software operated by Caspian inside AWS (integration engine, workflow engine, authentication service). The companies behind this software receive no data.

Part 2: Hosting models

Part 2A: Caspian-hosted (default)

2A.1 Application. This Part 2A applies to every workspace that is not set up under Part 2B.

2A.2 Where the data is. Caspian stores the Customer Personal Data of the workspace in its production environment, in Caspian's own AWS account in eu-central-1 (Frankfurt): a PostgreSQL database and object storage, encrypted at rest as described in Annex II §2. Credentials for the Customer's tools are stored there too, encrypted again in the application, including those held by Caspian's self-hosted integration engine. Backups are made and copied to eu-west-1 (Ireland) as described in Annex II §8(a), unless Schedule E applies.

2A.3 One shared deployment. One shared deployment of the Services serves all Caspian-hosted workspaces. Workspaces are kept apart as described in Annex II §4.

2A.4 Staff access. Only the people named in section 6.1 can access Caspian's production environment, with multi-factor authentication. They access Customer Personal Data only to provide the Services, including at the Customer's request through support, or to keep the Services secure and available. Their sign-ins to the production AWS environment are recorded in AWS CloudTrail.

2A.5 Deletion. Section 12 applies.

Part 2B: Customer-hosted data (on request)

2B.1 Application. This Part 2B applies to a workspace that the Customer creates through Caspian's customer-hosted set-up, which Caspian offers on request. It applies from the creation of that workspace. An existing workspace cannot be moved under this Part 2B, or out of it. This Part 2B prevails over the rest of this DPA on the matters it covers.

2B.2 Where the data is. The Customer Personal Data of the workspace is stored only in a database and storage that Caspian's set-up template creates in the Customer's own cloud account (Amazon Web Services, Google Cloud or Microsoft Azure), in the EU region chosen during set-up, encrypted with keys held in the Customer's cloud (the "Customer Data Plane"). This covers the data collected from the Customer's identity provider and connected tools, the credentials for the Customer's tools, uploaded files, exports, assistant history and the workspace audit log.

2B.3 Processing and access. Caspian processes the data in its production environment in AWS eu-central-1. The data is held in memory only while the operation that needs it runs, and every result is written back to the Customer Data Plane. AI inference stays in the EU as described in section 15, also where the Customer's data region is in another EU country. Caspian reaches the Customer Data Plane through an identity in the Customer's cloud that only Caspian's production environment can use, for that one workspace, without a stored password. Credentials for the Customer's tools are also encrypted under a workspace key that only a key in the Customer's cloud can unlock. Caspian's processing means that Caspian's systems see the data in readable form while they work on it. The technical set-up per cloud is described in the Trust Center technical annex.

2B.4 What Caspian keeps. For a workspace under this Part 2B, Caspian keeps on its side only:

(a) account and access data: the name, work email and picture of each Authorised User, their sessions (including IP address and browser user agent), their role in the workspace, pending invitations (email and role), the workspace name, logo, company sign-in settings and verified company domains, the data-location configuration with the results of its checks, the workspace's encrypted (wrapped) data keys, hashed lookup keys, deletion evidence (hashes only) and the record of acceptance of this DPA;
(b) workflow state for at most 7 days, encrypted with the workspace key described in section 2B.3, and copies of it in Caspian's backups for at most 35 further days; Caspian cannot decrypt this state once the Customer revokes Caspian's access to its key;
(c) operational logs that are redacted to identifiers and error codes: 1 day for backend, workflow, integration-engine and workflow-scheduler logs and 30 days for front-end logs (Planned: front-end logs 1 day), together with the load-balancer and web-firewall logs in section 3.2(b); and
(d) unless an Owner switches it off in the workspace's data-location settings, the names, public web addresses and public OAuth client identifiers of applications found in the workspace, added to Caspian's shared software catalogue without any link to the Customer (section 3.4).

Caspian does not add an item to this list without 30 days' notice and the objection right in section 8.4.

2B.5 Not available under this Part. Device management (Schedule B) and the integrations that run through Caspian's integration engine are not available for a workspace under this Part 2B. The Services show which integrations are available.

2B.6 Customer controls. The Customer can revoke Caspian's access at any time, by disabling its key or by removing Caspian's identity or network access in its cloud. Caspian's cached access to the workspace key expires within 5 minutes, after which Caspian can no longer open the workspace's credentials or workflow state, and the Services for that workspace stop. Nothing falls back to Caspian's own storage. The Customer's cloud can record each use of its keys by Caspian in the Customer's own audit logs.

2B.7 Shared responsibility. The Customer is responsible for its cloud account and for the security, availability, backup, retention and costs of the Customer Data Plane, including keeping its keys and Caspian's access available while it wants the Services to run. Caspian is responsible for its set-up templates and checks, its production environment, its use of the access the Customer grants, and its personnel. The Customer pays its cloud costs directly to its cloud provider; they are not part of Caspian's fees.

2B.8 Deletion. At the end, Caspian deletes the items in section 2B.4 under section 12.2 and makes the workspace's encrypted workflow state permanently unreadable by destroying the workspace's wrapped keys. (Planned: key destruction on the day of Caspian's deletion.) For the Customer Data Plane, the Customer chooses in the Services either (a) that Caspian deletes the workspace's records and files there, with deletion evidence, or (b) that Caspian disconnects and leaves the data in place. In both cases the database, storage and keys themselves are the Customer's to keep or remove. If Caspian cannot reach the Customer Data Plane, it deletes only what it holds itself, and the deletion certificate says that the data in the Customer's cloud stayed there.

2B.9 Customer-side actions: liability. Caspian is not liable for loss, unavailability or corruption of Customer Personal Data in the Customer Data Plane to the extent caused by the Customer disabling, deleting or failing to maintain its keys, by its backup settings, or by changes the Customer makes to its cloud or to Caspian's access. This does not apply to loss caused by Caspian's breach of this DPA, gross negligence or wilful misconduct, and does not limit section 16.4. Fees remain due during a suspension the Customer causes.

2B.10 Breach zones.

(a) Caspian zone (Caspian's production environment, the items in section 2B.4, Caspian's Sub-processors and staff): Caspian notifies within 48 hours of awareness (section 10).
(b) Misuse of Caspian's access to the Customer Data Plane, including stolen Caspian credentials or a compromise of Caspian's production environment: treated as Caspian zone. Caspian also supports the Customer's investigation using the Customer's cloud audit logs.
(c) Customer zone (the Customer's cloud, not involving Caspian's access): the Customer's responsibility. Caspian assists under section 9.

Where Caspian cannot see record contents, its notice describes what can reasonably be determined and the parties use the Customer's logs to identify the data subjects affected.

2B.11 Architecture changes. If Caspian changes this Part 2B so that a new category of Customer Personal Data is kept outside the Customer Data Plane, it gives 30 days' notice with an updated section 2B.4. The Customer may then terminate the affected Services with a pro-rata refund.

Schedule B: Device Management (optional)

B1. Application. This Schedule applies from the moment device management is enabled for a workspace. Caspian enables it per workspace. It covers company-owned Macs only. It does not cover personally owned devices or Windows devices, and it is not available for workspaces under Part 2B.

B2. Roles. The Customer is the controller of all personal data processed through device management. Caspian processes it as processor. The Customer decides which devices to enrol and which profiles, scripts and commands to apply, informs employees, and handles any information or consultation of staff representatives and any DPIA (section 9.4). Caspian provides the Customer with the information it needs for this: data collected, commands available, approvals required and retention.

B2a. Shared service. Caspian runs one device-management service for all its customers, in a separate AWS account of its own in eu-central-1, connected to Caspian's production environment over private AWS networking. Each customer is a separate tenant in that service, with its own database schema and database account, and device events are signed with a key per tenant. The service uses one internal API credential and one event endpoint for all tenants. (Planned: an API credential and an event route per tenant.)

B3. State and keys. Device records, the command queue and history, and enrolment and bootstrap tokens are stored in the device-management service's database in Caspian's AWS account. Bootstrap tokens and the private key of the Customer's push certificate are additionally sealed at rest with keys derived per tenant from a root key that Caspian holds. Device inventory, security state and command results are also sent to Caspian's production environment and stored there with the workspace's other data. None of this is under a key that the Customer holds. (Planned: device-management state and keys under a key in the Customer's own cloud.)

B4. Apple. The Customer's Apple Push Notification service certificate is issued by Apple to the Customer's own Apple Account, under the Customer's own agreement with Apple, and the Customer holds its Apple Business Manager account (where it uses one). Caspian signs the Customer's certificate request with Caspian's MDM vendor certificate. Caspian's device-management service holds the certificate's private key as described in B3 and uses the certificate only to send push messages to the Customer's enrolled devices. Caspian reminds the Owners before the certificate expires. Apple is not Caspian's Sub-processor (Annex III.3).

B5a. One-click commands. A Lock, Clear Passcode, Unlock User Account, Remove Application, Enable Lost Mode, Set Firmware Password and other commands that can be undone or do not remove data, run on the instruction of one Customer user with the Owner or Admin role, or automatically as a step in a workflow the Customer configured (for example offboarding). No second approval is needed. Each is logged.

B5. Irreversible commands. Caspian sends an Erase, Delete User (removing data), Remove Management, Set Recovery Lock or Activation Lock bypass command, or installs a profile that cannot be removed without a password, only after two different Customer users with the Owner role have approved that one command for that one Mac in the Services; an approval lapses after 30 minutes. Caspian's production environment then issues a single-use instruction naming both Owners, the command and the Mac, signed with a key that Caspian holds. The device-management service holds only the public half of that key and refuses any such command without a valid instruction. That instruction is the Customer's documented instruction under section 5. Because Caspian runs both the approval check and the signing key, the two-Owner rule is enforced by Caspian's systems, not by a key the Customer holds. (Planned: on request, signature with a key in the Customer's own cloud.) Caspian limits the number of destructive commands per hour, raises an alarm on each one, and can stop all destructive commands at once. Caspian may refuse or delay a destructive command it reasonably believes is not authentic, and tells the Customer at once. Caspian may suspend destructive commands across the Services to protect customers, and notifies affected customers.

B6. Escrowed secrets. FileVault recovery keys and managed administrator passwords escrowed by Caspian's endpoint agent, and device-lock PINs, recovery-lock passwords and Activation Lock bypass codes escrowed by the device-management service, are stored in Caspian's production environment. Each secret is encrypted with AES-256-GCM under a key that Caspian holds, bound to the workspace, the device and the kind of secret. Revealing a secret needs the approval of two Owners, except a device-lock PIN, which one Owner or Admin can reveal. Plaintext exists only in memory while a secret is stored, rotated or revealed. Escrowed secrets of a device are deleted 30 days after the device leaves Caspian's management, or earlier at the Customer's request. (Planned: secrets sealed under a key in the Customer's own cloud.)

B7. What is not collected. Device management collects no device location (no GPS, no Lost Mode location), no browsing history, no keystrokes and no screen content. Device data is limited to the device category in Annex I.F.5, including the asset location and travel notes the Customer's administrators enter themselves.

B8. Where it runs. All device-management data described in B3 and B6 is held by Caspian in AWS eu-central-1, in Caspian's device-management account and its production environment.

B9. Retention.

On unenrolment Caspian stops processing the device's data and deletes its escrowed secrets 30 days after unenrolment, or earlier at the Customer's request.
The device-management command audit log is kept 400 days.
At the end, Caspian deletes the device-management data it holds under section 12.2 and certifies it.

B10. Breach zones. Caspian side (device-management service, its certificate authority, Caspian's production environment, logs, credentials and keys): Caspian notifies within 48 hours. Apple: the Customer's relationship; Caspian tells the Customer if it learns of an issue. A destructive command sent without a valid two-Owner instruction is always a Caspian-zone incident.

B11. Liability for wipes and locks.

The Customer bears the consequences of a command executed on a valid two-Owner instruction, including data loss on the device.
Caspian is liable if it sends a destructive command without a valid instruction or to a device other than the one instructed, and for loss or disclosure of escrowed secrets caused in the Caspian zone. That liability falls under the Data Protection Cap in section 16.2 and is never capped lower.
Caspian is not liable where the Customer let its push certificate lapse or renewed it under another Apple Account.
Neither party is liable to the other for Apple service outages.

B12. Customer obligations. Renew the push certificate every year under the same Apple Account; name at least two Owners.

Schedule C: US State Privacy Addendum

C1. Application. This Schedule applies to personal information of US residents that Caspian processes for the Customer.

C1a. New York employee-monitoring notice. Where the Customer has employees in New York, New York Civil Rights Law §52-c requires the Customer, as employer, to give prior written notice of electronic monitoring on hiring, obtain each employee's acknowledgment, and post the notice. That duty is the Customer's. Caspian supports it by providing the information pack in section 9.4(c) (data collected, purposes, retention), which the Customer can use for its notice.

C1b. California and other states. Sections C2 to C4 apply only where the Customer has California personnel and the California Consumer Privacy Act as amended (CCPA) applies; section C5 applies where another US state comprehensive privacy law applies. Caspian is the Customer's service provider (CCPA) and processor (other states).

C2. CCPA terms (11 CCR §7051(a)(1)–(9), CPPA regulations effective 1 Jan 2026). Caspian:

does not sell or share personal information it receives under the Agreement;
processes it only for the specific business purposes in Annex I part D, which are the only purposes for which the Customer discloses it;
does not retain, use or disclose it for any other purpose, including any commercial purpose, except as the CCPA and its regulations allow a service provider;
does not retain, use or disclose it outside the direct business relationship with the Customer, and does not combine or update it with personal information from other sources or from its own interactions with the consumer, except as the CCPA and its regulations expressly allow;
complies with the CCPA and gives the same level of privacy protection the CCPA requires of businesses, including helping the Customer with consumer requests, its cybersecurity audits, risk assessments and automated decision-making obligations, and keeping reasonable security (Annex II);
allows the Customer to take reasonable and appropriate steps to ensure Caspian uses the information consistently with the Customer's obligations, including the reports and audits in section 13 at least once every 12 months;
notifies the Customer if it determines it can no longer meet its obligations;
allows the Customer, on notice, to take reasonable and appropriate steps to stop and remediate unauthorised use, including proof that deleted data is no longer retained or used;
enables the Customer to comply with consumer requests, or the Customer tells Caspian which requests it must act on and gives it the information needed.

C3. Sub-processors. Caspian's contracts with its sub-processors comply with the CCPA and §7051(a) (§7051(b)).

C4. Certification. Caspian certifies that it understands these restrictions and will comply with them.

C5. Other states. This section applies only to personal data within the scope of those laws; they generally exclude data about individuals acting in an employment context. For Virginia, Colorado, Texas and other states with comparable processor rules, Caspian also: binds its personnel to confidentiality; returns or deletes data at the end (section 12); makes available the information needed to show compliance; allows assessments (section 13); engages subcontractors only under a written contract and after giving the Customer an opportunity to object (section 8); and flows these duties down to them.

C6. Employee data. The Customer is responsible for any employee-monitoring notice required by state law (New York, section C1a; also Connecticut and Delaware where the Customer has staff there).

Schedule E: EU-Region Addendum (on order)

E1. Application. This Schedule applies when an order designates it, and narrows section 14.1 for the Customer's Services. Caspian does not offer it today: backups of Caspian's shared production environment, which hold the authentication records of every workspace and, for Part 2A, all Customer Personal Data, are copied to eu-west-1 (Ireland). (Planned: a deployment option without the eu-west-1 copy, so that E2 to E4 can be met.)

E2. Storage in Frankfurt. Caspian stores Customer Personal Data only in AWS eu-central-1 (Frankfurt), including Caspian's authentication records for the Customer's Authorised Users and backups. For a workspace under Part 2B, the Customer chooses a Frankfurt region for its Customer Data Plane and keeps its own backups there.

E3. No Ireland copy. Caspian keeps no backup copy in eu-west-1 (Ireland) of the Customer's data, unless the Customer agrees otherwise in writing. Security and infrastructure logs that contain no Customer Personal Data beyond staff identities may still be replicated to eu-west-1.

E4. AI inference. For the Customer's workspace Caspian calls Amazon Bedrock only in eu-central-1: through in-region model IDs or single-region inference profiles in eu-central-1. The AWS EU geographic inference profile (section 15.1) is used only if the order allows it. If no permitted model is available for a feature, that feature fails with an error rather than using another region.

E5. Exceptions that remain. Caspian's support mailbox (Google Workspace, section 12.4) and support access by Sub-processors' personnel under Annex III.

E6. Availability. Without the Ireland copy, the Customer's backups depend on one AWS region. The targets in Annex II §8 (RPO 24 hours, RTO 72 hours) apply except in a full loss of eu-central-1, for which no regional failover or recovery point objective is offered.