Data Processing Agreement

This Data Processing Agreement (the "DPA") sets out how Spyral processes personal data on behalf of its customers. It forms part of the agreement between Spyral and the Customer under the Terms of Service (the "Terms"). It follows the standard contractual clauses between controllers and processors that the European Commission adopted in Implementing Decision (EU) 2021/915, adapted into a standalone agreement for the Services.

A Workspace owner accepts this DPA in the application on behalf of the Customer (clause 19). Nothing in this DPA reduces the protection that data subjects have under the GDPR.

1. Parties

1.1 Controller. The business that subscribes to the Services and on whose behalf the Workspace is operated (the "Customer").

1.2 Processor. Spyral, as identified in the Terms and below ("Spyral"):

1.3 Customer acting as processor. Where the Customer itself processes personal data on behalf of its own clients (for example, a firm that processes data as processor for the companies it administers), Spyral acts as the Customer's sub-processor for that data. In that case the Customer warrants that its instructions to Spyral, including the engagement of Spyral and of the Sub-processors in Annex III, are authorised by the controller concerned, and the Customer passes on to that controller any information this DPA requires Spyral to give.

2. Definitions

Terms defined in the GDPR, such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority", have the meaning the GDPR gives them. In addition:

• Agreement: the Terms, this DPA and any other document the Terms incorporate.
• Allowed Countries: the Member States of the European Economic Area (EEA) and Switzerland.
• Customer Content: the documents and other content that the Customer and its users upload, connect or create in the Services, and everything derived from them. This includes extracted text, classifications and extracted attributes, company and person directory records, ownership relationships, search indexes and embeddings, bookkeeping entries, annual accounts files, AI output, chat conversations and review records.
• Customer Personal Data: personal data contained in Customer Content, and any other personal data that Spyral processes on behalf of the Customer under the Agreement, as described in Annex I.
• Data Protection Law: Regulation (EU) 2016/679 (the "GDPR"), the Luxembourg Law of 1 August 2018 on the organisation of the National Data Protection Commission and the general data protection framework, and any other EU or Member State law on the protection of personal data that applies to the processing.
• Services: the Spyral platform and related services described in the Terms.
• Sub-processor: a processor that Spyral engages to carry out processing of Customer Personal Data.
• Workspace: the isolated tenant in the Services that belongs to the Customer.
• Workspace owner: a user who holds the owner role in the Customer's Workspace. This is the role that manages the Customer's subscription and can export or close the Workspace.

3. Scope, roles and duration

3.1 This DPA applies to all processing of Customer Personal Data by Spyral under the Agreement. Annex I describes the subject matter, nature and purpose of the processing, the types of personal data, the categories of data subjects and the duration.

3.2 For Customer Personal Data, the Customer is the controller and Spyral is the processor, or the sub-processor in the case described in clause 1.3.

3.3 Spyral is an independent controller for the personal data it processes for its own purposes: user accounts and sign-in; billing and payment; measurement of usage of the Services, including the record of which AI provider and model handled each operation and where; the security of the Services and the diagnosis of errors; support correspondence; records of acceptance of its legal documents; service communications; compliance with its legal obligations, including notices under the Digital Services Act; and marketing to business contacts. The Privacy Policy describes that processing, and this DPA does not apply to it.

3.4 Activity records of the Customer's Workspace (which user did what, and when) are kept for the Customer as part of its audit trail and are processed on its behalf. Spyral also uses those records as controller to keep the Services secure, as described in the Privacy Policy.

3.5 Apart from the purposes in clauses 3.3 and 3.4, Spyral does not process Customer Personal Data for its own purposes. Error reports can contain fragments of Customer Content that were part of a failed request. Spyral uses them only to diagnose and fix the fault, removes the personal data fields it can identify before storing them, and deletes them as Annex II section 10 describes. Where the Terms allow Spyral to keep statistics about how the Services are used, those statistics must not contain personal data. Anything else that contains personal data is Customer Personal Data and remains subject to this DPA.

3.6 This DPA applies for as long as Spyral processes Customer Personal Data. That includes the retrieval and deletion period after the Agreement ends (clause 12).

4. Instructions

4.1 Spyral processes Customer Personal Data only on the Customer's documented instructions, unless EU or Member State law to which Spyral is subject requires otherwise. In that case Spyral informs the Customer of that legal requirement before processing, unless the law prohibits this on important grounds of public interest.

4.2 The Customer's documented instructions are:

