Part C: Data processing agreement
This data processing agreement applies when we process personal data on the forening's behalf. It is entered into under Article 28 of the General Data Protection Regulation and forms part of the agreement.
1. Roles
The forening is the controller. We are the processor.
The agreement covers only the personal data we process for the forening. It does not cover the data we process as an independent controller, such as data about the forening's account, billing, security and the people at the forening we are in contact with. Our data use statement describes those.
Two are worth naming explicitly, because they concern people at the forening and still fall outside this agreement: the record of which administration screens are used, and the internal notes about the relationship, both described in Part B clause 8. We are an independent controller for those, not a processor, because they concern our customer relationship with the forening and not the forening's members. We process them on the basis of our legitimate interest, and the forening does not instruct us in them. Nothing about members is recorded for these purposes.
Appendix 1 sets out the purpose, duration, nature, categories of personal data and categories of data subjects.
2. The forening's instructions
We process personal data only on the forening's documented instructions. Those instructions are this agreement, the way the forening has configured the platform, the forening's use of it, and anything else the forening asks us for in writing.
The forening instructs us to process the data to the extent necessary to run, host, secure, monitor, support and debug the platform, to run the AI features the forening has switched on using our own hardware, to use the subprocessors listed in Appendix 3, and to send data to the SMS, email and payment providers the forening has chosen.
If we consider an instruction to be contrary to data protection law, we say so. We may refuse an instruction that would expose us or other customers to legal or security risk.
3. The forening's obligations
The forening is responsible for the processing being lawful: that there is a basis, that data subjects have been informed, that no more is recorded than necessary, and that its instructions to us are lawful.
The forening may not put special categories of personal data, criminal offence data, health data or biometric data into the platform without a separate written agreement with us. Children's certificates (børneattester) are an exception: that feature is built for it, sits behind its own feature switch and its own permission area, and using it is the agreement.
The forening assesses for itself whether its use requires consent, an impact assessment or prior consultation.
4. Confidentiality and personnel
Those of us who can access the forening's personal data are bound by a duty of confidentiality.
Access is granted on need, not by default, and only to those who have to run, secure or support the platform.
5. Security
We implement appropriate technical and organisational measures as described in Appendix 2. We may update them so long as the overall level of protection is not lowered.
Security also depends on the forening: on who it gives access, what rights they get, what goes into free-text fields, and how the forening's own equipment and email are secured.
6. Subprocessors
The forening gives us general written authorisation to use subprocessors to run, secure and support the platform. The current ones are listed in Appendix 3.
If we want to add or replace one, we give 15 days' notice by email to the forening's contact address and in the platform. The forening may object on reasoned data protection grounds within 14 days. If no objection is made, the subprocessor is authorised.
If an objection cannot be resolved, we switch off the affected feature, offer an alternative, or the forening may terminate the affected part of the subscription at the end of the period paid for.
If the change is necessary for security, or because a provider shuts down from one day to the next, we may act first and give notice immediately afterwards.
We impose on subprocessors the same obligations we have under this agreement, and we are responsible for their work as for our own.
7. Transfers to third countries
Processing takes place in the EU and the EEA. We do not transfer personal data to countries outside the EEA.
Should that become necessary, it happens only once the subprocessor is listed in Appendix 3, the forening has been notified under clause 6, and a valid transfer mechanism is in place, such as an adequacy decision or the EU standard contractual clauses with any supplementary measures required.
8. AI and personal data
Where an AI feature runs on the forening's data, we process the prompt, the retrieved content, embeddings, logs and answers in order to perform the function the forening asked for. All of it happens on our own hardware.
We do not use the forening's content to train or fine-tune models. We use technical data, usage figures and feedback to run and improve the platform.
The forening must keep the volume of personal data in prompts down and must not put sensitive data in, per clause 3.
If we use an external AI provider at some point, it becomes a subprocessor and follows clauses 6 and 7. Until then we do not.
9. Assistance to the forening
We assist the forening with requests from data subjects, with security, with handling breaches and with impact assessments, to the extent relevant and where we hold the information.
Much of it the forening can do itself: access, rectification and erasure are features of the platform, and they are there so the forening does not have to ask us every time.
Assistance beyond what the platform and the documentation cover may be invoiced by time spent, unless the need arises from a fault of ours.
10. Personal data breaches
If we discover a breach affecting the forening's personal data, we say so without undue delay and give the information we have, so the forening can meet its own notification duty.
We provide the information as the investigation progresses, and we may take containment measures without asking first where that is necessary.
A notification from us is not an admission of liability. The forening decides for itself whether the Danish Data Protection Agency or the data subjects must be notified.
11. Deletion and return
When the agreement ends we delete or return the forening's personal data at the forening's choice, unless the law requires us to keep it.
The forening can export its data for 30 days after termination. After that we delete or anonymise it.
Backups are not deleted individually. They are overwritten on the rolling schedule, and until then they remain protected and are not used for anything but restoration.
Accounting records are kept for five years plus the current year under the Danish Bookkeeping Act.
12. Audit
We give the forening the information it needs to see that we comply with this agreement: a description of security, the list of subprocessors and answers to reasonable questionnaires.
The forening may have an audit carried out once a year, and in addition after a confirmed breach, on 30 days' notice and within working hours. The audit must not disrupt operations or give access to other foreninger's data.
The forening pays for the audit. It may be carried out as a review of documentation or remotely where that is sufficient.
13. Records
We keep the record of processing activities a processor is required to keep, and we cooperate with the Danish Data Protection Agency when we must.
The forening keeps its own record and its own impact assessments.
14. Liability and precedence
Liability under this agreement follows the limitation in Part B clause 12, to the extent data protection law permits.
The limitation does not change what the General Data Protection Regulation itself provides. It does not limit a party's liability to a data subject under Article 82, and it does not apply to administrative fines under Article 83. Where one party has paid the full compensation, it may recover the other party's share of the responsibility, cf. Article 82(5).
Where this data processing agreement conflicts with Part A or B on the processing of personal data, this agreement prevails. Where the EU standard contractual clauses apply, they prevail over this agreement to the extent of any conflict.
Appendix 1: Details of the processing
| Subject matter | Our provision of the hosted membership and forening platform, and the support, security and operation of it. |
|---|---|
| Duration | The term of the agreement plus the export period in Part A clause 8 and the backup overwrite cycle in clause 11 above. |
| Nature | Collection, recording, storage, structuring, retrieval, display, transmission, backup, restoration, logging and erasure. Where the forening has switched AI on: drafting, rewriting, summarising and retrieval within the forening's own content. |
| Purpose | To provide, run, secure, support and debug the platform on the forening's instructions, per clause 2. |
| Data subjects | The forening's board and administrators; members; mentors and mentees; participants in activities and trips; webshop customers; newsletter recipients; people who write in through contact, incident or feedback forms; people named by others in minutes, attendance lists, incident reports or notes; visitors to the forening's public pages. |
| Personal data | Name, email, phone, address and date of birth where given; passwords in hashed form; membership number, type, status and dates; registrations, check-ins and attendance; notes, agreements and progress in mentor and talent programmes; questionnaire answers; orders with delivery and billing address; payment status and payment reference; uploaded images, documents and media; minutes and attendance lists; incident reports; feedback and support correspondence; technical and interaction logs with IP address, browser, time, action and, for AI features, prompt and answer. |
| Card details | Card number, expiry date and security code are collected by the payment provider directly from the data subject. We do not receive them, process them or store them. We get a payment status and a transaction reference. |
| Sensitive data | None, except children's certificates where the forening has switched that feature on. They sit behind their own feature switch and their own permission area, not in the ordinary media library. Otherwise sensitive data must not be entered without a separate written agreement, per clause 3. The forening assesses for itself whether its use of free-text fields introduces such data. |
| Frequency | Ongoing, for as long as the platform is in use. |
| Disclosure | Only to the subprocessors in Appendix 3 and only for the purposes stated there. |
Appendix 2: Technical and organisational measures
These are the measures clause 5 refers to, described as they are implemented today. If something changes materially, the appendix is updated.
| Area | Measure |
|---|---|
| Sign-in | Email and password, or passkey (WebAuthn), which is supported and recommended for administrator accounts. Passwords are stored only as salted one-way hashes; plaintext is never stored or logged. Sessions use httpOnly cookies that browser scripts cannot read, marked secure and SameSite, with a CSRF token on state-changing calls. Users can end their own sessions, and we can end them for security reasons. |
| Access control | Roles with individual permissions, enforced on the server at every call and not by hiding buttons. Each forening's data is separated, and which forening a call belongs to is decided by the domain it arrives on, not by anything the client sends. Cross-forening functions require a separate elevated permission. |
| Transport | All traffic over HTTPS/TLS with HTTP Strict Transport Security. |
| Browser | A Content-Security-Policy with a per-response nonce, restricting which scripts the browser executes. |
| Storage | Application data in a database and uploaded files in object storage, both on our own hardware in Denmark. Access limited to operations personnel with a specific need. |
| Isolation | Components are separated at infrastructure level, and network access between them is restricted to what operations require. |
| Backup | Automatic backup roughly every six hours, retained on a rolling schedule and restorable for disaster recovery and operational recovery. No RPO or RTO is agreed unless a separate SLA sets one. |
| Logging | Application, security and interaction logs as described in Part B clause 8, kept only as long as the purpose requires, with access limited to personnel with a need. |
| Code changes | Version control with peer review, an automated test suite and static analysis in continuous integration before anything is deployed. Deployment is continuous, without fixed windows. |
| Vulnerabilities | Dependencies are updated and security advisories are acted on as they are published. External penetration testing is not carried out today. |
| Personnel | Least-privilege access, only for those who must run, secure or support the platform, all under a duty of confidentiality. |
| Data subject rights | Access, rectification and erasure, including account deletion, exist as features in the platform, so the forening can meet a request without going through us. |
| Export and deletion | Export in a standard format during the term and for 30 days after termination. Deletion and anonymisation thereafter, per clause 11. |
| Incidents | Notification of the forening without undue delay after we become aware of a breach, with information as the investigation progresses, per clause 10. |
| Availability | We keep the platform running with reasonable care. There is no uptime guarantee with numbers in it unless a separate SLA has been entered into. |
Appendix 3: Subprocessors
This is the list clause 6 refers to, filled in for the setup as it is operated today. Some rows are our own hardware, where there is neither a third party nor a transfer. The rest are named companies. If one is added or replaced, the appendix is updated first and the notice follows.
| Subprocessor | Service and purpose | Personal data | Location |
|---|---|---|---|
| Medlemsplatformen ApS CVR no. 46692667 Willemoesgade 50, 2., 2100 København Ø | Hosting, compute, database and object storage, that is, the environment the platform runs in. | All categories in Appendix 1. | Own hardware at our own sites in Denmark. No third-party hosting provider and no transfer. |
| ONLINECITY.IO ApS (GatewayAPI) CVR no. 27364276 Buchwaldsgade 50, 5000 Odense C | SMS, where the forening has switched it on and chosen this gateway. | The recipient's phone number and the content of the message. | Denmark. GatewayAPI can be selected in an EU variant, which is used where the forening chooses it. |
| COMPAYA A/S (SMS.dk) CVR no. 31375428 Palægade 4, 2. tv., 1261 København K | SMS, where the forening has chosen this gateway instead of GatewayAPI. | The recipient's phone number and the content of the message. | Denmark. |
| Snare ApS (Scanpay) CVR no. 45031144 Ulrikkenborg Allé 26, st. tv., 2800 Kongens Lyngby | Card payment and payment status for subscriptions, activities and the webshop. Each forening uses its own Scanpay account and key. | Amount, order and transaction reference, and the payer's contact details. Card number, expiry date and security code are collected by Scanpay directly from the data subject and never reach us. | Denmark. |
| PostStack | Outbound transactional email and newsletters, when this provider is the active one. | The recipient's name and email address and the content of the message. | EU. Legal entity and address disclosed on request. |
| SMTP2GO | Outbound transactional email and newsletters, when this provider is the active one instead of PostStack. | The recipient's name and email address and the content of the message. | EU region. Legal entity and address disclosed on request. |
| Web analytics on own hardware (Umami) | Aggregate statistics on use of the site, loaded only where the visitor has accepted analytics cookies. | Page views and events with the technical data the analytics component records. | Own hardware. Not a separate subprocessor. |
| AI on own hardware | Language models, embeddings, rerank and retrieval behind the AI features. The models run locally through our own gateway. | Prompts, retrieved content from the forening, embeddings, logs and answers. | Own hardware. Not a separate subprocessor. An external AI provider must appear here before it processes anything, per clauses 6 and 8. |
| Monitoring and logging on own hardware | Operational monitoring and fault diagnosis. | Technical and interaction logs, which may contain user identifiers and IP addresses. | Own hardware. No third-party service is used for monitoring or error tracking. |
Forwarding feedback from the platform to an external issue tracker is built but not switched on, and is therefore deliberately left out. If it is switched on, the provider becomes a subprocessor, and the appendix is updated and notice given before it is put to use.