Confidentiality

A performance review contains an opinion about a person, written down and kept for years. Who may read which part of it is not a preference to be configured later: it is the first thing to get right, and the reason several parts of this application are laid out the way they are.

This page is written for the person who has to answer, in a works council meeting or to a data protection authority, the question “who can see this?”.

Who can see what

What

Employee

Their reviewer

HR officer

The review itself: period, dates, status, who reviews them

Read

Read and write

Everything

Their own answers to the questionnaire

Read and write

No

Everything

The reviewer’s answers, once the review is shared

The shared questions only

Read and write

Everything

Answers given anonymously in a multi-rater round

No

No

Pooled only

The rating, the calibration decision and the scores

The released rating only

Their own reviews

Everything

The reviewer’s private working notes

No

Their own only

Break-glass, logged

Who was asked for feedback (the panel)

No

Named raters only

Everything

The development plan

Read

Read and write

Everything

Their own written comment at sign-off

Read and write, once

Read

Read

Two of those rows deserve more than a table cell.

The confidential assessment

The rating, the reviewer’s proposal, the calibration decision, the composite scores, the potential and flight-risk entries and the succession note do not live on the review. They live on a separate record, reached from the Rating page of the review form, which carries its own access rules — and none of those rules ever matches the employee under review.

That distinction matters more than it looks. If the rating were a hidden field on the review, its confidentiality would rest on a screen setting, and an export, a filter, a grouping or a report could still reach it. Because it is a separate record, an employee looking at their own review does not have the field at all: not in the interface, not in an export, not in a group-by.

Important

The employee sees a rating exactly once: the released rating, on the review that has been shared with them, and only after somebody decided to share it. The rating the reviewer originally proposed, and the reason it was changed, are never shown to them.

Note

The original proposal and the final rating are both kept, side by side, permanently. A calibration that moves a rating away from the proposal is refused unless the person who moves it writes down why. That is an audit trail, not a formality: it is what lets a rating be explained a year later.

What is written in the log of a review

The message log — the chatter — of a review is treated as a document the employee reads, because they can. Every confidential entry (a rating being set, a calibration, the decision to release, an unlock and its reason, a competency written back to the employee’s skills) is logged on the confidential assessment instead, where the employee has no access.

The same reasoning applies to to-dos. A scheduled activity is readable by anybody who can read the document it hangs on, so a review activity is never placed on the review: each person who owes something is chased on their own participation record. An employee therefore cannot work out who else was asked for feedback by looking at the to-do list of their own review.

What the employee can always see

Whatever else is configured, an employee reaches, for their own review and without asking:

  • the review record itself — the period, the questionnaire, the due date, the status and who their reviewer is;

  • every question they were asked, and every answer they gave;

  • once the review has been shared with them: the reviewer’s answers to the questions marked Shared With Employee on the questionnaire, and the released rating;

  • the development plan agreed with them, including the actions carried over from the previous review and what came of them;

  • the printed review packet — the same document, produced from the same template, whoever prints it;

  • their own comment at sign-off, in their own words.

And, deliberately, nothing else: not the panel, not another employee’s review, not the reviewer’s working notes, not the calibration, and not an individual answer from an anonymous round.

Answering a subject access request

There is no button labelled subject access request, and none is needed: the employee already holds the readable part of their own file, and the confidential part is a short, well-defined list an officer can produce by hand.

  1. Ask the employee to print their own reviews from Performance ‣ Reviews ‣ My Reviews, using Print. That is the review packet: the questionnaire with the answers, the released rating, the development plan and the sign-off, with the retention date stated in the footer.

  2. As an officer, add what the packet does not carry, if the request asks for it: the rating the reviewer proposed and the calibration reason, from the confidential assessment; the scores; and the potential, flight-risk and succession entries if they were used.

  3. Add the reviewer’s working notes about that employee, if any exist.

Warning

A reviewer’s working note is not secret from the employee it is about. It is not routinely shared, which is a different thing. Anybody writing notes should write them knowing that a subject access request, a labour dispute or a court can bring them out. The application does not pretend otherwise, and an HR policy should not either.

An officer who has to read another reviewer’s notes does so through a break-glass action, which records on the confidential log of the review that they did. Use it when you have a reason, and expect the fact to be visible afterwards.

Retention and the purge

When a review is closed it is stamped with a retention date: the day it closed plus the retention period of its cycle, or of the company when the cycle does not state one. The default is 36 months, the Hungarian limitation period for labour claims; set it to whatever your own legal advice says.

The retention date is a proposal. Nothing happens on that day. No scheduled job deletes anything, ever.

Running a purge

  1. Look at what is due first, at Performance ‣ Configuration ‣ Reviews Past their Retention Date.

  2. Open Performance ‣ Configuration ‣ Retention and Purge, choose the Companies and the Retention Reached On date, and click Dry Run.

  3. Read what the dry run reports on the Dry Run page: how many reviews would be anonymised per company, how many are refused because they are under legal hold, and the oldest and newest retention dates concerned. The Reviews Concerned and Refused, Under Legal Hold pages name them. Nothing has been touched at this point.

  4. If you are satisfied, click Anonymise the Listed Reviews and confirm.

Important

A purge anonymises; it does not delete. Each review keeps its row, its dates, the rating that was released and the sign-off, and is archived. What is removed is the free text and the identity of the raters: the employee’s own comment, the text and the comment of every answer, the body of every working note, and the identity of every rater other than the employee themselves. With the multi-rater pack installed, the outside raters’ names and addresses, who nominated and who approved each rater, and the fingerprint of every feedback link go with them.

This is not reversible.

A single run touches at most 500 reviews. If more are due, the result says so and you run it again.

Note

A review is only anonymised while it is genuinely past its retention date. If a review was reopened, or its retention date changed, between the dry run and the execution, it is refused and named in the result rather than being purged on stale information.

What this does not protect you from

Being clear about the boundary is part of being trustworthy about what is inside it.

  • An officer sees everything in their companies. That is what the access level means. Grant it to as few people as the work allows, and review the list of holders periodically.

  • A database administrator sees everything. No application rule constrains somebody with server or database access.

  • A printed packet leaves the system. Once a review has been printed or exported, retention and legal hold no longer reach that copy.

  • Anonymity is a threshold, not a cryptographic guarantee. It stops a small group being identified from counts and averages. It does not stop somebody being recognised by their writing style in a pooled comment — see Multi-rater (360) reviews.

  • Notes are private, not privileged. See the warning above.

See also