• (a) the Agreement, including this DPA;
• (b) the Customer's configuration of the Services and the actions its authorised users take in them, such as uploading, connecting, sharing, editing, exporting and deleting content, running searches and AI features, and sending signature requests; and
• (c) any further written instructions the parties agree.

Instructions that an authorised user gives through the Services are the Customer's instructions.

4.3 Spyral informs the Customer without delay if, in Spyral's opinion, an instruction infringes Data Protection Law. Spyral may suspend the instruction concerned until the Customer confirms or changes it.

4.4 Transfers of Customer Personal Data outside the EEA take place only as set out in clause 11.

4.5 Where the Customer instructs Spyral to send Customer Content to a third-party service that the Customer selects, that service is the Customer's own recipient and not a Sub-processor. Examples are a file storage service the Customer connects, a messaging channel it links to receive notifications, and its own electronic signature account. The Customer's own terms with that provider govern its relationship with it.

5. The Customer's obligations

5.1 The Customer is responsible for:

• (a) having a lawful basis for the processing it instructs, and for the lawfulness of the Customer Content it uploads or connects;
• (b) informing its own data subjects;
• (c) the accuracy of Customer Personal Data;
• (d) configuring roles and document visibility in its Workspace;
• (e) carrying out any data protection impact assessment that applies to it;
• (f) deciding how long Customer Content is kept, and deleting what it no longer needs; and
• (g) reviewing AI output before relying on it.

5.2 The Customer will not upload special categories of personal data under Article 9 GDPR, or personal data relating to criminal convictions and offences under Article 10 GDPR, unless it has a lawful basis and the parties have agreed the additional safeguards in writing. If such data appears in a document, Spyral protects it with the same measures as all other Customer Content.

5.3 Where the Customer is bound by professional secrecy or by a supervisory framework, the Customer is responsible for confirming that its use of the Services is permitted, and for obtaining any consent or authorisation that applies (clause 14).

6. Confidentiality and access by Spyral personnel

6.1 Spyral ensures that every person it authorises to process Customer Personal Data has committed in writing to confidentiality, or is under an appropriate statutory obligation of confidentiality, and that the commitment continues after their engagement ends.

6.2 Spyral gives its personnel access to Customer Personal Data only to the extent strictly necessary to perform, manage and monitor the Agreement. The Services are designed so that Spyral personnel have no function to browse Customer Content. Error records shown in the platform administration area can contain fragments of Customer Content that were part of a failed request (clause 3.5). Spyral personnel access Customer Content only:

• (a) when the Customer asks Spyral to investigate a specific problem, and then only the content concerned;
• (b) when strictly necessary to respond to a security incident or to restore the operation of the Services; or
• (c) when EU or Member State law requires it, subject to clause 15.

Such access is limited to named personnel and to what the purpose requires.

6.3 On request, Spyral will agree in writing that access under clause 6.2(a) or (b) takes place only with the Customer's prior consent for each occasion, or under the Customer's supervision. The only exception is immediate action needed to contain a security incident, which Spyral reports to the Customer afterwards.

7. Security of processing

7.1 Spyral implements at least the technical and organisational measures described in Annex II. They are designed to ensure a level of security appropriate to the risk, as Article 32 GDPR requires. In setting that level, the parties have taken into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to data subjects, in particular the confidential, professional and financial character of Customer Content.

7.2 Spyral regularly tests, assesses and evaluates the effectiveness of these measures. It may update them over time, provided that the overall level of protection is not reduced.

8. Sub-processors

8.1 General authorisation. The Customer gives Spyral general written authorisation to engage the Sub-processors listed in Annex III. The same list is published at /legal/subprocessors.

8.2 Notice of changes. Spyral informs the Customer in writing of any intended addition or replacement of a Sub-processor at least 30 days before the new Sub-processor processes Customer Personal Data. Notice is given by email to the Workspace owners and by notice in the application, and the updated list is published as a new version. The notice identifies the Sub-processor, the processing it will carry out and where it will carry it out. A listed Sub-processor starting to process Customer Personal Data outside the Allowed Countries is treated as an addition. A change of the AI model that a listed Sub-processor runs is not a change of Sub-processor, provided the model runs in the Allowed Countries. The models in use are listed in the AI register at /legal/ai.

8.3 Objection. The Customer may object to an intended change on reasonable grounds relating to the protection of personal data, by writing to privacy@spyral.lu within the notice period. The parties then discuss the objection in good faith, and Spyral may propose an alternative, such as not using the new Sub-processor for the Customer's data. If the objection is not resolved before the change takes effect, the Customer may terminate the affected Services with effect before the change, without penalty. Spyral then refunds any prepaid fees for the period after termination.

