Data processing agreement

This Data Processing Agreement ("DPA") is drawn up pursuant to article 28 of the General Data Protection Regulation (GDPR) between:

Haakje B.V., Chamber of Commerce number 42160038, VAT number NL869977817B01, established in Haarlem, trading under the name Aqlemy, hereinafter the "Processor";

and

the organisation registered on the Platform, hereinafter the "Controller";

together the "Parties".

Why this DPA exists.

The Controller determines the purposes and means of processing the personal data of its members, students, parents and teachers. The Processor processes that data solely on its instructions. Article 28(3) GDPR requires that relationship to be set out in writing; this DPA is that record.

When it applies.

This DPA applies as soon as the Controller registers on or uses the Platform, and continues for as long as that processing continues. No separate signature is required; acceptance is recorded with a version number, a timestamp and a checksum of the text, by the same route as the Terms of Service.

Order of precedence.

This DPA prevails over the Terms of Service and over any other arrangement between the Parties, for everything concerning the processing of personal data. That order is non-negotiable: a data processing agreement that can be set aside by general terms does not satisfy article 28 GDPR. For all other matters — price, term, availability, support — the Terms of Service apply.

The annexes.

Three annexes form an integral part of this DPA:

• - Annex A — Processing register: per processing activity the purpose, the categories of data and data subjects, and the retention period (article 23).
• - Annex B — Security annex: the technical and organisational measures, ordered by availability, integrity and confidentiality (article 24).
• - Annex C — Sub-processors and transfers: the reference to the current register and what it states per party (article 25).

Alignment with the sector standard.

This DPA broadly follows the structure of the Model Data Processing Agreement for Digital Educational Resources and Privacy, the standard widely used in Dutch education: a main text with a privacy annex and a security annex as appendices, an audit arrangement with a third-party statement, and a liability clause that does not allow the contractual limitation to be invoked against a recourse action under article 82 GDPR. We are not a signatory to the Dutch Privacy Covenant for Digital Educational Resources and claim so nowhere; we have adopted its structure because that structure does what it is meant to do.

Languages.

This DPA is available in Dutch, Turkish, English and Arabic. In the event of conflict, the Dutch text prevails.

Personal data: any information relating to an identified or identifiable natural person (GDPR art. 4(1)).

Processing: any operation performed on personal data, including collecting, recording, organising, storing, updating, altering, retrieving, consulting, using, disclosing, erasing or destroying (GDPR art. 4(2)).

Controller: the organisation that uses the Platform and determines the purposes and means of processing the personal data of its members, students, parents and teachers.

Processor: Haakje B.V., trading as Aqlemy, which processes personal data on behalf of the Controller.

Sub-processor: a third party engaged by the Processor to process personal data on behalf of the Controller.

Data subject: the natural person to whom the personal data relates.

Personal data breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed (GDPR art. 4(12)).

Security incident: an event affecting security without it being established that personal data is involved. Not every security incident is a personal data breach.

Supervisory authority: the Dutch Data Protection Authority (Autoriteit Persoonsgegevens), or the competent authority in another member state.

Platform: the management platform operated by the Processor, including the administration portal, the mobile applications, the public organisation pages and the information screens.

Main Agreement: the service agreement between the Parties, consisting of the order or registration and the Terms of Service.

Annex: an annex to this DPA, as listed in article 1.

In writing: on paper or by electronic means, including email and a notice in the administration portal, provided the content can be stored and reproduced.

Business Day: Monday through Friday, excluding public holidays generally recognised in the Netherlands.

Subject matter.

The Processor processes personal data in the context of the Controller's use of the Platform, solely to the extent necessary to perform the Main Agreement.

Nature of the processing.

• - Digitally collecting, recording, organising and storing data entered by the Controller or its users.
• - Displaying and managing that data via the administration portal, the mobile applications and the public pages.
• - Sending email, push notifications and in-app notifications on behalf of the Controller.
• - Processing payment information for payments the Controller collects from its own members, via its own payment service provider.
• - Making and restoring backups.
• - Generating reports and exports at the Controller's request.
• - Security logging and warning users of an anomalous sign-in.
• - Optionally, and only where the Controller enables that function: publication to social media, synchronisation with an email marketing service, and AI-supported summarisation and analysis.
• - Answering usage questions from the manual (help assistant), drafting replies to support requests and automatically translating texts, with the language model on the Processor's own hardware (see Annex A, A14).

Purpose of the processing.

Delivering the services described in the Main Agreement: member and educational administration, communication, financial records, publication, and the security and continuity these require. The precise purposes per processing activity are set out in Annex A.

What the Processor expressly does NOT do with the data.

• - No use for the Processor's own purposes.
• - No disclosure to third parties, other than to the sub-processors in Annex C or pursuant to a legal obligation.
• - No use to train, fine-tune or evaluate language models or other models.
• - No profiling of data subjects, and no use for advertising purposes.
• - No combining of data from different controllers.
• - No sale of personal data, in any form.

Duration.

This DPA applies for as long as the Processor processes personal data on behalf of the Controller, and in any event for the duration of the Main Agreement. See articles 20 and 18.

The following categories of personal data may be processed. What is actually processed in a given case depends on the chosen package, on the modules the Controller uses and on what it enters itself. Annex A sets this out per processing activity, with purpose and retention period.

Identification data: first and last name, date of birth, place of birth, gender. Contact details: email address, telephone number, address, postcode, town. Account data: role, language preference, notification preferences, two-step verification, hashed password. Educational data: student number, class, group, department, academic year, homework, grades, exam results, attendance and absences with reason, progress items, file notes, observations, certificates. Family data: name and contact details of parents and guardians, family address, the parent-student link, emergency contact details. Membership data: membership number, type and status, start and end date, contribution amount, payment history, outstanding items, board or committee position. Financial data: amounts, dates, payment method and status; cash book entries, invoices, expense claims, donations, subsidies. Full account numbers and card details remain with the Controller's payment service provider and are not stored on the Platform. Communication data: chat messages and their participants, announcements, events, newsletters and recipient lists, complaints and reports, support requests. Technical and security data: IP address (encrypted), device and browser information, sign-ins and failed attempts, device token for notifications, activity log. Custom fields: fields the Controller configures itself, with the content it records in them.

Special categories of personal data.

The Platform is not designed for processing special categories of personal data as referred to in GDPR article 9, and provides no specific fields or additional safeguards for them. If the Controller nonetheless records such data — for example in a free text field or a custom field — it does so on its own responsibility and must itself have a valid exemption ground. The Processor secures that data with the same measures as other data, but not with additional ones.

Two forms deserve attention here. Membership of an organisation with a religious aim may in context be data concerning religion; the Controller generally relies on GDPR article 9(2)(d) for that. And an absence reason referring to health is health data; the Platform provides a single status field for that and no medical record.

