Skip to content

Policy Scoping and Assignment

Policy scoping controls where a policy applies. You can scope policies to the entire organization, to specific projects, or to sub-projects. When multiple policies of the same kind apply, scoping determines which one wins.

Scope levels

Scope Applies to Use case
Organization All projects and sub-projects Default rules for your entire organization
Project A single project and its sub-projects Project-specific triage or ownership rules
Sub-project A single sub-project only Team-specific overrides within a shared project

Setting the scope

In the UI

  1. Open a policy from Policies in the left sidebar.
  2. Click the Scope tab.
  3. Choose one of:
    • Organization-wide — applies everywhere
    • Specific projects — select one or more projects
    • Specific sub-projects — select one or more sub-projects
  4. Click Save.

Via the API

curl -X PATCH https://mayoaspm.com/api/policies/{policy_id}/scope \
  -H "Authorization: Bearer mayo_ak_..." \
  -H "Content-Type: application/json" \
  -d '{
    "scope": "project",
    "project_ids": ["proj_abc123", "proj_def456"]
  }'

Precedence rules

When multiple policies of the same kind match a finding or asset, the most specific scope wins:

Sub-project policy  >  Project policy  >  Organization policy
(most specific)                           (least specific)

Example

Suppose you have three triage policies:

Policy Scope Rule
org-triage Organization Accept critical, reject info
payments-triage Project: payments Accept critical and high
payments-api-triage Sub-project: payments/api Accept all severities

For a finding in the payments/api sub-project:

  • payments-api-triage applies (most specific)
  • payments-triage and org-triage are overridden

For a finding in the payments/web sub-project:

  • payments-triage applies (project scope)
  • org-triage is overridden

For a finding in the identity project:

  • org-triage applies (only matching scope)

Viewing effective policies

To see which policies actually apply to a project or sub-project:

  1. Open the project or sub-project.
  2. Click the Policies tab.
  3. The Effective Policies view shows all active policies, grouped by kind, with their source scope indicated.
Effective Policies for: payments/api

Kind        Policy                  Scope           Status
────────    ──────────────────────  ──────────────  ─────────
Triage      payments-api-triage     Sub-project     Active
Priority    org-priority-scoring    Organization    Inherited
Ownership   payments-ownership      Project         Inherited
PR Scan     strict-pr-gate          Organization    Inherited

Inherited

Policies marked "Inherited" come from a parent scope. They apply because no more specific policy overrides them.

Combining vs. overriding

By default, a more specific policy replaces a less specific one of the same kind. However, you can configure a policy as additive:

Mode Behavior
Override (default) Replaces less-specific policies of the same kind
Additive Runs alongside less-specific policies; all decisions are collected

Conflict resolution in additive mode

If an additive policy and an inherited policy produce conflicting decisions (e.g., one says accept and the other says reject), the more specific policy's decision wins.

Setting the mode

In the policy editor, toggle Additive mode under the Scope tab.

Multi-project scoping

A single policy can be scoped to multiple projects:

  1. Open the policy's Scope tab.
  2. Select Specific projects.
  3. Check multiple projects from the list.
  4. Click Save.

This is useful for shared rules that apply to a subset of projects — for example, all PCI-relevant projects sharing a compliance triage policy.

Scope and policy lifecycle

Action Effect on scoped policies
Delete a project Policies scoped only to that project are deactivated (not deleted)
Delete a sub-project Policies scoped only to that sub-project are deactivated
Merge projects Policies from absorbed projects are re-scoped to the surviving project

Best practices

  1. Start with organization-wide policies — cover the common cases first.
  2. Add project-level overrides sparingly — only when a project genuinely needs different rules.
  3. Use sub-project scope for team ownership — different teams within a monorepo can have different ownership policies.
  4. Review effective policies regularly — ensure that overrides haven't created blind spots.
  5. Document scope decisions — use the policy description field to explain why a policy has a specific scope.

Next steps