8.4 Urgent replacement. Where a Sub-processor must be replaced at short notice to protect the security of Customer Personal Data or the continuity of the Services, for example because it has stopped providing its service, Spyral may give a shorter notice period. Spyral still gives notice before the replacement processes Customer Personal Data, and clause 8.3 applies in the same way.

8.5 Flow-down. Spyral engages each Sub-processor under a written contract that imposes on it, in substance, the same data protection obligations as this DPA imposes on Spyral, in particular sufficient guarantees of appropriate technical and organisational measures, confidentiality, assistance, deletion at the end of the service, and information for audits. That contract also requires the Sub-processor to impose equivalent obligations on any processor it engages in turn. Spyral sends no Customer Personal Data to a Sub-processor before that contract is in place, and Annex III shows any Sub-processor whose contract is not yet in place. On the Customer's request, Spyral provides a copy of a Sub-processor's data protection terms. The copy may be redacted to protect business secrets or other confidential information, including personal data.

8.6 Responsibility. Spyral remains fully responsible to the Customer for the performance of each Sub-processor's obligations. Spyral notifies the Customer of any failure by a Sub-processor to fulfil its data protection obligations.

9. Assistance to the Customer

9.1 Data subject requests. Spyral notifies the Customer without undue delay, and in any case within five business days, of any request it receives directly from a data subject about Customer Personal Data. Spyral does not respond to the request itself unless the Customer authorises it to, other than to refer the data subject to the Customer.

9.2 Self-service functions. The Services let the Customer act on most requests itself. Content can be searched, edited and deleted in the application. Each user can export their own data and delete their own account from the account settings. A Workspace owner can export the whole Workspace in machine-readable form (clause 12.1). Where the Customer cannot fulfil a request with these functions, Spyral assists on request, taking into account the nature of the processing.

9.3 Articles 32 to 36 GDPR. Taking into account the nature of the processing and the information available to it, Spyral assists the Customer in meeting its obligations:

• (a) on the security of processing, through the measures in Annex II;
• (b) on personal data breaches, as set out in clause 10;
• (c) on data protection impact assessments. On request, Spyral provides a DPIA support pack that describes the processing in the Services, the data flows, the AI models used and where they run, retention, and the security measures, and Spyral answers the Customer's reasonable questions for its assessment; and
• (d) on prior consultation with a supervisory authority, by providing the information the Customer needs for it.

9.4 Spyral provides the assistance in this clause without additional charge. Where the assistance requested goes materially beyond what the GDPR requires of a processor, Spyral may charge reasonable costs that it agrees with the Customer in advance.

9.5 Spyral keeps a record of the processing it carries out on behalf of its customers, as Article 30(2) GDPR requires, and cooperates with the competent supervisory authority on request.

10. Personal data breaches

10.1 Spyral notifies the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, and in any case within 48 hours. Notice goes by email to the Workspace owners and to any privacy contact the Customer has asked Spyral to add to its notification list by writing to privacy@spyral.lu, and, where appropriate, also appears in the application.

10.2 The notice contains at least the following, to the extent the information is available:

• (a) the nature of the breach, including, where possible, the categories and approximate number of data subjects and of personal data records concerned;
• (b) the name and contact details of Spyral's contact point for the breach;
• (c) the likely consequences of the breach; and
• (d) the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects.

Where not all of this information is available at once, the first notice contains what is known, and the rest follows in phases without undue delay.

10.3 Spyral takes the measures necessary to contain the breach and mitigate its effects. It documents each breach affecting Customer Personal Data (the facts, the effects and the remedial action) and makes that record available to the Customer. Spyral assists the Customer with its notifications to the supervisory authority under Article 33 GDPR and to data subjects under Article 34 GDPR. Spyral does not notify the Customer's supervisory authority or data subjects on the Customer's behalf unless the Customer instructs it to or the law requires it.

10.4 Where the Customer's regulatory regime imposes a shorter or additional reporting duty, the parties agree in writing the information and timing Spyral needs to provide to support it (Annex IV).

10.5 Notifying a breach is not an admission of fault or liability.

11. Location of processing and international transfers

11.1 Where data is processed. Spyral stores and processes Customer Personal Data in the Allowed Countries, except as clause 11.2 permits. The Services store Customer Content in the European Union, in Frankfurt (Germany). AI processing takes place in the Allowed Countries, at the locations shown in the AI register at /legal/ai. Each Sub-processor processes Customer Personal Data at the locations shown in Annex III, subject to clause 11.2.