Data of minors.

A substantial part of the data processed concerns minors. The Parties are aware that this entails an increased risk within the meaning of GDPR article 35(3) and that the Controller may therefore be more readily obliged to carry out a data protection impact assessment. Article 14 governs assistance with that.

The personal data processed concerns the following categories of data subjects:

• - Students and course participants, including minors.
• - Parents, carers and guardians. Several parent accounts may be linked to one student; they have equal rights.
• - Members of the organisation.
• - Teachers, instructors and supervisors.
• - Administrators and board members of the organisation.
• - Emergency contacts provided by a data subject.
• - Donors and periodic givers.
• - Contact persons of advertisers, where the Controller sells advertising space via the Platform.
• - Recipients of newsletters and announcements entered by the Controller.
• - Visitors to the Controller's public pages, insofar as personal data is processed there.

Not covered by this DPA.

The contact person and administrators of the Controller do not fall under this DPA insofar as the customer relationship with the Processor is concerned (invoicing, correspondence, support): for that the Processor is itself the controller. The same applies to the Processor's security and system logging and to visitors to the Processor's own website. Those processing activities are described in the Processor's Privacy Policy.

Solely on instructions.

The Processor processes personal data solely on the Controller's documented instructions, unless required to process by Union or member state law. In that case the Processor informs the Controller before processing, unless that law prohibits such information on important grounds of public interest.

What counts as an instruction.

The Controller's instructions consist of:

• - this DPA, including Annex A;
• - the Main Agreement;
• - the configuration the Controller records in the administration portal: which modules are enabled, which connections are switched on, which rights are assigned to which roles, which custom fields exist and which audience messages are targeted at. That configuration is an instruction within the meaning of this article; the Processor executes it without assessing its substance.
• - additional written instructions the Controller gives via the contact details in article 26.

Duty to report an unlawful instruction.

If the Processor considers that an instruction infringes the GDPR or another Union or member state data protection provision, it informs the Controller without delay (GDPR art. 28(3), final sentence). The Processor may suspend execution of that instruction until it is confirmed or amended. This duty does not entail a general duty of review: the Processor does not assess of its own accord whether every processing activity the Controller configures is lawful, nor is it in a position to do so.

Additional instructions outside the standard service.

An instruction that cannot reasonably be executed within the standard functionality of the Platform will be executed insofar as technically and organisationally possible. Where that requires considerable effort, the Parties consult in advance about execution and about any fee. The Processor does not refuse an instruction on grounds of cost without that consultation.

No own purposes.

The Processor does not process the personal data for its own purposes. Aggregated usage statistics about the operation of the Platform that cannot be traced to a person or organisation fall outside this; those are not personal data.

Security measures are not an own purpose.

The Processor determines and takes the security measures necessary to comply with article 32 GDPR, including sign-in logging and warning users of an anomalous sign-in. For that specific processing the Processor determines the purposes and means and acts as controller; it serves only the security of the Platform and is never used for any other purpose.

The Processor undertakes the following obligations (GDPR art. 28(3)):

a) Adherence to instructions.

As set out in article 6.

b) Confidentiality.

As set out in article 8.

c) Security.

The Processor takes appropriate technical and organisational measures as referred to in GDPR article 32. Those measures are described in article 11 and, fully and verifiably, in Annex B.

d) Sub-processors.

The Processor engages no sub-processor without the general written authorisation in article 10, and imposes on each sub-processor the same obligations as are imposed on itself in this DPA.

e) Assistance with data subject rights.

As set out in article 13.

f) Assistance with the obligations under articles 32 to 36 GDPR.

As set out in articles 11, 12 and 14.

g) Audit and evidence of compliance.

As set out in article 16.

h) Deletion or return after the end.

As set out in article 18.

In addition, not derived from article 28 GDPR but undertaken by the Processor:

i) Separation between organisations.

The data of each Controller is logically separated from that of every other. That separation is enforced on every query and not merely in the display.

j) Logging the Controller can inspect itself.

Actions in the administration portal are recorded in an activity log the Controller can inspect, search and export itself, without the Processor's intervention. Security-relevant entries — signing in, deleting, changing rights, exporting, revealing masked data and any change to a consent — are retained indefinitely. This facility exists so that the Controller can carry out its own supervisory task.

k) No inspection without cause.

The Processor does not take note of the content of messages, files or financial records other than to resolve an outage, execute an instruction or comply with a legal obligation, and limits itself to what is necessary.

l) Notification of changes affecting the processing.

Where the Processor implements a change to the Platform that expands the categories of personal data processed or introduces a new purpose, it informs the Controller in advance and in plain language, and updates Annex A. A new function that processes personal data is off by default until the Controller enables it.

m) Cooperation with an authority's request.

Where the Processor receives a request from an investigative or supervisory authority relating to the Controller's data, it assesses the legal basis and competence, provides no more than is demanded, and informs the Controller in advance — unless the law prohibits this.

Confidentiality.

The Processor keeps confidential the personal data it processes on behalf of the Controller and uses it solely to perform this DPA. This obligation survives the end of the DPA and is not limited in time.

Persons with access.

The Processor ensures that persons authorised to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that they have access only to the data they need for their task.

Scale and access.

The Processor is a small enterprise. The number of persons with access to the production environment is therefore very limited, which is an advantage from a security perspective. It also means that measures designed for a large organisation — segregation of duties between development and operations, a separate information security officer, a periodic internal audit programme — do not exist in that form. Annex B describes per category what exists and where the limit lies, so that the Controller does not assume measures that are not there.

Where personnel or auxiliaries are engaged.

Where the Processor engages employees, freelancers or auxiliaries who obtain access to personal data, it imposes on them in writing the same confidentiality and the same security obligations, and grants access only to the extent and for as long as necessary.

Access to the production environment.

Access to the production environment takes place to resolve an outage, execute an instruction or perform maintenance. Insofar as such access runs via the administration portal, it is recorded in the activity log the Controller can inspect itself. Access at server level — for instance to restore a backup — falls outside that log; the Processor reports such an action to the Controller where the Controller's data was viewed or altered in the process.

The Controller undertakes the following obligations:

Legal basis.

It has a valid legal basis for every processing activity it causes to take place via the Platform (GDPR art. 6, and where applicable art. 9), and does not provide the Processor with personal data it is not permitted to provide.

Duty to inform data subjects.

It informs its members, students, parents and teachers about the processing, in accordance with GDPR articles 13 and 14. The Processor's Privacy Policy describes the processing on the Platform but does not replace the Controller's own duty to inform: it must itself explain what it uses the data for.

Consent where required.

