There is a common misperception that Workday security is a purely technical undertaking and that “IT or the system integrator (SI) will know what roles we need, so we won’t need to worry about it.” Unfortunately, this is not true.
Quite the opposite, in fact. In the event there is a security incident, it is ultimately the business that will be impacted through exposure to financial risks. Therefore, it is of utmost importance that the business leadership is fully engaged in and takes ownership of security, both during and after implementation. Never leave system security for the end of the implementation.
At its core, Workday is built on a robust, secure foundation that couples governance and compliance with security and internal controls. Workday functionality offers the ability to leverage systematic checks and balances to reduce manual controls and automate future state processes. It is important to consider these while developing the Workday future state operating model.
The Workday Security Model
The Workday Security Model is logically segmented across Workday Domains and Business Process Security. Access to permissions within these domains and business processes is governed via security groups to which users can be added or removed. Businesses should design their security model to meet their business requirements and consider sensitive access and Segregation of Duties (SoD) conflicts.
Workday Domain Security controls what tasks, actions, and reports a user can perform or run. Examples of these types of actions are View, Modify, Get, and Put.
Business Process Security controls access to workflow approvals, routing, and data during the transactions. Examples of these types of actions include Initiate, Review, Approve, and Rescind.
For a user to complete a specific activity within Workday, the user must have access to both the appropriate domain and sub-tasks within the business process.
The Impact of Workday on Process and Internal Controls
Workday will facilitate numerous process enhancements, but it will also impact and change many of the existing internal controls and Sarbanes-Oxley (SOX) measures. Companies implementing / utilizing Workday should identify and address these changes in the following areas:
- Business Process and Controls – Mechanisms within the system that affect how Workday supports related processes, including automated workflows, key parameters and thresholds, and master data conversion and governance (i.e., master and transaction-level data).
- System Development Life Cycle (SDLC) – Controls that provide the assurance to both management and external auditors that Workday has been designed, configured, and tested appropriately, including documented requirements and design approval; completed test plans, test scripts, and test results; and a detailed and documented plan cutover strategy and execution.
- Security and Segregation of Duties (SoD) – These controls ensure that only authorized personnel can perform applicable functions, such as establishing an overall security architecture, creating new Workday custom roles, and defining user access privileges (e.g., system administrator, user access to powerful or sensitive areas within the system, and clearly defined segregation of duties).
- IT General Controls (ITGCs) – Even in a Cloud environment, companies will retain responsibility for various IT general controls and processes, including security administration and user provisioning, system configuration changes, and Workday integrations to other systems.
Your business leadership should remain current with emerging regulations and continually monitor Workday security design for sensitive access and segregation of duties to minimize the likelihood of security breaches or material weaknesses in internal controls.
Key security design considerations for the business include:
- Include security and compliance workstreams in the initial Workday architecture and design phase.
- Identify security owners, reporting, and accountability.
- Require security and controls subject-matter experts from the business to sign off on the business process blueprint documentation.
- Ensure Workday security design mirrors the business process design; otherwise, Workday processes will not work effectively with the security roles delivered by the system integrator and can lead to expensive security redesign projects after the initial implementation.
Always remember: Governance, Security, and Compliance (GSC) underlies everything while you design your system. Don’t leave system security for the end of the implementation or as an afterthought.
If you'd like to learn more about Workday best practices, watch the GRC Days on-demand session by Protiviti, "Best Practices and Tools for an Optimized Workday Environment".