ProAuditMap and co-determination.
What the software records, what it does not, and what works councils can check.
-
No performance evaluation
ProAuditMap does not evaluate the work of individual auditors. There is no ranking and no evaluation by person. If an evaluation per person is offered in future, it is switched off and can only be activated by a setting in the company’s account.
-
Roles
Access works through roles: auditors work on audits, quality assurance reviews, the head of audit designates an audit lead per audit, closes audits and sees the full log. The administration manages members and retention and does not see assigned persons in the log. Audited units work only in their own portal.
-
Logging
Changes to audits, approvals and exports are recorded in a tamper-evident log. It names the acting person and is meant for traceability. This is one more reason to agree on rules with the works council.
-
Deletion periods
Archived audits are proposed for deletion after the configured retention period, at least 6 years; the administration confirms the deletion.
-
Tasks and reminders
Anyone who assigns tasks with due dates and escalates overdue items is using a system that is suited to monitoring. We therefore say openly which data are created, who sees what and how long everything is stored, and provide a draft wording for purpose limitation. The head of audit sees only figures per audit, from two persons. Escalations can be limited to the audit lead or switched off entirely.
-
Planning and dashboards
Key figures, annual plan and board report count audits, not people. A field appears only from three audits, and with fewer than three auditors or quality assurance staff, management and board receive no figures on effort and lead time. The leadership view names audits only by number and closings only as a quarter. The software shows the key figure on effort per audit only if the head of audit deliberately switches it on after a notice on co-determination, and never to management or board. We also say openly where these rules reach their limits.
Storage and processing
Storage on servers in Germany, backups in Finland (EU); the sub-processors used and transfers to third countries are named in the DPA.
Co-determination
Technical systems suited to monitoring the behaviour or performance of employees are subject to co-determination under section 87(1) no. 6 of the German Works Constitution Act (BetrVG). Whether this applies to your use is for you and your works council to assess.
For questions about shaping a works agreement, please get in touch.
Works agreement template (Word, in German)
Privacy notice template for audit planning (Word, in German)
The template is available in German only. It is a sample without warranty; please have it reviewed legally before use.
Tasks and reminders
What the function does
The head of audit designates an audit lead for each audit. The audit lead or the head of audit assigns audit program lines to individual persons and can set a due date for them. Reviews are also assigned by the audit lead or the head of audit; whoever is responsible for a line or a finding can assign a review of exactly this item to another person. Milestones of an audit can also be scheduled, for example the end of fieldwork or the draft report. Each person sees under “My tasks” what is assigned to them. If a due date is set, they receive at most one digest e-mail a day per customer account: before the due date, on the due date and, if the task is overdue, a notice that it is overdue. Tasks without a due date generate no e-mail.
Which data about persons are created
| Data | Content | How long |
|---|---|---|
| Audit lead | Audit, person, who designated them and when, end and reason for the end | as long as active; it ends when the audit is closed or archived, and is then deleted 90 days after the last status change of the audit, in any case no later than 12 months after it ended, even if the audit is never closed |
| Assignment of an audit program line | Line, person, due date (optional), who assigned it and when, end and reason for the end | as above |
| Assignment of a review | Working paper or finding, person, due date (optional), who assigned it and when, end and reason | as above |
| Milestone | Type of milestone, due date, responsible person (empty means: the audit lead), when and by whom completed | as above, once the milestone is completed or ended |
| Reminder marks | one entry with time per task, stage (in advance, due, overdue) and recipient; if the digest e-mail is unsubscribed, an entry “skipped” | 180 days after creation, once the task is completed, no longer applies or has ended; as long as it is open, the mark remains |
| Digest e-mail note | Recipient and day of a digest e-mail | 180 days after creation, once no reminder mark refers to it any more |
| Notification preference | Digest e-mail unsubscribed yes or no, whether via the application or the link in the e-mail, time | as long as the person is a member of the customer account. On removal from the customer account the preference is reset, a later new invitation does not take it over; the daily run deletes entries of persons without membership |
| Unsubscription record | Customer account, person, identifier of the key used, time; no e-mail address | 12 months after creation (daily run of the platform), at the latest with the account or the customer account |
| Notices of assignments | one entry per new assignment or due date change: audit, person, type and identifier of the assignment, whether due date change, time, reference to the e-mail sent | 180 days after creation, once the e-mail has been sent, earlier if the assignment is deleted; notices not sent after 30 days; without membership of the person immediately in the next daily run; with the deletion run of the audit |
| Outbox | E-mail address, type of message, reference to the digest e-mail, time; no content from audits (the text is only created at the time of sending) | 30 days after creation, once the e-mail has been sent or has finally failed |
| Log (hash chain) | who assigned which task to whom and when (with line or item), when and why it ended, who became audit lead, creation, completion and end of milestones, changes to the settings, unsubscribing and re-subscribing. Due dates are not in the log, not even for milestones, and neither is the responsible person of a milestone. A due date change only appears there as “reassigned”. Whoever manually marks a milestone as completed is recorded as the acting person | permanently, like the entire log |
Ended assignments, the audit lead and completed or ended milestones therefore remain for at most 12 months after they ended, regardless of the status of the audit. At the latest, the deletion run that removes the audit itself deletes all data of an audit; the log is excepted. The daily clean-up run also runs for customer accounts in read-only state.
What can be reconstructed from this
We say this openly: from the log it can be traced permanently who was assigned which task and when, who assigned it and when the assignment ended. As long as the assignments are stored, that is until 90 days after the audit is closed, but no longer than 12 months after they ended, the due dates per person and every due date change can also be seen. As long as the reminder marks exist, it can be seen who received a reminder or an overdue notice for which task. Together with the timestamps of the working papers, one could calculate for this period whether a person completed their tasks before or after the due date. The software does not calculate this and does not display it. It would only be possible by manually compiling information from the log and the audit or with direct access to the database, which only the provider has for operation. We therefore propose a purpose limitation in the works agreement.
Who sees what
| Who | sees | does not see |
|---|---|---|
| every person | their own tasks with due date, effective due date and status; their own notification settings | tasks of other persons in “My tasks” |
| Auditors, quality assurance, head of audit in an audit | per line, review and milestone the responsible person and the due date of the active assignment, just as author and reviewer already today | “overdue since”, earlier assignments |
| everyone who may assign tasks (auditors, head of audit) | in the person selection the display name and role of all signed-in members with the role auditor or head of audit; only as long as the function is enabled | e-mail addresses, figures or tasks per person |
| Audit lead, only for their own audit | a team view with open and overdue tasks of this audit so that they can redistribute work; the names of the responsible persons only if they switch them on for this audit (default off); measures from findings are not included | totals per person, rankings, other audits, ended assignments |
| Head of audit, overview of all audits | per audit only figures: open, due in 7 days, overdue, milestones overdue | any information on persons; filter by person. If fewer than two different persons are affected in an audit, the overview shows no figures but “fewer than 2 persons”. Only persons with assigned lines or reviews are counted; the person calling up the overview and recipients of milestone reminders are not counted |
| Administration | only their own tasks | responsible persons and due dates in audits; the person selection |
| Head of audit in the log | the log entries according to the table above in full | due dates |
| Administration in the log | that an assignment, an audit lead or a milestone was created or ended, who did this and when | the assigned person, the line, the line hash of these entries; unsubscribing and re-subscribing of other persons (neither person nor search filter) |
| audited units | nothing from this section | all information in this section |
The minimum of two persons prevents simple inferences about an individual, but not every one: with exactly two persons and prior knowledge of the distribution, an inference remains possible. The head of audit also sees the responsible persons in each audit because they work on it. The software does not offer an analysis per person across several audits; a test in the code prevents the overview from getting a column relating to persons.
Exports
The archive export of an audit (head of audit only) contains the log entries of the assignments with line, acting person and time, but without the assigned person. Because these entries are exported with their hash values so that the chain remains verifiable, the assigned person can be recalculated with effort by trial and error. Whoever may trigger the archive export sees the same information in the log anyway; this residual risk remains stated. The quality evidence package contains no content of assignment entries and notification preferences. For readers without the task right (administration role without an additional functional role), it also contains no hash value of these entries and no hash value pointing to them: the entry itself appears without its line hash and without the hash value of the previous entry, the directly following entry without the hash value of its previous entry. For these readers there is therefore no recalculation of the assigned person from the evidence package. With the task right (head of audit, auditor, QA) the evidence package remains as before. The affected sections cannot be verified offline (data protection): the evidence package marks them in chain/rows.tsv, the verification script reports them as a notice and then ends with exit code 2, never with 0; if a hash value is missing without this marking, it reports an error. If such an entry lies in a section of the chain after the audit’s own entries, these earlier own entries can no longer be recalculated offline up to the anchor; the evidence package lists them separately. A remainder remains: the daily anchor states the hash value of the last chain entry of the day. If that happens to be an assignment entry, its hash value is in the anchor, which belongs to the evidence package; the head of a segment is therefore never redacted. Further residual risk: time (to the microsecond), acting person and a small number of possible persons allow a comparison where the persons are known; in addition, the marking of the following entry shows that an assignment or unsubscription entry precedes it, and the structure of the following entry remains visible.
Reminders and escalation
| Stage | Time (default) | to |
|---|---|---|
| in advance | 3 days before the effective due date, adjustable 0 to 30 | responsible person |
| due | on the effective due date | responsible person |
| overdue | 3 days after the effective due date, adjustable 1 to 60 | responsible person and, depending on the setting: the audit lead (default), all persons with the role head of audit, or no one else |
The effective due date is the set due date, but no earlier than the day on which the task can be worked on, plus the lead time. Anyone who receives a task only shortly before or after the due date is therefore not immediately reported as overdue. With the setting “audit lead”, the escalation goes to all active persons with the role head of audit if no audit lead is designated or the audit lead is responsible themselves. If a milestone has no responsible person, the same chain already applies to the reminder: it goes to the audit lead, without an audit lead to all persons with the role head of audit. An escalation only goes to persons who, at the time of sending, are still head of audit or active audit lead of this audit. Escalations state the type of task and the audit number, not the responsible person and not the line; the recipient only sees who is responsible in the application.
Settings of the customer account
Reminders fully on or off. Lead time and days until escalation. Recipient of the escalation: audit lead, head of audit or no one. Titles in e-mails (default off; switching on only after confirming a risk notice). Reply address. Tasks can also be assigned without a due date; then there are no e-mails. The audit lead switches the names of the responsible persons in their team view on or off per audit (default off, also for existing audits; every change is recorded in the log). For new and existing customer accounts, reminders are initially switched off until the head of audit deliberately switches them on. Every change to the settings is recorded with the new values in the log.
What each person can set themselves
The daily digest e-mail can be unsubscribed on the “My tasks” page or via the link in the e-mail. The customer account cannot block this. Unsubscribing takes effect immediately and comprehensively: also for e-mails already prepared but not yet sent, and also for reminders of measures from findings. Notices of overdue tasks continue after unsubscribing, because otherwise a deadline could pass unnoticed; e-mails that only contain such notices have no unsubscribe link but a sentence explaining this.
What the e-mails contain
The sender is ProAuditMap’s own mailbox (noreply@proauditmap.com, e-mail service of Hostinger), display name “ProAuditMap · name of the customer account”. Sent once a day from 06:00; if the platform’s daily budget is tight, the digest e-mail may be delayed because sign-in e-mails take priority. The subject states the number of tasks and of overdue tasks. Per entry: type of task, audit number, for the person’s own task the line or finding number, due date and a link; at most 25 entries, the rest as a note “and more”. Line numbers only appear if they look like an identifier, milestones only with their type. No texts, no names of other persons. Titles are only in the e-mail if the customer account has switched them on, then shortened; an escalation to third parties (also for measures and risk acceptances) even then states neither the audit title nor the finding title and no line, only the type of task and the audit number. The link contains no access key; only those who sign in with password and one-time code see the content. E-mail on assignment: Anyone who is assigned an audit program line, a review or, as the responsible person, a milestone receives a separate e-mail promptly, usually within 15 minutes, later when e-mail volume is high (a bulk assignment of several lines results in one e-mail with all lines; further assignments to the same person within one hour arrive bundled in one e-mail). Content as an entry of the digest e-mail: type, audit number, line or finding number, due date if one is set, and link; titles only with the display of titles switched on. No e-mail for self-assignment, with reminders switched off, after unsubscribing and to persons who have never signed in; per customer account at most 20 percent of the platform’s daily e-mail budget as assignment e-mails, beyond that they follow on the next day; if the due date changes (or is removed), a new e-mail arrives with the note “due date changed”. The e-mail carries the same unsubscribe link. The due date is still not recorded in the log.
What the function is not for
The function serves to organise ongoing audits. It is not built or intended to evaluate the performance or behaviour of individual employees. There are no figures per person, no ranking, no export per person and no list of late completions. The audit archive contains no due dates per person; the assignments appear in it only as log entries without the assigned person (see “Exports”).
Planning and dashboards
What the function does
The head of audit maintains an inventory of audit objects, for example applications, service providers, processes or organisational units, by hand or from a file. Each object is rated under an adjustable risk model. From this the software proposes an annual plan. The head of audit edits it, submits it to the responsible board and records the board’s resolution. Key figures show how far the plan has been fulfilled, which objects are overdue and how many findings are open. A board report summarises this for a period as PDF and Excel. Members of executive management or of a supervisory body can get their own read-only leadership view.
Seven rules the software always follows
They apply to key figures, the leadership view and the board report.
1. No evaluation by person. No key figure, no board report and no function of the leadership view aggregates data by person or filters by person. An automated test in the code rejects any query that groups or filters by a person identifier.
2. The annual plan names no persons. Plan items have a quarter and months, but no responsible person. Capacity is a sum of auditor days without reference to individuals. For titles of plan items and names of capacity lines, the interface asks users not to enter personal names. For every saved processing step, exports contain the identifier of the acting account (for example created, assessed, linked, submitted, withdrawn, resolved, acknowledged, actual effort recorded), the plan export additionally in the audit trail. They contain no names or e-mail addresses from the user administration; free text that was typed in can contain names. Anyone who knows the customer’s user list can assign the identifiers.
3. Effort per audit only by switch. Planned and actual effort per individual audit (key figure K9) is switched off. Only the head of audit can switch it on, and only after confirming a notice on co-determination. Switching it on and off is recorded in the log with person and time. Only the head of audit sees K9. The key figure does not go into the leadership view or the board report. Without K9, the actual effort of an individual audit appears only in the form in which the head of audit records it and in the full export of the planning, not in the annual plan. There is no separate right to record it; the form requires the right to edit the planning, which only the head of audit has. Auditors and quality assurance also see actual effort in sums on the audit dashboard: K8 shows planned and actual effort per quarter and risk class, K10 the actual effort of special audits. Under rule 4, both apply only from three audits per field, so that the value of a single audit cannot be read off the sum.
4. Minimum of three audits. Key figures on effort, special audits and lead times show a field (for example a quarter or a risk class) only when at least three audits are in it. Smaller fields are combined under “other”. “Other” also appears only if it covers at least three audits; otherwise it is hidden. Totals and shares are calculated only over displayed fields, so that no hidden field can be worked out by subtraction. K8 always hides plan items without a quarter. This also applies in the leadership view and the board report.
5. Small teams. If the customer account has fewer than three memberships with the role auditor or quality assurance, the leadership view and the board report show no key figures on effort, special audits and lead times and no plan fulfilment by auditor days. Instead they say “too few persons for an anonymous evaluation”. Anyone with the role head of audit does not count, even if they also audit. Every existing membership counts, including that of an invited person who has not yet signed in. There is no “blocked” or “inactive” status; anyone who should no longer count must be removed from the customer account or lose the role.
6. Leadership view and board report without exact dates and without free-text titles. Audits appear only with their number, never with their title, because titles can carry names or areas. In the board report and the plan export, plan items appear only with their item number (for example 2027-007) and the short code of the audit object, not with a title and not with the name of the audit object. Reasons appear there only as a note that one exists, never verbatim. The board report names neither the board nor the reference of the resolution. As free texts it contains only the names of the organisational units for open findings with high risk and the names of the factors of the risk model. The submission PDF “Annual plan”, which auditors, quality assurance, head of audit and administration can retrieve, is different: for items with an audit object it names the object name from the latest version of the object, and for manual items their title; it contains no names of capacity lines and no reasons. The PDF is not stored but generated from the current state of the database on every retrieval. Closings appear only as a quarter, the age of open findings only in ranges (up to 90 days, 91 to 180, 181 to 365, over 365). A single person’s course of work cannot be traced to the day.
7. There is no time recording. Time recording is planned for a later stage. It is to start switched off and, even when switched on, to offer no evaluation per person, only the person’s own view.
Why three audits apply here and only two persons in the task overview
The task overview from the area “Tasks and reminders” shows figures per audit only when at least two persons are involved. Only the head of audit sees this overview, and the head of audit knows the assignments in their audits anyway. Key figures, the leadership view and the board report, by contrast, go to a wider circle, for example executive management and the supervisory body. This circle does not know how work is split in the team. With two audits in a field, knowing one of them is enough to infer the other. With three, at least one more unknown remains. The two limits also count different things: there persons per audit, here audits per field.
Where these rules reach their limits
The minimum counts audits, not persons. If one person leads all three audits of a field, the field still shows a value, and that value then concerns this one person in effect. The rule for small teams counts only auditors and quality assurance and thus catches the most common case, but only for the leadership view and the board report. On the audit dashboard itself, which auditors, quality assurance and the head of audit see, the key figures remain visible even in small teams; everyone involved knows each other there anyway. Even in a team of three or more, a field can mainly reflect one person’s work. Employer and works council should keep this in view when using the software.
Effort per audit and audit lead
K9 shows planned and actual effort per audit. Since the area “Tasks and reminders”, an audit lead can be designated for every audit, and the head of audit sees who that is. Together, the two give planned and actual effort per audit lead, that is, per person. The software does not link the two items; the key figure never reads the audit lead, and a test in the code prevents this link. But the head of audit sees both views. That is why K9 is switched off, and switching it on is a deliberate and logged decision that the customer clarifies beforehand with its works council. The same applies on a small scale to the entry form: whoever enters the actual effort of an audit there sees this one value. The application shows the wording of the notice when K9 is switched on.
Which data about persons are created
| Data | Content relating to persons | How long |
|---|---|---|
| Audit objects | who created, changed, retired or reactivated an object, and when | until the customer account is deleted |
| Risk ratings | who rated, when, comment | until the customer account is deleted |
| Override of the risk class | who set or ended it, when, reason | until the customer account is deleted |
| Link between object and audit, plan item and audit | who linked or unlinked, when | until the customer account is deleted, also after the audit is deleted |
| File import, run | who prepared, adopted, discarded or reversed the file, when; checksums and figures. The file itself is deleted after reading; only its checksum is kept | until the customer account is deleted |
| File import, rows | raw values of every row of the file, including free texts that were never adopted | 30 days after adoption, discarding or expiry; a run not decided expires after 7 days |
| Annual plan | who created, submitted, withdrew, closed or discarded a version, when, reasons; resolution of the board with function of the board, date, reference and the person who recorded it | until the customer account is deleted |
| Acknowledgement | which member of the leadership view acknowledged which version, when | until the customer account is deleted |
| Actual effort per audit | auditor days of an audit, who recorded them, when. Visible individually only in the head of audit’s entry form, in K9 if switched on, and in the full export of the planning (with the user identifier of the person who recorded it). In sums in K8 and K10, from three audits per field, also for auditors and quality assurance | until the customer account is deleted, also after the audit is deleted |
| Settings | who changed interval, reserve, defaults or the display of K9, when, new value | until the customer account is deleted |
| Board report | who generated or downloaded it, when. The report itself names no names from internal audit and neither board nor resolution reference; plan items only with item number and object short code, without free texts of the planning. As free texts it contains names of organisational units for open high findings and factor names of the risk model | until the customer account is deleted |
| Deletion on request | table, row identifier, field, category of the reason, time and checksum of the deleted text; in the provider’s journal the same information without checksum and without text | permanently in the log; journal 90 days |
| Log (hash chain) | each of the actions above with the acting person. The actual effort is not in the log in plain text, only a checksum; reasons likewise only as a checksum bound to table, field and row; comments on ratings not at all | permanently, like the whole log |
The software shows who rated, overrode or decided something in the history of the object or the plan, as with audits and findings. That is an audit trail, not an evaluation. The software does not count how often a person rated or changed something. That would be possible only by counting in the history or the log.
Free texts that remain stored permanently
The planning stores these texts until the customer account is deleted:
- name, description and responsible function of every version of an audit object
- comments on risk ratings
- reasons for overrides and retirements (the reason for a retirement is cleared on reactivation, and the log keeps only its checksum; after an import is reversed, the system code IMPORT_REVERTED stands there instead of a text)
- reasons for plan versions, withdrawals, deviations from the priority rule and the discarding of a plan year
- titles of plan items and names of capacity lines
- function of the board and reference of a resolution
Board reports and the plan export contain none of these texts. The submission PDF “Annual plan” contains object names and titles of manual items (rule 6), the full export of the planning all texts.
The texts of the risk model, that is, names and explanations of the factors and their levels, are not in this list and not in the deletion route. They are configuration of the customer, appear in the board report and should contain no personal names.
The interface asks users to write functions instead of names in these fields, for example “Head of Purchasing” instead of a name. This applies especially to the short code of an audit object: it cannot be changed or deleted and appears in board reports and exports.
Deletion on request
If a name still stands in one of these fields, it can be removed on request. The request goes through the customer to the provider, for example when an affected person or the works council makes it to the employer. The provider replaces the text with a deletion note using a dedicated, logged operating command. The customer’s log keeps the time, field, row identifier, the category of the reason and a checksum of the old text so that earlier plan states remain traceable; the text itself is gone afterwards. The provider also records each deletion in a journal outside the database, without the text, and keeps it for 90 days. If the database ever has to be restored from an older backup, the provider uses the journal to repeat the deletion so that the text does not come back. From the backups themselves the text disappears within the retention period of the backups (40 days at the latest). A function for the customer to delete texts itself is planned for a later stage.
We state two limitations openly. First: board reports are a frozen state. They contain none of the free texts above and therefore need not be covered by the deletion, but they do name the short code of every audit object. The short code is immutable and cannot be deleted. If it is missing on import, the software proposes one from the object name; if a person is named in the name, the person then appears in the short code too. Short codes should therefore be neutral. Likewise, plan exports, full exports and submission PDFs that were downloaded before the deletion remain unchanged; a submission PDF retrieved afterwards reads the state after the deletion. Second: the checksum of the deleted text remains in the log. For very short, predictable texts it cannot entirely rule out guessing by trial and error; we accept this in favour of traceability.
Import files
An uploaded spreadsheet is scanned for malware before it is read. If the scanner is unavailable, the software does not accept the file. It rejects files with macros: in older Office files the virus scanner detects them, in Excel files (xlsx) the additional check for impermissible components. The file itself is deleted after reading. The rows read remain stored only as long as they are needed for preview, adoption and checking. A daily run deletes them 30 days after the decision (adopted, discarded or expired), including free texts that were never adopted. Only checksums and figures of the run remain. The adopted content then stands in the audit objects. Adoption retires no audit object and reactivates none. If an import is reversed, the software retires the objects newly created by that run (system code IMPORT_REVERTED); it names objects it does not retire, for example because of an active sub-object.
Who sees what
| Who | sees | does not see |
|---|---|---|
| Auditors, quality assurance | audit objects, ratings, annual plan, submission PDF “Annual plan” with object names and titles of manual items, key figures K1 to K8, K10, K11; within them actual effort in sums in K8 (planned and actual per quarter and risk class) and K10 (actual effort of special audits), in each case only from three audits per field; auditors edit objects and rate them | actual effort of individual audits, K9, board reports, leadership view |
| Head of audit | everything in the row above, plus risk model, plan decisions, board reports, leadership view; actual effort of an audit in the entry form; K9 only if switched on; full export of the planning with all texts, acknowledgements with person, the actual effort per audit with the user identifier of the person who recorded it, and the audit trail, as the customer’s data export | evaluations per person |
| Administration | audit objects and annual plan read-only, submission PDF “Annual plan”, the settings of the planning and thus whether K9 is switched on | key figures, actual effort of individual audits, K9, board reports |
| Members of the leadership view | key figures K1 to K8, K10, K11 with minimum number and rule for small teams, adopted and submitted plan version, audits only with number, status, plan item identifier, quarter of closing, number of findings per risk and the flag “deleted”, open findings only with number, audit number, risk, unit, age range, status and the flag “overdue”, board reports | titles of audits and findings, working papers, evidence, names of auditors, responsible persons, tasks, actual effort of individual audits, K9, exact dates. They receive no reminder or escalation e-mails |
| Audited units | nothing from this section |
A discarded plan year counts in no key figure and appears neither in the leadership view nor in the board report. Its versions remain readable for the audit trail.
What is not the purpose of the function
Planning and key figures serve to steer internal audit as a whole and to report to executive management and supervisory bodies. They are not built or intended to evaluate the performance or behaviour of individual employees. There are no figures per person, no ranking and no export per person.