Where processing rests on consent — in particular the publication and sharing of images — it ensures valid consent, and the consent or authorisation of a parent or guardian for children under 16 (GDPR art. 8, art. 5 of the Dutch GDPR Implementation Act). The Platform enforces that threshold and assumes the safest scenario where the date of birth is unknown, but responsibility for the consent itself remains with the Controller.

Clear instructions.

It provides clear and documented instructions, and keeps the configuration in the administration portal — roles, rights, connections, audiences, custom fields — current and consistent with what it is permitted to process.

Accuracy and minimisation.

It ensures the accuracy of the data it enters, and enters no more data than is necessary for its purpose. It ensures in particular that free text fields and custom fields are not used for data that does not belong there.

Access management.

It assigns rights on a need-to-know basis, revokes accounts of departing staff in good time, and ensures that credentials are not shared.

Retention periods.

It determines how long the data it processes on the Platform must be retained and applies those periods. The Processor does not delete that data of its own accord; see article 17.

Data subject requests.

It handles data subject requests. The Processor provides assistance in accordance with article 13.

Impact assessment.

It assesses whether a data protection impact assessment is required (GDPR art. 35). Given the nature of the data — including data of minors on a potentially large scale — that is a realistic possibility. The Processor provides assistance in accordance with article 14.

Its own reporting duty.

It itself reports a personal data breach to the supervisory authority and, where required, to data subjects. The Processor supplies the information for this in accordance with article 12.

Its own record of processing activities.

It maintains its own record of processing activities (GDPR art. 30(1)). Annex A to this DPA is intended to enable it to complete that record for the part that runs via the Platform, but does not replace it.

General written authorisation.

The Controller hereby grants general written authorisation for the engagement of sub-processors, as referred to in GDPR article 28(2).

The register is the binding list.

The current list of sub-processors — stating per party the purpose, the categories of data, the country and the transfer basis — is published at:

aqlemy.com/en/subprocessors

That list is the sole and binding enumeration. No names are fixed here deliberately: a fixed enumeration in a contract text inevitably falls behind reality, while the authorisation the Controller grants concerns precisely that list. The register carries its own version number.

What the register states per party.

Name, role, purpose of the engagement, the categories of personal data that go to that party, the country of establishment and processing, the basis for transfer outside the EEA, and whether the connection is optional. For an optional connection: if it is switched off in the Controller's environment, no data goes to it.

Change: notification and objection.

• - The Processor informs the Controller at least six weeks before the effective date about the intended addition or replacement of a sub-processor, by email to the administrators and with a notice in the administration portal.
• - The Controller may object in writing and with reasons within those six weeks.
• - On an objection the Parties consult. If that does not lead to a solution — for example an alternative party or switching off the function concerned — the Controller may terminate the Main Agreement as of the effective date of the change, free of charge and retaining its right to export under article 18.
• - The Processor does not implement the change for the organisation that has objected while consultation is ongoing, insofar as that is technically possible.

Exception in case of urgency.

Where a change is necessary to avert an acute security or continuity risk — for example because an existing sub-processor discontinues its service or has suffered a serious incident — the Processor may implement it immediately and informs the Controller without delay afterwards, stating the reasons. The right of objection remains.

Obligations towards the sub-processor.

The Processor imposes on each sub-processor by contract data protection obligations offering at least an equivalent level of protection to those imposed on itself in this DPA (GDPR art. 28(4)). In practice this is done by accepting that party's standard data processing agreement, which may be worded differently from this DPA in places — a different breach notification period, for example, or its own audit arrangement. The Processor assesses per sub-processor whether the level of protection is equivalent, and remains fully liable to the Controller for that party's conduct. On request the Processor provides copies of the relevant passages, or a statement that and how those obligations are recorded.

Not every party in the register is a processor.

A number of parties determine the purposes and means of certain processing themselves and to that extent act as an independent controller. No agreement under article 28 exists with such a party, nor can one exist; their own terms and legal basis apply. The register states per party which role it fulfils: processor, processor with an additional responsibility of its own, independent controller, or no processor relationship. Where a party is an independent controller, the Controller itself assesses whether it wants that disclosure and on what basis; the Processor makes such a connection optional where possible so that it can be switched off.

Liability.

The Processor remains fully liable to the Controller for the performance of the sub-processor's obligations.

What is not a sub-processor.

The register also expressly states what the Processor does not outsource: determining the location from an IP address is done with a file on its own server, the database runs on the same server as the application, and the language model behind the AI functions runs on its own hardware. Those are therefore not sub-processors, and no data leaves by that route.

The Processor takes appropriate technical and organisational measures pursuant to GDPR article 32, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, as well as the risks to the rights and freedoms of data subjects. The full description, worked out per category, is in Annex B. In summary:

Encryption.

• - All traffic to the Platform runs over TLS.
• - Contact details and other designated sensitive fields are stored encrypted using AES-256-CBC. The key is kept outside the program code.
• - Passwords are hashed with bcrypt and cannot be read.
• - Backups are encrypted before they leave the server.

Expressly: this is not database-wide encryption. Only the designated fields are stored encrypted. Student names, grades, absences and message content are stored as ordinary text in the database, on an encrypted disk behind a protected server. Nor is there end-to-end encryption: the Controller can view the data and technically so can the Processor, because the service cannot otherwise be delivered. The Processor describes it this way because a misrepresentation of the encryption would impede the Controller in its own risk assessment and would, in the event of a breach, lead to an inaccurate notification.

Access control.

• - Logical separation per organisation, enforced on every query.
• - Role-based access with a granular permission model within the organisation.
• - Teachers see only their own classes and students.
• - Two-step verification available for administrators.
• - Password policy: at least 8 characters with an upper-case letter, a lower-case letter, a digit and a punctuation mark; commonly used passwords and consecutive digit sequences are refused.
• - Sign-in attempts limited to ten per quarter of an hour per IP address. There is no account lockout; that could itself be abused to lock a user out.
• - Sessions can be revoked per user; a password change or an express revocation ends all existing sessions.

Detection and logging.

• - Sign-ins, failed attempts, unknown devices and changes to password or two-step verification are recorded, and the user concerned is warned.
• - Location determination from an IP address is done locally; no IP address goes to an external service.
• - Actions in the administration portal are recorded in an activity log the Controller can inspect itself.
• - Errors and system measurements are recorded and retained for 30 days.

Infrastructure.

• - Hosting within the European Union; the database runs on the same server as the application.
• - A Content Security Policy limits what may be loaded in the browser.
• - Dependencies are periodically updated against known vulnerabilities.
• - The hosting provider handles the physical security of the data centre.

Continuity.

• - Daily backup of database and files, encrypted and stored in a region other than the production environment.
• - Retention: 7 daily, 4 weekly and 12 monthly snapshots, alongside a daily system image from the hosting provider with a retention of 7 days.
• - Maximum data loss in the event of a disaster: 24 hours. Target recovery time after total loss of the server: 1 to 3 hours. There is no automatically failing-over standby server.

