Legal

Data processing agreement

Version 1.11, 4 October 2026

This is the previous version. It applies until 14 November 2026, when the current version (v1.14) replaces it.

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.

Where Caspian processed Customer Personal Data for the Customer before the Effective Date (for example during a pilot), this DPA does not cover that earlier processing. The parties acknowledge that the earlier processing was not covered by a contract under Art. 28(3) GDPR.

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 (Customer-Hosted Data Plane) always applies: it describes how the Services are deployed for every Customer and forms part of this base DPA.
Schedule B (Device Management) applies from the moment the Customer enables device management.
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.

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.

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) product analytics of how Authorised Users use the Services (clicks, page views and masked screen recordings). Caspian collects these with one instance of analytics software that it hosts and operates itself in its own AWS account in eu-central-1 (Frankfurt), so no third party receives them; the analytics software is not a Sub-processor. Collection is always on for sign-up and onboarding, before any Customer Personal Data exists in the workspace. Inside a workspace it runs only if an Owner of that workspace switches it on (Settings → Advanced → Product analytics); it is off by default. In both cases all text and form inputs are masked in the browser before they are sent, screens that show people, devices, access, inventory, chat or privacy data are never recorded, user identifiers are replaced by a salted one-way hash, no names, email addresses or IP addresses are kept, no cookie is set (identifiers are kept in browser memory only), the browser's Do Not Track setting is respected, page addresses are recorded without record identifiers, and the data is deleted after 90 days. When an Authorised User moves to a workspace where analytics is not switched on, collection stops at once and the analytics identifier is reset. 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. The Customer instructs Caspian to derive from Customer Personal Data, and Caspian may 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. This section is a documented instruction under section 5.1.

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, and the instruction in section 3.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 enters into a written contract with each Sub-processor that imposes on it the same data protection obligations as this DPA, in particular sufficient guarantees on security, to the extent relevant to the service it provides. 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 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, once available, through self-service tools in the Services (Settings → Data & Privacy → Find a person: search, export and deletion of a person's records; corrections are made in the Customer's source systems). A self-service request runs as a background job; the requesting user is notified by email, without personal data in the email, when the result is ready, and the result is deleted after 7 days. Erasing a person deletes that person's personal data. The Customer's audit log is append-only and hash-chained, so its stored entries cannot be changed without breaking the chain: they are kept as evidence for their retention period (Annex I part H), and wherever the audit log is shown or exported, an erased person is shown as "erased person". This masking covers only fields that contain the erased person's email address; other fields in those entries (for example a display name or free text) are not masked. The record of access granted or removed is kept on the same basis. The record of acceptance of this DPA is kept as evidence. None of these is used for any other purpose. An erased person is not imported again from the Customer's connected systems on later syncs;
(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) Step-by-step identification. The Services keep data aggregated until the Customer switches per-person views on, and ask the Customer to confirm the warning phase before they do. The Customer remains responsible for following Belgian collective labour agreement (CAO/CCT) no. 81: first aggregated data only; where an anomaly appears, the Customer warns staff of it before identifying individuals for that anomaly; direct identification only for the purposes CAO no. 81 allows. Every per-person view is recorded in an audit log available to the Customer. Caspian provides the controls; the Customer decides when and how to use them.
(c) Customer's duty to inform. Before enabling collection, the Customer informs its works council (or, failing one, the committee for prevention and protection at work, the union delegation or the employees), and each employee concerned, as CAO no. 81, CAO no. 39 (where it applies) and other applicable law require. 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, from Settings → Data & Privacy (an Admin can export but not delete). If an Owner asks to delete the workspace, the deletion takes effect 30 days after the request, not at once. During those 30 days the Owners receive a link to the one-click export, which works while deletion is pending. During those 30 days an Owner can also cancel the deletion, in one of two ways: (a) from the workspace list, where the pending workspace is shown only to its Owners and opens a page from which the Owner can export all data or cancel the deletion; or (b) from the link in the deletion email. Each Owner receives a personal link, which works without signing in, can be used once, is valid only for that deletion request and until the deletion date, and works only while its holder is still an Owner. A cancellation is refused from day 30. When an Owner cancels, the workspace returns as it was (invitations revoked by the deletion request stay revoked), the cancellation is recorded in the audit log and all Owners are emailed. The export described in section 12.1 remains available throughout the 30 days. Section 12.2 then applies from the end of those 30 days.

