Policies
Policies in Cakewalk dictate routing of access requests and tasks. They specify approvers, sequence, and conditions. Clear policies ensure consistent, compliant, and auditable access governance.
👥 Who It Applies To
Users
Cannot create or edit policies. Policies determine how their requests are routed.
Managers
Approve requests if they are part of a policy chain (e.g., first-line approver).
App Owners
Manage the policies assigned to the apps they own as well as approve requests for their apps if included in a policy chain.
Admins
Create, edit, assign and manage policies. Can override or enforce defaults.
📖 Key Concepts
Policies: Define the workflow for requests in Cakewalk, specifying review and action steps with assigned approvers.
Request Types: Every policy is tied to a request type (e.g., Grant Access, Change Permissions, Remove Access, Add New App, Archive App).
Assignment Levels: Policies can be applied on three levels:
Global: Applies to all apps by default for a given request type.
App: Applies to one specific app for a given request type.
Permission: Applies only to certain permission levels inside an app for a given request type.
See the Policy, Request and Task Data Model for details on how assignment levels connect to requests and tasks.
Default Policies: Cakewalk ships with built-in policies so governance works out of the box:
Grant Access: Manager → App Owner
Change Permissions: Manager → App Owner
Remove Access: App Owner only
Add New App: Admins only
Archive App: App Owner only
Versioning: Once active, policies are immutable; edits create a new version. This ensures historical accuracy in audits.
💡 Why this matters: Policies ensure consistent governance, align with compliance frameworks (SOC 2, ISO, SOX) and provide an auditable trail from request → task → decision.
🛠 Policy Workflows
Create Custom Policies
Navigation: Settings → Policies → + New Policy
Steps:
Name the policy, add description/tags.
Define the approval chain by adding review and action steps.
Define assignee(s) (supported types): Admins, App Owner, Manager, Privileged Users, User Groups, Custom Role (from custom layouts).
Save and assign.
Why this matters: Custom policies let you tailor workflows to compliance needs or internal processes while maintaining auditability.
Assign Policies
Navigation: App detail → Policies tab or Settings → Policies → Define global default policies.
Actions:
Assign at global level → applies to all apps by default for a given request type.
Assign at app level → applies to one specific app for a given request type.
Assign at permission level → applies only to certain permission levels inside an app for a given request type.
See 📜 Policies for examples of how these levels affect workflows.
Why this matters: The three-tier model ensures consistency across the org, while still allowing app-specific or permission-specific policies where needed.
Manage Existing Policies
Navigation: Settings → Policies.
Actions:
View active policies.
Edit policies (creates new version).
Track which apps and permissions each policy applies to.
Audit past versions.
Why this matters: Centralized visibility prevents policy drift and simplifies compliance audits.
📋 Policy Actions at a Glance
Create Custom Policy
Admins
Define approval chains and assign approvers (Admins, Owners, Managers, Groups, Roles, Privileged Users).
Tailors governance to compliance frameworks and org-specific needs.
Assign Policy
Admins (any), App Owners (owned apps only)
Apply a policy at global, app, or permission level. See Data Model for how this maps to requests & tasks.
Balances consistent governance with app-specific or entitlement-specific needs.
Edit / Version Policy
Admins
Edits create a new immutable version.
Maintains historical traceability and audit accuracy.
Audit Policies
Admins (any), App Owners (owned apps only)
View full lineage of policies, versions and related requests/tasks.
Critical for SOC 2, ISO 27001, SOX compliance and external audits.
Last updated
Was this helpful?