Evaluation.

The Processor periodically evaluates the measures taken and tightens them where requirements or technical developments give cause. The Controller for its part ensures appropriate measures on its own side; article 32 GDPR addresses both parties.

What the security rests on.

On the measures above and on Annex B, not on an external certification. The Processor holds no ISO 27001 certification, no SOC 2 report and commissions no periodic external penetration test. Annex B states this per category, so that the Controller can base its own risk assessment on accurate information and knows which route is open for verifying compliance: the audit arrangement in article 16.

Notification period.

The Processor informs the Controller without undue delay and in any event within 48 hours after becoming aware of a personal data breach concerning the Controller's data. That period is chosen so that the Controller remains comfortably within its own 72-hour deadline for notifying the supervisory authority (GDPR art. 33(1)).

Where there is only a suspicion, the Processor does not wait for the investigation: it reports the suspicion with the information available at that moment and supplements it as more becomes known. Phased notification is permitted; silence until the picture is complete is not.

Content of the notification.

The notification contains, insofar as known:

• - the nature of the breach, and whether it involves reading, copying, altering, deleting or misappropriating data;
• - the time or period in which the breach occurred, and the time of discovery;
• - how the breach was discovered;
• - the likely cause;
• - the categories of personal data and the groups of data subjects concerned, and the estimated number of data subjects and records;
• - whether the data concerned was encrypted, hashed or otherwise rendered unintelligible;
• - whether it concerns special categories of data or data of a sensitive nature, including data of minors, access or identification data, financial data or educational performance;
• - the likely consequences for the Controller and for the data subjects, with where possible an assessment of the risk;
• - the measures taken to end the breach and limit its consequences, and those proposed to prevent recurrence;
• - the name and contact details of the contact point at the Processor.

High risk.

Where there is a suspicion that the breach is likely to result in a high risk to the rights and freedoms of natural persons (GDPR art. 34(1)), the Processor states that expressly, so that the Controller can prepare its own communication to data subjects.

Who notifies whom.

Notification to the supervisory authority and, where required, to data subjects is the Controller's task. The Processor does not make that notification on its behalf, unless the Parties agree otherwise in writing. The Processor provides the assistance needed to make the notification and, on request, a draft description of the incident.

Security incidents that are not personal data breaches.

The Processor informs the Controller within five business days about a security incident that is not a personal data breach but may be relevant to it — for example a successful attack on availability, or a vulnerability that was exploited without data being viewed — with the same openness.

Recording.

All personal data breaches and security incidents are recorded by the Processor in an incident register, with the facts, the consequences and the corrective measures taken, even where notification to the supervisory authority is not required (GDPR art. 33(5)). That register is available for inspection by the Controller on request, insofar as it concerns it.

Contact point.

Notifications about a personal data breach or a security incident go to legal@aqlemy.com, copied to support@aqlemy.com. The Controller maintains a current email address in the administration portal at which it can receive a notification.

Costs.

The Parties make reasonable arrangements about apportioning the costs involved in meeting the notification obligations. The Processor charges no costs for the assistance it provides under this article.

The Processor assists the Controller by appropriate technical and organisational measures in fulfilling its obligation to respond to data subject requests under chapter III GDPR:

• - Right to information (arts. 13-14)
• - Right of access (art. 15)
• - Right to rectification (art. 16)
• - Right to erasure (art. 17)
• - Right to restriction of processing (art. 18)
• - Notification obligation regarding rectification, erasure or restriction (art. 19)
• - Right to data portability (art. 20)
• - Right to object (art. 21)
• - Right not to be subject to solely automated decision-making (art. 22)

What that assistance looks like in practice.

Assistance consists first of all of functionality the Controller can use itself, without the Processor's intervention:

• - access to and correction of every data item in the administration portal;
• - export of member records, students and parents, financial records, exam results and self-composed reports in CSV, XLSX or PDF;
• - an export of one's own file as JSON, which the data subject can request via the mobile application — an end user's access request is thereby usually fulfilled immediately;
• - deletion of an account, with a 30-day recovery period;
• - withdrawal of a consent with the same toggle by which it was given;
• - an activity log in which the handling of a request remains visible.

Where a request cannot be fulfilled by these means, the Processor provides additional assistance on written request, and responds to such a request within five business days, so that the Controller can meet its own one-month deadline.

Requests received directly by the Processor.

Where the Processor receives a request directly from a data subject relating to data for which the Controller is the controller, it does not handle it itself. It forwards it without delay to the Controller and informs the data subject that and where the request has been forwarded.

Restriction of processing.

Where the Controller instructs the Processor to restrict a processing activity (GDPR art. 18), the Processor executes that insofar as the Platform's functionality allows, and consults about an alternative where it does not.

Shared data.

Some data relates to more than one data subject — the family details of two parents, a chat message with two participants. On an erasure request the Processor deletes what relates to the requester and leaves the rest untouched, and reports to the Controller what has been done. One person's right must not cut across another's.

Costs.

The Processor charges no costs for assistance reasonably provided under this article. If it exceptionally wishes to charge costs — for a request requiring considerable, non-standard effort — it notifies this in advance and proceeds only after agreement.

The Processor assists the Controller, taking into account the nature of the processing and the information available to it, in fulfilling its obligations under articles 32 to 36 GDPR.

Security (art. 32).

The Processor provides the information the Controller needs to assess the appropriateness of the measures. Annex B is the starting point; additional questions are answered within ten business days.

Personal data breaches (arts. 33-34).

See article 12.

Data protection impact assessment (art. 35).

Where the Controller carries out an impact assessment, the Processor provides on request: a description of the processing activities, the categories of data and data subjects, the retention periods, the sub-processors and transfers, and the security measures taken. Annex A and Annex B are drawn up so that they largely answer those questions already.

Given the nature of the data — personal data of minors, processed on a potentially large scale — an impact assessment is a realistic obligation for many controllers on this Platform. The Processor does not assess on the Controller's behalf whether that obligation exists.

Prior consultation (art. 36).

Where the impact assessment leads to prior consultation of the supervisory authority, the Processor cooperates and provides the information the authority requires from the processor.

Requests and investigations by a supervisory authority.

A request or investigation by a supervisory authority relating to the processing of the Controller's personal data is forwarded by the Processor to the Controller without delay, insofar as the law permits. The Parties coordinate their response.

Mutual duty to inform on liability or fines.

Each party informs the other without undue delay of a liability claim or of a supervisory authority's intention to impose an administrative fine, insofar as it relates to this DPA. The party addressed:

• - takes reasonable account of the other party's interests in its defence;
• - gives the other party the opportunity to state its views;
• - accepts no settlement proposal and waives no legal remedy without first consulting the other party.

Costs.

The Parties charge each other no costs for assistance reasonably provided under this article. If a party exceptionally wishes to charge costs, it notifies this in advance and as far as possible with an estimate, and the assistance is provided only after agreement. This cost-free provision does not apply to an audit; article 16 governs that.

Starting point.

The Platform, the database and the backups are located within the European Union. The content of the Controller's member and educational administration, its messages and its financial records does not leave the EEA.

Where transfers do take place.

A limited number of supporting services are provided by parties established outside the EEA or with components there — including for push notifications, email delivery via certain providers and protection of forms against abuse. Which categories of data go to which party is stated per party in Annex C and in the register at aqlemy.com/en/subprocessors. In most cases it concerns a limited category: an email address, a device token, or the text of a notification.

Legal bases.

• - Adequacy decision. For parties certified under the EU-US Data Privacy Framework, transfers rest on the European Commission's adequacy decision of 10 July 2023 (GDPR art. 45).
• - Standard contractual clauses. For parties without an adequacy decision, the model clauses adopted by the European Commission apply (GDPR art. 46(2)(c)), supplemented where necessary with additional measures.

Status of the adequacy decision.

The Parties are aware that the adequacy decision is the subject of ongoing proceedings: the General Court of the European Union dismissed an action for annulment on 3 September 2025, after which an appeal was lodged with the Court of Justice. For as long as the decision stands, it is a valid basis. The Processor monitors its status and will switch to standard contractual clauses with additional measures as soon as that is necessary; it informs the Controller accordingly.

What the Processor does not do.

• - No hosting outside the EEA.
• - No transfer of student or member files to a third country.
• - No external service for determining the location from an IP address.
• - No external language-model provider.

The Controller's control.

Various connections that lead to transfers are optional and are enabled by the Controller itself. If a connection is switched off, no transfer takes place by that route. A change to the list falls under the notification and objection arrangement in article 10.

Scope.

The Controller has the right to have compliance with this DPA verified, including the technical and organisational measures taken by the Processor and compliance with the obligations regarding personal data breaches. The Processor makes available all information necessary to demonstrate compliance with article 28 GDPR, and allows for and contributes to audits (GDPR art. 28(3)(h)).

Conduct.

• - The audit is carried out by an independent, certified external expert appointed by either Party, subject to approval by the other, who issues a third-party statement.
• - The auditor provides the audit report only to the Parties.
• - The auditor is bound by confidentiality and obtains no access to the data of other controllers.
• - The Parties agree between them on how to deal with the findings and on a remediation period.

Conditions.

• - At least 30 days' written notice, stating the scope.
• - At most one audit per calendar year, unless there is a specific cause — for example a personal data breach, an indication from a supervisory authority or reasonable doubt about compliance. In that case an interim audit is also possible.
• - During regular office hours, and in a manner that does not unnecessarily disrupt the Processor's operations.

Costs.

The costs of the audit are borne by the Controller, unless the audit reveals shortcomings attributable to the Processor. In that case the Parties consult on a reasonable apportionment of the costs, and the Processor bears in any event the cost of remedying those shortcomings. This exception is deliberate: an audit arrangement in which the customer pays even when the audit demonstrates a shortcoming on the supplier's side discourages precisely the scrutiny article 28 is meant to enable.

Alternative evidence of compliance.

The Parties may agree that an audit already carried out, a valid internationally recognised certification or an equivalent means of verification is used instead of a new audit. The Controller is in that case informed of the findings.

The Processor holds no ISO 27001 certification, no SOC 2 report and no periodic third-party statement. The audit route under this article is therefore an audit by the Controller itself, not the production of a certificate; the alternative above exists for the event that this later changes. This is stated expressly, because a reference to "certifications or reports" without those existing would make this article an empty shell. As a lighter intermediate step, the Processor answers a written security questionnaire within ten business days.

Cooperation.

During the audit process the Processor makes available the necessary information and documentation and grants the access needed for the audit, having regard to the rights of other controllers and to its own security interests.

The Controller determines.

The Controller determines how long the personal data it processes via the Platform must be retained, and informs the Processor of statutory retention periods that apply. The Processor does not process the data longer than in accordance with those periods and than is necessary to perform the Main Agreement.

There is no automatic clean-up.

The Processor has no task that deletes accounts, student files or member records after a period of inactivity. That is a deliberate choice: such a clean-up is irreversible, and the period should be determined by the party that is the controller. The Controller must therefore apply its retention periods itself; the Platform provides the facility to archive or delete accounts and records.

Periods the Processor itself applies.

For processing activities the Processor considers technically necessary, fixed periods apply and are executed automatically:

• - sign-ins and known devices: 24 months;
• - activity log: 18 months for ordinary actions, 24 months for actions warranting attention, and indefinitely for security-relevant entries — signing in, deleting, changing rights, exporting, revealing masked data and any change to a consent;
• - technical error and system measurements: 30 days;
• - notifications from payment service providers: 90 days;
• - generated report files: 14 days, and the record that a report was run: 90 days;
• - cookie consent: valid for one year, deleted shortly afterwards;
• - one-time verification codes and incomplete registrations: hours to days.

Annex A states these periods per processing activity. Where the Controller wishes a shorter period for one of these activities, the Parties consult; a period longer than stated here is not possible.

Deletion of an individual account.

A deletion request leads to a period of 30 days in which the account is out of use and recovery is still possible, and thereafter to permanent deletion. For a parent, teacher or student, approval by the Controller precedes that period.

Statutory retention obligations.

Data subject to a statutory retention obligation — in particular the financial and tax records, for which article 52 of the Dutch General Tax Act sets a period of seven years — is retained for that period, even where the Controller requests deletion. The identifying data is removed from those records; amounts, dates and entries remain.

Backups.

Deleted data may still appear in backups until those expire. Given the retention of 12 monthly snapshots, that may take up to twelve months. A backup is not selectively edited: that would compromise its integrity and make recovery unreliable. During that period the data remains encrypted and is used solely for recovery.

The following applies at the end of the Main Agreement. This article prevails over article 16 of the Terms of Service.

The Controller's choice.

The Controller determines whether the personal data is returned or deleted (GDPR art. 28(3)(h)). If it does not make that choice within 30 days of the end of the agreement, the Processor deletes the data.

Return.

• - For 30 days after the end date the administration portal remains accessible in read-only form, so that the Controller can make exports itself. If the agreement was terminated for abuse, the Processor provides the export on request outside the portal.
• - On written request the Processor provides, within 30 days, a complete export of the personal data in a structured, commonly used and machine-readable format.
• - No costs attach to a first export. For a repeated request or a different format the Processor may charge a reasonable fee after prior notification.
• - On request the Processor provides a description of the structure of the export, so that the data can be imported elsewhere.
• - The Processor never withholds data as leverage. Even in a payment dispute the export is provided.

