Privacy policy

This Privacy Policy explains how personal data is collected, used, protected and shared on the platform operated by Haakje B.V. (Chamber of Commerce number 42160038, VAT number NL869977817B01, Haarlem, the Netherlands) under the trade name Aqlemy. It is drawn up in accordance with the General Data Protection Regulation (GDPR) and the Dutch GDPR Implementation Act.

What this document is — and what it is not.

This is an information document (GDPR articles 12 to 14), not a consent form. Reading it does not give consent, and neither does using the platform. Where we do rely on consent, we ask for it separately and you can withdraw it separately. That distinction is stated up front because privacy statements often blur it — and consent presented as a condition of the service is not valid consent (GDPR article 7(4)).

Two different roles — and it matters which one applies.

For the data of members, students, parents and teachers, the organisation using the platform is the controller: it determines the purposes for which that data is processed. We act as processor on that organisation's behalf. Questions about that data should therefore be addressed first to your own organisation; our relationship is set out in the data processing agreement.

In addition, we are ourselves the controller for our own customer relationship: the organisation's contact person, invoicing, visitors to our website, and our own security and system logging. Article 2 sets out that division situation by situation, including the borderline cases.

Legal basis.

Most of the processing described here rests not on consent but on the performance of a contract (the membership or the educational relationship), on a legal obligation, or on a legitimate interest. We use consent only where you genuinely have a free choice — for example for sharing photographs. You can withdraw that consent at any time; this does not affect the lawfulness of processing before withdrawal.

Scope.

This policy applies to the administration portal, the mobile applications, the public organisation pages, the information screens and our own website aqlemy.com. For cookies and similar techniques on the website, the Cookie Policy applies in addition.

Version.

This policy carries a version number and an effective date. We inform you of a change as described in article 18; we do not ask for renewed acceptance, because an information document does not need to be accepted — doing so would wrongly suggest that consent is the legal basis.

No data protection officer, but a fixed point of contact.

We are not required to appoint a data protection officer (GDPR article 37): we are not a public authority, and our core activity does not consist of large-scale regular and systematic monitoring or large-scale processing of special categories of data. There is however a single fixed point of contact for privacy questions: privacy@aqlemy.com. Your own organisation may be required to appoint an officer on account of its own size or nature; that is separate from us.

The GDPR recognises two roles. The controller determines why and how processing takes place. The processor processes solely on instructions. In our case that line does not fall in one single place, so it is set out below situation by situation.

We are the PROCESSOR — the organisation is the controller.

• - Member, student, parent and teacher data: names, contact details, date of birth, address, class assignment.
• - Educational data: homework, grades, exam results, attendance, progress, file notes, certificates.
• - Membership data: membership type and status, contributions, payment history within the organisation.
• - Communication within the organisation: announcements, events, newsletters, chat messages, complaints and reports.
• - The organisation's financial records: cash book, invoices, expense claims, donations, subsidies.
• - Custom fields the organisation configures itself.

For all of this data: the organisation determines what it is used for, how long it is kept and who may see it. We execute. If you want access, correction or deletion of this data, address your organisation; we forward without delay any request that reaches us directly.

We are the CONTROLLER.

• - Our customer relationship: the contact person and administrators of the organisation with which we have an agreement, the invoicing, the correspondence about the service and the support.
• - Visitors to aqlemy.com: visit data, the contact form, requests for a trial or demonstration, template downloads, the governance scan and the newsletter. This data deliberately has no organisation link; see article 10.
• - Security logging: sign-ins, known devices, failed attempts and the revocation of sessions. We ourselves determine that this is logged, for how long, and when a warning is issued, because securing the platform appropriately is our own obligation (GDPR article 32). For that processing we therefore act as controller, not as processor.
• - System measurements and error reports: technical measurements of memory, processor use and application errors. These contain no substantive data of your members or students; they may incidentally contain an identifier or an email address in an error message. Retention 30 days.
• - The evidence of acceptance of the terms and the data processing agreement, with version number, checksum, timestamp and — encrypted — the IP address of that action.

The borderline cases, explicitly.

Advertisers. Where an organisation sells advertising space via the platform, the contract is between the advertiser and that organisation. For the advertiser's business and contact details, that organisation is the controller and we are the processor; the data is accordingly stored separately per organisation. For two matters we are the controller: the evidence that the advertiser accepted our platform terms (version, timestamp, encrypted IP address), and the intermediation fee we invoice to the organisation.

Marketing leads. Anyone who fills in a form on our own website, downloads a template or completes the governance scan is a contact of ours. That data is held in a separate administration without an organisation link, and for it we are the controller. It is never mixed with the data of an organisation on the platform.

