Home›Data Processing Agreement

Data Processing Agreement

This is the agreement itself, not a summary of one. It applies between your organisation (the controller) and us (the processor) for personal data you put into Intellayer.

Version 2.4 · in force from 3 October 2026

How this becomes binding on you. You accept this DPA when you accept the Intellayer Terms of Service, by a separate checkbox at sign-up. Your acceptance is recorded with a timestamp, the accepting user, and the version number, and your admins can see it under Settings → Organisation & Privacy. If your organisation needs a signed counterpart on paper instead, email [email protected] and we will provide one at no charge.

Parties

This Data Processing Agreement (this “DPA”) is made between:

AS Creative Technologies LTD, trading as Intellayer, a private limited liability company registered in the Republic of Cyprus, of Alamanas 50, Dali, Nicosia 2547, Cyprus (“Intellayer”, “we”, the “Processor”);

and

the organisation that subscribes to Intellayer and accepts the Terms (the “Customer”, “you”, the “Controller”).

Each is a “Party”; together, the “Parties”.

Recitals

(A) The Customer subscribes to Intellayer under the Intellayer Terms of Service (the “Terms”). Words defined in the Terms have the same meaning here.

(B) In providing the Service, Intellayer processes personal data on the Customer’s behalf. For that data the Customer is the Controller and Intellayer is the Processor for the purposes of Regulation (EU) 2016/679 (the “GDPR”) and the Cyprus Law Providing for the Protection of Natural Persons with regard to the Processing of Personal Data 125(I)/2018 (the “Cyprus Data Protection Law”).

(C) Article 28(3) of the GDPR requires that relationship to be governed by a contract. This DPA is that contract.

(D) Separately, Intellayer is a Controller in its own right for certain data — the Customer’s own users’ account and billing data, security logging, and Intellayer’s direct relationship with any individual who holds their own Intellayer account. That processing is governed by the Intellayer Privacy Policy and the customer Privacy Policy, not by this DPA. Section 3 explains the boundary.

The Parties agree as follows.

1. Definitions

  • “Applicable Data Protection Law” means the GDPR, the Cyprus Data Protection Law, Directive 2002/58/EC as transposed in Cyprus by Law 112(I)/2004, and any other data protection law that applies to a Party’s processing under this DPA.
  • “Controller”, “Processor”, “Personal Data”, “Processing”, “Data Subject”, “Personal Data Breach”, “Special Categories of Personal Data” and “Supervisory Authority” have the meanings given in the GDPR.
  • “Customer Personal Data” means Personal Data that the Customer, its users, or its own customers provide to or generate within the Service, and which Intellayer processes on the Customer’s behalf. It is described in Annex I.
  • “Sub-Processor” means a third party engaged by Intellayer to process Customer Personal Data.
  • “SCCs” means the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
  • “Service” means Intellayer as described in the Terms.

2. Subject matter, duration, nature and purpose

Subject matterIntellayer’s processing of Customer Personal Data in providing the Service.
DurationFrom the Customer’s acceptance until the Customer’s subscription ends, plus the wind-down periods in section 11.
Nature of the processingCollection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure by transmission, alignment, restriction, erasure and destruction, by automated means.
PurposeOperating the Service for the Customer as the Customer directs.
Types of Personal DataSee Annex I, section B.2.
Categories of Data SubjectSee Annex I, section B.1.
Special CategoriesNot permitted by default. See section 4.3.

3. Roles of the Parties

3.1 Where we are your Processor. For Customer Personal Data, you are the Controller and we are the Processor. We process it only as set out in this DPA.

3.2 Where we are a Controller in our own right. We act as a Controller, not as your Processor, for:

  • account, authentication, billing and support data about your own users — the people at your organisation who log in;
  • security and abuse-prevention logging across the platform;
  • aggregated statistics that do not identify any Data Subject (section 8);
  • our direct relationship with any individual who holds a Intellayer account in their own name, under our own contract with them.

We do not need your instruction for that processing, and you are not responsible for it.

3.3 We are not joint controllers. Intellayer and the Customer are independent controllers of the personal data each holds in its own right, and processor and controller respectively for Customer Personal Data. The Parties do not jointly determine the purposes and means of any processing and do not intend to create a joint controllership under Article 26 of the GDPR.