Deletion.

• - Unless the Controller requests otherwise, the Processor deletes the personal data from the production environment within 90 days of the end of the agreement, including uploaded files.
• - Data in backups disappears with the backup cycle. Given the retention of 12 monthly snapshots, that may take up to twelve months. During that period the data remains encrypted and is used solely for recovery, never for any other purpose.
• - The Processor ensures that the sub-processors also delete or return the data.
• - The deletion is confirmed in writing. The Controller may, at its own expense, have it verified that deletion has taken place.

Exceptions: what remains, and why.

• - Financial and tax records: payments, invoices, cash book entries, expense claims, donations, subsidies and bank import data are retained for the statutory period of approximately seven years. The identifying data — name, email address, address, account number — is removed from them; amounts, dates and entries remain.
• - The evidence of acceptance of the Terms of Service and of this DPA remains, with document name, version, checksum, language and timestamp. The IP address and browser information of that action are erased. Legal basis: GDPR article 17(3)(e), the establishment or defence of legal claims.
• - Immutable registers: the archive overview of deletion actions, the audit log of platform actions, the record of deletion requests and the deduplication record of payment notifications remain untouched. They contain no substantive personal data of members or students.
• - Anonymised statistics: data that can no longer be traced to a person or organisation does not qualify as personal data and falls outside this obligation.

Survival of the DPA.

Until the personal data has been returned or deleted, the Processor continues to comply with this DPA in full, even where the Main Agreement has already ended.

Liability of the Processor.

The Processor is liable for damage arising from failure to comply with this DPA and with the obligations specifically imposed on processors by the GDPR (GDPR art. 82(2)), as well as for damage arising from acting outside or contrary to the Controller's lawful instructions.

Liability of the Controller.

The Controller is liable for damage arising from unlawful or incomplete instructions, from the absence of a valid legal basis, from failing to inform data subjects, or from entering data it was not permitted to process. It bears the primary responsibility towards data subjects for the processing.

Contractual limitation.

For the rest, the liability regime in article 12 of the Terms of Service applies: direct damage limited to the total of the fees over twelve months with an absolute ceiling of € 250,000, exclusion of indirect damage, and lapse of the limitation in the event of intent or wilful recklessness on the part of management.

When that limitation CANNOT be invoked.

Neither Party may invoke a limitation of liability from the Main Agreement or from any other arrangement between the Parties, in the case of: (a) a recourse action brought by either Party under GDPR article 82; or (b) a claim for damages under this DPA, insofar as it consists of recovery of an administrative fine paid to the supervisory authority that is wholly or partly attributable to the other party.

This exception is taken from the sector standard for Dutch education and is deliberate. Article 82 GDPR allocates liability towards data subjects between controller and processor and provides a right of recourse between them. If a contractual limitation also applied against that recourse, the statutory allocation of risk would be hollowed out by contract and the controller would bear the consequences of the processor's failure.

Duty to inform.

Each party informs the other without undue delay of a liability claim or of an intention to enforce by a supervisory authority relating to this DPA, and reasonably provides the information and support needed for the defence. See article 14.

Insurance.

The Processor has taken out professional and general liability insurance and cyber insurance. On request, it provides a statement that this insurance is in force.

Term.

This DPA takes effect at the moment the Controller registers on or uses the Platform, and applies for the duration of the Main Agreement, including renewals.

Ending by operation of law.

This DPA ends by operation of law at the end of the Main Agreement. Until the personal data has been returned or deleted in accordance with article 18, the Processor continues to comply with this DPA.

Termination for a breach.

The Controller may terminate this DPA and the Main Agreement with immediate effect if the Processor breaches a material obligation under this DPA and does not remedy that breach within a reasonable period after written notice of default. Where a breach is by its nature irremediable, or where a serious breach acutely affects data subjects' rights, notice of default is not required.

Termination after an objection to a sub-processor.

See article 10.

Surviving obligations.

The following obligations survive the end of this DPA:

• - the confidentiality in article 8, without limitation in time;
• - the obligations regarding return and deletion in article 18, until they have been fulfilled;
• - the statutory retention obligations in article 17;
• - the liability provisions in article 19;
• - the notification obligation in article 12, for a personal data breach concerning data still held by the Processor under article 18.

Version control.

This DPA carries a version number and an effective date. On each amendment the version number is increased and a checksum of the new text is recorded, so that it is afterwards established which text applied at which moment and which text an organisation accepted.

When the Processor may amend.

The Processor may amend this DPA where:

• - amended legislation, a guideline of the European supervisory authorities or a ruling of a court or supervisory authority so requires;
• - a change to the service requires it, including an expansion of the categories of data processed or a new processing activity;
• - the amendment is editorial and does not affect the rights and obligations of the Parties.

How.

• - An editorial amendment is published with a new version number, without separate notification.
• - A substantive amendment is notified at least 30 days before the effective date by email to the administrators and with a notice in the administration portal, with a short explanation of what is changing and why.
• - Where the amendment concerns an expansion of the categories of personal data processed or a new purpose, the Processor requests express acceptance in the administration portal, recorded with version number, checksum and timestamp.
• - If the Controller does not agree to a substantive amendment, it may terminate the Main Agreement as of the effective date, free of charge and retaining its right to export under article 18.

What the Processor does not do.

Continued use does not constitute agreement to a substantive amendment of this DPA.

Amendment by mutual agreement.

The Parties may in addition amend or supplement this DPA jointly and in writing. Deviations from the standard text are recorded in writing, stating the article they concern, the old and the new text, and the reason. That record then forms part of the DPA between those Parties.

Amendment of the annexes.

The annexes may be updated without the main text changing, for example where a processing activity is added or a measure is tightened. Article 10 applies to a change to Annex C. The notification arrangement in this article applies to a change to Annex A that expands the data processed.

This DPA is governed by Dutch law.

Disputes relating to this DPA are submitted to the court designated as competent in the Main Agreement: the Amsterdam District Court, or — for matters heard by the subdistrict court under article 93 of the Dutch Code of Civil Procedure — the subdistrict division of that court.

The Parties will endeavour to resolve a dispute by mutual consultation first, as described in article 17 of the Terms of Service. That endeavour does not prevent either Party from seeking interim relief where urgency requires it, nor does it affect a data subject's right to approach the supervisory authority or the courts directly.

This DPA is drawn up in Dutch, Turkish, English and Arabic. In the event of conflict between the language versions, the Dutch text prevails.

This annex forms an integral part of the DPA. It describes per processing activity the purpose, the categories of personal data and data subjects, and the retention period, so that the Controller can complete its own record (GDPR art. 30(1)) and substantiate an impact assessment.