11.2 Permitted transfers. Spyral does not transfer Customer Personal Data to a country outside the EEA, or to an international organisation, except:

• (a) to Switzerland, where an AI provider's European endpoint processes a request there. The European Commission has recognised Switzerland as providing adequate protection (Decision 2000/518/EC);
• (b) where a Sub-processor, or a company in its group, may access Customer Personal Data from outside the EEA for support or security operations, as its data protection terms allow. Any such access must rest on an adequacy decision, including the EU-US Data Privacy Framework (Implementing Decision (EU) 2023/1795) where the recipient is certified, or on the standard contractual clauses in clause 11.3;
• (c) where the Customer instructs it, for example by connecting a service under clause 4.5;
• (d) where EU or Member State law requires it, under clause 4.1; or
• (e) where Annex III shows that a Sub-processor that delivers email or monitors errors stores data outside the EEA. Emails and error reports can contain small parts of Customer Content, such as a document name. Such storage must rest on an adequacy decision or on the standard contractual clauses in clause 11.3.

By accepting this DPA, the Customer instructs the transfers in (a), (b) and (e). Each transfer must comply with Chapter V GDPR.

11.3 New third-country processing. No processing of Customer Content in a third country without an adequacy decision is planned. If Spyral ever proposes it, it gives notice under clause 8.2. The transfer then relies on the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914, Module Three (processor to processor), concluded with the Sub-processor and supported by a transfer impact assessment and by supplementary measures where that assessment calls for them.

11.4 Location controls for AI. Some AI providers operate shared endpoints whose terms allow them to change where a model runs. Spyral does not rely on that location staying fixed:

• it checks the location each provider publishes for each model before routing any request to it;
• where the provider reports it, it checks the location that actually served each request; and
• it does not route Customer Personal Data to a model it knows to run outside the Allowed Countries.

If a response shows that a request was served outside the Allowed Countries, Spyral stops using that model at once, moves further requests to the next model that runs in the Allowed Countries, and informs the Customer without undue delay. If no such model is available, the AI feature concerned fails rather than sending data outside the Allowed Countries.

11.5 Data in transit. A connection between a user and the Services may pass through the hosting provider's network location nearest to that user. That location can be outside the EEA when the user is.

11.6 On request, Spyral tells the Customer which transfer mechanism applies to any Sub-processor.

12. Deletion and return of data

12.1 Export. At any time during the Agreement, a Workspace owner can request an export of the whole Workspace from the application, after confirming with their password, and with their two-factor code where two-factor authentication is enabled. The export is a ZIP archive containing:

• the Workspace data as JSON and CSV files;
• a manifest that describes the schema and lists anything not included, with the reason; and
• a list of the original files, with download links.

The archive and the download links remain available for 7 days. Individual documents and outputs can also be downloaded at any time.

12.2 Closing the Workspace. A Workspace owner can close the Workspace in the application, with the same confirmation. Closure starts a retrieval period of 30 days. During that period the Workspace keeps working, all members are told about the closure in the application, and a Workspace owner can export the data or cancel the closure. When the retrieval period ends, Spyral permanently deletes the Customer Personal Data in the Workspace: database records, stored files and search indexes, including embeddings. When deletion is complete, Spyral sends the Workspace members an erasure confirmation by email, stating the number of records and files deleted.

12.3 Other endings. If the Agreement ends in any other way, the same applies: Customer Personal Data remains retrievable for at least 30 days after the Agreement ends, and Spyral deletes it from the Services no later than 90 days after the Agreement ends. If the Customer needs a longer retrieval period, it should say so before the Agreement ends, and the parties will agree one.

12.4 Deletion during the Agreement. When a user deletes a document, Spyral deletes the document record, its stored original file and the data derived from it in the database. When a user deletes a company record, it is hidden at once and permanently erased 12 months later, together with person records that only that company referenced. A company that is the subject of a ledger, an annual accounts document or an approval and signature workflow is part of the Customer's statutory records: it is hidden but kept until the Workspace is erased under clause 12.2 or 12.3. During those 12 months the company is restored if a user adds the same company again, or uploads a document in which it is a party or the subject, so that its documents and people are not lost.

12.5 What remains. After a Workspace is erased, Spyral keeps a record of the closure as evidence of the erasure: the Workspace name, the user who requested the closure, the relevant dates, and the number of records and files deleted. This record contains no Customer Content. Data that Spyral holds as controller, such as billing records, is kept as the Privacy Policy describes.

