Whistleblowing channel and GDPR: confidentiality, access and retention
Whistleblowing channel and GDPR: how businesses separate identity, reports, access rights and retention under Austrian law.
Mag. Bernhard Brandauer, Austrian attorney-at-law
BRANDAUER Rechtsanwälte
Mag. Bernhard Brandauer advises businesses on the legal classification and practical implementation of data protection requirements.
A whistleblowing channel regularly processes identity data, allegations, evidence and information about other people. It must therefore be more than accessible: confidentiality, purpose limitation and restricted access must work in practice. In Austria, the GDPR and the Whistleblower Protection Act apply together.
This article explains who may access a report, how the identity of the reporting person and the person concerned is protected and which retention periods apply. It focuses on the data protection process around an internal report, not on the employment-law assessment of the allegation.
Is your whistleblowing channel organised lawfully?
Answer the questions about the actual process. The result indicates where confidentiality, access and retention should be strengthened first.
Is the purpose of the channel defined for the report?
The channel should receive reports, assess their substance and enable necessary follow-up action.
Your orientation
Access controls do not yet adequately protect identity and report content.
The channel’s retention logic must be aligned with the Austrian Act.
The basic structure is prepared; evidence and configuration remain decisive.
Which legal framework applies to the channel
The Austrian Whistleblower Protection Act protects people who have obtained information about breaches through a current or former professional connection. Under Section 3(1), its general subject-matter framework applies to businesses with 50 or more employees. Certain areas covered by Union law can trigger the Act regardless of that number. The scope of the Act and the concrete organisational duty must therefore be assessed separately.
Section 8 of the Act is central to data protection. Processing personal data contained in reports is permitted for the purposes of the Act, but it must be limited to data needed to establish and sanction a breach. This reflects the GDPR principles of purpose limitation and data minimisation in Article 5(1)(b) and (c).
Under Section 8(4), the legal entity to which the internal body belongs is generally the controller for setting up the reporting system. If several controllers operate one system together, joint controllership under Article 26 GDPR may arise. A technical provider is not automatically a controller; its role must be assessed by the purposes and means of each processing operation.
Protect the identity and content of a report
Section 7(1) requires internal and external bodies to protect the identity of the reporting person. It also covers information from which identity can be derived directly or indirectly. A user name is therefore not the only protected item. Department, timestamp, file properties, wording or a very small group of possible reporters may also identify a person.
Under Section 7(2), people who receive report content outside the responsible body may not disclose the content or identity. Forwarding it to the responsible body remains possible. In practice, a general inbox, assistant or IT administrator should not automatically see the complete report if it is not needed for their task.
The protection also covers the person concerned by the report. Section 7(5) extends the rules to that person’s identity and information from which it can be inferred. An internal investigation should therefore not be conducted through an open distribution list. Disclosure to authorities, courts or prosecutors is subject to statutory requirements and proportionality.
Define access roles, logging and security
Section 9(6) requires a confidential and secure system. Access must be restricted and logged so that only employees who need access to handle the report can use it. This applies not only to the login screen. It also covers exports, backups, support access, notifications and administrator accounts.
A practical structure separates data areas. The identity of the reporting person, the report itself, evidence and investigation notes do not need to be visible to every role. The responsible body may need the full content. A technical administrator may only need the information strictly necessary for operation and security. Permissions should be limited in time and subject matter.
Article 32 GDPR requires a level of security appropriate to the risk. Measures may include strong authentication, encryption, separated roles, secure recovery and regular testing of effectiveness. The relevant point is not a long list of security terms, but evidence that actual access, changes and transfers are controlled.
Organise data scope, legal basis and information
A report may contain sensitive information that is not needed to assess the allegation. Sections 8(2)(2) and 8(10) require processing to be limited to necessary data. Unnecessary data must not be collected and must be deleted without delay if it is collected accidentally. Clear submission guidance, structured handling and attachment review support this rule.
The legal basis does not automatically come from consent by the reporting person. The Austrian legislature provides for processing for the purposes of the Act. The GDPR principles, controller allocation and necessary technical and organisational measures still apply. Special-category data under Article 9 GDPR may be processed under Section 8(5) only under the strict conditions set out there.
Privacy information should explain how the channel works, who handles reports, which data is processed and how long it is retained. The special rule in Section 8(9) must be taken into account: rights of the person concerned may be restricted for as long and to the extent necessary to protect identity and ensure effective handling. A blanket refusal to provide any information is not a substitute for that assessment.
What retention and deletion the Act requires
Section 8(11) contains a specific retention rule. Personal data must be retained for five years from the last processing or transfer. It may be retained longer for as long as required for administrative or court proceedings already initiated, or for criminal investigations. Once the retention obligation ends, the personal data must be deleted.
The period therefore does not necessarily begin on the day the report arrives. The case file must show when the last relevant processing or transfer took place. An investigation, transfer to a competent authority or later follow-up action may affect the relevant date. The system should record that date in a structured field rather than only in a free-text note.
Audit-log data follows a separate rule. Section 8(12) requires actual processing operations, such as changes, queries and transfers, to be logged. Those logs must be kept from their last processing or transfer until three years after the retention obligation under Section 8(11) ends. The case file and access logs should therefore not share one deletion date.
Control providers and disclosures carefully
If a digital whistleblowing system is operated by a provider, assess the provider’s role for each processing operation. If it processes report data only for the entity’s purposes and on documented instructions, processing on behalf of the entity is likely. An Article 28 GDPR agreement must then cover the subject matter, duration, data types, data subjects, instructions, confidentiality, security, assistance and deletion.
The platform must not undermine the Act’s confidentiality through default access. Review hosting, support, subprocessors, backups, administrator rights and possible transfers to third countries. The article SaaS agreement: controller or processor? explains the role assessment for digital services.
An internal disclosure is not permitted merely because the recipient is part of management. Necessity, confidentiality and the concrete task remain decisive. If report data is accidentally sent to an unauthorised recipient, assess the incident as a possible security event. The article Email to the wrong recipient: when is it a personal data breach? explains the initial assessment.
Checklist for a privacy-compliant channel
Purpose: Describe which reports are accepted, which follow-up actions are possible and which data is needed.
Roles: Assign the legal entity, internal body, investigators, IT administrators and external providers to concrete tasks.
Confidentiality: Separate identity, report, evidence and investigation notes. Check indirect identifiers as well.
Access: Define permissions, time limits, strong authentication and logging of queries and changes.
Retention: Record the last processing, ongoing proceedings, the five-year period under Section 8(11) and the separate log period under Section 8(12).
Information: Explain the channel, responsibility, processing, safeguards and possible restrictions of data-subject rights clearly.
Avoid common mistakes with report data
Everyone can see the report: A shared mailbox or open collaboration channel can spread identity and allegations unnecessarily.
Only the name is treated as confidential: Timestamps, department, file names and wording can also identify a person indirectly.
The period always starts on receipt: Section 8(11) focuses on the last processing or transfer. Ongoing proceedings may extend retention.
Logs are deleted together with the case: Access and change logs have a separate retention rule under Section 8(12).
The provider may administer everything: Technical administrators do not automatically need the content or identity. Support and backup routines must be restricted.
Three practical cases on confidentiality and deletion
Report to a general inbox: An employee sends a report to a publicly known email address. The recipient must not circulate it internally, but forward it securely to the responsible body. The misdirection should be documented and access to the message restricted.
External investigation: An external body receives the full file even though it only needs to perform a technical review. Before transfer, define the data needed, the body’s role and the rules for return, deletion and access.
Closure without deletion: The investigation ends, but the report, exports and logs remain permanently in the system. Record the relevant date, check ongoing proceedings and run separate deletion processes for the case and audit data.
Frequently asked questions about whistleblowing channels and GDPR
How long must personal data from a whistleblowing channel be retained? +
Who may see the reporting person’s identity? +
Is the operator of a whistleblowing platform automatically the controller? +
Review the channel and data protection together
A whistleblowing channel is reliable only when the law, process and technical configuration match. We review roles, safeguards, information routes, providers and deletion logic against the actual reporting process. Contact us with the channel description, role and permission concepts and the planned retention rules so that the open points can be addressed concretely. You can receive new articles and legal guidance from the firm through BRANDaktuelle Rechtsnews.
Discuss your data protection matter
Tell us briefly what is happening. We will help classify the situation and discuss which documents and next step are useful for your business.
Clarify a data protection question
Address
BRANDAUER Rechtsanwälte GmbH Giselakai 51 5020 Salzburg Österreich
Phone
+43 662 6280000