Which processing activities actually take place depends on the chosen package and on the modules enabled. A processing activity that is switched off at an organisation does not take place there.

A1. Account and access management

Purpose: creating accounts, assigning roles and rights and granting access. Data: name, email address, telephone number, role, language preference, hashed password, two-step verification. Data subjects: all users. Retention: for as long as the account exists; thereafter in accordance with articles 17 and 18.

A2. Member administration

Purpose: maintaining memberships, contributions and board positions. Data: identification and contact details, membership number, type and status, start and end date, contribution amount, position. Data subjects: members. Retention: determined by the Controller; the financial part falls under the tax retention obligation.

A3. Student administration and educational delivery

Purpose: enrolment, class assignment, homework, attendance, progress, exams and certification. Data: identification data, student number, class and department, academic year, homework and status, grades and assessments with remarks, attendance and absences with reason, progress items, file notes, observations, certificates. Data subjects: students (including minors), teachers. Retention: determined by the Controller; no automatic clean-up.

A4. Parent and family data

Purpose: the link between parent and child, communication about the child and reachability in emergencies. Data: name and contact details of parents and carers, family address, the parent-student link, emergency contact details. Data subjects: parents, carers, guardians, emergency contacts. Retention: determined by the Controller.

A5. Communication

Purpose: announcements, events, newsletters, chat, complaints and reports, targeted at an audience determined by the Controller. Data: message content and participants, recipient lists, audience definition, delivery status, read confirmation where used, newsletter subscriptions and unsubscriptions. Data subjects: all users and recipients entered by the Controller. Retention: determined by the Controller.

A6. Payments and financial records

Purpose: collecting contributions, parental contributions, donations and ticket revenue, and maintaining the financial records. Data: amount, date, payment method and status, description, outstanding items, cash book entries, invoices, expense claims, donations, subsidies. Full account numbers and card details remain with the Controller's payment service provider. Data subjects: members, parents, donors, claimants. Retention: approximately seven years pursuant to article 52 of the Dutch General Tax Act; identifying data is erased from those records on deletion.

A7. Publication

Purpose: displaying information on the Controller's public page, in embeds and on information screens. Data: whatever the Controller publishes itself, including names, photographs and contact details. Data subjects: those about whom it publishes. Retention: until the Controller removes the publication.

A8. Security and sign-in logging

Purpose: preventing and detecting unauthorised access, and warning the user. Data: time, result, device and browser information, encrypted IP address, location at city and country level, whether the device has been seen before. Data subjects: all users. Retention: 24 months. Note: for this processing the Processor acts as controller (article 6).

A9. Activity log

Purpose: enabling the Controller to establish who performed which action. Data: action, time, encrypted name labels of actor and target, non-identifying parameters. Data subjects: users with administrative rights and those to whom an action relates. Retention: 18 months (ordinary), 24 months (attention), indefinite (security-relevant).

A10. Notifications

Purpose: delivering in-app notifications, push messages and email. Data: device token, notification text (may contain names), notification preferences, delivery status. Data subjects: all users. Retention: the token for as long as it is valid; delivery data in accordance with the periods in article 17.

A11. Reports and exports

Purpose: compiling overviews at the Controller's request. Data: the fields it selects from the processing activities above. Data subjects: depending on the selection. Retention: the file 14 days, the record of the run 90 days.

A12. Advertising (optional)

Purpose: reviewing, invoicing and displaying advertisements the Controller sells. Data: business details and contact details of the advertiser's contact person, and aggregated impression and click counters without user, device or IP data. Data subjects: contact persons of advertisers. Retention: for as long as the business relationship lasts; the financial part falls under the tax retention obligation.

A13. Optional connections

Purpose: publication to social media, synchronisation with an email marketing service, calendar integration. Data: only what is necessary for the connection concerned; see Annex C. Data subjects: depending on the connection. Retention: at the sub-processor, in accordance with its own periods; on the Platform in accordance with the processing activities above. Note: every connection is off by default and is enabled by the Controller itself.

A14. AI support

Purpose: (1) summarising, analysing and answering questions about data to which the user already has access (optional, enabled per organisation); (2) answering questions about using the Platform from the Processor's manual (help assistant); (3) drafting replies to support requests by a staff member of the Processor; (4) automatically translating texts at the request of an administrator. Data: for (1) the data from the processing activities above, within the user's rights, for a teacher limited to their own classes and with masked parent contact details; for (2) the user's question text and the page on which it is asked; for (3) the subject and messages of the support request, without internal notes; for (4) the text to be translated. For (2) and (3), email addresses, telephone numbers, IBANs, citizen service numbers and postcode-and-house-number combinations are replaced before storage. Data subjects: users with administration or teacher rights, and persons they mention in a question or support request. Retention: (1) conversation history per user, deletable by that user; (2) 90 days after the last message, and a copy with a support request for as long as that request exists; (3) the draft text is not kept, a non-reversible fingerprint for 180 days; (4) not kept. Note: the language model runs on the Processor's own hardware; there is no external provider and there is no training or evaluation on this data. A draft reply is always read and sent by a person.

This annex forms an integral part of the DPA and describes the technical and organisational measures referred to in GDPR article 32 and in article 11 of this DPA. The structure follows the three classic aspects: availability, integrity and confidentiality. Per category it states what exists — and, where relevant, what does not.

Preliminary: the scale of the service.

The Processor is a small enterprise, and this annex is written accordingly. The number of persons with access to the production environment is very limited — an advantage from a security perspective, because the human attack surface stays small. Against that, measures designed for a large organisation, such as segregation of duties between development and operations, a separate information security officer and an internal audit programme, take a different form here. This annex describes per category what exists and where the limit lies, so that the Controller can base its own risk assessment on accurate information.

AVAILABILITY

Design and capacity. The Platform and the database run on a server at a European hosting provider, within the European Union. Capacity is monitored by a built-in monitor measuring memory, processor use, disk space, response time and the status of the database and processes, with warnings on threshold exceedance.

Maintenance. Scheduled maintenance is announced at least 48 hours in advance and carried out as far as possible outside peak hours. Emergency maintenance for a security vulnerability or a stability problem takes place without announcement, with notification afterwards.

Deployment. A new version is built alongside the running version and only then swapped in, with a health check and an automatic rollback if it fails.

Backup. Daily backup of database and uploaded files, encrypted before transmission, stored with the same hosting provider in a region other than the production environment. Retention: 7 daily, 4 weekly and 12 monthly snapshots. In addition a daily system image from the hosting provider with a retention of 7 days. The integrity of the backup is checked periodically.

Recovery. Maximum data loss in the event of a disaster: 24 hours. Target recovery time after total loss of the server: 1 to 3 hours, by means of a manual rebuild according to a documented runbook.