System and security logs. See above: controller, not processor. We do not share those logs with other organisations, and an organisation receives from our system log only what concerns its own environment.

Your own activity log. The activity log in the administration portal — who performed which action within your organisation — is data for which your organisation is the controller. You can inspect and export it yourself.

Your organisation's public pages. If your organisation publishes names, photographs or contact details on its public page, it is the controller for that. We do not determine what is placed there.

Below are the categories of data that may be processed on the platform. What is actually processed in your case depends on your organisation's package, on the modules it uses and on what it enters itself — a mosque with only a member administration processes considerably less than a school with student files.

Open a category to see the individual data items.

Special categories of personal data.

The platform is not designed for processing special categories of personal data as referred to in GDPR article 9 — data on health, religious belief, ethnic origin or criminal matters. There is no field for it, and no additional safeguards are built in for it. If an organisation nonetheless enters such data in a free text field or a custom field it created itself, it is the controller for that and must itself have a valid exemption ground. We advise against it.

Two points deserve a note here. The mere fact that someone is a member of a religious organisation may in context be data concerning religion; the organisation generally has the exemption in GDPR article 9(2)(d) for that (processing by a foundation or association with a religious aim, concerning its own members). And an absence with the reason "ill" is essentially health data; the platform provides a single status field for that and no medical record.

What we deliberately do NOT collect.

• - No national identification number and no copy of an identity document.
• - No biometric characteristics on our servers: if you use face or fingerprint recognition to sign in, that characteristic stays in the secure environment of your own phone. We only receive confirmation that the unlock succeeded.
• - No location data on our servers: prayer times and the qibla direction are calculated on your device itself.
• - No advertising profile, no tracking pixel from an advertising network, no interest segments.
• - No full IP address in readable form: where we retain an IP address it is encrypted, and in overviews you see a masked representation.

Each processing activity has exactly one primary legal basis. They are set out below per activity, with the GDPR article.

Performance of a contract — GDPR article 6(1)(b)

• - Creating and managing an account, and granting access to the platform.
• - Member administration: enrolment, membership type, contributions and cancellation.
• - Educational administration: enrolment in a class, homework, attendance, grades, progress and certificates.
• - Communication that is part of the service: timetable changes, announcements about the class or the association, event confirmations, payment requests and reminders.
• - Handling payments the organisation collects from its members.
• - Our own service to the organisation: the subscription, the invoicing and the support.

Legal obligation — GDPR article 6(1)(c)

• - The financial and tax records, and the 7-year retention obligation that applies to them (article 52 of the Dutch General Tax Act).
• - Retaining the evidence of acceptance of the terms (article 6:234 of the Dutch Civil Code).
• - Complying with a request from a competent authority or a court order.
• - Recording and being able to demonstrate consent given and withdrawn (GDPR article 7(1)).

Legitimate interest — GDPR article 6(1)(f)

• - Securing the platform: sign-in logging, recognition of unknown devices, rate-limiting of sign-in attempts, and warning a user of a suspicious sign-in. Interest: preventing account takeover. Balancing: the processing is limited to the time, the device, an encrypted IP address and the location at city and country level, the user is informed about it themselves and receives a button to end all sessions. Without this processing, a takeover can only be discovered afterwards and often too late.
• - Resolving outages and errors, and measuring server capacity. Interest: continuity. Balancing: the measurements contain no substantive data and disappear after 30 days.
• - Preventing abuse of forms and of the email channel.
• - The activity log in the administration portal, so an organisation can establish who made which change. Interest: accountability and fraud prevention within the organisation.
• - Our own business operations: maintaining customer contact, answering questions and improving the service on the basis of aggregated, non-identifiable statistics.

You may object to processing based on legitimate interest; see article 14. For security logging such an objection will generally not succeed, because the logging itself discharges a statutory security obligation.

Consent — GDPR article 6(1)(a)

• - Publishing photographs in which you are recognisable, and sharing them on social media. These are the only two consents in the mobile application that genuinely represent a free choice; all other toggles there are notifications about processing that rests on the contract.
• - Non-essential cookies and measurement tools on our website.
• - Our own commercial email to someone who asked for it.

Consent once given can be withdrawn at any time, and doing so must be as easy as giving it (GDPR article 7(3)). Withdrawal works forwards: what happened lawfully before remains lawful.

Vital interests — GDPR article 6(1)(d)

• - Using emergency contact details in an acute situation during a lesson or activity.

What we do not use as a legal basis.

We base no processing on "you used the platform, therefore you agree". That is not a legal basis.

Education.

