Who should see which parts of an employee record?

01

Begin with tasks and decisions rather than job titles

List the tasks each role performs using employee information. A manager approving leave needs different fields from a person preparing equipment or maintaining contractual documents. Write the access requirement as a task with a purpose and a responsible owner. Broad labels such as manager or administrator hide important differences between organisations and between teams within the same company.

Ask HR and the relevant business owners to approve the matrix before implementing it. Technical permission and the organisation’s basis for processing information are related but distinct questions. The application can enforce the agreed access rules; it cannot establish every legal or organisational justification by creating a role. Record who owns those decisions and how a new requirement is reviewed when the company changes its process.

02

Separate categories of information within the record

Avoid treating the employee profile as one indivisible document. Contact details, team membership, planning information, employment documents and restricted supporting material may need different readers and editors. Design fields and attachments so that permission can follow those categories instead of relying on a warning at the top of a page that everyone can already open.

Define which values a person can see, which they can change and which changes require review. Employees may be able to propose updates to their details without directly altering an authoritative payroll or contractual record. Preserve the original value and the review outcome where appropriate. A useful interface explains what will happen to a requested change, including which team receives it and when the employee can expect to see its status.

03

Tie managerial access to approved membership

A manager’s access often depends on the people they are responsible for, not simply possession of a manager role. Keep the approved reporting relationship available to the authorisation process and decide when transfers take effect. A colleague moving between teams should not remain indefinitely visible to every previous manager because an old membership was never removed.

Handle temporary delegation and matrix responsibilities explicitly. A project lead may need project-related availability without access to the complete employee file. A temporary substitute may require a limited approval function for a defined period. Record the scope and expiry rather than granting a broad permanent role for convenience. Test these relationships with accounts representing ordinary users, including people who manage two teams or change responsibilities during an active request.

04

Apply the same boundary beyond the main screen

Hiding a field in the interface does not protect it if an export, attachment link or background endpoint still returns it. Trace each route by which employee data leaves the record. Include search results, notifications, calendar feeds, downloadable files and integrations. The access decision should use the authenticated user and the approved scope at the point the data is retrieved.

Use a boundary checklist when reviewing the system. It should cover routine use and attempts to open a reference obtained earlier, because permissions may have changed since a document link was first created. Keep the tests focused on the organisation’s agreed access model.

• Verify an ordinary manager can see only their approved employee scope.
• Check restricted fields and attachments independently of the profile page.
• Review exports, search previews and notification content.
• Recheck access after a transfer, delegation expiry or account removal.
• Confirm integrations receive only the fields their task requires.

05

Make administration and support access deliberate

Separate user administration from permission to read every employee record. A person helping reset access may not need the contents of a private document. Define privileged support actions, who authorises them and what evidence is recorded. Where temporary access is needed, give it a purpose and an end condition instead of leaving a standing exception that nobody reviews.

For EU-hosted or company-managed deployment, map the people and services that can access backups, logs, stored documents and operational consoles. Those routes matter alongside the application’s own role system. Limit sensitive content in diagnostic records and confirm how incidents are investigated without spreading copies through informal messages. Review provider and support responsibilities with the organisation’s owners; server location alone does not establish the complete access or data-handling arrangement.

06

Test changes in responsibility before release

Rehearse a new manager, a team transfer, temporary cover, an employee proposing a correction and a departing user. Verify both allowed actions and denied requests through the relevant interfaces. The test should establish that a denied action remains denied even if the person knows a record identifier or previously saved a link to it.

RDC can translate the approved access matrix into application rules, document handling and integration boundaries, then build repeatable checks around role and membership changes. Measure unresolved access requests, stale memberships and exceptions that remain open beyond their intended purpose. Keep a named owner for reviewing the matrix as responsibilities evolve. Bring a redacted employee record, the tasks each team performs and the current joiner, mover and leaver process; these provide a concrete basis for an HR system with explainable access boundaries.