7.4 Security Policy Activation, Role Assignment & Security Audit

7.4 Security Policy Activation, Role Assignment & Security Audit

Quick Answer: While Domain Security Policies govern what data users can see and modify, Business Process Security Policies (BPSP) govern who can perform operational steps in a workflow. A BPSP defines which security groups can Initiate, Approve, Review, View All, Rescind, or Correct a business process event. Whenever an administrator alters a DSP or BPSP, the change is held in a staged Pending state with zero operational impact in the tenant. To push changes into active memory, an administrator must execute the Activate Pending Security Policy Changes task, providing a mandatory, immutable audit comment. Troubleshooting security discrepancies relies on diagnostic tasks such as View Security for Securable Item and Test Security Group Membership.

---

Business Process Security Policies (BPSP) Architecture

Every business process definition in Workday (such as Hire, Change Job, Request Compensation Change, Terminate, or Create Position) is paired with a dedicated Business Process Security Policy (BPSP). The BPSP controls the operational rules of engagement for that workflow.

The Functional Scope of BPSPs

While a Domain Security Policy controls access to individual securable fields and report data, a Business Process Security Policy controls the lifecycle of an operational transaction:

+---------------------------------------------------------------------------------------------------+
|                         BUSINESS PROCESS SECURITY POLICY PERMISSIONS                              |
+---------------------------------------------------------------------------------------------------+
|  1. WHO CAN INITIATE                                                                              |
|     - Defines which security groups can start the business process event.                        |
|     - Example: 'Manager' and 'HR Partner' can initiate 'Change Job'.                              |
|                                                                                                   |
|  2. ACTION STEP ACTORS & APPROVERS                                                                |
|     - Defines which security groups can be assigned to Approval, Review, or Action steps.        |
|     - Example: 'Compensation Partner' can approve salary changes; 'VP' approves promotions.       |
|                                                                                                   |
|  3. WHO CAN VIEW ALL                                                                              |
|     - Permits security groups to see all instances of the business process and full event history |
|       across their organizational security scope, even if not an active approver.                 |
|                                                                                                   |
|  4. RESCIND, CANCEL & CORRECT                                                                     |
|     - Rescind: Completely reverses an already completed business process event.                   |
|     - Cancel: Aborts an in-flight, unapproved business process event.                             |
|     - Correct: Modifies specific past data values within an active or completed event.            |
|                                                                                                   |
|  5. REASSIGN                                                                                      |
|     - Permits an administrator to reroute a pending approval step from one user to another.      |
+---------------------------------------------------------------------------------------------------+

Domain Security Policy (DSP) vs. Business Process Security Policy (BPSP)

Understanding the architectural distinction between DSPs and BPSPs is one of the most heavily tested domains on the Workday certification exam:

---

The Dual-Key Security Requirement (DSP + BPSP Alignment)

A common real-world defect and frequent certification trap is the Dual-Key Security Requirement. In Workday, granting a user permission in a Business Process Security Policy to initiate a process is not sufficient to successfully complete the transaction if they lack the corresponding permissions in the underlying Domain Security Policy.

The Operational Failure Mode

Consider an enterprise configuring the Change Job business process:

• Key 1 (BPSP): The administrator adds the Manager security group to the Who Can Initiate section of the Change Job BPSP.
• Key 2 (DSP): However, the administrator forgets to add Manager with Modify permission to the domain Worker Data: Job Information.
• The Consequence: The manager clicks on a direct report, opens the Related Actions menu, and sees the Change Job task (because BPSP allows initiation). However, when the form loads, the job profile, business title, and scheduled hours fields are read-only, blank, or completely hidden. When the manager attempts to submit, the system halts with an authorization error.
• The Rule: Both keys must turn simultaneously. The user must have BPSP Initiate permission to launch the workflow, AND DSP Modify permission on every securable domain whose fields are updated during that transaction.

+---------------------------------------------------------------------------------------------------+
|                             THE DUAL-KEY SECURITY REQUIREMENT                                     |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|       KEY 1: Business Process Security Policy            KEY 2: Domain Security Policy            |
|       - Governs: Can the user INITIATE the workflow?     - Governs: Can the user MODIFY the data? |
|       - Setting: Change Job BPSP -> Initiate             - Setting: Worker Data: Job Info -> Modify|
|                        |                                                 |                        |
|                        +-----------------------+-------------------------+                        |
|                                                |                                                  |
|                                                v                                                  |
|                                     BOTH KEYS MUST BE PRESENT                                     |
|                                 [ SUCCESSFUL TRANSACTION COMMIT ]                                 |
|                                                                                                   |
|       If Key 1 is missing: Task does not appear in Related Actions menu.                          |
|       If Key 2 is missing: Task launches, but fields are uneditable, blank, or error on submit.  |
+---------------------------------------------------------------------------------------------------+

---

The Pending Security Policy Mechanism

