Study guide
7.4 Security Policy Activation, Role Assignment & Security Audit
Workday Human Capital Management HCM
Track your progress as you read
Finished sections get a check mark.
1 Foundation & Navigation
1.1 Workday Cloud Architecture, Tenants & Navigation 1.2 Business Objects, Data Model & Related Actions 1.3 Worker Types, My Tasks & Delegation
2 Organizations & Hierarchies
2.1 Supervisory Organizations & Hierarchy Structure 2.2 Matrix, Location & Custom Organizations 2.3 Cost Centers & Financial Organization Hierarchies 2.4 Reorganizations, Effective Dating & Inactivation
3 Staffing Models & Worker Lifecycle
3.1 Staffing Models: Position Management vs Job Management 3.2 The Hire Process & Contingent Worker Contracting 3.3 Job Changes: Transfers, Promotions & Lateral Moves 3.4 Terminations, Separations & Staffing Audit Trails
4 Jobs, Positions & Headcount Management
4.1 Job Profiles, Families & Management Levels 4.2 Position Creation, Restrictions & Availability Dates 4.3 Managing Positions: Close, Freeze & Requisitions
5 Business Process Framework Fundamentals
5.1 Business Process Definitions & Flow Architecture 5.2 Step Types: Actions, Approvals & Approval Chains 5.3 To-Do Steps, Checklists & Integration Steps 5.4 Completion Order, Parallel vs Serial Routing, Conditions & Advanced Routing
6 Advanced Business Process Administration
6.1 Event Operations: Rescind, Cancel, Correct & Mass Operations 6.2 Effective Dates vs Entry Moments & Subprocess Execution 6.3 Service Center Routing & Workday Illuminate AI for BP Intelligence
7 Configurable Security Architecture
7.1 Security Fundamentals: Domains, Functional Areas & Domain Security Policies 7.2 Role-Based Security Groups: Constrained vs Unconstrained 7.3 User-Based, Job-Based, Segment-Based & Workday-Assigned Security Groups 7.4 Security Policy Activation, Role Assignment & Security Audit
8 Compensation Structure & Plan Design
8.1 Compensation Packages, Grades & Grade Profiles 8.2 Base Pay, Allowance Plans & Period Salary Plans 8.3 Bonus Plans, Merit Plans, Commission Plans & Stock Grants 8.4 Compensation Eligibility Rules, Defaulting Logic & Merit Review Cycles
9 Talent, Performance & Skills Management
9.1 Talent Profiles, Competencies & Certifications 9.2 Skills Cloud, Machine Learning Taxonomy & Skill Matching 9.3 Performance Review Cycles, Goals & Anytime Feedback 9.4 Succession Planning, Talent Pools & 9-Box Matrix
10 Absence Management & Time Off
10.1 Absence & Time-Off Plans, Types & Accruals 10.2 Absence Eligibility Rules, Validation Rules & Calendars 10.3 Leave of Absence (LOA) Types, Pay Status & Return to Work
11 Recruiting & Candidate Lifecycle
11.1 Job Requisitions, Postings & Career Sites 11.2 Candidate Pipelines, Stage Progression & Screening Workflows 11.3 Employment Offers, eSignatures & Ready for Hire Transition
12 Report Writer & Data Visualization
12.1 Building Custom Reports: Types, Columns, Sorting, Filters & Prompts 12.2 Primary Data Sources, Indexed Data Sources & Business Objects 12.3 Calculated Fields: Text, Date, Arithmetic, Logic & Lookup Related Value 12.4 Discovery Boards, Dashboards & Prism Analytics Integration
13 Workday Integrations & Enterprise Interface Builder
13.1 Integration Architecture: Core Connectors, Studio, REST & SOAP APIs 13.2 Integration Security: ISUs, ISSGs & Web Services 13.3 Enterprise Interface Builder (EIB): Outbound Integrations & Transformations 13.4 Enterprise Interface Builder (EIB): Inbound Integrations & Spreadsheet Templates
14 Release Management, Ecosystem & Workday AI
14.1 Semi-Annual Release Cadence, Preview Tenants & Feature Opt-In 14.2 Workday Illuminate AI, AI Assistant & Generative Productivity 14.3 Agent System of Record, AI Governance & Workday Extend
7.4 Security Policy Activation, Role Assignment & Security Audit
Key Takeaways Explain This Topic AI
Business Process Security Policies (BPSP) govern transactional workflow authority, dictating which security groups can Initiate, Approve, Review, View All, Rescind, or Correct a business process.
Modifications made to Domain Security Policies or Business Process Security Policies enter a staged 'Pending' status and have zero operational effect until explicitly activated.
The 'Activate Pending Security Policy Changes' task requires a mandatory, auditable confirmation comment and timestamp that cannot be retroactively altered or deleted.
Successfully executing a transaction requires simultaneous alignment between the BPSP (authorizing workflow initiation) and the DSP (authorizing field-level data modification).
Diagnostic tasks such as 'View Security for Securable Item' and 'Test Security Group Membership' serve as the primary administrative tools for resolving authorization gaps.
Last updated: September 2026
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:
- Feature Domain Security Policy (DSP) Business Process Security Policy (BPSP)
- Primary Purpose Governs access to Data and Securable Items Governs access to Workflows and Actions
Core Permissions View, Modify (Users) / Get, Put (Integrations) Initiate, Approve, Review, View All, Rescind, Correct
Scope of Protection Securable report fields, tasks, web services Steps and operational actions within a business process
Runtime Evaluation Evaluated whenever a field, report, or task renders Evaluated when an event is launched, routed, or edited
Workflow Routing Does not route items to My Tasks / Inboxes Directly controls task routing to My Tasks / Inboxes
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
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.
Runtime Isolation: The running tenant continues to execute against the active, compiled security snapshot in memory without interruption while administrators stage complex policy updates.
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
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 .
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 .
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 .
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.