12.6 Backups. Where Customer Personal Data is held in backups, it is deleted when those backups expire under the arrangements described in Annex II. Spyral does not restore backups to the Services in the meantime except to recover from an incident. If it does, it deletes again any data that the Customer had already deleted.

12.7 Confirmation and legal holds. On request, Spyral confirms the deletion in writing. Where EU or Member State law requires Spyral to keep Customer Personal Data, Spyral keeps only what the law requires, for as long as it requires, and continues to apply this DPA to it.

13. Information and audits

13.1 Spyral makes available to the Customer all information necessary to demonstrate compliance with Article 28 GDPR and this DPA. Spyral answers reasonable written requests for information, including security questionnaires, within 30 days.

13.2 Spyral first offers its existing documentation. This includes a description of its technical and organisational measures, its record of processing for the Services, summaries of its Sub-processors' data protection terms, and any third-party certification or audit report Spyral holds. Such documentation often answers the request.

13.3 Where that information does not reasonably demonstrate compliance, or after a personal data breach affecting Customer Personal Data, or where a supervisory authority requires it, the Customer may carry out an audit or inspection itself or through an independent auditor. The auditor must be bound by confidentiality and must not be a competitor of Spyral. The audit takes place:

• on at least 30 days' written notice, or shorter notice after a breach or where an authority requires it;
• during business hours, under a scope and plan agreed in advance, remotely where that is sufficient;
• no more than once in any 12-month period, except after a breach or where an authority requires it; and
• without access to other customers' data, or to information whose disclosure would compromise the security of the Services.

13.4 The Customer bears its own costs and those of its auditor, and Spyral bears its own. If an audit reveals a material breach of this DPA by Spyral, Spyral bears the reasonable costs of the audit and remedies the breach without delay.

13.5 Spyral cooperates with audits and inspections by a supervisory authority competent for the Customer, including the Commission nationale pour la protection des données (CNPD) and, for a supervised Customer, its prudential supervisor, to the extent EU or Member State law requires it.

13.6 Audit results are confidential information of both parties.

14. Professional secrecy

14.1 Spyral acknowledges that many of its customers are bound by professional secrecy, for example under Article 458 of the Luxembourg Penal Code, Article 41 of the Law of 5 April 1993 on the financial sector, or the rules of their profession. It also acknowledges that disclosure of information covered by that secrecy may expose the Customer and its personnel to criminal, disciplinary and regulatory sanctions.

14.2 Spyral is not a professional of the financial sector and is not supervised by the Commission de Surveillance du Secteur Financier (CSSF). Whether or not a statutory secrecy obligation applies to Spyral, Spyral undertakes by contract that:

• (a) all Customer Content is treated as confidential information covered by the Customer's professional secrecy;
• (b) its personnel access Customer Content only as clause 6 permits;
• (c) every person it authorises to process Customer Content is bound by a written confidentiality obligation that expressly covers information subject to professional secrecy and continues after their engagement ends;
• (d) it discloses Customer Content to no one, including public authorities, except to Sub-processors under clause 8, or where the law requires it under clause 15;
• (e) Sub-processors receive only the data they need to perform their service, encrypted in transit and at rest; and
• (f) these obligations continue without time limit.

14.3 Where the Customer relies on an exception to its secrecy obligation that permits outsourcing, it may have to inform its own clients of, or obtain their acceptance to, the outsourcing, the types of information transmitted and the countries in which the service providers are established. Annex I and Annex III give that information, and Spyral provides any further detail the Customer needs on request. Several Sub-processors belong to groups established outside the EEA, even where they process data inside it. The Customer should take that into account.

14.4 The Customer remains responsible for deciding whether its secrecy regime permits its use of the Services (clause 5.3). Where its regime requires further terms, Annex IV applies.

15. Requests from public authorities

15.1 If Spyral receives a request from a public authority for Customer Personal Data, Spyral:

• (a) assesses the legality and proportionality of the request, and challenges a request that is invalid or overbroad;
• (b) where possible, redirects the authority to the Customer;
• (c) notifies the Customer promptly before disclosing, unless the law prohibits it; and
• (d) discloses only the minimum the request lawfully requires.

15.2 Spyral has not built, and will not build, any facility that gives a public authority direct or unsupervised access to Customer Personal Data.

16. Non-compliance and suspension

16.1 Spyral informs the Customer promptly if it is unable to comply with this DPA for any reason.

