Internal reporting: what the form itself has to do

A packaging business in Wohlen with forty staff wants observations from the shop floor to reach management: a machine guard that has been swung out of the way for weeks; a supplier who is related to a team member; something in the early shift that someone no longer wants to watch happen. Until now this went through the direct line manager. Now a form on the intranet is meant to be added.

The form takes fifteen minutes to build. The question it answers, though, is not “which fields do we need” but “who reads this afterwards”. Whether the form gets used hangs on that question. A reporting channel where nobody knows where the message lands stays empty — and an empty form is not the same thing as a business without problems.

Why a reporting form is not a contact form

An ordinary contact form on a website produces an enquiry: a person writes about themselves and would like an answer. An internal reporting form produces something else. Three differences stand out.

The report is usually about a third person. The table then holds not only who wrote, but also who it was about. Both are personal data within the meaning of Art. 5 lit. a FADP, and both have rights attached.

The sender is the sensitive part. On a request for a quote, the name is a formality. On a report about a conflict of interest, the name is the detail that decides what follows for the person who wrote it.

A way back is needed. An enquiry is answered by email. A report that arrived without an address cannot be answered — unless the form provided for that beforehand.

Who can see the submission

The Swiss data protection ordinance names confidentiality as one of four protection goals: data should be “accessible only to authorised persons” (Art. 2 lit. a DPO). Art. 3 para. 1 lit. a DPO then gets more concrete and names access control — authorised persons should only have access to the personal data they need to carry out their tasks. For data security as a whole, Art. 8 FADP requires technical and organisational measures appropriate to the risk.

That stays abstract until you count who can actually look inside a form set up the usual way.

Who	Typically sees	Because
The mailbox behind the form	Every report in full	Forms often send answers to a shared address
Whoever holds that account	Every report in full	A shared mailbox rarely belongs to one person
The stand-in during holidays	Every report in full	Forwarding and delegated access are rarely undone
IT administration	Reports, attachments, logs	Administrator rights apply to every folder
The form tool itself	All answers in the results table	That is where they are stored
The processor	Whatever the tool stores	Art. 9 FADP governs the transfer, not the visibility

None of these is a mistake. They are defaults that are exactly right for a request for a quote — and that, for a reporting channel, describe a wider circle than the word “confidential” on the page suggests.

The other half of the same question concerns the people who should not see it: the manager the report is about; the department it came from; whoever decides on salaries and contracts. A form can reflect that if it has its own, separate place to store answers. It cannot reflect it if the reports sit in the same table as the holiday requests.

Reporting anonymously, and what it costs both sides

Anonymity is not a setting you switch on. It is an arrangement with costs on both sides.

What	With a name	Anonymous
Asking a follow-up question	Possible	Not possible without a channel for it
Sending documents later	Possible	Only through the same route as the first report
Being told the outcome	Possible	Only through a reply channel without an address
Putting the report in context	The role and viewpoint are known	The report stands on its own
Consequences for the sender	Depend on access control	Depend on what else the form stores

The point most often overlooked in practice is the third. Without an address there is no way back, so the person who wrote never learns whether anyone read it at all. That is exactly why the second report never comes.

Between the two lies a third state that is neither. On submission the form issues a reference — a string only the sender knows — and shows it once. That reference later opens a page carrying a follow-up question or a message. The business knows the reference but no address; the person knows both. It is a post box with no street name. It works as long as the reference is not stored linked to an account number, an email address or a session — otherwise the detour is cosmetic.

What comes along even when the name field is empty

Alongside the filled-in fields, submitting creates a second layer of information. On a registration form that layer is administrative. On a reporting form it is the subject itself.

The timestamp. In a business with forty staff, “Sunday, 23:40” already narrows the circle. In a shift of six people it narrows it a great deal.

The signed-in account. If the form sits on the intranet behind a login, the system knows who opened it — even when no name appears in the form. “Anonymous” then means anonymous in the form, not anonymous in the system.

Network and device. IP address, browser, operating system, sometimes the screen size. On its own that says little. Together with a timestamp and a device list from IT it says more. Whether such details make a person identifiable is decided under Art. 5 lit. a FADP, and therefore by what else is in the same row.

The attached file. A photo often carries the time it was taken and the device with it; an office document carries the name of the account it was created under, and sometimes its entire revision history.

The logs. Under certain conditions, Art. 4 DPO requires the logging of storage, modification, reading, disclosure, deletion and destruction — in particular where it would otherwise be impossible to establish afterwards whether the data were processed for the purposes they were obtained for. Such logs exist for the traceability that Art. 2 lit. d DPO names as a protection goal. They are also one more list recording who was where, and when.

The person the report is about

The second person concerned rarely comes up in the discussion, but sits in the same row.

Art. 5 lit. c no. 5 FADP lists “data on administrative and criminal proceedings and sanctions” as sensitive personal data. A report is neither a proceeding nor a sanction. It can, however, contain details that move in that direction, and depending on its content also details about health or trade union activity under the same provision.

For employment relationships Art. 328b CO is added: an employer may process data concerning the employee only to the extent that it concerns their suitability for the employment relationship or is necessary for the performance of the employment contract; otherwise the provisions of the FADP apply. Art. 362 para. 1 CO lists Art. 328b among the provisions that may not be departed from to the employee’s detriment. On employer data processing, the Federal Data Protection and Information Commissioner also notes that employees, because of their subordinate position, are only very rarely in a position to consent freely, or to refuse or withdraw consent.

In practice this means one thing above all for the form: what a report says is not automatically something that ends up permanently in a personnel file. Art. 6 paras. 3 and 4 FADP call for a specific purpose that is evident to the person concerned, and for destruction or anonymisation once the data are no longer needed for it. A reporting form whose answers flow automatically into the same place as job applications makes that separation hard.

Why the general contact form rarely fits

The obvious route is to add a “report” option to the existing contact form. It saves half an hour and brings four things with it that only show up later.

• One destination for everything. Enquiries and reports land in the same mailbox, and the circle of people with access there was set for the milder of the two cases.
• No separate retention. Contact form enquiries are deleted after a year, or never. The same reasoning rarely applies to reports.
• No reply channel without an address. A contact form assumes an email address, because it was built for answers.
• A confirmation that writes back. Many forms send an automatic acknowledgement to the address given. For a report sent from a work account, that is an email about a report sitting in a mailbox others can read.

Questions a reporting form can be checked against

The useful questions are not legal ones but countable ones. They can be worked through on your own form in half an hour:

1. How many accounts can open the answers — listed by name, not estimated?
2. Does one of them belong to a person who might be the subject of a report?
3. What sits in the table beside the report text: time, IP address, account, referring page?
4. Can someone get through the form without an email address, and what do they see afterwards?
5. How does an anonymous report learn that it arrived?
6. Who receives the automatic confirmation, and where?
7. How long do the answers stay, and who decides that?
8. What happens to the attachments, and where do they sit?

For a sports club with a volunteer committee the same eight questions apply, only with smaller numbers. There the third one is the most delicate, because a club mailbox is almost always open to several people.

A reporting channel does not become confidential because the word “confidential” sits above it. It becomes confidential because the list of people with access is short and somebody knows it.

With Formulare we are building a web app in which answers are encrypted in the browser and stay stored in Switzerland. For a reporting channel that mainly means the list above gets shorter: the places that store and pass on the answers along the way are no longer on it. Which fields the form has, and who inside the business may read them, remains the decision of whoever sets it up.