Setting Up Security Groups And Access To Your HRIS, HRMS Or HR Software

It could be easily argued that the data contained in your HR application should be the most guarded information in your organization. Social Security numbers are obvious but equally important data to protect includes payroll data, performance history, medical history, and EEO related data. As I mention above, I am not going to address protecting this information from an IT perspective. There is simply too much liability for me to make any statements or recommendations for something on which I am not qualified to offer advice. Make sure to involve your IT staff in your HR application selection process to make sure their security concerns are addressed.

HR applications can benefit many people in your organization. You may permit training managers, risk managers, HR assistants, payroll administrators, IT and others to have limited access to your HR application. HR applications provide the ability of allowing you to setup security groups or SQL roles. Basically, you set up an access group and then add individual employees who will have the same access to that same group.

Before setting up security, it is a good idea to write out the names of those who will need access. Lump those together that will have similar access rights. Now, next to each one of these groups write out what they should and, perhaps more importantly, should not have access to in your HR application.

You are now ready for the first step for setting up security access. Let’s say, for example, that you have four HR assistants who all have equal access rights. In this case, you are going to setup a security group called HR assistants and on a screen by screen, and in some cases field by field, level identify what they can change, view and not view. Once you have setup the security group or SQL role, the next step is to simply add this individual to that group and establish their user ID and password.

Important tip

Once you have established a security group, I highly recommend testing it before you add employees. Create a dummy employee and login using this new security group; move around the application and double check that this group of users does not have any access to critical data they don’t need and that they have access to what they do need to perform their jobs.

I take this one step further. If I have part time users on the system, I only provide them access to what they need. The fewer screens and information they have access to, the easier it is to train them on the application; and the less likely it is they will access an area they should not be able to or create problems within the system.