Loading page
All-in-one HR platform · v2.0
14-day free trial · No credit cardhello@HrMagix.com
All-in-one HR platform · v2.0
14-day free trial · No credit cardhello@HrMagix.com
Most HR data leaks are not breaches. They are a salary sheet forwarded to the wrong person, a manager who can see the pay of a peer's team, or a former HR executive whose login still works. The data was available to someone who did not need it, and eventually that mattered.
Access control in an HRMS is the work of deciding, in advance, who needs to see what to do their job. This guide sets out how to classify the data, how to design roles, and how to keep them correct over time. The legal obligations around personal data are a separate subject and worth taking advice on; this guide is about the practical design.
01
Not every field is equally sensitive, and treating everything as confidential makes the system unusable while treating everything as open is how leaks happen. Sort employee data into a small number of tiers and decide access per tier.
02
A role describes what a job needs: payroll processor, HR business partner, line manager, finance approver, auditor. Assign people to roles rather than granting individual permissions, so that when someone changes job you change their role rather than unpicking a list of exceptions.
Keep the number of roles small enough to explain. If every new request produces a new role, the role list stops meaning anything and nobody can say with confidence who sees what.
Watch for itBe careful with the super-admin role. It is convenient during implementation and dangerous afterwards. Limit it to the smallest number of people who need it, and do not use it for daily work.
03
A role answers what someone can see; scope answers whose. An HR executive at one plant usually needs the records for that plant, not the whole company. A manager needs their own team, and often their skip-level team, but not a peer's.
Base manager access on the reporting line in the employee record rather than a separately maintained list. When a reorganisation moves a team, the access moves with it, and nobody has to remember to update a permission.
04
Viewing a salary and changing one are different powers. Someone who can both edit a bank account and approve a payroll run can redirect a salary without anyone else noticing. Split the duties: one person maintains, another approves, and the system records both.
The same applies to attendance corrections, salary revisions and loan entries. Any change that moves money should need a second person and leave an audit trail of who changed what and when.
05
Access goes wrong at transitions. A new HR hire is given broad access to get started and never narrowed. A manager moves teams and keeps sight of the old one. Someone leaves and their login works for another month.
Tie access changes to the events that cause them. A role change in the employee record should change access; an exit should disable the login on the last working day, as part of the exit checklist rather than a separate request to IT.
06
Even a well-designed scheme drifts. Set a regular review, at least once a year and more often for compensation and sensitive case data, where the owner of each role confirms the list of people in it.
The review should also cover exports. Data downloaded to a spreadsheet leaves the access controls behind. Decide who may export compensation data, and keep a record when they do.
Every guide ends here rather than in a summary. If a line below is not true yet, that is the next thing to do.
The employee, the people who process payroll, and a small set of approvers such as the HR head and finance. Line managers seeing their team's pay is a policy decision some companies make and others do not; decide it explicitly.
Permissions are attached to roles that describe a job, and people are assigned to roles. When someone changes job, you change their role instead of editing individual permissions.
At least once a year across the board, and more often for compensation and sensitive case data. The owner of each role should confirm who is in it.
No. It covers the practical design of access. Obligations under data protection law depend on the current rules and how you process data, so take advice on those separately.
The checklist above is generic by necessity. Bring your own structures, states and rota and we will tell you which lines are already true and which are not.
14-day free trial · Full access to all 12 modules · Zero implementation fee · Cancel anytime