Students are assigned to classes. Teachers record attendance, set homework, track progress and enter grades. Parents see the data of their own children — and only theirs. Where two parent accounts are linked to a student, they have equal rights; there is no "primary parent" who sees more than the other.

Teachers see only their own classes.

A teacher working in the administration portal is shown only the students and classes they are linked to. This is not a setting that is on or off per organisation, but a boundary enforced separately on every component involved. Parents' contact details are additionally masked for a teacher's AI assistant.

Member management.

The organisation maintains memberships, sends contribution invoices and collects payment. Members can view and update their own data in the application and, depending on the settings, choose a subscription themselves.

Communication.

Announcements, events and newsletters are targeted at an audience: everyone, parents only, teachers only, or a specific class or department. That boundary is enforced on the server side, not merely in the display: a message intended for one class is also only sent to that class and cannot be retrieved by the rest.

Notifications.

You can choose per type of notification which channel you receive it on: in the application, by push message or by email. Two types cannot be switched off for in-app and email: security notifications about your own account, and notifications that would make the service unusable if you missed them. Push notifications can always be switched off.

Payments.

Contributions, donations and tickets run through your own organisation's payment service provider. We see whether a payment succeeded, the amount and what it was for — not your full account number or card details. Those stay with the payment service provider.

Security.

See article 6 and the sign-in notifications described there.

AI functions.

See article 12.

What does not happen.

• - We do not sell personal data. Not to advertisers, not to data brokers, not to anyone.
• - We do not use your organisation's data to sell our own services to you or to others.
• - We never use one organisation's data for another. The separation between organisations is enforced on every query.
• - We do not read messages or files out of curiosity. Access by us occurs only to resolve an outage or at the organisation's request, and is limited to what is needed for that.

We take appropriate technical and organisational measures as referred to in GDPR article 32. Below is what those measures concretely are — and, just as importantly, what they are not.

In transit:

• - All traffic runs over an encrypted connection (TLS), with a certificate from Let's Encrypt.

At rest:

• - Contact details and other sensitive fields are stored encrypted using AES-256-CBC, with a key kept outside the program code.
• - Backups are encrypted before they leave our server and are stored in a second region.
• - Passwords are not stored but hashed with bcrypt; we therefore cannot read your password, even if we wanted to.

No end-to-end encryption, and no database-wide encryption.

We state this explicitly because it is often suggested otherwise. Your organisation can view your data, and technically so can we. Without that access the service cannot be delivered — a teacher must be able to enter a grade and an administrator must be able to collect a contribution. Moreover, encryption at rest applies to the designated fields, not to the entire database: student names, grades, absences and message content are stored as ordinary text on an encrypted disk behind a protected server.

Access:

• - The data of each organisation is separated; every query is limited to the organisation itself.
• - Within an organisation a granular permission model applies: an administrator gets exactly the components for which they hold a right.
• - A teacher sees only their own classes and students.
• - Administrators can enable two-step verification with an authenticator app.
• - Passwords must be at least 8 characters and contain an upper-case letter, a lower-case letter, a digit and a punctuation mark; commonly used passwords and consecutive digit sequences are refused.
• - On our side the need-to-know principle applies: access to the production environment only where an outage or a request requires it.

Management:

• - Dependencies are periodically updated against known vulnerabilities.
• - A Content Security Policy limits what may be loaded in the browser.
• - Sign-in attempts are limited to ten per quarter of an hour per IP address.
• - Where failed sign-in attempts persist, the IP address they come from is temporarily refused. That refusal applies to the address, never to your account.
• - Actions in the administration portal are recorded in an activity log the organisation can inspect itself; security-relevant entries are retained indefinitely.
• - Our hosting provider handles the physical security of the data centre.

What our security rests on.

On the measures above and on the security annex to the data processing agreement, not on an external certification. We hold no ISO 27001 certification, no SOC 2 report and commission no periodic external penetration test; nor does an automated security scanner run over the code. We say so because your organisation asks in a procurement review, and because it determines which route is open for verifying our compliance: the audit arrangement in the data processing agreement.

Sign-in notifications.

We warn you when your account is signed into from a device or country we have not seen before, when there are repeated failed sign-in attempts, and when your password or two-step verification changes. That notification contains the time, the device and browser, a masked IP address and the location at city and country level.

The location is determined using a local database on our own server; your IP address is not sent to a third party for this. The legal basis is legitimate interest arising from our security obligation (GDPR article 32). Via the link in the notification you can end all your sessions immediately. That link only takes effect after an explicit confirmation on the page itself, so that an email scanner cannot activate it accidentally, and it can be used only once.

Your own part.

