Privacy policy

01

Introduction

Komma ApS (CVR no. 46208765), Paul Bergsøes Vej 16, 1. tv, 2600 Glostrup, Denmark, builds the HR system for Nordic companies — all of HR in one place, with the AI assistant Karma built in. This privacy policy explains how we process personal data: which data, why, for how long — and which rights you have.

The policy covers the whole journey: your first visit to our website, a demo request or other enquiry, the customer relationship, everyday use of the platform and the mobile app — and your application if you apply for a job at Komma. Wherever you meet us, you can find yourself in this policy.

The policy is written to be read. Sections 3 to 21 each open with an "In short" box: one to three sentences in plain language that give you the essence before the detail follows. Anything that fits a table — data categories, legal bases, deadlines — is set out in tables, and the full glossary is in Annex A.

The policy applies to kommahr.com, kommahr.dk, the Komma platform and the mobile app. Where your company uses the platform, your company is the data controller for the data in the platform, and the details of our processing are governed by the data processing agreement (DPA) — see sections 5 and 12.

This is version 1.2 of the policy. It takes effect on 31 July 2026. If you have questions at any point, you can always write to hej@kommahr.com — see section 23.

02

Definitions

Data protection has a vocabulary of its own. Here are the ten terms you will meet most often in this policy, explained in plain words — the full glossary is in Annex A.

03

Our privacy philosophy

It is your data. We are just holding it. That sentence is the division of labour at Komma: your company owns and controls the data in the platform — Komma stores and protects it. Everything else in this policy follows from it. We have translated it into five commitments:

• Privacy is a product feature. Field-level access control, an audit log that cannot be edited, and automated retention rules are built into the platform from day one — not add-ons, and not something you have to build yourself. See section 15.
• Data minimisation from the first field. We collect only what a specific purpose requires — our demo form has six fields, and the phone number is optional. Inside the platform, each role sees only the fields it needs.
• A website where you decide. kommahr.com and kommahr.dk set no cookies, load no advertising pixels and have no chat widgets. On your first visit, a pop-up asks whether you want to switch on Statistics and Company recognition — both stay off until you say yes. Without your consent, our server only counts, anonymously, how many times each page is shown. See section 8.
• We never sell data. Not to advertisers, not to data brokers, not as "anonymised insights". Your data is not our business model — the platform is.
• Plain language over legalese. This policy is written for people: sections 3 to 21 each open with an "In short" box, and we cite the relevant GDPR articles so you can check our claims yourself.

These five commitments are not aspirations — they can be verified. Read section 8 on the website, section 14 on AI and section 15 on security, and hold us to them.

04

The GDPR principles in practice

Article 5 of the General Data Protection Regulation (GDPR) sets out seven principles for all processing of personal data. They are the yardstick we work to — here is each principle and what it means in practice at Komma.

05

Our roles: controller and processor

The General Data Protection Regulation (GDPR) distinguishes between two roles. The data controller decides why and how personal data is processed. The data processor processes personal data solely on the controller's behalf and on its instructions.

For Komma, the split is simple. When you approach us yourself — visiting our website, booking a demo, writing to support or applying for a job with us — Komma ApS is the data controller. When your company uses Komma as its HR system, you are the controller of everything you put into the platform: employees, former employees, candidates, contractors and contact persons. Your employees' data belongs to you — not to us. We process it solely on your instructions under the data processing agreement (DPA).

If an employee, candidate or other data subject in a customer's Komma solution wants access to, rectification of or erasure of their data, the request always goes to the employer — as data controller, the employer can and must answer it. If we receive such a request directly, we forward it to the customer without undue delay and never answer it on our own. We assist the customer in fulfilling the request, as the data processing agreement obliges us to (Art. 28). Read more about the platform in section 12 and about your rights in section 19.

06

Categories of personal data

This section sets out which categories of personal data we process in each of our two roles (see section 5). Section 7 links the categories to purposes, legal bases and retention.

6.1 Where Komma is the data controller

Where Komma is the data controller, we collect only what it takes to answer you and run our business:

6.2 Where Komma is the data processor (data in the platform)

When your company uses the platform, you as data controller decide which categories are processed, about whom and for how long. The table shows the categories the platform can hold:

We process special categories of personal data — health information and trade-union membership — solely on the customer's documented instructions and on the customer's legal basis, typically employment-law obligations (Art. 9(2)(b)). CPR numbers are processed only where payroll or statutory purposes require it (section 11 of the Danish Data Protection Act (databeskyttelsesloven)).

Absence reasons enjoy separate protection in the platform: access is restricted in the role model, and API keys can never retrieve them — absence reasons are, together with salary and CPR numbers, excluded from API access at source.

07

Processing activities — overview

The table covers both of our roles. In the "Platform operation" row, Komma is the data processor: there, the customer's legal bases and retention settings apply, and the data processing agreement (DPA) sets the frame. In every other row, Komma is the data controller.

Wherever the legal basis is legitimate interest, we have named the interest in the table and carried out a balancing test weighing it against your interests. You can always object to processing based on legitimate interest (Art. 21) — see section 19.

The detail follows in sections 8–13: website and cookies (section 8), leads and marketing (section 9), demos, webinars and events (section 10), support (section 11), customers and employees in the platform (section 12) and job applicants at Komma (section 13).

08

Website and cookies

The website sets no cookies, loads no advertising pixels and has no chat widgets. The first time you visit kommahr.com or kommahr.dk, a pop-up asks which of three kinds of storage you accept: Necessary, Statistics and Company recognition. Necessary only remembers your choice, so we do not ask again on every page. The other two stay off until you switch them on, and you can change or withdraw your choice at any time with Cookie settings at the bottom of every page.

8.1 What we store in your browser

We store only what you have said yes to, and we use no cookies for any of it. Your choice in the pop-up sits in your browser's localStorage under the key "komma-consent" for 12 months, so we do not ask again on every page. If you have switched on Statistics or Company recognition, we also keep, in your browser's sessionStorage, which page or campaign sent you here ("komma-src"), and for Company recognition a random visit ID ("komma-sid"). Both disappear when you close the tab. The language comes from the address — each language has its own folder, such as /da/ — and is not stored.

8.2 Server logs

The web server automatically records technical logs containing your IP address, the time and the pages you request. We use them solely for security and troubleshooting — for example to detect attacks, abuse and operational faults — based on our legitimate interest in a secure and stable website (Art. 6(1)(f)). Logs are deleted after 90 days at the latest. The website is hosted by Vercel, and our server functions run in the EU (Stockholm) (see section 16).

Besides the logs, our server counts every page it delivers, for every visitor and without asking: one more in that day's totals for the page, the website that sent you here (its name only), any campaign tags in the link and your country and region (for example Region Midtjylland), both from the network's location. No IP address, no browser details and no ID are kept, and nothing is read from or stored on your device. Requests that look automated are counted separately. The daily totals are deleted after 120 days.

8.3 Statistics and company recognition — only with your consent

If you switch on Statistics, each page loads Vercel Web Analytics from the website's own address. It counts page views, referrer, country, browser and device type, shows us only totals, sets no cookies and follows you neither across other sites nor from one day to the next.

If you switch on Company recognition, we try to work out which company — never which person — a visit comes from. Your IP address is looked up in a copy of IPinfo's database that sits in our own server function in the EU (Stockholm), and in public DNS and in a copy of RIPE NCC's public register of who IP addresses are assigned to, which also sits in our own server function. Then the IP address is discarded; we never store it, not even as a hash. If the network belongs to a company, we keep the company's name, the pages viewed, the time spent on them, where the visit came from and the country in our database at Upstash (Frankfurt) for 90 days. The same facts may become a note or a lead in our CRM, Pipedrive, and our sales team may get a message about the visit in Microsoft Teams. For Danish companies we look up size and industry in the CVR register via cvrapi.dk — by the company's name only.

A visit from a home or mobile connection is only counted, never named. If the connection has its own domain in DNS, we count only that domain per day, for 30 days, to measure how well the lookup works.