This is a deliberate statement of the actual position, not a disclaimer of one. You decide what to record about your own customers and why; we decide what our own contract with an individual account holder requires us to show them. Neither decision is taken jointly.

3.4 If a regulator or court disagrees. If a Supervisory Authority or a court of competent jurisdiction determines that the Parties are joint controllers for any processing, then for that processing only, the allocation of responsibilities in Annex IV takes effect as the arrangement required by Article 26(2), and the Parties will make its essence available to affected Data Subjects. This section does not create a joint controllership; it provides for one if it is found to exist.

3.5 Your obligations as Controller. You warrant that, for all Customer Personal Data:

(a) you have a valid lawful basis under Article 6 (and Article 9 where relevant) for every processing operation you instruct; (b) you have given the Data Subjects the information required by Articles 13 and 14, including that you use a processor and where to find our sub-processor list; (c) you have obtained any consent that is required, including for any AI-assisted feature you switch on; (d) your instructions comply with Applicable Data Protection Law; (e) you are responsible for the accuracy, quality and lawfulness of the Customer Personal Data and for how you obtained it.

You will indemnify us against third-party claims, fines and reasonable legal costs arising from your breach of (a) to (e). This indemnity is subject to the liability provisions in the Terms except where Applicable Data Protection Law prevents that.

4. Our instructions from you

4.1 Documented instructions. We process Customer Personal Data only on your documented instructions, including as regards transfers to a third country, unless EU or Member State law requires otherwise — in which case we will tell you before processing, unless that law forbids us to.

Your documented instructions are:

  • the Terms and this DPA, including its Annexes;
  • the configuration choices you make in the Service — retention settings, roles and permissions, integrations, which optional AI features you enable, and which mailboxes you connect;
  • written instructions sent to [email protected].

4.2 Unlawful instructions. If we believe an instruction infringes Applicable Data Protection Law, we will tell you without undue delay and may suspend that instruction until you confirm or change it. We are not obliged to give you legal advice and our not objecting to an instruction is not a statement that it is lawful.

4.3 Special categories. You must not put Special Categories of Personal Data (Article 9) or criminal-offence data (Article 10) into the Service unless you have told us in writing beforehand and we have agreed in writing to the additional safeguards that processing needs.

This restriction matters in practice wherever an organisation records health, dietary or safeguarding information: injury records, medical clearances, dietary requirements and safeguarding concerns are Article 9 data. If your organisation needs to hold them in the Service, contact us before you start so we can agree the safeguards and record the arrangement.

4.4 Confidentiality. Everyone we authorise to process Customer Personal Data is bound by a written confidentiality obligation that survives the end of their engagement.

5. Security

We implement and maintain the technical and organisational measures in Annex II, which are designed to meet Article 32 taking into account the state of the art, cost of implementation, and the nature, scope, context and purposes of the processing as well as the risk to Data Subjects.

We may change those measures, but not so as to materially reduce their protective effect during the term.

You are responsible for your side of the security boundary — who you invite into your organisation, what role you give them, whether you remove leavers promptly, whether your staff enable two-factor authentication, and what your staff choose to upload.

6. Sub-processors

6.1 General authorisation. You give us general authorisation to engage Sub-Processors under this section.

6.2 Current list. The Sub-Processors we use are listed in Annex III, published and kept current at https://intellayer.app/legal/dpa/subprocessors/. We are contractually bound to keep that page available at that path.

6.3 Notice of change. We will give you at least 30 days’ notice before a new or replacement Sub-Processor starts processing Customer Personal Data. Notice is given by updating Annex III and by email to your organisation’s admin contacts. Changes to this page are also recorded on the change history page.

6.4 Your right to object. You may object on reasonable data-protection grounds within 30 days of notice. We will discuss it with you in good faith and try to offer an alternative. If we cannot, you may terminate the affected part of the Service, or the whole subscription if the Sub-Processor is essential to it, on written notice, and we will refund the unused portion of anything you have prepaid.

6.5 Terms and responsibility. We impose data protection obligations on each Sub-Processor that are no less protective than those in this DPA, and we remain fully liable to you for each Sub-Processor’s performance of those obligations.

