Configuration change management in Workday: Seven secrets for better audit outcomes

Many auditors are homing in on configuration change practices for Workday as an integral part of their financial statement and integrated audits. Configuration change controls are a foundational requirement in many audits. As Workday increases its enterprise footprint, especially with Workday Financials, many companies and key stakeholders such as internal/external auditors are asking questions about how they can define effective Workday configuration management controls to help meet audit and internal control regulatory requirements.

Workday provides an evolving toolset to control tenant configuration changes. However, companies should have a sound approach to help confirm configuration change controls are both effective and audit ready.

To help companies navigate their options, we curated the following seven secrets to Workday configuration change management for better audit outcomes.

1. Assess risk and define scope

One of the more important Workday configuration change control practices is effective scoping supported by a detailed risk assessment. Effective controls can help address risks that matter. This requires forming an opinion on the relationship between risk (financial, operational, fraud) and specific Workday configurations. Focus configuration management activities on the risks that matter by specifying the tasks and object instances relevant to management’s risk management objectives. These include configurations accomplished via tasks, business processes, domains, custom reports, and integrations systems. Make sure to document risk assessment and scope rationale. This can be a big undertaking, but it can pay dividends by reducing scope and effort over time.

2. Write a Workday configuration change policy

Memorialize expected change management practices in a formal policy. Not only does a policy help educate internal stakeholders, it also can help establish a control baseline used by audit teams. An effective policy should address the following.

• Workday changes and customer-initiated changes: Workday changes include weekly updates and semi-annual updates. Customer-initiated changes are those performed by company stakeholders. The processes and tools used for each are different.
• Risk level: Higher risk changes should follow a more rigorous process. Consider using the policy to stipulate what constitutes a higher risk change based on risk assessment results from #1 above and clarify control requirements, including testing requirements, for higher risk versus lower risk changes.
• Implementers and privileged access: Implementers shouldn’t have update/modify access to production systems after hyper-care, but they typically do. In cases where implementers require access to support production activities, program change production activity should be reviewed for propriety.
• Object Transporter 2.0 (OX): Limit changes made directly to production using OX which allows designated user accounts to create and migrate configuration packages. OX helps provide a more controlled migration path that should be used when possible (OX is typically not available for every object type, therefore some changes need to be made directly in Production).
• Segregation of duties: Because configuration changes are frequently made directly to production companies should apply Segregation of Duties principles between workers making, approving, and migrating changes versus those which can transacted within the tenant. A second set of eyes can help reduce risk.
• Approvals: Workday doesn’t capture approvals before configuration changes can be made. Specify when approvals are required and how approvals are recorded and retained. Be aware that matching change tickets and related approvals to configuration changes in Workday can be difficult. Establish policy stipulates controls that can streamline audit evidence requirements.

3. Coordinate with auditor

Use suggested risk assessment and policy (tips #1 and #2) to educate audit teams (external financial statement auditor, internal auditor) on the rationale for how configuration change risks can be managed, and which approach is more appropriate. Have a dialog that enables alignment. Doing this early can streamline your audit and likely improve audit results. An important part of this alignment process is agreeing on the types of configuration changes, the associated risk of the changes, and the level of control designed for higher risk configuration changes. At a minimum, a short list of higher risk business processes, tasks, reports and integration systems should be considered for more robust change management practices. Obtain buy-in on these key configurations once identified.

4. Be aware of interrelated changes

Changes to Workday configurations (technically, object instances) can affect multiple other configuration elements. Workday calls this relationship object lineage. For example, changing a calculated field may change a report where the field is used. This can lead to reporting complexities and difficulty identifying changes related to key configurations. See tip #6 to confirm your approach captures interrelated changes, where possible.

5. Know these standard reports

There is no one singular report to get a population of all changes made during an audit period. There is just too much audit data in Workday. That’s why a risk assessment (see #1) can be so important. But Workday does come ready with multiple audit reports that are helpful. Here are a few reports you should know:

• Audit Trail Report
• ‘View Audit Trail’ off the related action
• View User or Task or Object Audit Trail (UTO)
• Audit Trail – Business Process Definition
• Audit Trail – Custom Report Definition
• Audit Trail – Integration
• Audit Trail – Security
• View User Activity
• Business Process Security Policy History
• Domain Security Policy History

Most companies use both standard and custom reports to meet their configuration change control requirements. Many of these reports can be customized with filters and work tags to help focus on certain types of configuration changes.

6. Monitor higher-risk changes

Ultimately in an audit, companies may have to demonstrate that change controls are effective. To this end companies may have to incorporate configuration change monitoring controls to help provide comfort that higher risk changes are known, approved and appropriate. The approach used varies based on the type of change.

a. Use audit tags: Audit tags allow companies to select specific business processes, reports, integrations, and security group to monitor. Even better, audit tags can help address object lineage challenges noted in #4.

b. Use transaction reports: Configuration changes made outside of taggable instances aren’t currently monitored by audit tags. To help monitor changes made by tasks, use custom reports built on top of processed transaction data to identify and report on selected configuration changes.

7. Be ready to prove completeness and accuracy

Using Workday custom reports likely requires companies to evidence that the custom reports are complete and accurate (applicable to certain types of audits). This type of validation can be very time consuming, or worse, lead to control deficiencies if not properly performed. To mitigate the risk, explore completeness and accuracy requirements with audit teams early, and incorporate the requirements into control design procedures.

Don’t underestimate the complexity and effort required to design configuration change controls in Workday. Avoid audit surprises and streamline your audit process by considering these tips early in the transformation process and audit cycle. And consult with experts early.

Contact us or learn more about how PwC can support your Workday journey with effective security and internal controls.