Access rights to employee data: roles, logs and controls

Access rights to employee data should follow the task, purpose and risk. Human resources needs different information from payroll, IT administration or an external accounting provider. If every role can open the same personnel file, the organisation usually lacks not only a technical barrier but also a traceable privacy structure.

This article explains how businesses can structure permissions for employee data, use logs for a defined security purpose and document reviews. It focuses on roles, the data fields that are actually needed, privileged accounts and the way privacy, information security and employee representation fit together.

Start with a role matrix. It should describe not just who has an account, but which function needs which data for which purpose. HR may manage master data and employment documents, while a manager planning work may need only the information required for that task. Payroll needs remuneration-related data, but not automatically every note in the personnel file.

Articles 5(1)(b) and (c) GDPR require purpose limitation and data minimisation. Articles 24 and 25 turn those principles into organisational and design duties. In practice, define data fields and system functions separately. “Access to personnel administration” is too broad if the same system also contains health information, disciplinary documents or private contact details.

The employee data protection section places processing in the employment lifecycle. For the concrete role model, also check whether an external payroll provider acts as a processor and whether the agreement, subprocessors and audit rights match the actual processing.

Permissions arise at onboarding, change when a task changes and should end at departure. Between those events there may be cover arrangements, parental leave, department transfers, project roles and temporary emergency access. A system that records only onboarding often leaves the most critical transitions open. Each permission should therefore have an owner, a purpose and, where possible, a time limit.

Privileged accounts require particular care. Administrators can change configuration, export data or grant further access. Use separate personal identities, justified allocation, a secure emergency procedure and a follow-up review. A shared account prevents reliable attribution and makes it harder to investigate a security incident.

The exit process must connect the HR event with technical deactivation. HR records the effective time, IT disables accounts and the responsible manager confirms whether handover or legally required retention must be handled separately. The existing article deleting former employees’ data covers the separate question of deletion, restricted retention and handover.

Logs can show when an account opened a personnel file, exported data or changed a permission. That supports security controls and the investigation of specific anomalies. A log is not permission to evaluate every activity indefinitely. Before implementation, define which risk the log reduces and what level of analysis is actually necessary.

Article 32 GDPR requires a level of security appropriate to the risk. Measures may include confidentiality, integrity, availability and regular testing. Define event types, access to logs, investigation triggers, retention and deletion. A small set of clear security events is often more reliable than an oversized data store that nobody can meaningfully review.

Where a system also reveals attendance, behaviour or performance in detail, an additional labour-law assessment may be required. Section 96(1)(3) of the Austrian Labour Constitution Act concerns control measures that may affect human dignity. Whether it applies depends on design, purpose, intensity and use in the specific workplace. Where a works council exists, privacy and participation should therefore be assessed together.

HR processes sometimes require access beyond a standard role. A security incident, extended absence or legal request may justify a broader view. Do not solve such cases through a permanent group permission. Use an exception process that records the reason, scope, approval, duration and subsequent review.

Emergency access should be designed so it does not become the normal route. Options include time-limited activation, two-person approval or an independent post-use review. The person approving an exception should not be able to decide alone how their own access is assessed.

Sensitive data need a separate layer. Health information, trade-union membership and other special categories under Article 9 GDPR should not be available through a general employee role. Assess the legal basis, purpose, access group and safeguards separately. This remains necessary even where the system technically displays all data in one screen.

A reliable permission model consists of connected records: processing activity, role matrix, data-field description, technical configuration, logging rule, review evidence and exit or transfer procedure. They need not be stored in one file. They should allow a clear connection between processing, system, role and responsible owner.

Article 24 GDPR requires suitable measures and their review. In the context of accountability, the Austrian Data Protection Authority likewise expects controllers to be able to explain their organisational and technical measures. A screenshot of a system screen is rarely enough. The key question is whether the business can explain why a role may see particular data, when it was reviewed and what happens after a deviation.

Assign both a business and a technical owner to each system. The business owner understands purpose and data need; IT understands configuration and logging. Both need an escalation path when a role is too broad or an access cannot be explained. This turns permission review into an ongoing control rather than a one-off clean-up.

Groups instead of tasks: Every manager gets the same full access even though tasks and employees differ.

Old permissions remain: After a transfer, an account accumulates new rights without losing its former access.

Logs without purpose: The system records everything, but nobody defines when and by whom it may be analysed.

Emergency accounts without review: A privileged account is known but neither personally assigned nor checked after use.

Privacy and participation are separated: A control system is implemented before its impact on human dignity and works-council rights is assessed.

Choose one process, such as the digital personnel file, payroll or recruitment management. Record data fields, roles, exports, interfaces and external recipients. Then test which role really needs which part and whether special categories of personal data receive separate protection.

Test the model with realistic events: onboarding, department transfer, cover, parental leave, departure and emergency access. For each scenario, show when access starts, who approves it, how it ends and what evidence remains. For logs, also check purpose limitation, access to the logs and deletion.

The processor checklist helps with external HR or payroll services. For responsibilities and evidence, see privacy compliance and governance. Neither replaces the system review, but both provide a useful structure.

We can review the role matrix, data fields, privileged accounts, logging and review process with you. This combines privacy, information security and, where required, labour-law participation. Contact us with the system overview, an existing permission matrix or specific open access questions so that the next steps can be defined clearly.