12.2 Deletion. Customer Personal Data is stored in the Customer Data Account, which the Customer owns (Part 2). Within 30 days after the end of the Export Period (or earlier on the Customer's written instruction), Caspian carries out the deletion split in Part 2, A13, 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 of the Customer Data Account are under the Customer's control (Part 2, A9). Backups of Caspian's 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.

12.3a Timeline in short. Day 0: the Agreement ends. Days 0–30: Export Period. By day 60: Caspian-side deletion done (A13). By day 95: gone from Caspian's central-service backups. The deletion certificate is sent within 5 Business Days after the Caspian-side 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 Part 2 (A13) and Schedule B set out which party deletes what.

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 penetration test. Today this is Workstreet's external, unauthenticated black-box test of the public sign-in surface of app.getcaspian.io (19 August 2026): no critical, high or medium findings, 4 low and 3 informational; the signed-in product was out of scope. 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: storage in the Customer Data Account and processing in the Caspian Runtime Account, both in AWS eu-central-1 (Frankfurt) (Part 2), with a backup copy in AWS eu-west-1 (Ireland) only if the Customer switches it on in its own account (Part 2, A9); Caspian's central services (authentication, transactional email, and the shared front end at app.getcaspian.io described below) in AWS eu-central-1; replicas of Caspian's security and infrastructure logs (AWS CloudTrail, AWS Config, load-balancer access logs) in AWS eu-west-1 (Ireland); and AI inference in AWS EU regions (section 15). The only exceptions are those listed in Annex III: Caspian's support mailbox (Google Workspace), support access by Sub-processors' personnel and, until Caspian's own authentication service replaces it, Clerk (USA) for Authorised Users' sign-in data. 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.1a Shared front end. Authorised Users reach the Services at app.getcaspian.io. This shared front end, run by Caspian in AWS eu-central-1, routes each workspace's requests to that Customer's own Caspian Runtime Account. For that purpose it sees which workspace a request is for and checks that the request carries a valid session; requests and responses pass through it in memory only. It stores no Customer Personal Data and does not log request or response contents. The Caspian Runtime Account checks every request again itself. Sign-up, sign-in, the workspace list and onboarding are served by the shared front end directly. Each Caspian Runtime Account has an internal hostname (<customer>.runtime.getcaspian.io) that is not used by Authorised Users; it answers only requests from the shared front end that carry that runtime's own front-door key, and refuses all others. Keys differ per runtime, so one runtime's key opens no other. The one exception is the integration engine's sign-in page (nango.<customer>.runtime.getcaspian.io), which the browser opens while an Authorised User connects a tool; it accepts only Caspian's single-use connect-session tokens.

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. (Planned: an AWS-level control that 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 the following tools, as also listed in the Services' documentation: apply access changes (apply_access_changes), ask to remove in an access review (revoke_access_review), decide an access request (decide_access_request, decide_grant_access_request), mark an offboarding check as reviewed (review_offboarding_item; offboarding evidence can be approved only by Owners and Admins), start, publish or delete a workflow (start_workflow, publish_workflow, delete_workflow), take Caspian's profiles off a Mac (start_mdm_decommission), set a policy's trigger (set_policy_trigger), delete a policy (delete_policy) and delete a tool credential (delete_tool_credential). 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 (apply_access_changes, start_workflow, delete_workflow, start_mdm_decommission, delete_policy, delete_tool_credential) 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 or of its employees, auxiliaries or Sub-processors (Art. 5.89 Civil Code);
(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 2 and Schedule B add specific allocations for key revocation and device commands.

17. Insurance

17.1 During the term Caspian maintains, with a reputable insurer, cyber liability and technology errors-and-omissions insurance (which may be combined in one policy) with an aggregate limit of at least the amount in section 16.2(b).

17.2 Caspian provides a certificate of insurance on request, and once a year if the Customer asks. Caspian 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 Part 2 A13 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. Today these are held by Clerk, Inc. as listed in Annex III. (Planned: Caspian's own authentication service in AWS eu-central-1 stores them, 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. Clerk stays listed in Annex III until Caspian's former Clerk instance is deleted; its credentials are kept until then for rollback.)
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):

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)	24 hours in each Caspian Runtime Account. In Caspian's central-services account (production account 511) 365 days today; (Planned: 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
(Planned) Sessions, verification codes and rate-limit records of Authorised Users	deleted 1 day after they expire
(Planned) MCP access tokens	deleted 1 day after expiry or revocation
(Planned) Encrypted Google and Microsoft OAuth tokens of Authorised Users	as long as the user account exists
(Planned) Records of removed workspace memberships	until the workspace is purged (section 12.2)
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. Customer Data Account and Caspian Runtime Account in AWS eu-central-1 (Part 2); Caspian's central services, including the shared front end at app.getcaspian.io that routes requests in memory (section 14.1a), 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: databases, cache, object storage, EBS volumes and backups encrypted with AES-256 under customer-managed AWS KMS keys, rotated automatically every year.
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. Today this is provided by Clerk, Inc. (Annex III). (Planned: Caspian's own 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; it replaces Clerk once live.) The Customer's Caspian Runtime Account admits only users of the Customer's verified company domains, never a public email provider. 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. Each Customer has its own Customer Data Account (owned by the Customer) and its own Caspian Runtime Account (Part 2); no Customer Personal Data is stored in a shared database. Within the Services every request is also scoped to the authenticated workspace. 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 24 hours in each Caspian Runtime Account, and 365 days today in Caspian's central-services account (511) (Planned: 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. Caspian commissioned an independent external black-box penetration test of the public sign-in surface (Workstreet, 19 August 2026; no critical, high or medium findings) and repeats an independent test every year. (Planned: an authenticated follow-up test of the signed-in product, date to be set.) Container images are also scanned when pushed to Caspian's image registry. 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's side (the Caspian Runtime Account and Caspian's central services: authentication, Amazon Bedrock, Amazon SES): backed up daily and kept 35 days. Targets: RPO 24 hours, RTO 72 hours. The RPO target is not yet met for the loss of the whole eu-central-1 region: it is met for that case only once backups and their eu-west-1 copies run every 12 hours in production and a restore into eu-west-1 has been tested. 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 during the rollout of 4 October 2026, as required before this DPA is signed.
(b) Customer data plane (the Customer Data Account, Part 2): the deployment template enables daily encrypted Aurora backups with 14-day point-in-time recovery (the template refuses less than 14 days) and S3 versioning, all kept in eu-central-1. A second copy in eu-west-1 is off by default; the Customer can switch it on in its own account (template parameter EnableBackupCopy: a daily AWS Backup copy kept 35 days). Disaster recovery of the data plane is the Customer's choice and responsibility (Part 2, A9). Caspian helps restore from the Customer's backups on a best-effort basis; where the Customer has switched on the eu-west-1 copy, Caspian targets having the Services running again on the restored data plane within 72 hours of the Customer's request, with data as recent as the Customer's latest copy.

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. Founder laptops have full-disk encryption and screen lock enforced by 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). (Planned: AWS-level guards for the region and for 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 all Customer Personal Data from production; a scheduled job enforces the deadline in section 12.2; 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)	The Caspian Runtime Account (compute, in-memory processing) 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 (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)
Clerk, Inc. (USA) (until Caspian's former Clerk instance is deleted; its credentials are kept until then for rollback)	Authentication of Authorised Users	Name, email, organisation membership, sign-in IP and device metadata of Authorised Users	USA	EU-US Data Privacy Framework
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 AWS account

The Customer Data Account and its services (database, storage, the integration vault) are under the Customer's own contract with AWS and are not Caspian's Sub-processors. The integration and workflow engines are self-hosted software that Caspian runs in the Caspian Runtime Account, with their state stored in the Customer Data Account. See Part 2.

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 once it replaces Clerk, and the product analytics software, PostHog, in section 3.2(d)). The companies behind this software receive no data.

Part 2: Customer-Hosted Data Plane (the deployment model)

A1. Application and precedence. This Part applies to every Customer: the Services always run on the Customer-Hosted Data Plane. Caspian offers onboarding as a guided deployment (one-click AWS CloudFormation quick-create) into the Customer's own AWS account. When the Customer's stack is created, it notifies Caspian through a signed callback; Caspian then provisions the Caspian Runtime Account and deploys the Services automatically, without Caspian staff involvement unless the Customer asks for support. This Part is part of the base DPA and prevails over Part 1 on the matters it covers. Everything else in the DPA, including Caspian's security, confidentiality and assistance duties, continues to apply.

A2. Definitions.

"Customer Data Account" means the AWS account the Customer owns, inside the Customer's own AWS Organization, in which the data plane runs, in eu-central-1, as identified in the order form. It holds Aurora PostgreSQL, the S3 bucket, Secrets Manager, the integration vault, workflow state and the Customer KMS Key.
"Caspian Runtime Account" means a dedicated AWS account per customer that Caspian creates in its own AWS Organization, in eu-central-1, as identified in the order form, that runs the Caspian application, integration engine and workers on Caspian-operated compute. Caspian administers it. Runtime Accounts sit in a dedicated organisational unit, and Caspian's provisioning role can act only on accounts in that unit, not on Caspian's other accounts. It processes Customer Personal Data in memory and stores none of it at rest except the Outbound Metadata in A5.
"Caspian Roles" means the caspian-<customer>-deploy and caspian-<customer>-runtime IAM roles the Customer creates in the Customer Data Account, which Caspian assumes from the Caspian Runtime Account with an External ID.

A3. Role. The Customer hosts Customer Personal Data in the Customer Data Account. Caspian processes it as processor by remote access through the Caspian Roles and transiently in memory in the Caspian Runtime Account. Not hosting the data does not reduce Caspian's obligations under the DPA.

A4. Connection. The accounts connect over AWS private networking (PrivateLink / VPC Lattice), one way, without the public internet.

A5. Outbound Metadata Register. Caspian stores nothing from the Customer Data Account in the Caspian Runtime Account except the items below. Caspian does not add an item without 30 days' notice and the objection right in section 8.4.

Item	Purpose	Personal data?	Retention
Application and container logs	Operations, debugging	No (redacted automatically; no record content, credentials or request bodies)	≤ 24 hours
Security and access logs (who used which Caspian Role, operator sessions)	Security, audit	Staff identities only; no customer payloads	12 months
Metrics (counts, latencies, error rates)	Monitoring	No	15 months (AWS default)
Deployment configuration (account IDs, role ARNs, endpoint names, customer slug)	Routing	No	Term + 30 days
In-memory processing state (cache, queues)	Running requests and jobs	Yes, transient	Until the job ends; never written to disk (`/tmp` is memory-backed)

Authentication records of the Customer's Authorised Users are held in Caspian's central authentication service (Annex I.F.8), not in the Caspian Runtime Account.

The shared front end at app.getcaspian.io (section 14.1a) sees, for each request, the workspace it is for and whether its session is valid, and routes it to the Caspian Runtime Account; request and response contents pass through it in memory only. It stores no Customer Personal Data. Deployment records (account IDs, customer slug, External ID, runtime address, infrastructure state and internal DNS names under runtime.getcaspian.io) are kept in Caspian's central services, not in the Caspian Runtime Account, for the term plus 30 days, and contain no Customer Personal Data. Caspian's own shared OAuth client secrets for the Customer's tools are never stored in the Customer Data Account: the integration engine reads them at runtime from the Caspian Runtime Account, and the Customer's database holds only a placeholder. The OAuth tokens of the Customer's connections stay in the Customer Data Account, encrypted with the Customer's key.

A6. IAM roles and deny-list. Caspian uses only the Caspian Roles, with the permissions set out in the deployment template the Customer approved. The deploy role is denied at least: deleting databases, snapshots or backups; administering, disabling or scheduling deletion of the Customer KMS Key; changing CloudTrail; changing IAM; and changing the bucket policy. Caspian will not ask for or use broader permissions without the Customer's prior written consent. The Customer may narrow the roles at any time, accepting that the Services may degrade.

A7. CloudTrail visibility. Every use of the Caspian Roles and of the Customer KMS Key appears in the Customer's own CloudTrail. The Customer keeps CloudTrail enabled with at least 12 months' retention.

A8. Operator access and break-glass. Routine operation is automated. Caspian staff access Customer Personal Data only (a) at the Customer's documented request through support, or (b) in an emergency, where the session is ticketed with a reason, time-limited and fully logged to the Customer Data Account. Caspian notifies the Customer of every emergency session within 24 hours, with the reason and actions taken.

A9. Shared responsibility.

Area	Customer	Caspian
Customer Data Account security, SCPs, network	✔
Customer KMS Key, its policy and availability	✔
CloudTrail enablement and retention	✔
Backup policy of Aurora and S3 in the Customer Data Account	✔	Template enables Aurora backups and S3 versioning by default, kept in eu-central-1; Caspian never disables them
Second-region backup copy (eu-west-1) and disaster recovery of the Customer Data Account	✔ (off by default; the Customer switches it on in the deployment template, in its own account)	Helps restore from the Customer's backups (Annex II §8)
Caspian Runtime Account, application code and images		✔
Use of the Caspian Roles; Caspian personnel		✔
Physical infrastructure	AWS, under each party's contract with AWS

A10. Customer KMS Key. The Customer alone controls the Customer KMS Key. Caspian cannot administer it. If the Customer disables the key or revokes Caspian's grant, the Services stop at once. On AWS, an Aurora cluster whose key is disabled stays recoverable for 7 days; after that it becomes unusable and can be brought back only by restoring from backup once the key is enabled again. Deleting the key makes the encrypted data permanently unrecoverable.

A11. Key and customer-side actions: liability. Caspian is not liable for loss, unavailability or corruption of Customer Personal Data in the Customer Data Account to the extent caused by the Customer disabling, deleting or failing to maintain the Customer KMS Key, by the Customer's backup settings, or by changes the Customer makes to its account or the Caspian Roles. This does not apply to loss caused by Caspian's breach of this Schedule, gross negligence or wilful misconduct, and does not limit section 16.4. Fees remain due during a suspension the Customer causes.

A12. Breach zones.

(a) Caspian zone (Caspian Runtime Account, Caspian's Sub-processors, Caspian staff): Caspian notifies within 48 hours of awareness (section 10).
(b) Misuse of the Caspian Roles or of Caspian-deployed code in the Customer Data Account, including stolen Caspian credentials: treated as Caspian zone. Caspian also rotates credentials and supports the Customer's CloudTrail investigation.
(c) Customer zone (the Customer Data Account, not involving the Caspian Roles or code): 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.

A13. Deletion split. Processing ends when the order ends or the Customer revokes the Caspian Roles, whichever is first. The Customer already holds its data, so no Export Period is needed. Within 30 days Caspian (a) deletes everything in A5 and its authentication records for the Customer's users, (b) on instruction removes the components it deployed in the Customer Data Account, or hands over the tooling for the Customer to do so, (c) closes the Caspian Runtime Account, and (d) sends a deletion certificate, which includes a line confirming the Runtime Account closure. The close-out of the Runtime Account runs in this order: a dry run, confirmation by a member of Caspian's operations staff, removal of all resources in the Runtime Account, removal of the DNS records belonging to that Runtime Account only, and closure of the account. If the removal of resources fails, the account is not closed and Caspian's operations staff are alerted. Data in the Customer Data Account, including the KMS key and the S3 bucket, which survive stack removal by design, is the Customer's to keep or delete.

A14. Audit. The Customer's CloudTrail, Caspian's operator-session log (kept 12 months, provided on request) and Caspian's reports under section 13.1 are the primary evidence for this Part. Section 13.2 audits remain available.

A15. Region. Caspian does not deploy components outside eu-central-1 without the Customer's written instruction, except Bedrock inference in AWS EU regions. The second-region backup copy in eu-west-1 exists only if the Customer switches it on (A9).

A16. Architecture changes. If Caspian changes this deployment model so that a new category of data leaves the Customer Data Account, it gives 30 days' notice with an updated A5. The Customer may then terminate the affected Services with a pro-rata refund.

A17. Customer obligations (operational; not Art. 28 duties). Keep the Caspian Roles, network path and KMS grants as approved; keep CloudTrail; grant no access beyond what the Services need; bear the costs of the Customer Data Account.

A18. AWS costs. The Customer pays its own AWS costs directly to AWS, including the optional second-region backup copy; they are not part of Caspian's fees.

Schedule B: Device Management (optional)

B1. Application. This Schedule applies from the moment the Customer enables device management in the Services. It covers company-owned Macs only. It does not cover personally owned devices or Windows devices.

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 works-council information or consultation and DPIA (section 9.4). Caspian provides the Customer with the information it needs for its employee notice and works-council information on device management: data collected, commands available, approvals required and retention.

B2a. Dedicated service. Caspian runs a separate device-management engine for each customer in that customer's Caspian Runtime Account (Part 2), reachable at a customer-specific endpoint (for example <customer>.mdm.getcaspian.io), with its own API key. It is not shared with other customers. The engine stores no device data at rest in the Caspian Runtime Account; its data and keys are in the Customer's account (B3, B6). Caspian's former shared device-management account holds no Customer Personal Data and only relays or is retired. On order, the engine can instead run entirely in the Customer's own AWS account.

B3. Customer-held state and keys. All device-management state (device records, command queue and history, script output, enrolment and bootstrap tokens) is stored only in an Aurora PostgreSQL database in the Customer's AWS account, encrypted under the Customer's KMS key. Caspian processes it through the Caspian Roles and in memory.

B4. Apple. The Customer holds the Apple Push Notification service certificate and the Apple Business Manager account for its devices, under its own Apple Account and its own agreement with Apple. The push certificate is created by the Customer in Apple's portal under its own Apple Account (a Managed Apple Account is recommended). The private key for it is generated by the Customer's device-management engine, is stored only sealed under the Customer's KMS key (B3), is reused for renewals and never leaves the engine. Caspian signs the Customer's certificate request with Caspian's MDM vendor certificate, and Caspian's engine sends the push messages, using the Customer's certificate and server token only to manage the Customer's devices. Caspian reminds the Owners 30 and 7 days 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 or signature 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 on an instruction that:

(a) two different Customer users with the Owner role approved in the Services; and
(b) after both approvals, is signed once with an approval key held in the Customer's AWS KMS, by a role the Customer names.

That signed instruction is the Customer's documented instruction under section 5. Caspian holds no key or credential that can produce it: the approver signs in their browser with their own sign-in to the Customer's AWS account, and the signature appears in the Customer's CloudTrail. Before the sign-in opens, the browser decodes the instruction and refuses to sign unless it names the command, action and Mac shown to the approver, the two approvers and a valid expiry. Residual risk: Caspian serves the web page and the code used for signing, so a compromised Caspian frontend could skip that check during a real Owner sign-in. The browser check protects against a compromised Caspian backend only. Remaining safeguards: a live sign-in by a named Owner, a 15-minute session that can only sign with the approval key, the digest in the Customer's CloudTrail and per-hour limits on destructive commands. On request, Caspian supports a signing page hosted by the Customer and running code the Customer controls, which removes this risk. 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, local administrator passwords, Activation Lock bypass codes and bootstrap tokens are stored only in the Customer's AWS account, encrypted under the Customer's KMS key: each secret is sealed with its own data key generated by that key, bound to the Customer, the device and the kind of secret. Caspian refuses to escrow a secret if the Customer's key is not available, and never falls back to a key of its own. Caspian decrypts a secret only to rotate it, to show it once to a Customer user after a second Owner approves, or once to re-seal under the Customer's key a secret stored before this Schedule applied. Plaintext exists only in memory during that operation. Each reveal is a separate decryption with the Customer's key and appears as its own Decrypt event in the Customer's CloudTrail; storing a secret appears there as a GenerateDataKey event. A revealed administrator password is rotated within one hour. Escrowed secrets of a device are deleted 30 days after the device is unenrolled or removed, or earlier at the Customer's request (B9).

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. What Caspian holds on its side. Only: operational logs and metrics with no command payloads or secrets, kept at most 30 days; device identity certificates issued by Caspian's certificate authority; the routing configuration for the Customer's account; and the names and emails of approvers as Authorised Users.

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.
Script output is kept 90 days unless the Customer sets another period, and is capped in size.
The device-management audit log is kept 400 days, and a copy is delivered to the Customer's account at least daily.
At the end, Caspian deletes the items in B8 within 30 days and certifies it. Data in the Customer's account is the Customer's to keep or delete.

B10. Breach zones. Customer account (database, KMS, approver role): the Customer's. Caspian side (device-management service, certificate authority, logs, runtime credentials): 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 signed instruction, or misuse of Caspian's runtime role, is always a Caspian-zone incident.

B11. Liability for wipes and locks.

The Customer bears the consequences of a command executed on a valid signed 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 escrowed secrets become unrecoverable because the Customer disabled, deleted or restricted its key, deleted its database or backups, or 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; keep the key, approver role and database available; name at least two Owners; keep CloudTrail.

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. It narrows section 14.1 for the Customer's Services. The Customer Data Account is already in eu-central-1 and dedicated to the Customer (Part 2, A15); this Schedule adds the commitments below.

E2. Storage in Frankfurt. Caspian stores Customer Personal Data only in AWS eu-central-1 (Frankfurt). This covers the production databases, object storage, Caspian's authentication records for the Customer's Authorised Users, and backups. The Services refuse to switch the Customer's workspace to EU-Region mode unless the stack, its object storage and its backups are all confined to eu-central-1.

E3. No Ireland copy. The Customer's stack is deployed without the backup copy to eu-west-1 (Ireland), 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.