How Access Control Works
Because Evenpay handles sensitive compensation, employee, and organizational data, access control is a core part of the platform — not an afterthought.
Evenpay uses a capability-based authorization model. Every user's access is determined by two things: their role and their organizational scope. The system enforces access at two independent layers:
Record-level access — which employees and records a user can see
Field-level access — which data fields within those records are visible (e.g., whether compensation details are shown)
This dual-layer approach ensures that sensitive information like salary data is only visible to those with a legitimate need.
Identity & Provisioning
Evenpay integrates with the identity and access management systems you already use. When connected to a directory service like Microsoft Entra ID (formerly Azure AD), Google Workspace, or another identity provider supported through Auth0, Evenpay can automatically inherit organizational membership and group assignments.
In practice, this means:
When a new employee is added to your identity provider and assigned to the right group, they get provisioned in Evenpay with the correct role and scope — no manual setup needed
When someone leaves or changes roles in the directory, their Evenpay access updates accordingly
Your existing identity infrastructure is the starting point for access. Evenpay layers its own capability model on top.
User Roles
Evenpay defines six standard roles, each with a distinct level of responsibility. Roles are assigned when a user is invited or onboarded, and can be changed by authorized administrators.
Role | What they can do |
Owner | Full, unrestricted access to all data, settings, and admin functions. Typically the primary account holder. |
Administrator | Broad access across the organization including system administration. Can manage users, integrations, settings, and most organizational data. |
HR Administrator | Focused on HR management. Organization-wide access to employee data, compensation, and analytics. Cannot manage integrations or permanently delete data. |
Manager | Scoped to their direct reports, inherited reports, and the organizational units they manage. Can view and act on employee and compensation data only for the people they're responsible for. |
Employee Representative* | For employee representatives participating in joint pay assessments (JPA) and other representative functions. Organization-wide visibility on JPA-related data, plus self-only access to their own employee record. |
Employee* | The default role with self-only access. Can view their own employee card and personal data but cannot access other employees' information. |
* The Employee Representative and Employee roles are defined in the system and available for activation. In current deployments, organizations typically manage compensation workflows through the Owner, Administrator, HR Administrator, and Manager roles. These roles will become central as Evenpay expands employee-facing functionality, including joint pay assessment participation and employee pay information requests under the EU Pay Transparency Directive.
Capabilities
Access is controlled through granular capabilities — specific permissions that define what actions a user can perform on which resources. Each capability follows a clear naming pattern that pairs a resource with an action (for example, the ability to view employee profiles, edit compensation data, or manage organization settings).
You don't need to configure capabilities individually — they're assigned automatically based on the user's role. But they're the underlying mechanism that makes the access model precise.
Scope and Visibility
Every capability grant is paired with a scope that determines where it applies. This is how Evenpay ensures that a manager sees only their team's data while an HR Administrator sees the entire organization.
Scope | What it covers |
Organization-wide | Full visibility across the entire organization. Used by Owners, Administrators, and HR Administrators for most capabilities. |
Assigned organizational units | Limited to specific organizational units directly assigned to the user. |
Descendant organizational units | The user's assigned units plus all child units below them in the hierarchy. The primary scope for managers overseeing a department or division. |
Direct reports | Limited to employees where the user is the direct manager. |
Inherited reports | Both direct reports and all employees in the manager's descendant organizational units. This is typically how managers experience the system in practice. |
Self only | The user can see only their own employee record. Used by the Employee role and for certain Employee Representative capabilities. |
Custom Scope Overrides
The standard roles and scopes cover most organizational structures, but real-world access needs aren't always straightforward. Evenpay supports custom scope overrides that let administrators manually adjust who can see whom on a per-user basis.
Common examples:
Restricting access within a role — A manager may formally oversee a team but shouldn't have access to certain employees within it, for example during a sensitive HR investigation.
Granting cross-unit access — A project lead, dotted-line manager, or regional coordinator may need visibility into employees outside their own organizational unit. An administrator can grant them access to specific additional units or individuals without changing the org structure.
Temporary access for specific processes — During a compensation review cycle or organizational restructuring, certain users may need broader or narrower access than their standard role provides.
How Access Is Enforced
Evenpay enforces access at every level of the application, following a deny-by-default principle. If the system cannot confirm that a user has the required capability, access is denied.
Here's what happens when a user makes a request:
The system verifies they are a member of the relevant organization
It checks whether the user holds the required capability for the requested action
It applies the user's scope to filter the data, ensuring they see only the records they're authorized to access
For compensation-sensitive data, an additional field-level filtering step removes salary and compensation fields for users without specific compensation read access
This means that even if a manager can view an employee's profile, they won't see compensation details unless they have the specific compensation capability.
The frontend hides navigation items and interface elements that a user can't access (frontend gating), but the backend always enforces authorization independently. Security doesn't depend on what the UI shows.
Audit Trail
All significant actions within Evenpay are recorded in an audit log. Authorized users can view and export audit log entries, providing a complete trail of who accessed or changed what data and when. This supports compliance requirements and internal governance.
Security Principles
These security principles are maintained across the entire system:
Principle | What it means |
Deny by default | Any failure in the authorization check results in access being denied. Unknown or unrecognized scopes match no records. |
Backend as source of truth | The server always enforces access rules. Frontend visibility controls are supplementary and never relied upon for security. |
Record-level filtering in the query | Scope-based filters are applied directly in database queries, not as post-processing. Unauthorized records are never fetched from the database. |
Field-level filtering after the query | Sensitive fields (particularly compensation data) are removed from results after retrieval, ensuring responses contain only the fields the user is authorized to see. |
Encryption at rest and in transit | All data transmission occurs over HTTPS. Sensitive credentials such as integration API keys are encrypted using AES-256-GCM with envelope encryption backed by Google Cloud KMS. |