Whenever an administrator edits a Domain Security Policy or Business Process Security Policy, Workday does not write those changes immediately to the active in-memory security graph. Instead, the changes are placed into a staged Pending status.

Architectural Rationale for Pending State

1. Atomic Batch Commits: Security reconfigurations frequently span multiple related domains and business processes (e.g., configuring an entire new onboarding workflow with five domains and two BPSPs). If changes took effect piecemeal upon saving, users could encounter partial security states, data corruption, or broken workflows in mid-flight.
2. Runtime Isolation: The running tenant continues to execute against the active, compiled security snapshot in memory without interruption while administrators stage complex policy updates.
3. Audit and Verification: Staging changes into a pending queue allows security administrators to review the comprehensive list of all pending security changes using the View Pending Security Policy Changes report before committing them to the tenant.

---

The Activate Pending Security Policy Changes Task

To commit staged policy modifications into active runtime memory, an authorized administrator must execute the Activate Pending Security Policy Changes task.

+---------------------------------------------------------------------------------------------------+
|             ADMINISTRATIVE WORKFLOW: ACTIVATE PENDING SECURITY POLICY CHANGES                     |
+---------------------------------------------------------------------------------------------------+
| Step 1: Stage Policy Edits                                                                        |
|         Admin edits DSPs and BPSPs. Changes accumulate in the Pending Changes cache.              |
|                                                                                                   |
| Step 2: Launch Activation Task                                                                    |
|         Task: Search for 'Activate Pending Security Policy Changes'                               |
|                                                                                                   |
| Step 3: Review Staged Changes                                                                     |
|         Workday displays every domain policy and business process policy with pending edits.      |
|                                                                                                   |
| Step 4: Mandatory Confirmation & Audit Comment                                                    |
|         - Check the 'Confirm' checkbox                                                            |
|         - Enter an 'Audit Comment' detailing the business reason and change request ticket #      |
|                                                                                                   |
| Step 5: Runtime Compilation                                                                       |
|         Click OK. The in-memory kernel recompiles the tenant security graph.                      |
|         New permissions take effect immediately across all users and integrations!                |
+---------------------------------------------------------------------------------------------------+

The Mandatory Audit Comment & Compliance Non-Repudiation

During policy activation, Workday enforces strict compliance standards:

• Mandatory Audit Comment: The administrator must enter a descriptive audit comment explaining why the security policy was modified (e.g., "Authorized per IT Change Ticket #CR-88219: Added Regional HR Partners to Compensation Review BPSP").
• Immutable Audit Record: The activation event, system timestamp, administrator identity, and audit comment are permanently written to the tenant security log. This record cannot be altered, overwritten, or expunged by anyone, including named System Administrators.
• SOX Compliance Requirement: External auditors routinely audit this log to ensure that all security activations correspond to approved enterprise change control tickets.

---

Security Diagnostic & Troubleshooting Tools

When a user reports that they cannot access a task, view a field, or receive an approval step, Workday provides specialized administrative diagnostic tools to isolate the issue:

1. View Security for Securable Item

• Accepts any securable report field, operational task, or web service operation.
• Displays the parent domain, functional area, and every security group granted View, Modify, Get, or Put access.
• Quickest way to identify which domain governs an inaccessible field.

2. Test Security Group Membership

• Evaluates a specific worker against a specific security group.
• Outlines whether the worker is an active member and details the exact evaluation criteria (e.g., position held, assignable role held, organization context, or job profile match).
• Solves the question: "Why is Marcus Vance not receiving HR Partner approval tasks?"

3. View Security Group

• Displays all members currently belonging to a security group, as well as all domain policies and business process policies where that group has been granted permissions.

4. Worker Security Profile

• Accessible from any worker's Related Actions menu under Security > View Worker Security Profile.
• Provides a 360-degree inventory of every security group (user-based, role-based, job-based) currently active on that worker's account, along with their assigned organizational boundaries.

---

Certification Pitfalls & Common Exam Traps

1. The Unactivated Policy Trap (The #1 Security Question on the Exam): An administrator edits a Domain Security Policy to add the Recruiter security group, saves the page, and has a recruiter test the access. The recruiter still cannot see the fields. The exam asks: "What step did the administrator fail to complete?" The answer is always: The administrator failed to run the Activate Pending Security Policy Changes task.
2. The Partial Key Trap: A manager can initiate a promotion, but the new compensation fields are read-only. The exam tests whether you recognize that the manager's security group was granted Initiate on the BPSP, but was not granted Modify on the governing Compensation domain policy.
3. The Uneditable Audit Comment: An exam question might ask how an administrator can correct a typo or update an audit comment on a previously completed policy activation. The correct answer: Activation audit comments are immutable and cannot be edited or deleted.
4. Pending State Isolation: Changes sitting in the pending security queue have zero effect on active users. They do not partially apply, nor do they apply only to administrators. They remain dormant until compiled via activation.