16.2 If Spyral is in breach of this DPA, the Customer may instruct Spyral to suspend the processing of Customer Personal Data until compliance is restored. The Customer may terminate the Agreement, as far as it concerns the processing of Customer Personal Data, if:

• (a) the processing has been suspended under this clause and compliance is not restored within one month;
• (b) Spyral is in substantial or persistent breach of this DPA; or
• (c) Spyral fails to comply with a binding decision of a competent court or supervisory authority about its obligations under this DPA or Data Protection Law.

If the Customer terminates under this clause, Spyral refunds any prepaid fees for the period after termination.

16.3 Spyral may terminate the Agreement, as far as it concerns the processing of Customer Personal Data, if the Customer insists on an instruction after Spyral has informed it under clause 4.3 that the instruction infringes Data Protection Law.

16.4 After termination under this clause, clause 12 applies.

17. Liability

17.1 Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Terms, except where Data Protection Law provides otherwise. Nothing in this DPA limits the rights of data subjects under Article 82 GDPR, or makes a party liable for an administrative fine imposed on the other.

17.2 Spyral is liable to the Customer for the acts and omissions of its Sub-processors as for its own (clause 8.6).

18. Precedence, changes and governing law

18.1 Order of precedence. On the protection of personal data, the following order applies where documents conflict:

• (a) standard contractual clauses concluded under clause 11.3;
• (b) a regulatory addendum signed by both parties under Annex IV, on its subject matter;
• (c) this DPA;
• (d) the Terms; and
• (e) the documentation in the application.

A written agreement signed by both parties that expressly amends this DPA prevails over it.

18.2 Changes. Spyral may update this DPA to reflect changes in the law, in the Services or in its practices. Changes to the list of Sub-processors follow clause 8, not this clause. Each version is published with its version number, the earlier versions remain available, and the version history appears at the end of this document. Spyral notifies a material change at least 30 days before it takes effect, by email to the Workspace owners and by notice in the application, and asks a Workspace owner to accept the new version in the application. A change required by law, or needed to address a security risk, may take effect sooner. If a material change is unacceptable to the Customer, it may terminate the Agreement before the change takes effect.

18.3 Severability. If a provision of this DPA is invalid or unenforceable, the rest continues in force, and the provision is replaced by a valid one that comes as close as possible to its purpose and to the requirements of Article 28 GDPR.

18.4 Governing law. This DPA is governed by the law that governs the Terms, and the courts named in the Terms have jurisdiction, without prejudice to the rights of data subjects and the powers of supervisory authorities under Data Protection Law.

19. Acceptance and record of acceptance

19.1 A Workspace owner accepts this DPA on behalf of the Customer in the application, either when the Workspace is created or when the application asks for acceptance of this DPA or of a new version of it. Other users of the Workspace are informed but do not need to accept. The person accepting confirms that they are authorised to bind the Customer.

19.2 Spyral records each acceptance. The record holds the accepting user, the Workspace, the version accepted, a cryptographic fingerprint of the English text of that version, the language in which it was displayed, the date and time, and the IP address and browser details used. On request, Spyral gives the Customer a copy of its acceptance records and of every version it accepted. Earlier versions also remain available on this site.

19.3 A Customer that needs a counterpart signed by hand or by electronic signature can request one at privacy@spyral.lu. The signed counterpart is recorded as an acceptance of the same version.

19.4 This DPA is drafted in English, and the English version is binding. Translations are provided for convenience only, and in case of any difference the English version prevails.

Annex I: Description of the processing

A. Parties and contacts

• Controller: the Customer, as identified in its Workspace and billing details. Contacts: the Workspace owners and any privacy contact the Customer asks Spyral to add to its notification list (clause 10.1). Role: controller, or processor in the case described in clause 1.3.
• Processor: Spyral (clause 1.2). Data protection contact: privacy@spyral.lu. Security contact: security@spyral.lu.

B. Categories of data subjects

• Directors, managers, shareholders and partners, beneficial owners, authorised signatories, auditors and other officers of the companies and other entities that the Customer serves or administers.
• Employees, contractors and contact persons of the Customer's clients.
• Counterparties named in documents, such as suppliers, customers, lenders and landlords of the Customer's clients, and their contact persons.
• Signers and recipients of signature requests sent through the Services.
• The Customer's own personnel and other authorised users, to the extent their data is part of Customer Content, for example as authors, reviewers, assignees, chat participants or in Workspace activity records.
• Any other individual whose personal data the Customer uploads or connects.

C. Types of personal data

