Viewers & Doers: An Intro to Workday Security
Viewers & Doers: An Intro to Workday Security
As with all new software, when you 're brand new to Workday there 's a lot to learn. One area of functionality that requires special attention is your security permissions.
What Is Workday Security?
Your security groups configuration underpins all of your Workday tenants. These groups fall into three categories: role-based, user-based, and standard worker.
In role-based groups, the role is given certain security permissions and is constrained on a Workday Organisation (for example, Supervisory Organisation, Company, etc). Any worker assigned to that role is able to see key data/perform the actions against workers and objects within the Organisation (for example positions) as specified for that security group.
User-based security access is generally tenant-wide and these security groups contain critical tenant maintenance functions (for example Business Process Administrator, Security Administrator).
Standard workers are security groups that apply across the majority of the worker population (for example Employee as Self).
If you 're like most companies, during implementation you will derive your security configuration from the default Workday security groups and then amend them as you:
- design your business processes;
- define which security groups should be able to initiate/approve business processes; and
- define which security groups should have visibility of key data fields.
When to Test Your Security Configuration and Why
Your business process configuration (your flow and approvals) and security are the two most critical areas of your configuration to test. Yet, security is often overlooked during testing. As it defines what a given person can see in your tenant and which business processes they can initiate, approve, and reject, it 's a critical element of functionality that needs to be tested to give a level of assurance. Here 's when we recommend that you run security tests:
During Implementation
Once all those implementation design decisions are made, it 's important that you stand back and review each of the security groups to assess whether overall tenant access is appropriate. You may have made multiple design decisions about specific business processes that enable a key security group to be the initiator/approver across processes.
A key test at this stage of your Workday journey should be to check that the aggregated decisions that you 've made around BPs don 't give a specific security group too much power or visibility on the tenant (for example, can a given security group initiate a hire and maintain payment elections against the worker?). Once you 've reviewed the security configuration and are comfortable that the available actions and field permissions are correct, this should become your security 'baseline' for future tests.
After a Change
As with implementation, when you 're modifying your tenant or rolling out new functionality, this can initiate a change to your current security configuration or require the introduction of entirely new security groups. When changing security group settings, you should check these against the original design to verify that the incremental changes do not give inappropriate access to the tenant.
When staff are added to more than one group
Within small, core functional teams (HRIS, Finance, etc) individual workers may have multiple roles and user based-security groups assigned to their worker record. It 's possible, for example, for a worker in the HR team to be assigned roles of HR Partner, Absence Partner, Benefits Partner and Comp Partner. When high concentrations of security groups have been assigned, it 's important to ensure that the aggregation of security groups against core workers still maintains an appropriate level of segregation of duties within the tenant.
How to test thoroughly
Ensuring that your worker data is protected and only visible to those who should have access is a legislative requirement for all employers. So you need to test security in line with:
- your security policies,
- your changes to security configuration, and
- as part of an overall regression strategy.
Not only will a thorough test approach help you meet audit/legislative requirements, it will also reduce risk. But there is no silver bullet. You 'll need to prepare. You 'll have to test, either manually or by using an automated tool. Both approaches will require you to draw up a matrix that lists which roles you 're assigning (HR Director, Benefits Partner etc.) to which security group within each organisation on Workday.
You should perform tests that ensure that each security group you 've assigned within your tenant retains the same available action and field permission access to key objects within their span of control. This baseline of available actions and field permissions should then form a point to test against changes that you make to your sandbox (and use the security regression as a key part of your test approach), before promoting to production. You should also run this regression regularly against sandbox and preview to capture potential changes on Workday delivered roles.
In addition, changes to menus and security may form part of Workday 's ongoing releases, and it 's vital that you 're able to pick up changes to these areas of configuration to ensure that your security configuration stays in line with your overarching security policy.
These tests can be time consuming, given the number of actions and fields that a security group has access to. Whether you decide to manually test each user and role against their expected permissions or you decide to employ an automated tool to do that heavy lifting for you, you shouldn 't treat security testing as optional. It 's your configuration 'firewall '.