6.6 Emergency changes. If we must replace a Sub-Processor immediately to keep the Service secure or running — because it has suffered a breach, failed, or terminated its contract with us — we may do so before the 30 days expire. We will tell you as soon as we can, explain why, and your right to object under 6.4 still applies.

7. Data Subject rights and assistance

7.1 Requests that come to us. If a Data Subject contacts us directly about Customer Personal Data, we will not respond substantively. We will tell them to contact you and, unless the law forbids it, forward the request to your admin contacts without undue delay.

7.2 Helping you respond. Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures, so far as possible, in meeting your obligations under Articles 12 to 22. In practice:

  • the Service includes self-service export of an organisation’s data in machine-readable form, and a separate export for time-series readings;
  • the Service includes deletion tools. A deleted record can be restored for 30 days (a deleted lead for 90 days) and is then deleted permanently; your administrators can delete it permanently at once, for example to answer an erasure request. Deleting the whole organisation has a 30-day grace period;
  • the Service includes a consent history view;
  • where a request cannot be met with those tools, we will give reasonable additional help. We may charge for that at our standard rates where the request is unusual or repetitive, having told you the cost first.

7.3 Helping you with Articles 32 to 36. Taking into account the nature of the processing and the information available to us, we will help you comply with your obligations on security (Art. 32), breach notification to the Supervisory Authority (Art. 33) and to Data Subjects (Art. 34), data protection impact assessments (Art. 35) and prior consultation (Art. 36).

8. Aggregated statistics

We may create and use statistical data derived from Customer Personal Data — for example how long a stage of a pipeline typically takes, or how a class of equipment performs across a region — for the purposes of operating, securing, supporting and improving the Service, and for producing industry-level insight.

We may only do so where the result is aggregated and anonymous: it must not identify you, any Data Subject or any individual customer of yours, directly or by combination with other information we hold or could reasonably obtain, and we must not attempt to re-identify it. Anonymous data of that kind is not Personal Data and is not Customer Personal Data. We do not sell Customer Personal Data, and we do not use it to train generalised machine learning models.

9. Personal Data Breach

9.1 Notification to you. We will notify you of a Personal Data Breach affecting Customer Personal Data without undue delay after becoming aware of it, and early enough for you to meet your own Article 33 deadline as Controller.

We do not commit to a fixed number of hours. Article 33(2) sets no clock for a processor, and a deadline we could miss while still acting properly is worth less to you than an obligation measured against what you actually need — which is notice in time to report to your supervisory authority within your own 72 hours.

For this purpose we become “aware” when we have a reasonable degree of certainty that a security incident has occurred which has led to Personal Data being compromised — not at the moment of first suspicion. A short period of investigation to establish that is not a delay.

9.2 What we will tell you. So far as we know it at the time, and in stages if necessary:

(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 our point of contact; (c) the likely consequences; (d) the measures we have taken or propose to take, including to mitigate its effects.

9.3 What we will not do. We will not notify your Supervisory Authority or your Data Subjects on your behalf unless you ask us to in writing — that decision is yours as Controller. We will not make a public statement identifying you without telling you first, unless the law requires it.

9.4 No admission. Notifying you of a breach is not an admission of fault or liability by us.

10. Audit

10.1 Information first. We will make available to you all information necessary to demonstrate compliance with Article 28 and with this DPA. On written request, and no more than once in any 12 months (unless a Supervisory Authority requires otherwise or there has been a Personal Data Breach affecting your data), we will provide a completed security questionnaire, a current description of the Annex II measures, and answers to reasonable follow-up questions.

An honest statement about certifications. We do not hold ISO 27001, SOC 2 or any equivalent third-party certification, and we do not currently commission an annual external penetration test. If a supplier questionnaire asks, that is the answer. We would rather tell you that than let you assume otherwise, and we will update this page if it changes.

10.2 Audits and inspections. Where the information under 10.1 does not answer your concern, you may audit us, or appoint an independent auditor to do so, on at least 30 days’ written notice, during normal business hours, no more than once in any 12 months, and at your cost. The auditor must be bound by confidentiality and must not be one of our competitors.

An audit under this section is limited to review of documentation and interviews with relevant personnel about the processing of your data. It does not extend to:

  • physical access to data centres, which are operated by our hosting Sub-Processors and are not under our physical control;
  • any system, record or environment to the extent it contains another customer’s data;
  • our source code, cryptographic key material, or commercially sensitive information not relevant to the audit.

We will contribute to the audit and cooperate in good faith. If an audit finds a material non-compliance on our side, we will bear the reasonable cost of that audit and remediate without undue delay.

11. Deletion or return at the end

11.1 Your choice. At the end of the provision of services relating to processing, we will, at your election, delete or return all Customer Personal Data to you, and delete existing copies, unless EU or Member State law requires us to keep it.

11.2 If you do not choose. Tell us which you want before your subscription ends, or within 30 days after. If you do not tell us, we will delete.

11.3 The wind-down timetable.

  • Export tools remain available for 30 days after termination.
  • After that, Customer Personal Data is deleted from live systems.
  • Backups containing it are overwritten on the standard rotation, normally within 35 days of deletion from live systems. Between deletion and overwrite, backup data is access-controlled and is not used for any purpose other than restoring the platform. If we do restore from a backup, we re-apply any erasure that had already been made.
  • Data we must keep by law is kept only for that legal purpose, only for as long as the law requires, and is access-restricted. The clearest example is invoice records, which section 62 of the VAT Law 95(I)/2000 requires to be kept for seven years. Where the legal purpose can be met with less, we anonymise the rest.

11.4 Certification. We will confirm deletion in writing on request.

12. International transfers

12.1 Where data is held. The platform’s servers and its database are located in Germany, within the EEA. Annex III states, for each Sub-Processor, where it processes data and what safeguard applies.

12.2 Transfers outside the EEA. Where providing the Service involves transferring Customer Personal Data to a country outside the EEA that is not covered by a European Commission adequacy decision, we will:

(a) rely on a Chapter V transfer mechanism — in practice the SCCs, Module Two for our own transfers and Module Three for onward transfers by a Sub-Processor; (b) carry out and document a transfer impact assessment where the EDPB’s Recommendations 01/2020 call for one, and apply supplementary measures where they are needed; (c) give you the executed transfer documents, or a summary of them where they are confidential, on request.

12.3 The SCCs, incorporated. Where the SCCs apply, the Parties incorporate them into this DPA and agree the following selections. Each Party is deemed to have signed the relevant Annexes.

ItemSelection
ModuleModule Two (controller to processor). Module Three (processor to processor) applies between Intellayer and a Sub-Processor.
Clause 7 — dockingIncluded.
Clause 9 — sub-processorsOption 2 (general written authorisation), with 30 days’ notice, per section 6.
Clause 11(a) — independent dispute resolution bodyNot included.
Clause 13 / Annex I.C — competent supervisory authorityOffice of the Commissioner for Personal Data Protection (Cyprus).
Clause 17 — governing lawLaw of the Republic of Cyprus.
Clause 18(b) — forumCourts of the Republic of Cyprus.
Annex I.A — partiesAs set out in “Parties” above.
Annex I.B — description of transferAnnex I to this DPA.
Annex II — technical and organisational measuresAnnex II to this DPA.
Annex III — sub-processorsAnnex III to this DPA.

12.4 Conflict. If the SCCs conflict with the rest of this DPA, the SCCs prevail for the transfer they govern.

12.5 Government access requests. If we receive a legally binding request from a public authority for Customer Personal Data, we will — unless legally prohibited — notify you, challenge the request where there are reasonable grounds to consider it unlawful, and disclose only the minimum permissible. We will keep a record of such requests and make it available to you so far as the law allows.

13. Liability

13.1 The Terms govern. The limitations and exclusions of liability in the Terms apply to claims under this DPA as though set out here.

13.2 What cannot be capped. Nothing in this DPA or the Terms limits either Party’s liability to a Data Subject under Article 82 of the GDPR, or to a Supervisory Authority. A cap between us does not bind them.

13.3 Apportionment between us. Where one Party has paid full compensation for damage caused by processing, it may claim back from the other the part of the compensation corresponding to that other Party’s responsibility, in accordance with Article 82(5).

13.4 Cooperation. Each Party will give the other reasonable assistance and information in defending a claim or responding to a Supervisory Authority, at the requesting Party’s cost.

14. Term, changes and precedence

14.1 Term. This DPA takes effect when you accept it and continues for as long as we process Customer Personal Data for you, plus the survival period in section 11.

14.2 Changes. We may amend this DPA on 30 days’ notice, published here with the change recorded on the change history page and sent to your admin contacts. If a change materially reduces your rights or our obligations, you may terminate the subscription before it takes effect and we will refund the unused portion of anything you have prepaid. We may make a change without notice where it is needed to comply with a change in the law, and will tell you as soon as we can.

14.3 Precedence. If this DPA, the Terms and the Privacy Policies conflict on a data protection question, the order is: (1) the SCCs, where they apply; (2) this DPA; (3) the Terms; (4) the Privacy Policies.

14.4 Survival. Sections 8, 11, 12, 13 and this section survive termination.

15. Governing law, forum and notices

This DPA is governed by the law of the Republic of Cyprus and the courts of Nicosia have jurisdiction, except that disputes under the SCCs follow the selections in section 12.3 — which are the same.

Notices to us under this DPA: [email protected], subject line “DPA”, copied to [email protected], and by post to Intellayer, Alamanas 50, Dali, Nicosia 2547, Cyprus. Notices to you: the email addresses of your organisation’s admin users.


Annex I — Description of the processing

A. The Parties

Controller (data exporter): the Customer — the organisation that has subscribed to Intellayer. Its identity, address and contact details are those recorded in its organisation profile in the Service. Activities: using the Service to run its business. Role: Controller.

Processor (data importer): AS Creative Technologies LTD, trading as Intellayer, Alamanas 50, Dali, Nicosia 2547, Cyprus. Contact: [email protected]. Activities: providing the Service. Role: Processor.

B. Description of the transfer

B.1 Categories of Data Subject

  • the Customer’s clients, customers, members and supporters;
  • the Customer’s prospective customers and leads;
  • where the Customer’s activities involve young people: children registered with the Customer, their parents and guardians, and the Customer’s volunteers;
  • individuals named on the Customer’s invoices and in its correspondence;
  • the Customer’s own employees, contractors and volunteers, in their capacity as subjects of records inside the Customer’s organisation (for their user accounts we are Controller — see section 3.2);
  • senders and recipients of email in a mailbox the Customer connects to the shared inbox, or forwards to its logging addresses;
  • people who call, or are called by, the Customer through a phone system the Customer connects.

B.2 Categories of Personal Data

CategoryExamples
Identity and contactName, email address, telephone number, preferred language
Address and locationPostal address, district, postcode, and where recorded, coordinates
Account and relationshipStatus, tags, pipeline stage, custom fields, notes, assigned owner
Staff availabilityThe days and times a member of the Customer’s staff is away, entered by them or a manager or copied from out-of-office events in their connected calendar, with an optional private note; no reason or category is recorded
Commercial recordsQuotes, proposals, orders, invoices, line items, payment status
CommunicationsEmail, SMS and push delivery logs; support tickets and replies; messages filed from a connected mailbox, including sender, recipients, subject, body and timestamps; email sent from a connected mailbox; calendar events synced with a connected calendar; call records reported by a connected phone system — number, direction, time, duration and the staff member
Documents and mediaFiles and photographs uploaded by the Customer’s users, and whatever they contain
Audit recordsInside the Customer’s organisation: who changed what and when, with the values before and after (personal fields redacted in the record itself); every request that changes data, and every export, download and generated document, with its outcome; sign-in history, including failed attempts and why they failed; tool calls made by AI features and connected AI apps; with the IP address and user agent of each
Technical metadataIP addresses, user agents, device push tokens, platform and OS metadata
Membership and participationMembership type and number, group or team, age band, attendance, participation records
Date of birthHeld where age-banded eligibility or safeguarding rules require it — including for children
PaymentsSubscription and fee records, bookings and payments received

B.3 Special Categories

None by default. Section 4.3 governs. If the Customer has notified us and we have agreed in writing, the categories agreed are recorded in that agreement and form part of this Annex for that Customer.

This is the most likely place for the Service to be misused: injury and medical records, dietary and religious requirements, and safeguarding referrals are all Article 9 or Article 10 data. Do not enter them without agreeing the arrangement with us first.

B.4 Frequency

Continuous for the duration of the subscription. Data enters the Service whenever the Customer’s users use it, when a connected mailbox or calendar is synced — approximately every five minutes — and when a connected phone system reports a call.

B.5 A note on data that reveals more than it appears to

Two categories in the Service warrant more care than their labels suggest. Children’s data — dates of birth, attendance, photographs, guardian contacts — carries the heightened protection the GDPR gives to children in Recital 38 and Article 8. Attendance and location records for adults can reveal patterns of movement and association. The measures in Annex II reflect that, and Customers should limit internal access accordingly.

B.6 Nature and purpose

To provide the Service to the Customer as the Customer directs: storing, retrieving, transmitting, organising and presenting the Customer’s records; computing aggregates and derived values; generating the communications the Customer configures; and the platform operations that support all of that.

B.7 Duration

For the term of the subscription plus the periods in section 11.

C. Competent supervisory authority

Office of the Commissioner for Personal Data Protection, 1 Iasonos, 1082 Nicosia, Cyprus — https://www.dataprotection.gov.cy.


Annex II — Technical and organisational measures

These are the measures in place as at the date at the top of this page. We may change them provided the protective effect is not materially reduced. Where a measure is a target rather than a guarantee, it says so.

II.1 Encryption and pseudonymisation

  • Traffic between client devices and the platform is encrypted with TLS 1.2 or above.
  • The production database is encrypted at rest by the managed database provider (AES-256).
  • Backup archives are encrypted at rest with AES-256; the passphrase is held in a secret manager and is never stored alongside the archives.
  • Passwords are stored only as salted hashes produced by an adaptive, deliberately slow hashing function (currently bcrypt), with the work factor reviewed periodically and raised as hardware improves.
  • Third-party API credentials the Customer supplies — for any integration the Customer connects — are encrypted at rest in the application layer with AES-256-GCM and decrypted only at the moment of use.
  • Before any request to an AI Sub-Processor leaves the platform, personal names are replaced with placeholder tokens, which are restored in the response inside the platform, and direct contact identifiers — email address, telephone number, street address — are omitted from the payload. This is a data-minimisation safeguard under Articles 25 and 32. It is not anonymisation: we hold the mapping, so what is transmitted remains Personal Data, the Sub-Processor relationship still applies, and residual identifiers can still appear in free text and in files processed verbatim.

II.2 Confidentiality, integrity, availability and resilience

  • Every organisation’s data is logically isolated, and isolation is enforced at every API boundary: a request whose authenticated organisation does not match the requested resource is rejected rather than filtered.
  • Role-based access control is enforced at the API, not only in the interface.
  • Network controls restrict database access to the application tier.
  • Denial-of-service protection at the network edge provider.
  • The production database runs with a standby and automatic failover.
  • Two independent backup layers, both inside the EEA: point-in-time recovery retained 14 days by the managed database provider, and encrypted application-level archives retained 30 days.
  • A documented incident response procedure covering investigation, the Article 33 clock, and re-application of erasures after any restore.

II.3 Restoring availability after an incident

The following are objectives, not contractual guarantees:

  • Recovery Time Objective: 4 hours for the production database after an incident affecting the primary; 1 hour for application-tier failures.
  • Recovery Point Objective: 5 minutes for the production database; up to 24 hours where a full restore from archive is required.

We will use reasonable efforts to meet them and will tell you if a real incident does not.

II.4 Testing and assessment

  • Security review at each material release.
  • Automated dependency vulnerability scanning in the build pipeline.
  • Periodic review of the measures in this Annex.
  • A published route for third parties to report vulnerabilities, acknowledged as soon as we reasonably can.

We do not currently commission an annual external penetration test, and we do not hold ISO 27001, SOC 2 or an equivalent certification. Section 10.1 says the same thing and means it.

II.5 People

  • Everyone with access to Customer Personal Data is under a written confidentiality obligation.
  • Access is granted on a need-to-know basis and is logged.
  • When our support staff act as one of the Customer’s users, the session is marked as such throughout, everything done in it is recorded with both identities, and the Customer’s administrators see it in their audit log.
  • Data protection responsibilities are covered at onboarding and reviewed periodically.

II.6 Managing Sub-Processors

  • Each Sub-Processor is engaged under a written contract with data protection terms no less protective than this DPA.
  • The list in Annex III is published, and changes are notified with 30 days’ notice.
  • Transfer mechanisms are recorded per Sub-Processor and reviewed when a Sub-Processor’s arrangements change.

II.7 Minimisation by design

  • Data collection is limited to what the Service needs.
  • Retention defaults are set per category and are documented in the Privacy Policies.
  • The web application loads no advertising, marketing or third-party analytics scripts. The mobile applications include Firebase Cloud Messaging for push notification and Firebase Crashlytics for crash reporting, and nothing else of that kind.
  • Push notification payloads carry record identifiers, not names.

II.8 Logging and audit

  • Every request that changes data, and every export, download, generated document and view of audit or sign-in records, is recorded with time, user, organisation, any support user acting for them, the action, its target, its outcome (including requests that were refused or failed), IP address and user agent. Request bodies and query strings are not recorded.
  • Other authenticated requests are recorded with the same fields in the operational logs, which are overwritten as they fill rather than kept for a set period.
  • Changes are recorded with the values before and after. Personal fields (names, contact details, addresses, notes and similar) are redacted in the record itself: it shows that they changed, not what they contain.
  • Sign-ins are recorded, including failed attempts and why they failed, two-factor events and password resets. A failed attempt on an address with no account is recorded with a keyed hash of the address, never the address.
  • Every tool call made by an AI feature of the Service or by an AI app the Customer connects is recorded: for whom, which tool, when and with what outcome.
  • The audit trail is append-only, in the application and in the database itself, which refuses any change to an audit record and any deletion except the retention purge and an erasure the law requires. Audit records are retained for 24 months.
  • The Customer’s administrators can search and export their organisation’s audit trail, request log, sign-in history and AI tool calls in the Service.
  • Incidents and the actions taken on them are documented.

II.9 Disposal

  • Live records are deleted on the schedule in section 11.
  • Backups are overwritten on rotation.
  • Decommissioning and media destruction at the hosting layer are performed by the hosting Sub-Processor to its published standard.

Annex III — Sub-processors

The current list, with purposes, locations and safeguards, is published and maintained at https://intellayer.app/legal/dpa/subprocessors/ and forms part of this DPA. We are contractually bound to keep it available at that path. Changes are notified 30 days in advance under section 6.3 and recorded on the change history page.


Annex IV — Allocation if joint controllership is found

This Annex has no effect unless section 3.4 is triggered. It exists so that, if a regulator or court finds a joint controllership, an Article 26 arrangement is already in place rather than being negotiated after the fact.

IV.1 Allocation of responsibility

ObligationWho leads
Article 13/14 information to the individual about the Customer’s own processingCustomer
Article 13/14 information about Intellayer’s own processing under its own contract with an individualIntellayer
Article 15 accessEach Party for the data it holds; both cooperate to give a complete answer
Article 16 rectificationEach Party for the data under its control
Article 17 erasureEach Party in its own sphere; each notifies the other without undue delay after acting
Article 20 portabilityIntellayer provides the export tooling; the Party receiving the request verifies identity
Article 33 notification to the authorityEach Party for a breach in its sphere; each tells the other without undue delay
Article 34 notification to individualsThe Party with the direct relationship to the individual leads
Security measuresEach Party for the systems it controls

IV.2 Single point of contact

Whatever the table says, an individual may exercise their rights against either Party — Article 26(3) requires it. The Party that receives a request will act on it so far as it can and tell the other Party promptly.

IV.3 The essence of the arrangement

To be made available to individuals under Article 26(2):

Your data is held both by the organisation you deal with and by Intellayer, which supplies that organisation’s software. The organisation decides what to record about you and why. Intellayer decides how its platform works and, where you hold your own account with Intellayer, what it shows you under its own agreement with you. You can ask either of them to give you a copy of your data, correct it, or delete it, and whichever you ask will deal with it and tell the other. If you are not satisfied you can complain to the Office of the Commissioner for Personal Data Protection.


Acceptance

By accepting the Terms — including by ticking the DPA box in the Intellayer sign-up flow — the Customer accepts this DPA for itself and for any affiliate that uses the Service through the Customer’s organisation. Intellayer accepts it by making the Service available.