# Policies

### 👥 **Who It Applies To**

| Role           | Capabilities                                                                                                                |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **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](/concepts/data-models/policy-request-and-task-data-model.md#requests) (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](/concepts/data-models/policy-request-and-task-data-model.md) *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
  * *Group Membership*: Used for all group-based (RBAC compliant) accesses. This policy always skips the review step.
* **Versioning**: Once active, policies are immutable; edits create a new version. This ensures historical accuracy in audits.
* **Policy Scope**: Policies apply to Access Requests (new access). They do **not** apply to browser extension-recorded access (current access). Use the **Source** column in each app's User table to distinguish access sources.

:bulb: *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**:
  1. Name the policy, add description/tags.
  2. Define the approval chain by adding review and action steps.
  3. Define assignee(s) (supported types): Admins, App Owner, Manager, Privileged Users, User Groups, Custom Role (from custom layouts).
  4. 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* [Policy, Request and Task Data Model](/concepts/data-models/policy-request-and-task-data-model.md#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

| Action                    | Who performs it                                | What happens                                                                                                  | Why it matters                                                                  |
| ------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **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.              |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.getcakewalk.io/how-to-guides/policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.