Do not share your credentials, use a password you do not use anywhere else, enable two-step verification if you are an administrator, and report a suspicious notification immediately. A large share of incidents begins not with the platform but with a shared or reused password.

A personal data breach is the destruction, loss, alteration, or unauthorised disclosure of or access to personal data.

If the breach concerns an organisation's data (for which we are the processor), we inform that organisation without undue delay and in any event within 48 hours after we become aware of it. That period is chosen so that the organisation remains comfortably within its own 72-hour deadline for reporting to the Dutch Data Protection Authority (GDPR article 33). Reporting to the supervisory authority and, where required, to data subjects is the organisation's task; we provide the information and the support for it.

We provide: the nature of the breach, how and when it was discovered, the likely cause, which categories of data and which groups of data subjects are affected and approximately how many people are involved, whether the data concerned was encrypted or hashed, the likely consequences, the measures taken and proposed, and a contact person.

If the breach concerns data for which we are ourselves the controller — our customer relationship, our website, our security logging — we report it where required within 72 hours to the Dutch Data Protection Authority, and inform the data subjects ourselves where the breach is likely to result in a high risk to their rights and freedoms (GDPR article 34).

Recording.

Every personal data breach is recorded in an incident register with the facts, the consequences and the corrective measures taken, even where it does not have to be reported to the supervisory authority.

Reporting a vulnerability.

If you discover a vulnerability, report it to support@aqlemy.com. The conditions under which we take no legal action against a reporter are set out in article 11 of the Terms of Service.

We do not sell your personal data and do not share it with third parties, except in the cases below.

Service providers (sub-processors).

To deliver the platform we engage other parties, for example for hosting, payments, email and notifications. Most of those parties are processors: they process the data solely on our instructions, under a data processing agreement pursuant to GDPR article 28, and may not use it for their own purposes.

A number of parties are not. A payment service provider, for example, processes payments on our instructions but additionally uses the same data for its own statutory obligations around fraud, sanctions screening and knowing its customer; for that part it is an independent controller and its own terms apply. Where an organisation publishes a post to social media, that platform decides for itself what it does with it. With such parties no data processing agreement exists, nor can one exist.

The register below states per party which role it fulfils, so that you can see where we give the instruction and where a party acts on its own legal basis.

Rather than naming a handful of parties here, we refer to the current list — a fixed enumeration inevitably falls behind reality:

aqlemy.com/en/subprocessors

That page states per party the purpose, which categories of data go there, the country and the legal basis for the transfer. It also states which connections are optional: if a connection is switched off in your organisation, nothing goes to it.

What we deliberately do NOT outsource.

• - Determining the location from an IP address is done with a file on our 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 our own hardware. No data goes to OpenAI, Google, Anthropic or any other provider.

Removed in August 2026.

Two connections have been dropped and therefore no longer appear in the list: 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.

Within your organisation.

Data is visible to the roles that hold a right to it: administrators within their rights, teachers within their own classes, parents for their own children. That is not sharing with a third party but the operation of the service itself.

Umbrella organisations.

If your organisation falls under an umbrella, that umbrella sees aggregated figures and can send joint announcements and events. Full contact details of your members and students are shown to the umbrella in masked form, and the umbrella cannot modify member data, payments or lessons of your organisation.

Legal obligations.

Pursuant to a legal obligation, a court order or a justified request from a competent authority. We assess such a request for legal basis and competence, provide no more than is demanded, and inform the organisation concerned in advance — unless the law prohibits us from doing so.

Business transfer.

In the event of a merger or acquisition, maintaining the same level of protection and continuing the data processing agreement. We announce this in advance.

This article concerns our own website aqlemy.com and the public pages of organisations. The full overview is in the Cookie Policy.

Necessary cookies are always placed: they maintain your session, remember your language choice and protect forms against abuse. No consent is required for these (article 11.7a(3) of the Dutch Telecommunications Act).

All other cookies and measurement tools are placed only after you have given consent. Refusing is as easy as accepting, and the refuse button sits at the same level as the accept button. If you do nothing, nothing is placed.

What we retain of your choice.

A consent record contains a randomly generated identifier, the categories you accepted or refused, the time and the version of the text you saw. Your IP address is not stored with it. The record is valid for one year; after that you are asked again, and the record itself is deleted shortly afterwards. This retention is necessary to be able to demonstrate that you made a choice (GDPR article 7(1)).

Changing your choice.

You can do so at any time via the link at the bottom of the website.

Statistics.

If you accept analytical cookies, we measure which pages are visited, in order to improve the site. Measurement data is not used to track you personally across other websites.

In the mobile application no advertising or tracking cookies are used.

This article concerns the data you give to us — not to an organisation on the platform. For this we are the controller.

