Mapping business requirements to authorization policy in HR systems

You’re in the process of setting up an Enterprise Human Resources (HR) System for your company, and getting the authorization model right is critical to its success. After collaborating with business representatives, HR analysts, and technical teams, you’ve likely compiled a Business Requirements Document (BRD). Among its many requirements, you’ll find a high-level overview of how system authorization should be structured.

In this blog, we’ll explore best practices for translating those requirements into actionable authorization policies for your HR system. We’ll walk through the process of reviewing business requirements, analyzing them, defining policies, and ultimately deploying them to production systems as efficiently as possible.

This is where the journey to effective authorization policies begins.

Step 1: Review and refine business requirements

Reviewing business requirements for authorization needs is a critical step that must be done carefully, ensuring every detail is accounted for. This process is typically handled by an architect or a team of architects from the implementation team.

The goal of this exercise is to:

• Ensure consistency in policy requirements, avoiding contradictions in policy.
• Identify gaps in the requirements to catch any missing critical policy that may have overlooked a function.
• Eliminate duplicate policies that could lead to redundancy.
• Align policy definitions with business objectives.
• Get the BRD approved by the necessary stakeholders.
• Establish a tracking method to map requirements to policies especially when dealing with hundreds of authorization policies. This is especially useful for determining authorization policies' conformance to BRD.

In HR systems, business requirements often revolve around sensitive data like payroll information, employee performance records, and leave requests. Review the requirements to ensure they are only accessed by authorized roles.

By taking a structured approach, we ensure that authorization policies are both comprehensive and enforceable.

Step 2: Define the access model for your HR system

As our focus in this exercise is on enterprise HR Systems, having a background in HR systems is invaluable when designing authorization policies. It helps you grasp the access model more effectively and ensures policies align with business needs.

When analyzing the BRD, we focus on the following aspects to better understand the access model:

User roles and responsibilities

Identify the various user types interacting with the HR system and define their responsibilities. This understanding is essential for crafting clear and effective authorization policies. For instance, roles might include Line Manager, IT Manager, Finance Team, and others.

Access levels

Define the access levels for each role, specifying what resources they can read, write, update, or delete. For example, an HR Manager, Finance Team, or IT Manager may have distinct permissions. Additionally, identify which roles can delegate access or act as delegates for other users.

Resources

List all resources within the HR system and outline the operations permitted on each. For example:

• Employee Profiles (Personal details, employment history, and performance reviews.): read, write, delete
• Payroll Data (Salary, bonuses, and tax information.): read, write
• Leave Requests (Vacation, sick leave, and maternity/paternity leave.): read, write, delete

Where possible, group resources into categories to simplify policy management and enforcement.

Scope

Define which users can access other users' data. For instance:

• A Line Manager can view and approve leave requests for their managed employees.
• A Finance Manager can view and edit payroll data for all employees.

Compliance and security requirements

Ensure that your authorization policies align with compliance and security standards relevant to your industry. If your company operates under specific regulations such as GDPR, HIPAA, or SOC 2 your HR system must adhere to these requirements to be production-ready.

Segregation of duties

While authorization policies typically focus on whitelisting who has access to what, Segregation of Duties (SoD) takes the opposite approach, it defines blacklisting rules to prevent conflicts of interest and enforce security best practices.

Some sample SoD policies for HR system could be:

1. Finance users should not have a toxic combination of roles, such as the ability to both submit and approve expense requests.
2. Payroll resources should be restricted to payroll team members only and not be accessible by general HR employees.

By addressing these key areas, you create a structured and secure authorization model that meets business and compliance needs.

Step 3: Analysis

The goal here is simple: define clear, effective authorization policies that work seamlessly together without conflicts. Some of the below tools help us guide to that target state.

RACI

RACI stands for Responsible, Accountable, Consulted, and Informed. A RACI matrix informs per resource type, who owns a resource, who should be consulted before it's updated, and who should be informed on when it's accessed or updated. A RACI is a helping tool to guide the building of the authorization policies. A sample RACI matrix looks like this:

Activity	HR Manager	Employee	Payroll Admin	IT Security	Compliance
Define access levels & authorization policies	R	C	C	A	I
Approve/review access requests	A	C	R	I	I
Request access to personal records	I	R	I	I	I
Approve leave requests	R	C	I	I	I
View payroll details	I	I	R	I	I
Modify employee records	R	I	I	I	I
Audit user access & authorization policies	I	I	I	R	A
Enforce security & compliance policies	I	I	I	R	A

Legend

• R (Responsible) – The person who does the work to complete the activity.
• A (Accountable) – The person who is ultimately answerable for the correct completion of the activity.
• C (Consulted) – The person who provides input or expertise before the activity is completed.
• I (Informed) – The person who is kept informed about the activity.

The RACI Matrix is a valuable tool for defining who is responsible for access-related decisions and actions. It helps identify key decision-makers involved in access control policies, such as those who approve access requests or audit access rights. By clarifying roles and responsibilities, the RACI Matrix ensures that authorization policies are implemented and maintained effectively, with clear accountability at every step.

Roles and resources matrix

Once you have a clear understanding of user roles and resources in the HR system from the BRD, you can create a roles and resources matrix, which serves as the foundation for Role-Based Access Control authorization policies. The sample matrix below provides a structured approach to defining access control, helping you establish the initial set of authorization policies.

Resource Type	Action	IT Admin	Line Manager	Finance Manager	Scope of Access
Account	Create	x		x	IT Admin → All Users; Finance Manager → All Users
	Update	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Suspend	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Delete	x		x	IT Admin → All Users; Finance Manager → All Users
Expense	Create	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Update	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	View	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Delete	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Approve	x	x	x	IT Admin → All Users; Line Manager → Managed Employees; Finance Manager → All Users
	Mark-as-paid	x		x	IT Admin → All Users; Finance Manager → All Users

The roles and resources Matrix is designed to map which roles can perform specific actions on particular resources. This matrix plays a critical role in translating business requirements into enforceable access control rules or policies, ensuring that the right individuals have the appropriate level of access to the resources they need to perform their duties. By clearly defining these relationships, the matrix helps create a structured and secure authorization framework.

Migrating authorization policies

When migrating authorization policies from a legacy HR system, ensure the following steps are taken to align with business requirements and modern standards:

• Extract and convert the existing authorization policies into a format compatible with the target authorization policy server that will serve the new HR system.
• Conduct a thorough review of the policies, similar to the process outlined in the Step 1: Review and refine business requirements section, to ensure they meet current needs.
• Be mindful that legacy policies are often prone to duplicates and deviations from naming standards, which may require updates for consistency and clarity.
• Address potential role explosion in legacy Role-Based Access Control (RBAC) systems where too many roles with minor differences exist by optimizing them into a smaller, more manageable set of roles using techniques like role mining.

Step 4: Crafting authorization policies that work

Now that we’ve defined the access model, let’s analyze how to translate these requirements into actionable policies. In the authorization world, these policies are defined at the Policy Administration Point (PAP), which can either reside within the application (e.g., the HR system) or in a centralized platform like Cerbos Hub.

Using a Centralized Policy management tool like Cerbos offers significant advantages. It decouples authorization logic from the HR system, reducing dependencies on vendor-specific implementations. This flexibility makes it easier to upgrade or switch HR systems in the future without disrupting business operations.

Another key benefit of Cerbos is that policies are defined in a human-readable YAML format, making them easy to manage and review. Additionally, they can be version-controlled in a Git-like repository, ensuring traceability and governance.

Key considerations for policy definition

Least privileged access

Following modern Zero Trust principles, it's crucial to design authorization policies with Least Privilege Access in mind. This means granting users only the minimum access necessary to perform their duties, reducing the risk of misuse or accidental actions beyond their intended scope.

For example, a Line Manager should only have access to the payroll details of employees they directly manage, preventing unauthorized visibility into broader financial data.

Role-based access control (RBAC) in enterprise HR systems

RBAC simplifies authorization by assigning permissions to roles rather than individual users. Users inherit permissions through roles, which naturally align with job functions, regulatory needs, and compliance policies, making access management easier.

As a structured approach, RBAC is the ideal foundation for authorization policies. The RACI matrix and Roles vs. resource matrix help define clear access rules. For example:

Role	Resource	Permissions
HR Manager	Employee Records	Read, Write, Update
Finance Manager	Payroll Data	Read, Approve
Line Manager	Direct Reports’ Leave Requests	Read, Approve

This ensures clear, secure, and compliant access control for example, an HR Manager can modify employee records, a Finance Manager can approve payroll but not edit employee details, and a Line Manager can only approve leave for direct reports.

Below is a Cerbos policy implementing this RBAC model:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "employee_record"

  rules:
    - actions: ["read", "write", "update"]
      effect: "EFFECT_ALLOW"
      roles: ["hr_manager"]

    - actions: ["read", "approve"]
      effect: "EFFECT_ALLOW"
      roles: ["finance_manager"]

    - actions: ["read", "approve"]
      effect: "EFFECT_ALLOW"
      roles: ["line_manager"]

Attribute-based access control (ABAC) in enterprise HR systems

Once RBAC is in place, ABAC (Attribute-based access control) can be layered to enhance authorization policies. ABAC considers contextual attributes such as department, location, device, risk score, or time of access, allowing fine-grained access control beyond static role assignments.

ABAC helps mitigate the "role explosion" issue in RBAC, where an excessive number of roles is required to cover all access scenarios. A hybrid approach combining RBAC and ABAC is the most effective strategy for organizations to maintain a scalable and adaptable authorization model. For example:

Attribute	Resource	Condition	Permissions
Department	Employee Records	User’s department matches record’s department	Read, Update
Location	Payroll Data	Access is from an allowed office location	Read, Approve
Device	HR Reports	Access is from a company-managed device	Read
Risk Score	Sensitive Data	User’s risk score is below threshold	Read, Update
Time of Access	Leave Requests	Access is within business hours	Read, Approve

This approach dynamically evaluates access conditions instead of relying solely on predefined roles, making authorization more adaptive and secure. Below is a Cerbos policy implementing ABAC for an HR system:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "employee_record"

  rules:
    - actions: ["read", "update"]
      effect: "EFFECT_ALLOW"
      roles: ["employee"]
      condition:
        match:
          expr: request.resource.attr.department == request.principal.attr.department

    - actions: ["read", "approve"]
      effect: "EFFECT_ALLOW"
      roles: ["finance_manager"]
      condition:
        match:
          expr: request.principal.attr.location in ["HQ", "Regional Office"]

    - actions: ["read"]
      effect: "EFFECT_ALLOW"
      roles: ["hr_manager"]
      condition:
        match:
          expr: request.principal.attr.device_trusted == true

    - actions: ["read", "update"]
      effect: "EFFECT_ALLOW"
      roles: ["security_officer"]
      condition:
        match:
          expr: request.principal.attr.risk_score < 50

    - actions: ["read", "approve"]
      effect: "EFFECT_ALLOW"
      roles: ["line_manager"]
      condition:
        match:
          expr: request.env.time.hour >= 9 && request.env.time.hour <= 17

Categorize policies

It pays to have policies categorized for easier management, consider categorizing policies by HR modules such as Core Personnel Management, Performance & Development, Compensation & Benefits, etc., or based on other logical separation that makes sense for your business.

Logging

Implement logging for policy decisions, as it can be particularly valuable for operations teams when investigating incidents or debugging issues. If your system involves hundreds of sequential or layered policies, understanding how the Policy Decision Point (PDP) arrives at an ALLOW or DENY decision becomes critical. To avoid overwhelming log files in production environments where hundreds of policy decisions may occur every second consider configuring these logs in "DEBUG" mode. This ensures logging is only enabled when necessary, keeping your production servers efficient and clutter-free.

Below is an example of how a policy evaluation might be logged in an HR system, showing the decision-making process for an employee attempting to access a payroll record.

Policy:

rules:
    - actions: ["read", "update"]
      effect: "EFFECT_ALLOW"
      roles: ["employee"]
      condition:
        match:
          expr: request.resource.attr.department == request.principal.attr.department

Audit Log:

{
    "timestamp": "2023-01-05T15:51:13Z",
    "requestId": "01GP1A25FW6BVX9JWYM9M6T0Z0",
    "principal": {
        "id": "sally",
        "roles": ["employee"],
        "attr": {
            "department": "SALES"
        }
    },
    "resource": {
        "kind": "employee_record",
        "id": "record123",
        "attr": {
            "department": "SALES"
        }
    },
    "action": "read",
    "effect": "EFFECT_ALLOW",
    "policy": "resource.employee_record.vdefault"
}

The decision arrived at ALLOW for employee Sally accessing her own employee record since:

• ✔ Role "employee" matches policy
• ✔ Department "SALES" is the same for both principal & resource
• ✔ Action "read" is allowed under this policy

Checkout Cerbos Audit logs capability for more information.

Warning mode enforcement for pilot

"Warning Mode" policy enforcement is a piloting strategy where newly developed authorization policies are rolled out in production-like systems with enforcement disabled. Instead of enforcing decisions, the system logs warnings and available for developers or devops engineers for review. This approach is particularly useful in several scenarios:

• The number of warnings logged can help identify policies that are misconfigured or deviate from the Business Requirements Document (BRD) compared to their actual usage in production. Adjustments can then be made accordingly.
• If a policy doesn’t align with business needs as initially planned in the BRD, enforcement could disrupt operations such as payroll processing cycles and performance review duration. Warning Mode allows for a safer rollout.
• In cases where business operations can continue without strict policy enforcement, Warning Mode provides a temporary buffer while policies are fine-tuned in collaboration with decision-makers.

Once the number of warnings logged falls below a predefined threshold, the system can transition from the pilot stage to full production, enabling policy enforcement with confidence. Policy enforcements are typically done at the PEP (Policy Enforcement Points), which can reside at the application layer.

Step 5: Testing policy

As with any development project, testing of the authorization policies forms a key tool of confidence to promote them to production. Testing ensures that the policies you’ve defined align with the business requirements and function as intended in real-world scenarios. Engage the testing team early in the development process to ensure your authorization policies are robust and reliable. The testing team would review the BRD, build documents and architectural diagrams, and come up with a testing strategy and test cases that complement the BRD to gain confidence in its coverage and effectiveness.

With the authorization policies, here are some key points for the testing team to consider:

Unit testing

The team should develop both positive and negative test cases to validate each policy, ensuring they produce the desired outcomes. If Cerbos is being used, the Cerbos Playground can be a valuable tool for testing policies interactively. However, as the number of policies grows into the hundreds and multiple sprint iterations are involved, it’s highly advisable to automate the testing process. This ensures that policies can be validated consistently with each incremental release, saving time and reducing the risk of regressions.

Here are a few examples of unit tests that can be automated using the Cerbos API to validate authorization policies for an HR system:

Test Case 1: Employee access to personal records

• Policy: Employees should only access their own personal records.
• Positive Test:
  • User: Employee A
  • Resource: Employee A’s personal record
  • Expected Result: ALLOW
• Negative Test:
  • User: Employee A
  • Resource: Employee B’s personal record
  • Expected Result: DENY

Test Case 2: Manager access to team records

• Policy: Managers should be able to view their team members’ records but not edit them.
• Positive Test:
  • User: Manager X
  • Resource: Team Member Y’s record
  • Action: view
  • Expected Result: ALLOW
• Negative Test:
  • User: Manager X
  • Resource: Team Member Y’s record
  • Action: edit
  • Expected Result: DENY

Test Case 3: HR admin access to all records

• Policy: HR Admins should have full access to all employee records.
• Positive Test:
  • User: HR Admin
  • Resource: Any employee record
  • Action: view or edit
  • Expected Result: ALLOW
• Negative Test:
  • User: HR Admin
  • Resource: Non-existent employee record
  • Action: view
  • Expected Result: DENY (or appropriate error handling)

---
name: HRSystemAuthorizationTestSuite
description: Tests for verifying access control policies in an HR system

principals:
  employee_a:
    id: employee_a
    roles:
      - EMPLOYEE

  employee_b:
    id: employee_b
    roles:
      - EMPLOYEE

  manager_x:
    id: manager_x
    roles:
      - MANAGER

  hr_admin:
    id: hr_admin
    roles:
      - HR_ADMIN