Scope. There is no automatically failing-over standby server and no second production environment. There is no external, independent availability measurement, and therefore no availability guarantee expressed as a percentage.

INTEGRITY

Traceability of users. Every action in the administration portal is traceable to an individual account. Actions are recorded in an activity log the Controller can inspect, search and export itself, without the Processor's intervention. Security-relevant entries are retained indefinitely.

Non-repudiation. Acceptances of legal documents are recorded with version number, a checksum of the text, language, timestamp and an encrypted IP address, in a record in which an existing entry cannot be modified; a new acceptance is a new entry.

Application controls. Input is validated; file uploads are checked for type and size, partly on the basis of the actual file content and not only the file name. Notifications from payment service providers are verified by signature and deduplicated before any effect is given to them.

Traceability of technical operations. Changes to the software are version-controlled. Actions at server level that do not run via the administration portal are reported to the Controller where the Controller's data was viewed or altered in the process.

Scope. There is no formal segregation of duties between development, test and operations, and no mandatory review by a second person for every change.

CONFIDENTIALITY

Logical access. Access is via a personal account with a password. Passwords are stored hashed with bcrypt and cannot be read. The password policy requires at least 8 characters with an upper-case letter, a lower-case letter, a digit and a punctuation mark, and refuses commonly used passwords and consecutive digit sequences. Administrators can enable two-step verification with an authenticator app. Sign-in attempts are limited to ten per quarter of an hour per IP address. Sessions can be revoked per user; a password change ends all existing sessions.

Separation between organisations. The data of each Controller is logically separated. That separation is enforced on every query, not merely in the display. Within an organisation a granular permission model applies; a teacher sees only their own classes and students.

Separation of environments. The development and test environment is separate from the production environment. No development or testing is done with production data.

Transport. All traffic to the Platform runs over TLS.

Storage. Designated sensitive fields — including email addresses, telephone numbers, addresses, IP addresses and a number of free text fields — are stored encrypted using AES-256-CBC, with a key kept outside the program code. This is not database-wide encryption: student names, grades, absences and message content are stored as ordinary text in the database. There is no end-to-end encryption.

Network access. The Platform is reachable only via the web server; the database is not accessible from the internet. A Content Security Policy limits what may be loaded in the browser. The hosting provider handles the physical security of the data centre and network security at infrastructure level.

Data lifecycle. Retention periods are enforced technically where possible by automatic deletion. Deleted files are also removed from disk, not only from the records.

Vulnerability handling. Dependencies are periodically updated against known vulnerabilities. There is a reporting point for vulnerabilities with an undertaking that no legal action will be taken against a reporter who observes the conditions (article 11 of the Terms of Service). Reports are acknowledged within five business days.

Scope. There is no periodic external penetration test, no automated security scanner over the code, no ISO 27001 certification and no SOC 2 report.

ORGANISATIONAL

Personnel. Persons with access to personal data are bound in writing to confidentiality and obtain access only to what they need for their task.

Incidents. There is a procedure for recognising, recording and reporting security incidents and personal data breaches, with the information list in article 12. Incidents are recorded and used to tighten the measures.

Evaluation. The measures in this annex are evaluated periodically and adjusted where requirements or technical developments give cause. A change to this annex is announced in accordance with article 21.

Incident contact. legal@aqlemy.com, copied to support@aqlemy.com.

This annex forms an integral part of the DPA and belongs with articles 10 and 15.

The register.

The current list of sub-processors is published at:

aqlemy.com/en/subprocessors

That list is the binding enumeration for which the Controller grants general written authorisation in article 10. It carries its own version number and is available in four languages.

What the register states per party.

• - the name of the party;
• - the role: hosting, payments, email delivery, email marketing, push notifications, publication to social media, protection against abuse, website analytics, lookup service, or sign-in;
• - the purpose of the engagement, in plain language;
• - the categories of personal data that go to that party — from "all platform data" for the hosting provider to "device token for notifications" for the notification service;
• - the country of establishment and processing;
• - the transfer basis: processing within the EEA, the EU-US Data Privacy Framework, standard contractual clauses, or no transfer;
• - whether the connection is optional.

Optional connections.

A number of parties are engaged only where the Controller enables the function concerned — including email marketing, publication to social media and sign-in via an external identity service. If that function is switched off, no data goes to them. The register states per party whether that is the case.

What is expressly not a sub-processor.

The register also states what the Processor does not outsource, because that is equally relevant to a risk assessment:

• - Location determination from an IP address is done with a database file on the Processor's own server. No IP address goes to an external service.
• - The database runs on the same server as the application, not with an external database provider.
• - The language model behind the AI functions runs on the Processor's own hardware. No data goes to an external language-model provider.

Removed in August 2026.

Two parties have been removed from the service and therefore no longer appear in the register: an SMS service that received student, teacher and class names, and an external service that sent every website visitor's IP address to the United States before that visitor had made any cookie choice.

Notification and objection.

A change to the register is notified at least six weeks in advance, and the Controller may object with reasons within that period. The full arrangement, including the exception in the case of an acute security or continuity risk, is in article 10.

Obligations towards sub-processors.

A data processing agreement has been concluded with each party listed in the register as a processor, offering at least a level of protection equivalent to that imposed on the Processor in this DPA; as a rule this is that party's standard data processing agreement. With a party listed as an independent controller no article 28 agreement exists — their own terms apply — and with a party without a processor relationship no personal data is sent. On request the Processor provides the relevant passages or a statement about them. The Processor remains fully liable to the Controller for the performance of those obligations.

Processor

Company: Haakje B.V. Trade name: Aqlemy Chamber of Commerce number: 42160038 VAT identification number: NL869977817B01 Place of business: Haarlem, the Netherlands

Contact points

Questions about this Data Processing Agreement: legal@aqlemy.com Privacy and data subject requests: privacy@aqlemy.com Reporting a personal data breach or security incident: legal@aqlemy.com, copied to support@aqlemy.com Technical support: support@aqlemy.com Telephone: +31 85 212 8355 (business days 09:00 - 17:00 CET)

Data protection officer.

The Processor is not required to appoint a data protection officer (GDPR art. 37) and has not appointed one. The fixed point of contact for data protection is privacy@aqlemy.com. The Controller may itself be required to appoint an officer on account of its own size or nature; it maintains in the administration portal the contact details at which the Processor can reach it.

Controller

The Controller's details are those it has recorded in the administration portal. It keeps them current, in particular the email address at which it can receive a notification about a personal data breach or about a change to the sub-processor register.

Supervisory authority

Autoriteit Persoonsgegevens, PO Box 93374, 2509 AJ The Hague, autoriteitpersoonsgegevens.nl.