When this applies.

If you fill in the contact form, request a trial or demonstration, download a template, complete the governance scan or subscribe to our newsletter.

What we record.

Your name, email address, any telephone number and organisation name, your message, which form you filled in, and where you came from. The content of your message and the notes we make about it are stored encrypted. In our own inbox that data is shown masked; revealing it in full is possible only with a stated reason, and that action is itself recorded.

Legal basis.

For answering your question or delivering a requested file: performance of your request. For sending news and updates: your consent, via a separate checkbox that is empty by default.

Two things we keep strictly separate.

Delivering a file by email is performance of your request and does not create a newsletter subscription. If you also wish to stay informed, that is a separate choice you tick yourself. A free download is not an existing customer relationship, and consent for one may not be tied to the other (GDPR article 7(4), article 11.7 of the Dutch Telecommunications Act).

Unsubscribing.

Every commercial email from us contains an unsubscribe link and the technical unsubscribe headers your email program uses for it. Unsubscribing applies to your email address as a whole and takes effect immediately; only a new, express subscription lifts it. Transactional messages — a password reset, a confirmation, an invoice — contain no unsubscribe link, because they are part of the service itself.

The governance scan.

The scan can be completed anonymously. If you do not enter an email address, no contact record is created. Your score is calculated on our side; your answers do not go to a third party.

Retention.

We keep this data for as long as the contact is current and no longer than necessary thereafter. We do retain an unsubscribe and the evidence of your consent, because otherwise we cannot demonstrate that we respect your choice.

What does not happen here.

This data is never mixed with the data of an organisation on the platform, and it is not resold.

An organisation on the Platform may sell advertising space to businesses. Where an advertisement appears in the app, on an information screen, on the organisation's website or in its newsletter, the following applies.

Not personalised: Advertisements are not tailored to individual users. If an organisation sells the same placement to more than one advertiser, an information screen rotates through all of them and the app picks one at random per screen visit. Which advertisement you see therefore does not depend on who you are, on what you have done before, or on which device you use.

No profiling: No advertising profile is built about you. We do not infer interests, characteristics or segments from your behaviour in the app or on the site, and we do not use your data to determine which advertisement you are shown.

No third-party advertising SDK: The app and the website contain no advertising network, no ad exchange and no tracking pixel from an advertising party.

No sharing with advertisers: Advertisers receive no personal data. They see only aggregated totals about their own advertisement.

Aggregated counters only: We record per advertisement how often it was shown and clicked in total. No user identifier, device identifier, IP address or cookie is stored with it; it is a single tally that cannot be traced to a person. A click goes directly to the advertiser's website and not via an intermediate measurement URL of ours.

On a website an impression counts only once the advertisement is visible. On an information screen everything rendered is also visible; on a website an advertisement is often below the fold. There, the counter only increments once the advertisement is actually half in view, and once per visit. In a newsletter an impression counts when the email is opened, via the open measurement the organisation already uses; if that is switched off, the block is not counted. No new measurement is added for this.

Recognisability: Every advertisement visibly carries the label "Advertisement", the name of the advertiser and an explanation of why you are seeing it. This follows from article 26 of the Digital Services Act and from the recognisability requirement of the Dutch Advertising Code, and cannot be switched off.

The advertiser's data: From the advertiser itself we process business details and the contact details of its contact person, in order to review, invoice and deliver the advertisement. Legal basis: performance of the contract. The controller for this is the organisation with which they advertise; see article 2. The advertiser can view and update that data in their own advertiser portal. They cannot change their own email address — that is the key to their account — and the evidence of the advertising terms they accepted is recorded immutably.

No automated decisions with legal effect.

No decisions are taken on the platform that are based solely on automated processing and that produce legal effects concerning you or similarly significantly affect you (GDPR article 22). Grades are entered by a teacher, an absence established by a human, a membership assessed by an administrator. What the platform does is calculate, sort and signal — a human decides.

What does happen automatically, and what that means.

• - The platform can signal that a student has been absent several times or that homework is falling behind. That is a signal to the teacher, not a judgement about the student.
• - With a family discount, the contribution amount is calculated on the basis of the number of enrolled children. If that number changes later, the portal shows a "review discount" signal rather than silently adjusting the amount — a human decides.
• - Payment reminders follow a fixed sequence. They never automatically lead to deregistration.
• - On a sign-in from an unknown device you receive a warning. Your account is not blocked as a result.

AI functions.

The platform has three kinds of AI functions. For all three:

• - The language model runs on our own hardware. No data goes to OpenAI, Google, Anthropic or any other external provider.
• - Your data is not used to train, fine-tune or evaluate models.
• - You can always see that you are dealing with an AI function, and you can always involve a person.
• - The output of a language model may be incorrect. Use it as an aid and not as a finding; verify an outcome before basing a decision on it.

The AI assistant for data. It answers questions about data to which the user already has access, and produces summaries and analyses. It is off by default and is enabled per organisation. For a teacher, it is limited to educational data within their own classes. Financial data, member administration, registrations and exports are excluded for them, and parents' contact details are masked.

The help assistant. In the administration portal it answers questions about using the platform, exclusively from the Aqlemy manual. It does not read your organisation's data. It is available to administrators and teachers; an organisation can have it switched off, and an administrator can switch it off per administrator. For it:

• - Your questions are stored without email addresses, telephone numbers, IBANs, citizen service numbers and the combination of postcode and house number: these are replaced by a placeholder before storage. A conversation is deleted automatically 90 days after the last message.
• - If you want to put your question to a staff member, a copy of the conversation, with the same replacements, goes with your support request. That copy is kept for as long as the support request exists.
• - Your rating of an answer (thumbs up or down) and the number of questions without an answer are used exclusively to improve the manual. They are not used to train or evaluate a model.

Draft replies to support requests. An Aqlemy staff member can have a draft reply made for your support request. For this, the model receives the subject and the latest messages of the request, with the same replacements as above, and never our staff's internal notes. The draft is always read by a person, adjusted where needed and sent by a person; it never counts as our response until a person sends it. We do not keep the text of the draft. To measure whether a draft was useful, we keep a non-reversible fingerprint of it for 180 days.

Translation.

If an administrator has a text translated automatically, this is done with the same language model on our own hardware. The text does not leave our server. Do not put personal data into a text you have translated if that is not necessary.

What disappears automatically. The following data is deleted of its own accord once the period has elapsed:

• - Sign-ins and known devices: 24 months
• - Record of a temporarily refused IP address: around 31 days at most after the last refusal. An address we place on an exception list by hand remains until we remove it
• - Activity log: 18 months for ordinary actions and 24 months for actions that warrant attention. Security-relevant entries — signing in, deleting, changing rights, exporting, revealing masked data, and any change to a consent — are retained indefinitely
• - Technical error and system measurements: 30 days
• - Notifications from payment service providers: 90 days
• - Generated report files: 14 days; the record that a report was run: 90 days
• - Conversations with the help assistant: 90 days after the last message
• - Measurement data of a draft reply to a support request (without the text): 180 days
• - Cookie consent: valid for one year, and deleted shortly afterwards
• - One-time verification codes and incomplete registrations: within hours to days, depending on the type

Data attached to your account. Membership, educational and contact data is retained for as long as the organisation maintains the account. We do not delete it of our own accord: the organisation is the controller and determines what is kept and for how long.

There is deliberately no automatic clean-up of inactive accounts. We have no task that deletes accounts or student files after a period of inactivity. That is a choice: such a clean-up is irreversible, and the period should be determined by the organisation that is the controller — not by us. We state this explicitly because privacy statements often claim periods that no task actually carries out. As controller you would do well to set a retention period yourself and to apply it periodically; for a member administration, two years after deregistration is customary for name and address data, with the seven years below for the financial part.

Deletion on request. If you request deletion of your account, it is taken out of use for 30 days — during which you can still change your mind — and then permanently erased. For a parent, teacher or student, those thirty days are preceded by approval from the organisation, because the account may be attached to an ongoing educational relationship. A member can do it themselves. If a request is refused, you are told why.

On termination of the agreement with the organisation the data is deleted from the production environment within 90 days, unless the organisation requests otherwise. See article 16 of the Terms of Service.

Backups. Deleted data may still appear in backups until those expire. We retain 7 daily, 4 weekly and 12 monthly snapshots, so that may take up to 12 months. A backup is not selectively edited; that would compromise the reliability of recovery. During that period the data remains encrypted and is used solely for recovery.

Financial records. Payments, invoices, cash book entries, expense claims and donations are retained for 7 years, including after deletion of the account (tax retention obligation, article 52 of the Dutch General Tax Act). Name, email address, address and account number are removed from those records; amounts, dates and entries remain.

Evidence that is retained. The evidence that an organisation accepted the terms and the data processing agreement is retained — version, checksum and timestamp — because we must be able to produce it in a dispute (GDPR article 17(3)(e)). The IP address and browser information of that action are erased.

The IP address on sign-ins is stored encrypted; in overviews you see only a masked representation.

Whom to approach.