• Identification and contact data: names, postal and email addresses, telephone numbers, dates and places of birth, nationality.
• Official identifiers as they appear in documents or settings: national identification numbers, identity document details, tax and VAT identifiers, and registration numbers of sole traders and of filing agents.
• Professional and corporate data: functions and mandates, appointment and resignation dates, shareholdings and ownership percentages, ownership and control relationships, signing powers.
• Financial data: amounts, balances, invoices, payment details including bank account numbers, and remuneration, as contained in accounting, bookkeeping and annual accounts documents.
• Other document content: personal data contained in contracts, minutes, registers, correspondence and any other document the Customer uploads or connects.
• Derived data: extracted text, classifications and extracted attributes, directory records, ownership relationships, embeddings, bookkeeping entries, annual accounts files, AI output and review corrections.
• Workspace data about users: names, email addresses and roles; actions with their date and time; the IP address and browser details recorded with security-relevant actions; chat conversations, comments and tasks.
• Electronic signature data: signer names and email addresses, the status of each signature request, and its audit events.

D. Sensitive data

The Services are not designed for special categories of personal data or for data relating to criminal convictions and offences, and the Customer is instructed not to upload them unless the parties have agreed additional safeguards in writing (clause 5.2). If such data appears in a document, the measures in Annex II apply to it in full, including restricted access within the Workspace by role and document visibility, encryption in transit and at rest, and EU location.

E. Nature of the processing

Receiving content that users upload or connect; storage; text extraction, including optical character recognition of scanned documents; classification and extraction of attributes by AI models; creating embeddings and search indexes; retrieval and AI-generated answers with citations to sources; AI-assisted drafting and editing; linking documents to the companies and people they concern; preparing bookkeeping entries; preparing annual accounts and the filing files the Customer submits itself; sending electronic signature requests; notifications and email; collaboration within the Workspace; export; deletion; and backup, where backups are held (Annex II).

The Services do not take decisions about data subjects based solely on automated processing that produce legal effects concerning them or similarly significantly affect them. AI output is a proposal that the Customer's users review.

F. Purpose of the processing

Solely to provide the Services to the Customer under the Agreement. This includes support the Customer requests, maintaining the security and integrity of the Services, and complying with the law.

G. Duration and frequency

Continuous, for the term of the Agreement and until deletion under clause 12.

H. Sub-processors

As listed in Annex III, for the subject matter, nature and duration stated there.

Annex II: Technical and organisational measures

1. Location

• The application runs in the hosting provider's Frankfurt (Germany) region. The database, file storage, search index and realtime service also run in Frankfurt.
• AI models run with AI providers in the Allowed Countries, at the locations shown in the AI register at /legal/ai. The location controls in clause 11.4 apply to every AI request.
• Transactional email is sent through the email provider's EU sending region.

2. Encryption

• All connections between users, the Services and Sub-processors are encrypted with current TLS, and HTTP Strict Transport Security is enforced.
• Databases and file storage are encrypted at rest with AES-256 by the infrastructure providers.
• Two-factor authentication secrets and access tokens for connected services are additionally encrypted with AES-256-GCM under dedicated keys before they are stored.
• Passwords are hashed with bcrypt and a per-user salt, and are never stored or logged in plain text.

3. Separation of customers

• Every request is authenticated, checked against the acting user's permissions and limited to that user's Workspace before any data is read.
• The database enforces Workspace boundaries independently, through row-level security under a least-privilege database role. A query that does not identify its Workspace returns no rows; it fails closed.
• The few functions that must work across Workspaces (sign-up, incoming provider notifications, scheduled jobs and platform administration) use a separate privileged connection. Those functions are restricted to a fixed list, and an automated check on every proposed code change fails if the list is bypassed.
• Another automated check on every proposed code change fails if the change adds a database query without a Workspace boundary.
• Search and AI features only use content from the requesting user's Workspace, limited to the documents that user is allowed to see, and this filter is applied before any content is sent to an AI model. Content from different customers is never combined in a model request.

4. Access control within the Workspace

• Roles and attribute-based permissions, default-deny, enforced on every request.
• Document visibility can be set to the whole Workspace, a project team, a restricted group or named individuals.
• Exporting and closing the Workspace require the owner role and re-entering the password, plus the two-factor code where two-factor authentication is enabled.

5. Authentication and sessions

• Two-factor authentication with time-based one-time passwords is available to every user.
• Session cookies are HTTP-only, Secure and same-site restricted, with a lifetime of 24 hours.
• Users can sign out of all devices, and changing a password invalidates existing sessions.
• Sign-in attempts are rate-limited per email address. The rate-limit store holds keyed hashes of email addresses and IP addresses, not the addresses themselves.

