Perspectives on Security in HRSD: COE Security Policies

I've been working on ServiceNow's HR Service Delivery Application from the time it was originally offered through the mature product that we have today. Throughout that time, one of the most common topics that many clients have struggled with is how to appropriately secure their data in HR.  

 For the last four years, ServiceNow has possessed a configurable technology to protect cases in a fashion that doesn't require even a line of coding, but I rarely see it adopted when reviewing existing environments. The intention of this blog is to raise awareness and give a few basic approaches for clients looking to further their intra-HR security standards.   

The Problem 

HR Services have a wide array of different process areas- ServiceNow has grouped these into Centers of Excellence (COEs)- think topics like Benefits, Payroll, or Employee Relations. For clients that have a small number of HR Agents overall, it may not be critical to divide visibility amongst these agents. For clients where their HR service desk can number in the dozens if not hundreds of agents, exposing all case data to so many individuals can pose a huge risk. 

The Options 

To solve this issue, there are two basic options: 

1. Access Control Lists (ACLs): ACLs are the first line of defense in controlling who can access specific data within ServiceNow and are a globally present. They define permissions for accessing records and fields, ensuring only authorized users can view or modify sensitive information. Within HR, the ACLs rely upon heavy scripting (present baseline with the platform) and can be extremely challenging to maintain customizations as you expand your use cases. You may even open up unintended security loopholes. Key: ACLs grant access to users with particular roles. 

2. COE Security Policies: COE (Center of Excellence) Security Policies allow for more granular control over data access based on specific criteria, such as role, department, or location. These policies can be tailored to meet the unique needs of different HR functions, providing a robust framework for protecting sensitive HR data. Key: COE Security Policies grant access in particular groups. 

→ Side Note: Security Advantages for Employee Relations 

Employee Relations cases often involve highly sensitive information that requires extra layers of security. Many of these needs are addressed in the baseline Human Resources: Employee Relations scoped application. We will cover the security features of Employee Relations in a later blog in this series. 

So, how do they work? 

When you define a COE Security policy, you are setting values for the following elements: 

With this, you can create a COE Security Policy for Benefits Cases where the subject person is from the United States and only allow the US Benefits group access. All other HR groups, be they benefits or otherwise, cannot see those cases. 

What are the drawbacks? 

I have observed two primary concerns that keep clients back from diving into COE Security Policies: 

1  Fear around how to structure them: given you might need one or more for each COE, potentially several, the number of COE Security Policies can quickly grow and become a source of concern for maintenance and regression testing. Many clients try to blend different strategies (see below) and wind up unintentionally providing or withholding access. 

2  Impacts to User Experience: With either ACLs or COE Security Policies, when viewing a list in ServiceNow of records you don't have access to, you will see a message saying a certain number have been removed due to security constraints. Typically with ACLs we would advise to create a Before Query business rule, allowing you to filter out inapplicable cases and only showing the user what they should see. Due to the potentially complex stacking of COE Security Policies, this is not advised. We instead recommend you mitigate this impact by using aligning group filters in your Agent Workspace, directing agents to only the cases they should be seeing via breadcrumbs. 

Some basic strategies: 

How should you structure them is often a question that we work through in workshops. I see clients initially opt for one of 3 approaches: 

Role-Based Access: COE Security Policies can be configured to grant access based on user roles. This means that HR personnel in benefits administration can only access case data relevant to their function, while those in onboarding or payroll have access to entirely different datasets. 

Organization-Specific Access: By defining policies that align with organizational structures, ServiceNow ensures that data is segmented and protected within each organizational unit, however you define it. For example, an HR agent who supports manufacturing associates cannot see administrative associates' cases and vice versa. 

Location-Based Policies: In global organizations, COE Security Policies can be tailored to comply with regional data protection laws. This ensures that data access is compliant with local regulations, thereby mitigating legal risks and enhancing global data security. 

My recommended approach for most clients: 

Through several dozen HRSD implementations, I've noticed my clients usually align to a structure that is simple & easy to maintain: 

HR Agents: Agents have access to cases that they are either a member of the assignment group or if they are listed as a collaborator. This allows your teams to ask each other for help and grant access on a case-by-case basis. 

HR Management: Allow managers & leadership to see across cases for monitoring & reporting on the overall health of your service delivery. 

This approach allows you to put up easy-to-maintain lines between your assignment groups while granting visibility across all cases to only a select group of individuals. It is to a certain extent "future-proofed" as you can continue to add new HR services and assignment groups with minimal edits or risk of impacts to existing functionality. 

Want more information or to discuss in greater depth? Feel free to request a meeting to get the conversation started. 

For more insights and detailed guidance on ServiceNow security practices, visit our Resource Center.