--- title: "About Policies" slug: "about-policies" status: "update" updated: 2025-11-10T11:10:41Z published: 2025-11-10T11:10:41Z canonical: "docs.plainid.io/about-policies" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.plainid.io/llms.txt > Use this file to discover all available pages before exploring further. # About Policies ## Understanding Policies in the {{variable.PlatformName}} An **Authorization Policy** defines the relationship between **Who** (Identities) and **What** (Assets). When an Identity, typically represented as a user in a Dynamic Groupm wants to perform an **Action** on an Asset, the Platform determines which Policies apply and what access is allowed. Policies can grant access to Assets or define permissions for specific actions, such as view, update, delete, or approve. The **Application** is the mechanism through which the Identity interacts with the Asset to perform the Action. To make Policies more granular, additional objects like **Conditions** are used. Conditions define *when* access is allowed, based on factors such as date and time, IP address, Identity Attributes, and Request Attributes. **Example:** A **manager** accessing their **account via an online application** during **working hours**. ## Policy360 Policy 360° provides a unified view of all Policies within the {{variable.PlatformName}}. It combines every aspect of a Policy, including its logic, metadata, dependencies, and lifecycle, into one intuitive interface. This view lets you **navigate**, **edit**, and **manage Policies** in a single location. With Policy 360°, you can: - **Review** and **modify** Policy logic in structured Rego or vendor-native formats. - **Define** and **apply** business rules to ensure consistency and compliance. - **Add** metadata to improve traceability and auditing. - **View** dependencies to understand how changes affect other Policies before implementation. In large or complex environments, Policies often exist across multiple systems, which makes it difficult to maintain visibility, control, and compliance. **Policy 360° resolves this issue by serving as a single source of truth for all Policies in the {{variable.PlatformName}}.** It increases transparency, enforces consistency and governance, improves operational efficiency, and reduces risk by giving you full visibility into Policy relationships and dependencies in one view. Refer to [Managing Policies](/v1/docs/managing-policies-1){target=`_blank`} for more information. ![Policy-360-Final-GIF.gif](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/Policy-360-Final-GIF.gif){height="" width=""} --- ## Policy Catalog The **Policy Catalog** contains all Policies within the Environment, regardless of how they were created, whether via the Policy Wizard, imported as Rego code, or discovered from third-party vendors. When a Policy is created, it consolidates all elements into a logical expression of the Organization’s authorization requirements, including: * Assets and Asset Types * Identity Attributes * Asset Attributes * Policy Custom Attributes * Actions * Rulesets * Conditions * Applications * Scopes Policies can be assigned to existing Dynamic Groups or to new Dynamic Groups created during Policy creation. You can configure as many Policies as needed to fulfill the Organization’s business requirements. **Example:** In an online knowledge base containing marketing, sales, and technical materials, a Policy can define which departments can access marketing and sales content versus technical content. Each Policy consists of one or more **Rules**, grouped into a **Ruleset**. Each Policy must have at least one Ruleset, which must contain at least one Rule. --- ### Policy Icons | **Icon** | **Meaning** | | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | ![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28280%29.png){height="" width="33"} | Policy is **Inactive** and not considered in authorization decisions. | | ![image.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image%28281%29.png){height="" width="33"}| Policy Type is **Restrictive**. | | ![Icon.png](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/Icon.png){height="" width="33"} | Policy is **incomplete** and cannot be used in Authorization decisions. | --- ### Incomplete Policies If a Policy has not been completed, a red dot will appear next to the Policy listing in the Policy Catalog and the Policy will not be active. Once you complete the required configurations, the red dot is removed and the Policy will be applied appropriately. ### Active/Inactive Policies Active Policies are included in Authorization decisions. By default, Policies are **Active** when created or imported. Inactive Policies can be used for testing or onboarding. Importing an Inactive Policy into a new Environment sets it as Active in the target Environment. **Updating a Policy does not change its status**. See [Managing Policies](/v1/docs/managing-policies){target=`_blank`} for more information. ### Restricted/Allowed Policies Policies can be configured to either restrict or allow access. A Restricted Policy enforces limitations by denying access when its conditions are met. An Allowed Policy explicitly grants access under the defined conditions. This flexibility lets you decide whether a Policy functions as a safeguard (restricting) or as a permission enabler (allowing), depending on your authorization requirements.