resources:
  employee_a_record:
    id: employee_a_record
    kind: employee_record

  employee_b_record:
    id: employee_b_record
    kind: employee_record

  team_member_y_record:
    id: team_member_y_record
    kind: employee_record

  non_existent_record:
    id: non_existent_record
    kind: employee_record

tests:
  - name: Employee Access to Personal Records
    input:
      principals:
        - employee_a
        - employee_b

      resources:
        - employee_a_record
        - employee_b_record

      actions:
        - view

    expected:
      - principal: employee_a
        resource: employee_a_record
        actions:
          view: EFFECT_ALLOW

      - principal: employee_a
        resource: employee_b_record
        actions:
          view: EFFECT_DENY

      - principal: employee_b
        resource: employee_b_record
        actions:
          view: EFFECT_ALLOW

      - principal: employee_b
        resource: employee_a_record
        actions:
          view: EFFECT_DENY

  - name: Manager Access to Team Records
    input:
      principals:
        - manager_x

      resources:
        - team_member_y_record

      actions:
        - view
        - edit

    expected:
      - principal: manager_x
        resource: team_member_y_record
        actions:
          view: EFFECT_ALLOW
          edit: EFFECT_DENY

  - name: HR Admin Access to All Records
    input:
      principals:
        - hr_admin

      resources:
        - employee_a_record
        - employee_b_record
        - non_existent_record

      actions:
        - view
        - edit

    expected:
      - principal: hr_admin
        resource: employee_a_record
        actions:
          view: EFFECT_ALLOW
          edit: EFFECT_ALLOW

      - principal: hr_admin
        resource: employee_b_record
        actions:
          view: EFFECT_ALLOW
          edit: EFFECT_ALLOW

      - principal: hr_admin
        resource: non_existent_record
        actions:
          view: EFFECT_DENY
          edit: EFFECT_DENY
        

By automating these tests, the team can ensure that policies are consistently validated across sprints, reducing manual effort and improving reliability.

Integration testing

Perform end-to-end testing with the HR system and your PDP (if your PDP is separate from the application like in Cerbos), to ensure the authorization policies are applied correctly when accessing resources with respective user roles.

UAT and penetration testing

Perform UAT (User Acceptance Testing), by the business users to get business approval on the authorization policies deployed if it aligns with the day-to-day business activities performed on the HR system And perform Penetration testing from expert teams to identify any gaps in the system that has a potential of being exploited by unwanted threat actors.

Step 6: Production deployment

Planning is critical for a smooth production rollout. It’s essential to identify all teams involved, outline their responsibilities during the production change, and create a detailed list of tasks. Estimate task durations, dependencies, and determine which tasks can be completed ahead of time. Conduct a tabletop dry run to identify any gaps in the plan and address them proactively.

Here are some key considerations for a successful production deployment:

• Capture any gotchas, known workarounds, and operational details. Deliver Knowledge Transfer (KT) sessions to the Operations team to ensure they are well-prepared.
• Have a clear rollback strategy in case the deployment doesn’t go as planned.
• Schedule tasks with enough buffer time to accommodate unexpected delays or issues.
• After a successful deployment, closely monitor logs to identify any authorization-related issues.
• Actively monitor feedback and incidents from users and the operations team to detect misconfigured authorization policies.
• Establish a hypercare strategy where the build team remains on high alert for at least the first six weeks post-deployment. This ensures quick resolution of production issues without relying solely on traditional ticketing systems.
• Avoid production deployments during key times such as payroll processing cycles. If the task requires data migrations, like employee records or performance reviews, carefully plan migrations of sensitive data such that access to them is only allowed by authorized personnel at all times.

Wrap

Implementing authorization policies in an HR system is a structured journey from understanding business requirements to deploying secure, compliant policies. Key steps include defining access models, crafting concise policies, rigorous testing, and continuous monitoring. Tools like Cerbos Hub and strategies like warning mode enforcement ensure flexibility and reliability.

The result? An authorization system that just works, is scalable, secure, and aligned with business needs. By following these best practices, you can build an authorization system that protects sensitive HR data while empowering your workforce.

Your journey to effective authorization policies is now complete. 🎉

If you’re interested in implementing externalized authorization - try out Cerbos Hub or book a call with a Cerbos engineer to see how our solution can help streamline access control in your applications.