With this consent we also count the approximate city the network is in (for example Aarhus; on mobile networks often the operator's city). For visits we cannot tie to a company, we also count per region — never per city — whether the pricing, demo or contact page was viewed. Both are kept only as daily totals without an IP address or ID and are deleted after 90 days.

The server logs and the anonymous page count rest on our legitimate interest (Art. 6(1)(f)) in a secure, stable website and in knowing which pages are used. Statistics and any storage in your browser beyond your choice rest on your consent (Art. 6(1)(a)), which you can withdraw at any time. Following up on company visits rests on our legitimate interest in knowing which companies are looking at Komma (Art. 6(1)(f)). We have carried out the required balancing test against your interests, and you can always object (Art. 21) — see section 19.

8.4 Our promise

If we add new services that store anything in your browser or send information about your visit, they go behind the consent pop-up, and this section is updated before anything at all is placed in your browser (see section 22 on changes to this policy).

09

Leads and marketing

Komma is B2B: our marketing is aimed at companies, but it is always people who fill in the forms. Here is exactly what we collect, why we are allowed to, and what we never do.

9.1 What we collect

The website has two forms. We collect only what the fields show, plus which form you used, the page you sent it from and the page's language. There is no hidden enrichment behind them: company recognition happens only if you have said yes to it in the pop-up or in the form (see section 8.3). We record your role or title only where it appears in your enquiry — for example in your email signature.

9.2 Legal bases

Where we rely on legitimate interest, we have carried out the required weighing of our interest against your rights (the balancing test). You can object to the processing at any time (Art. 21) — and we stop. Read more about your rights in section 19.

9.3 Marketing we do not do

The easiest way is to list what does not happen when you contact us:

• No nurture flows — booking a demo does not trigger an email sequence.
• No autoresponder campaigns — the next thing you hear from us is a human who has read your message.
• No newsletter — we do not have one today, so there is nothing you need to remember to unsubscribe from.
• No selling on — we never sell or share your contact details with anyone for marketing.

9.4 Retention

If your company does not become a customer, we delete your enquiry and contact details 12 months after our last active contact. If you do become a customer, the details move into customer master data and follow the customer relationship (see section 18).

9.5 If we ever launch a newsletter

If we ever launch a newsletter, it will run on consent alone (Art. 6(1)(a)): we only write to you if you have actively signed up, no existing contacts are moved across automatically, and you can withdraw your consent as easily as you gave it — one click in every email.

10

Demos, webinars and events

We would rather show you Komma than talk about it. Here is how we handle personal data when you meet us at a demo, in a trial environment or — one day — at a webinar.

10.1 Demos

A demo is a scheduled session where we show you the platform — and afterwards a human follows up with a personal reply to what you asked about. You are not enrolled in anything automatically — no lists, no flows, no campaigns. We process the booking details as described in section 9, and they are deleted under the same rules.

10.2 Trial environments

If we set up a trial environment for you, one simple rule applies: the data in the trial is yours. We process it solely to provide the environment (Art. 6(1)(b)) and use it neither for development, statistics nor marketing. If you become a customer, processing continues under the data processing agreement as part of the customer relationship (see section 12). If the trial expires without an agreement, we delete the trial environment and all data in it no later than 30 days after expiry — and backups are fully purged within a maximum of 90 days, exactly as when a customer relationship ends (see section 18).

10.3 Webinars and events

We do not run webinars today. If we ever do — or host events with registration — we use your registration details for that specific event only: practical information before, during and just after. You are never added to marketing lists without separate, active consent (Art. 6(1)(a)).

11

Support

Good support needs surprisingly little personal data. Here is what we process when you write to us — and what we ask you not to send.

11.1 What we process

Support is reserved for customers using the Komma platform and runs through support@kommahr.com. Enquiries from anyone else are answered at hej@kommahr.com. When you write to us, we process your name, your work contact details and the content of your enquiry — nothing more, nothing less. For customers, support is part of our contract with you (Art. 6(1)(b)). If you write to us without being a customer, we reply based on our legitimate interest in answering enquiries about our product (Art. 6(1)(f)); you can object under Art. 21 (see section 19).

11.2 Do not send employees' personal data

We ask one thing of you: do not paste employees' personal data into support enquiries. Describe the problem instead — for example with an employee ID or a screenshot without personal data. CPR numbers, payroll details and absence reasons belong in the platform, not in an email. If we receive such data anyway, we delete it when the case is closed.

11.3 Access to your data in the platform

Some cases can only be resolved by a member of our support team looking at your data in the platform. That happens solely when it is necessary to resolve the specific case. The access is scoped by the platform's role model and is always recorded in the uneditable audit log — so you can see for yourselves who saw what, and when.

11.4 Retention

12

Customers and employees in the platform

This section is for you as a Komma customer — and for you as an employee, candidate or contact person at a company that uses the platform. It describes the division of roles and the data processing agreement (section 12.1), what the platform holds and how it cleans up on its own (section 12.2), and how employee access is controlled and logged (section 12.3).

12.1 Roles and the data processing agreement

When your company uses the platform, you are the data controller for every piece of personal data you put into it. You decide the purposes, choose the retention settings and give the instructions. Komma ApS is your data processor and processes the data only within that framework (Art. 28).

The foundation is our data processing agreement (DPA), a standing part of every customer agreement. Among other things, it commits us to the following:

If an employee, candidate or any other data subject contacts us directly about data in your platform, we forward the request to you and never answer it on our own. You, as the controller, respond — we supply the assistance and the tools.

12.2 What the platform holds — and when it deletes on its own

Section 6.2 describes the categories of personal data the platform is built to hold — from employee master data and payroll data to absence, recruitment and feedback. You decide which categories you use and how long they are kept. Deletion is a built-in feature, not a manual chore — the platform ships with these automatic defaults:

The defaults reflect Danish practice and statutory retention requirements, but the retention settings are yours: you can adapt them to your own deletion deadlines — within the limits of the law.

12.3 Employees in the platform

Employees are the people who log in to your platform — the HR team, managers and employees. Access is built on a simple principle: every employee sees only what their role requires.

• Login with Microsoft Entra ID (SSO) with automatic provisioning and deprovisioning: when an employee leaves the company, access is closed automatically.
• Role-based access control down to field level, scoped by department, location and legal entity.
• Uneditable audit log: every read, change and export is recorded in an audit log that cannot be edited.
• Anonymity thresholds in pulse surveys: answers are shown only in groups large enough that no one can be identified.

If you are an employee with access to a customer's platform, your employer is the data controller for your data. To exercise your rights, contact your employer — see section 19.

13

Job applicants at Komma

If you apply for a position at Komma — by email or through a job posting — we process your application, your CV, your contact details and our notes from the interviews. We take up references only after agreeing it with you.

There is no automation in our recruitment: every application is read by a person, and every decision along the way is made by people (see section 21).

If you have questions about your application or your data, write to hej@kommahr.com. Your rights are described in section 19.

14

AI and responsible AI

AI is not an add-on in Komma — it is part of the platform. That is exactly why we owe you a precise answer to three questions: What does Karma do? What does it not do? And who decides? This section answers all three.

14.1 What Karma is

Karma is the built-in AI assistant across the platform's modules. When Karma works, it processes the personal data already in your platform — as your data processor and only on your instructions (see section 5). Here is the honest list of what Karma does:

• answers questions on live HR data — for example "How many holiday days does the team have left this year?"
• drafts changes to fields and master data, which an employee then approves or rejects
• parses CVs into skill scores from 0 to 5 that can be explained axis by axis
• drafts job adverts
• matches candidates to roles using a transparent weighted formula — the weights are visible, not hidden away
• flags absence patterns so a manager can start the conversation in good time
• explains pay lines in plain language
• summarises evaluations and feedback processes
• suggests learning paths and shift coverage

14.2 Our eight commitments

Every AI feature in Komma is built on one principle: "Karma drafts. A person decides." That principle unfolds into eight commitments, and they apply to every single AI feature in the platform:

1. Nothing is written to the system until a person approves it.
2. No automated decisions about people — and this cannot be switched on.
3. One customer's data never trains models used for other customers, and prompts are not used to train the underlying foundation models.
4. Karma inherits the platform's role model and can never show an employee data their role could not see itself.
5. Scores are explainable: weighted and axis by axis — never a number from a black box.
6. Every AI suggestion lands in the uneditable audit log.
7. You can switch AI off.
8. Karma marks what it has inferred and says so when it is unsure.

14.3 Where we stop

Responsible AI is just as much about what you choose not to build. We have deliberately left out the following:

• individual productivity scoring of employees
• sentiment analysis of free text in reviews and pulse surveys
• automatic rejection of applicants
• flight-risk scores that single out named employees as likely to resign

These features do not exist in the product, and they cannot be enabled — not through a setting, not for a fee and not on request.

14.4 The technology behind Karma

Karma runs on EU infrastructure and under the same security rules as the rest of the platform:

• EU processing: The AI models behind Karma run on Azure OpenAI Service in Microsoft's Sweden Central region (EU) — your data does not leave the EU to be processed by AI.
• No training: Prompts and outputs are never used to train the underlying foundation models or models for other customers. Processing is transient — what is stored is the suggestion in the audit log.
• Inherited access control: Karma inherits the platform's role-based access control down to field level. A question to Karma can never become a back door to data.
• Full traceability: Every suggestion is recorded in the uneditable audit log (see section 15).
• Your control: You switch AI on and off — the decision sits with you.

And the legal position: no decision with legal or similarly significant effect for a person is made solely by automated means in Komma (Art. 22). Karma provides decision support — people decide. Read more about automated decision-making and profiling in section 21.

15

Information security

An HR system holds some of the most confidential information a company has: pay, absence, health documentation and CPR numbers. That is why security is not a feature in Komma — it is a precondition. We protect your data with technical and organisational measures (Art. 32), and these are the most important:

• Technology and infrastructure
  • All traffic is encrypted in transit (TLS 1.2 or newer), and all data is encrypted at rest.
  • The platform runs on Microsoft Azure in the Sweden Central region (EU) — see also section 17 on international transfers.
  • Secrets such as keys and certificates are stored in Azure Key Vault, and system components authenticate with managed identities — no shared passwords.
  • Backups are encrypted, located in the EU and deleted on a rolling window of no more than 35 days.
• Access and traceability
  • Role-based access control down to field level determines who sees what — a manager can see that an employee is absent, for example, without seeing the reason.
  • Every read, change and export is recorded in an audit log that cannot be edited.
  • Telemetry and error data are scrubbed of personal data before they are logged.
  • Pulse survey answers are only shown in groups large enough to prevent identification of individuals.
• People and process
  • Security is part of our development work from design to release.
  • Every Komma employee has signed a confidentiality declaration and is introduced to our security requirements.
  • We assess a supplier's security before we start using them (see section 16).

Our security programme is structured around recognised frameworks: the requirements of Art. 32 of the GDPR and the principles of ISO 27001. Komma is in the process of becoming ISO 27001 certified. We will only write "certified" the day an independent party has said so.

The full catalogue of our technical and organisational measures (TOMs) is in Annex C.

16

Processors and sub-processors

Our two roles (see section 5) matter here. Where we are the data controller — the website, leads, support and our own administration — the suppliers we use are our data processors. Where we are the data processor for the data you put into the platform, those same kinds of suppliers are sub-processors. The requirements are identical in both cases.

16.1 How we vet our processors

No supplier processes personal data on our behalf until four things are in place:

• A data processing agreement. We sign a DPA that meets the requirements of Art. 28(3) — documented instructions, confidentiality, security, rules for further sub-processors and deletion when the engagement ends.
• Due diligence. We review the supplier's security documentation, hosting locations and GDPR compliance before we sign.
• EU first. We choose suppliers that process personal data in the EU/EEA. Anything else is the exception and requires a valid transfer mechanism (see section 17).
• Security at our own standard. Encryption, access control and logging at the level we require of ourselves (see Annex C).

16.2 Who we use today

The platform runs on Microsoft Azure in the Sweden Central region, and Azure OpenAI Service — in the same EU region — provides the AI models behind Karma. Microsoft is therefore our central sub-processor: infrastructure, database, storage, backup and AI. Prompts and outputs are not used to train the underlying AI models (see section 14), and should Microsoft ever, by way of exception, need support access from a third country, the framework in section 17 applies.

In our own operations, Vercel hosts the website (kommahr.com and kommahr.dk); our server functions run in the EU (Stockholm), and the pages are delivered from Vercel's network close to you. Upstash stores company visits and consent records in the EU (Frankfurt). For our sales work we use Pipedrive as our CRM — leads and customer contacts are processed in the EU — and our sales team receives messages about company visits in Microsoft Teams. The fonts and every script are served from the website's own domain, so your browser sends nothing to third parties.

The authoritative, always-current list of our sub-processors is Annex D together with the live list referenced in the data processing agreement.

16.3 Changes with at least 30 days' notice

We never add or replace a sub-processor quietly. You receive at least 30 days' notice before a new sub-processor processes your data, and you can object under the procedure set out in the DPA.

16.4 Payroll engines are your choice — not our sub-processors

If you connect Komma to your payroll engine — Zenegy, Danløn, Dataløn, Visma, Lessor or Intect — you choose the integration and it runs on your instruction. The payroll provider is your own data processor or an independent data controller, not a Komma sub-processor. We transmit only the data your configuration tells us to, and the contractual relationship with the payroll provider is yours.

17

International transfers

This section explains where your personal data is physically processed, and what has to be in place before a transfer to a country outside the EU/EEA — a third country — could even come into question.

17.1 The default: everything stays in the EU/EEA

Personal data in Komma is stored and processed in the EU/EEA. The platform — database, files, backups and the AI processing behind Karma — runs in Microsoft Azure's Sweden Central region in Sweden, and the website's server functions run in the EU (Stockholm) (see section 16). We do not transfer your data to third countries as part of the normal operation of the platform; the website's data flows are described in section 17.3.

17.2 If a transfer becomes necessary

If a transfer to a third country ever becomes necessary — for example because a sub-processor provides support from outside the EU/EEA — it takes place only with a valid transfer mechanism under Chapter V of the GDPR (Art. 44–49):

• an adequacy decision by the European Commission (Art. 45) — for US recipients this includes companies certified under the EU–US Data Privacy Framework (DPF) — or
• Standard Contractual Clauses (SCCs) (Art. 46(2)(c)), supplemented with additional measures where a case-by-case assessment shows they are needed, or
• the specific derogations in Art. 49, such as your explicit consent, in individual cases.

For data in the platform, one further rule applies: any such change goes through the sub-processor notice process in section 16 — at least 30 days' notice and a right to object — before it takes effect.

17.3 The website's third-country data flows

The website has three data flows that may leave the EU/EEA. Vercel Inc. (USA) hosts the website and provides Statistics once you have switched it on; our server functions run in the EU (Stockholm), but Vercel is a US company. Microsoft (USA) delivers the Teams messages our sales team receives about company visits. Both transfers rest on the European Commission's adequacy decision for the EU–US Data Privacy Framework, under which Vercel Inc. and Microsoft Corporation are certified. Finally, the reverse DNS lookup used for Company recognition, which contains the IP address, goes through our hosting provider's DNS service to whoever runs the network's DNS, and that may be outside the EU/EEA. Google Fonts is no longer used — the fonts are served from our own domain.

18

Retention and deletion

We keep personal data for as long as the purpose requires, and no longer (Art. 5(1)(e)). For us, that always means a concrete period or a named criterion for every category — never an open end.

• Automated wherever possible. The platform has built-in retention settings, so deletion happens automatically — not because someone remembers to do it.
• Backups roll off within 35 days. Our encrypted backups follow a rolling window of at most 35 days, so deleted data disappears from backups as the window rolls.
• Deletion covers production and backups. When a customer relationship ends, you can export your data at any time until deletion is carried out. We delete from production within 30 days of your instruction, and everything — backups included — is deleted no later than 90 days after termination (per the DPA).
• You control retention in the platform. How long data stays in Komma is governed by the retention settings you choose (see section 12).

The complete retention schedule — every category, every period and its anchor — is in Annex B. And one rule ties it all together: we never keep personal data just in case.

19

Your rights

Where Komma is the data controller (see section 5), you have the following rights under the General Data Protection Regulation (GDPR). The table shows what each right means and how to use it.

19.1 The practicalities

• Write to hej@kommahr.com. No special form is needed — an ordinary email is enough.
• We respond within 1 month. For complex requests the deadline can be extended by up to 2 further months — but in that case you hear from us within the first month, with an explanation (Art. 12(3)).
• It is free of charge. We never charge a fee for exercising your rights.
• We verify your identity proportionately. We only ask for what is necessary to make sure the data reaches the right person — usually, writing from an email address we already know is enough.

19.2 If your data lives in your employer's Komma platform

If your employer — or a company you have applied to — uses Komma, that company, not Komma, is the data controller for your data in the platform (see section 5). So contact the company directly, typically HR, when you want to exercise your rights. We help the company respond quickly and correctly under the data processing agreement (DPA), but we never answer requests about customer data on our own. If your request reaches us by mistake, we refer you to the company and explain why.

20

Personal data breaches

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss or alteration of personal data — or to someone gaining unauthorised access to it. In practice, that could be an email sent to the wrong recipient, a lost laptop or unauthorised access to a database.

Our internal response follows four fixed steps:

1. Contain: we stop the breach and secure the systems so the damage does not spread.
2. Assess: we map which data and which people are affected, and what risk the breach poses to them.
3. Document: we record the breach, its consequences and our handling in our internal breach register.
4. Learn: we fix the root cause and adjust procedures and technical measures so it does not happen again.

Who we notify depends on our role (see section 5):

We document every personal data breach internally — including those that trigger no notification duty (Art. 33(5)). That gives us the overview, the lessons learned and the documentation to show Datatilsynet.

21

Automated decisions and profiling

Under the GDPR you have the right not to be subject to a decision based solely on automated processing which has legal or similarly significant effect (Art. 22). At Komma this is not a risk we manage around — it is a feature we have deliberately chosen not to build: the platform makes no such decisions, and it cannot be configured to. Not by us, and not by our customers.

A few features may resemble profiling — such as candidate matching in Recruitment and absence-pattern flags in Workforce. They are decision support, not decisions:

• Explainable scores: every score is weighted and broken down axis by axis — never a black-box number.
• A human decides: Karma suggests; no suggestion takes effect until a person with the right role actively approves it.
• Everything is logged: every AI suggestion is recorded in the audit log, which cannot be edited — so the basis for a decision can always be reviewed.

Read more about how Karma works — and what we have deliberately chosen not to build — in section 14.

22

Changes to this policy

The current version of this policy is always available at kommahr.com. The version history at the front of this document shows what changed, and when.

We announce material changes on our website. Changes that affect the platform — such as new sub-processors or changed processing — are additionally notified to our customers in advance, before they take effect.

We review this policy at least once a year and update it whenever the product, the law or our practices change.

23

Contact and complaints

If you have questions about this policy or about how we process your personal data, you are always welcome to write to us.

We answer all privacy enquiries ourselves. There is no call centre and no ticket queue — your email is read and answered by a person at Komma.

Komma has not appointed a data protection officer (DPO) — we are not required to under Art. 37 of the GDPR. We have instead designated an internal data protection lead, and every data protection question is answered by us directly via hej@kommahr.com.

You can always complain about our processing of your personal data to the Danish Data Protection Agency (Datatilsynet) (Art. 77). We appreciate the chance to put things right first — do write to us — but you never need our permission to complain.

Annex A

Glossary

This glossary explains the terms used in this policy in plain language. The short version is in section 2 — this is the full one.

Annex B

Retention schedule

This schedule collects every retention period in the policy in one place — with the role, period and basis for each category. How deletion works in practice is described in section 18. The last three rows are the platform's automatic deletion defaults; there, the customer is the data controller and sets retention in the platform's settings.

Annex C

Technical and organisational measures

This annex describes the technical and organisational measures (Art. 32) that protect personal data in the platform — across all 11 modules and Karma — and in Komma's own operations.

Our security programme is structured around recognised frameworks — the principles of ISO 27001 and the requirements of Art. 32 — and Komma is in the process of becoming ISO 27001 certified. We review the measures at least once a year and update them as technology and the threat landscape evolve.

C.1 Confidentiality and access control

• Role-based access control down to field level, scoped by department, location and legal entity. Sensitive fields such as salary and absence reasons are visible only to roles with a work-related need.
• Single sign-on via Microsoft Entra ID with automatic provisioning and deprovisioning — when an employee leaves the customer, access closes automatically.
• The principle of least privilege: no role has more access than the task requires.
• Secrets — keys, certificates and connection strings — are stored in Azure Key Vault and accessed via managed identities, never in code.
• Telemetry and operational logs are scrubbed of personal data before they are stored.
• Every Komma employee has signed a confidentiality declaration.

C.2 Integrity

• Encryption in transit with TLS 1.2 or higher and encryption at rest across both database and storage.
• An uneditable audit log records every read, change and export — including Karma's suggestions.
• API keys are role-scoped with a per-key scope, rate limit and expiry — and salary, CPR numbers and absence reasons are excluded at source.
• Secure development: changes are tested and reviewed before they reach production.

C.3 Availability and resilience

• The platform runs on Microsoft Azure in the EU (Sweden Central region) on redundant infrastructure.
• Encrypted backups in the EU with a rolling window of a maximum of 35 days.
• Soft-delete and versioning in storage protect against accidental deletion and overwriting.

C.4 Restorability

• Documented procedures for restoring data and system access after a technical or physical incident.
• Restore procedures are documented, and restore testing forms part of our security programme — we do not count an untested backup as a backup.
• Soft-delete and versioning make it possible to restore individual data quickly without a full restore.

C.5 Testing and evaluation

• Vulnerability assessment of the platform and infrastructure forms a standing part of the security programme.
• Access reviews: roles and permissions are checked and tightened when needs change.
• Annual review of the security policies and of the measures in this annex.

C.6 Organisational measures

• Ongoing training of all employees in data protection and information security.
• A defined internal process for security incidents and personal data breaches — see section 20.
• Due diligence on suppliers before onboarding and continuous follow-up — see Annex D.
• Data-minimising defaults in the product, such as automatic deletion of applicants after 6 months and anonymisation of former employees after 5 years (see Annex B).

Annex D

Processors and sub-processors

We deliberately keep our supplier list short. This annex shows all of them, split by our two roles — see sections 5 and 16.

D.1 Komma as data controller

Suppliers that process personal data in Komma's own operations — website, enquiries, support and administration.

IPinfo and cvrapi.dk are not processors. The same applies to RIPE NCC: we use a copy of its public register, so no IP address is sent to RIPE. Company recognition uses a copy of IPinfo's database inside our own server function, so no IP address is sent to IPinfo (IP data by IPinfo, licensed under CC BY-SA 4.0). cvrapi.dk is a public lookup service in Denmark that receives only the company's name.

D.2 Komma as data processor (the platform)

Sub-processors involved in delivering the platform. The list is short by design.

The payroll integrations (Zenegy, Danløn, Dataløn, Visma, Lessor and Intect) are not Komma sub-processors. They run solely on your instructions and are your own processors or independent controllers — see section 16.

We give at least 30 days' notice of changes to the sub-processor list, with a right to object, as set out in the data processing agreement (DPA). The current list is always available via the DPA and at kommahr.com.