Considerations for Regression Testing Workday Security

Date posted
16 September 2020
Reading time
12 Minutes
Rachael O'Connell

Why test your Workday Security configuration?

Companies are more accountable to regulators than ever before and the consequences for non-compliance are significant. Your organisation will also want to be confident that its sensitive and commercial transactions are correctly secured to minimise the risk of fraud or costly errors. Evidencing that your security configuration is effective is essential to build that confidence in your organisation's controls and for meeting the audit requirements the current regulatory environment demands. Regular, rigorous testing and record-keeping is vital to meeting these requirements.

Key considerations include:

  • Can your workers only see data which is relevant to them and their jobs?
  • Are you confident that your security roles only have the abilities they need to have?
  • Can you back up your answers to these questions with proof?
  • Is your evidence up to date?

It's important to bear these issues in mind to avoid the significant impacts they can have upon you and your business.

When to test your security configuration?

Ideally, you should test as often as possible. However, there are several periods during the life of your system when comprehensive security regression testing is critical.

During a Workday deployment

To ensure you start your Workday journey well, it's important to review the Security configuration and be comfortable that the available actions and field permissions are correct. Whilst your workers won't be assigned to their specific roles until the later stage of the deployment, early testing of the rights inherited from those groups helps save time and effort as you near go-live. Automating testing during the deployment can free up the test team to help with other roll-out activities, whilst increasing the breadth of coverage.

After a change

When changes have been made, you need to verify that these changes won't expose data to unauthorised persons, create new risks of fraudulent activity or allow transactions by unauthorised users. Whether it's a weekly patch release from Workday or your own day-to-day business as usual changes, inevitably there'll be an impact on Security. A weekly regression test cycle is an excellent way to keep on top of this and allows you to quickly address and assess any potential risks. Regular testing and good record keeping of your test efforts are also a great way to gather evidence that your Security configuration is effective. One of the most efficient ways to do this is to invest in a system that will allow you to track your test results and highlight any issues which are identified as a result of testing.

Bi-annual Workday updates

Twice a year, Workday releases useful new features and functionality to all of its customers. This is an extremely important time for Security testing as the Workday roll out can cause a material change to how your current configuration works. At the start of the release window, you're furnished with a sandbox preview tenant loaded with the updated version which will be refreshed with production data several times. It's best to test your Security configuration immediately after each refresh - this gives you a simple A/B comparison that allows you to clearly spot which processes have been impacted by the Workday update and need attention. The release window is a busy time for testing, meaning your preview tenant dataset can quickly become out of sync with your sandbox tenant, which can make comparisons more difficult. Kainos Smart, our automated testing tool is a great way to increase the efficiency and consistency of your testing. Kainos Smart can carry out Security comparisons across tenants with greater accuracy than manual testing and in a fraction of the time. The resulting comparison is also reported so you can quickly see any differences between the two tenants and take remedial action.

Change Projects

As your organisation undergoes major change projects such as phase-x deployments, or is redesigned to merge, divest or restructure, this will mean considerable changes to your Security configuration and increased risk. As the focus of these projects will often be elsewhere, it can be easy to overlook where a required security update may impact an area outside of the scope of the project. Time should be made to regression test Security within these projects to ensure any unforeseen issues are corrected before the update is promoted to production.

Testing & monitoring your Workday Security configuration

There are several methods to test and monitor a Security configuration. You can employ an audit trail-based approach and regularly review your audit logs and reports to review where domain access for security groups has been changed or updated. However, there is a shortcoming to this approach, which is that it may not break down the individual permissions which have been granted or removed by making these changes. An approach that focuses on the actual actions and data available to your security groups is a great way to test security and track the effects of changes. This approach would be to check the actual tasks, BP and reports (available actions) available to roles and security group holders or a range of objects in your tenant. Take the Workday release window as an example, there won't necessarily be changes registered in your audit logs if Workday update a security domain but there could still be actual changes to security permissions because of it. An "effect-based" approach can highlight such changes.

Additionally, it gives a more wholistic view of where intentional changes your organisation make, may have unintentional effects elsewhere. It also provides a very clear picture of how your testing is working effectively for internal and external audits.

You can add further depth and accuracy to this variety of testing by focusing on workers who hold individual security roles or security groups. This makes it easier to identify the cause of unexpected changes. This approach can also be further enhanced by creating synthetic workers in your test tenant, assigning them your key security groups individually and testing/monitoring their security permissions. The benefit is that these workers will always be the same whereas real workers ' roles can be changed or removed, causing noise in test results

How automation can help

Automation can be the key to unlocking efficient and effective testing for your Workday Security configuration. Kainos Smart checks hundreds of thousands of securable actions and data items at the click of a button and automatically compares against your expectations. Kainos Smart quickly highlights any variation away from those expectations, allowing you to react immediately to problems and instil confidence that your configuration is working as expected. Kainos Smart also has the capability to test HCM, Financials, Payroll, Recruiting, Integrations and Reports, meaning you can gain valuable automated testing and reduced effort and resource requirements for testing across your whole Workday solution.

Want to learn more about Kainos Smart's Security testing capabilities? Request a demo today. Over 200 Workday customer trust Kainos Smart to handle their Security configuration testing.

About the author

Rachael O'Connell