If it concerns your data as a member, student, parent or teacher, your own organisation is the controller. Address your request there. If it reaches us, we forward it without delay and let you know. If it concerns our own customer relationship or our website, we are the right party: privacy@aqlemy.com.

Your rights.

Information (articles 13-14). Knowing which data is processed, for what purpose, on what legal basis, for how long and with whom it is shared. This document is the discharge of that.

Access (article 15). A copy of your personal data. In the mobile application you can request this yourself: you receive your own file as a JSON document, decrypted and immediately readable. That works instantly and without a waiting period.

Rectification (article 16). Correction of inaccurate data and completion of incomplete data. You can update much of it yourself in your profile.

Erasure (article 17). Deletion of your data, subject to statutory retention obligations and to data needed for the establishment or defence of legal claims. See article 13 for how that proceeds.

Restriction (article 18). Temporarily "freezing" the processing, for example while the accuracy of a data item is contested.

Portability (article 20). The data you provided yourself, in a structured, commonly used and machine-readable format. The export from the application is JSON; the organisation can additionally export per component in CSV, XLSX or PDF.

Objection (article 21). Against processing based on legitimate interest, on grounds relating to your particular situation. Objection to direct marketing is always possible and is always honoured, without any balancing.

Withdrawal of consent (article 7(3)). At any time, and as easily as giving it. In the application you do so with the same toggle.

Automated decision-making (article 22). See article 12: it does not take place.

Complaint (article 77). You always have the right to lodge a complaint with the Dutch Data Protection Authority, and to go to court.

How we handle a request.

• - We respond within one month. Where a request is complex or there are many, we may extend that period by two months; we tell you within the first month, stating the reasons.
• - A request is free of charge, and there is no maximum of once per year. Only in the case of a manifestly unfounded or excessive request — in practice: the same request repeatedly in quick succession — may we charge a reasonable fee or refuse, and we then explain why (GDPR article 12(5)).
• - We verify your identity, but do not ask for a copy of your identity document. Verification via the email address or the account by which you are known is sufficient and proportionate.
• - If we refuse a request in whole or in part, you are told the reason and we point you to the complaint route.

Special case: shared data.

Some data relates to more than one person — the family details of two parents, for instance, or a chat message with two participants. Deletion of your data must not cut across the rights of that other person. In such a case we delete what relates to you and leave the rest untouched, and explain what we have done.

A large share of the data on this platform concerns minors. Additional safeguards apply to it.

The age threshold is 16.

For an information society service, the consent of a child under 16 is valid only where a parent or guardian gives it or authorises it (GDPR article 8, implemented in the Netherlands in article 5 of the GDPR Implementation Act). That is the threshold the platform applies.

This threshold affects only the processing that rests on consent: publishing photographs and sharing them on social media. For the educational administration itself, consent is not the legal basis — that rests on the agreement between the organisation and the family — so age changes nothing there.

How it is enforced.

• - Where the date of birth is unknown, the platform assumes the child may not decide for themselves. That is the safe side of the doubt.
• - The threshold applies on every path by which a consent can be stored, including via the profile screen. A single unchecked path would render the whole threshold worthless.
• - A refused consent is not recorded as "no" where the child was not permitted to give it. Nothing is stored in that case, so that "not yet asked" remains distinguishable from "refused". Recording a refusal the child never expressed would itself be inaccurate.

Parental rights.

A parent or guardian can inspect their child's data, have it corrected and have it deleted, and object to processing. Where two parent accounts are linked to a student, they have equal rights.

Limited access.

Student data is visible within the organisation only to those with a role in it: their own teacher, the relevant administrator, and their own parents. A teacher sees only their own classes.

No marketing to children.

We never use minors' data for our own marketing, and advertisements on the platform are not tailored to individual users — not even by age.

Images.

Publishing photographs in which a child is recognisable is a real and revocable choice. If you withdraw it, that works forwards: already published material is removed on request insofar as that lies within the organisation's power. What has already been copied elsewhere cannot always be retrieved by the organisation.

The application requests only permissions it actually uses. Below is what each permission is for and what happens to the data. You can refuse or later withdraw every permission via your phone's settings; the associated function will then not work, while the rest of the app will.

Location.

For calculating prayer times for your location and for the qibla direction. The coordinates are used on your device and not transmitted to our servers. If you refuse this permission you can set the location manually; the compass will not work.

Camera.

For taking a photograph for a homework assignment or a profile picture. The photograph only goes to the platform if you send it yourself.

Photo library.

For choosing an existing photograph for your profile or as an attachment. The app receives only the photographs you select yourself, not your entire library.

Calendar.

For adding prayer times, lessons and events to your own calendar. The app also requests read access, and that deserves explanation: it is needed to be able to show which calendar is being written to, so that you can choose. Your existing appointments are not read, not transmitted and not stored.

