Data Roles and Security Profiles: Controlling Who Sees Which Records
Function security says what you can do. Data security says whose records you can do it to. Miss the second and you've built a leak.
I said it before and it's worth its own post: function security and data security are two different locks, and teams that nail the first while ignoring the second build a system that leaks. A manager with payroll access to the whole company instead of their own unit is a data-security failure, not a function one.
Build security profiles around real boundaries
Business unit, legal entity, department, position hierarchy, these define whose data a role can touch. Model them on your actual organisational boundaries and confidentiality needs, not a loose default that scopes too wide.
Mind the hierarchy-based profiles
Position and supervisor hierarchy security is powerful, a manager sees their team and below, but it's only as accurate as your hierarchy. A broken or outdated reporting line silently grants or denies access to the wrong records. Keep the hierarchy clean.
Audit data access, not just role assignment
Knowing who has a role isn't enough; you need to know whose records that role can reach. Regularly answer 'who can see this person's salary' and verify it matches intent.
Real scenario: a client granted HR business partners a role with the right functions but a security profile scoped to the whole enterprise instead of their assigned units. Every HRBP could see every employee's pay across the company. No function was wrong, the data scope was wide open. We tightened the profiles to their real units. The leak was invisible until we went looking, which is exactly why you go looking.