6. Application security

• Origin checks protect every state-changing request against cross-site request forgery.
• A content security policy, clickjacking protection, MIME-type sniffing protection and a restrictive permissions policy apply to all responses.
• All input is validated against strict schemas at every boundary, and database queries are parameterised.
• Uploaded files are validated by their content, not only by their file extension.
• Rate limits apply to the API, to uploads and to AI features.
• Error messages shown to users carry a reference code instead of internal details.

7. Realtime updates

Live updates sent to browsers over realtime channels carry only record identifiers and version numbers, never content. The browser then fetches the content through an authenticated request that is checked against the user's permissions.

8. Logging and monitoring

• Security-relevant and administrative actions in the Workspace are recorded with the acting user, the date and time, the IP address and browser details. Authorisation decisions are logged.
• Errors are monitored continuously. Before an error report leaves the Services, automated filters remove known personal data fields and document names from it.
• The Services use no session recording, no third-party analytics and no advertising trackers.

9. AI processing

• Spyral does not use Customer Personal Data to train or fine-tune AI models.
• Spyral routes Customer Personal Data to an AI provider only under terms that prohibit the provider from using that data to train or improve its models. Spyral asks each AI provider for zero data retention. Annex III shows, for each AI provider, whether these terms are confirmed in writing and whether zero data retention is in effect.
• Only the content needed for the request is sent, under the separation rules in section 3.
• AI output is labelled in the application, carries citations to its sources where it draws on documents, and is presented as a proposal for review. Output with low confidence is flagged for review.

10. Retention and minimisation

An automated job enforces the following periods every day:

• IP addresses and browser details are removed from activity, authorisation and error records after 90 days;
• authorisation and error records are deleted after 13 months, and free text in error records is redacted of personal data;
• in-app notifications are deleted after 12 months;
• verification codes are deleted 24 hours after they expire, and expired session records are deleted;
• company records that the Customer deleted are erased after 12 months, except those kept as statutory records (clause 12.4); and
• when a user deletes their account, it is erased immediately and checked again every day for 30 days, so that anything written after the erasure is also removed.

Customer Content otherwise remains until the Customer deletes it or the Agreement ends (clause 12).

11. Availability and recovery

• The Services run on managed infrastructure providers in the European Union, which operate redundant infrastructure.
• Spyral does not promise that a backup exists for any given data. Where backups of the database or file storage are held, they are encrypted, stored in the European Union and expire on a fixed schedule. On request, Spyral tells the Customer whether backups are currently held and, if so, their frequency, retention period and location, and the date of the last restore test.
• Spyral maintains an incident response process covering detection, containment, notification under clause 10, and follow-up.

12. Personnel and organisation

• Every person who can access Customer Personal Data is bound by a written confidentiality obligation (clauses 6 and 14).
• Administrative access to the infrastructure providers is restricted to named personnel.
• The platform administration area of the Services is designed not to give access to Customer Content. The error records it shows can contain fragments of Customer Content that were part of a failed request; they are minimised and deleted as section 10 describes.

13. Deletion

Deletion and return follow clause 12, including the 30-day retrieval period, the permanent deletion of database records, stored files and search indexes, and the erasure confirmation.

14. Sub-processors

Sub-processors are selected, contracted and reviewed as described in clause 8 and at /legal/subprocessors.

15. Review

Spyral reviews these measures at least once a year, and after any significant incident or change to the Services.

Annex III: Sub-processors

The Customer authorises the following Sub-processors under clause 8.1. The current list is also published at /legal/subprocessors, and changes follow clause 8.

Annex IV: Regulated customer addendum

Customers that are supervised entities may need terms beyond this DPA. Examples are professionals of the financial sector subject to CSSF Circular 22/806 on outsourcing arrangements, and financial entities subject to Article 30 of Regulation (EU) 2022/2554 (DORA). On request, Spyral agrees a written addendum covering what the Customer's regime requires, which may include:

• a description of the services and of the service levels;
• the locations where data is processed and stored, and notice of any change;
• rights of access, inspection and audit for the Customer, its auditors and its competent authority;
• incident reporting timelines and content;
• business continuity and exit arrangements, including transition assistance;
• conditions for sub-outsourcing; and
• termination rights.

The Customer should request the addendum at privacy@spyral.lu before placing data covered by that regime in the Services. Until an addendum is signed, this Annex creates no obligations beyond the rest of this DPA.

Version history