Notifications.

For reminders of prayer times, announcements from your organisation, events and security warnings. To deliver a push message, a device token from your phone is passed to the notification service; that token identifies the device, not you personally. If you switch notifications off, you receive them in the app itself and by email.

Motion and magnetic field sensor.

Solely for the qibla compass. Nothing is recorded or transmitted from it.

Storage.

For storing attachments you download and your preferences and temporary files on the device itself.

Biometric unlock.

You can unlock the app with face or fingerprint recognition. This runs entirely through your phone's secure facility: the biometric characteristic does not leave your device and never reaches our servers. We only receive confirmation that the unlock succeeded.

What the app does NOT do.

• - No background location, no movement profile, no record of where you have been.
• - No advertising identifier, no tracking pixel, no advertising network.
• - No access to your contacts, your messages or your phone calls.
• - No QR code scanning and no offline audio; those functions are not in the app.

Withdrawing a permission.

Via your phone's settings, per app and per permission. The app does not ask again.

The starting point: your data stays in the EU.

The platform, the database and the backups are held with a European hosting provider, in data centres within the European Union. The content of your member administration, your student files, your messages and your financial records does not leave the EEA.

Where transfers do take place.

A number of supporting services are provided by parties established in the United States or with components there — for example for push notifications, email delivery via certain providers, or protection of forms against abuse. What exactly goes there is stated per party at aqlemy.com/en/subprocessors. In most cases it concerns a limited category: an email address, a device token, the text of a notification.

On what basis.

• - Adequacy decision. For parties certified under the EU-US Data Privacy Framework, the European Commission's adequacy decision of 10 July 2023 applies. We are aware that this decision is the subject of ongoing proceedings before the Court of Justice: the General Court dismissed an action for annulment on 3 September 2025, after which an appeal was lodged. For as long as the decision stands, it is a valid basis. We monitor its status and will switch to standard contractual clauses as soon as that is necessary.
• - Standard contractual clauses (GDPR article 46(2)(c)). For parties without an adequacy decision, the model clauses adopted by the European Commission apply, supplemented where necessary with additional measures.

What we deliberately do not do.

• - No hosting with a United States provider.
• - No external service for determining the location from an IP address; that is done with a file on our own server.
• - No external language-model provider; the model runs on our own hardware.
• - No transfer of student or member files to a third country.

Your organisation has a say.

Various connections are optional and are enabled by your organisation itself. If a connection is switched off, nothing goes to it. A change in the list of sub-processors is announced in advance and your organisation can object to it; the arrangement is set out in the data processing agreement.

Version control.

This policy carries a version number and an effective date at the top of the page. On each change 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.

How we inform you.

• - An editorial change — a language correction, a clarification — is published without separate notification.
• - For a substantive change we inform the administrators of the organisations by email and with a notice in the administration portal, at least 30 days before the effective date, with a short explanation of what is changing.

We do NOT ask for renewed acceptance of this policy.

A privacy statement is an information document. Requiring re-acceptance would wrongly give the impression that consent is the legal basis for processing that in reality rests on the contract or on the law, and would contaminate the consents that do matter. We only ask for a new, express choice where the scope of an actual consent changes — for example where a new choice about images is added.

Continued use is not agreement.

We do not infer agreement from the fact that you continue to use the platform. If you disagree with a change, you may exercise your rights under article 14; an organisation may terminate the agreement under article 15 of the Terms of Service.

Earlier versions.

An earlier version is available on request via privacy@aqlemy.com.

First: whom to approach.

If your question concerns data your organisation processes on the platform — your membership, your child, your class, your contribution — address that organisation. It is the controller and its contact details appear in its own communications. We may not change or delete that data without its instruction.

Our contact details.

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

Privacy and data subject requests: privacy@aqlemy.com Legal matters: legal@aqlemy.com Technical support: support@aqlemy.com General enquiries: ask@aqlemy.com Telephone: +31 85 212 8355 (business days 09:00 - 17:00 CET)

A complaint to us.

If you are not satisfied with how we have handled your data or your request, let us know via privacy@aqlemy.com. We respond substantively within 30 days. A complaint to us is not a precondition for going to the supervisory authority — you may also do that straight away.

A complaint to the supervisory authority.

You have the right to lodge a complaint with the Dutch Data Protection Authority (GDPR article 77):

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

If you live in another EU member state, you may also approach the supervisory authority of your own country.

Going to court.

You additionally have the right to an effective judicial remedy against us or against your organisation (GDPR article 79), and to claim compensation (GDPR article 82).