Policy Management
The organization console gives you two complementary tools for managing security policies across the tenants you operate:
- Org Policies (Dashboard > Org > Org Policies) — organization-wide policies that act as a floor underneath every tenant's own policies. They always apply, they combine with tenant policies using most-restrictive-wins rules, and tenant admins cannot edit or remove them.
- Policy Templates (Dashboard > Org > Policy Templates) — reusable policy definitions you curate once and deploy to selected tenants. A deploy stamps a real, independent, tenant-editable policy into each chosen tenant.
Both tools build on the same policy model used inside each tenant — conditions, actions, and priorities — described in Security Policies.
Org Policies vs. Policy Templates at a glance
| Org Policy | Policy Template | |
|---|---|---|
| Where it lives | At the organization level | Template at the org level; deploys create policies inside tenants |
| Which tenants | Every tenant managed by your organization, automatically | Only the tenants you select at deploy time |
| Can tenant admins change it? | No — it is not theirs to edit | Yes — the deployed copy is a normal tenant policy |
| What happens when you edit it | The change applies everywhere immediately | Nothing, until you re-deploy |
| How it combines with tenant policies | Most-restrictive-wins floor | It is a tenant policy after deploy |
| How you remove it | Delete the org policy | Roll back per tenant (record kept) or let the tenant delete its copy |
| Best for | Non-negotiable baseline controls | Starter kits and repeatable per-customer configurations |
The one-sentence rule of thumb: an org policy is a floor that always applies; a template deploy is a one-time stamped copy the tenant then owns.
Org Policies
How they work
Org policies are evaluated alongside each tenant's own policies whenever the browser extension decides how to respond to an event. When both an org policy and a tenant policy match, the outcomes combine using the same most restrictive wins logic used for group policies inside a tenant: block beats warn, which beats learning-only behavior. A tenant admin can always add stricter controls of their own, but they can never relax the outcome below the floor your org policies set.
Two consequences worth internalizing:
- Editing or disabling an org policy changes enforcement in every managed tenant at once, on the next policy sync.
- Org policies do not appear in a tenant's own policy list as editable rows — tenant admins cannot weaken, disable, or delete them.
Using the page
The Org Policies page shows the All org policies list. Each entry displays the policy name, an Enabled or Disabled badge, an optional Locked badge, the description, and its Priority.
[SCREENSHOT PLACEHOLDER: The Org Policies page with the "All org policies" list showing a few policies with Enabled and Locked badges, priorities, and the "New org policy" button]
To create one, click New org policy. The Create Policy editor opens:
- Policy Name and Description — what the policy is for.
- Priority — a number from 0 to 1000; lower numbers are evaluated first.
- Enabled — whether the policy is active.
- Locked — an informational marker indicating this policy is an org mandate that tenants should not work around. It displays a Locked badge in listings; it does not currently change enforcement behavior.
- Conditions — the visual rule builder, matching on fields such as URL Domain, User Action, Credential Reuse, Sensitive Data Type, File Extension, and more.
- Action — Block (block the action entirely), Warn (show a warning, allow proceed), Silent Alert (log an alert with no user-facing UI), or Allowlist (allow only matched domains).
Unlike a tenant policy, there is no "Applies To" section — org policies always apply org-wide.
[SCREENSHOT PLACEHOLDER: The Create Policy editor opened from Org Policies, showing the name, priority, Enabled and Locked checkboxes, the condition builder, and the four action choices]
To edit a policy, click the pencil icon. To delete one, click the trash icon: the Delete org policy confirmation explains that this removes the policy from all managed tenants and asks you to type the policy name exactly to confirm.
Viewing org policies is open to any org role, but creating, editing, and deleting them requires the Org Owner role — see Admins & Access.
Policy Templates
How they work
A template is a curated policy body — name, description, priority, and rules — kept at the organization level. It does nothing on its own. When you deploy a template to a set of tenants, Surface creates a real policy inside each selected tenant with the template's contents. From that moment:
- Each deployed copy is a normal tenant policy. Tenant admins can edit, disable, or delete it, and it drifts independently of the template.
- Editing the template later does not change already-deployed copies. To push an updated version, deploy again: re-deploying to a tenant updates the previously created policy in place rather than creating a duplicate.
- Deploy targets are limited to tenants you have access to (see the per-tenant access matrix in Admins & Access).
Using the page
The Policy Templates page lists All templates with each template's name, optional Locked badge, description, and priority. Each row has four icon actions: deploy (rocket), deployments board, edit (pencil), and delete (trash).
[SCREENSHOT PLACEHOLDER: The Policy Templates page listing several templates with their action icons, and the "New template" button]
Create a template. Click New template. The same Create Policy editor opens; define the name, description, priority, conditions, and action.
Deploy a template.
- Click the deploy icon on a template. The Deploy dialog opens with the note: "Select the tenants to deploy this template into. A real, tenant-editable policy is created in each."
- Check the target tenants and click Deploy.
- A Confirm your identity prompt appears — deploying into tenants is a privileged action, so you must re-enter your password (SSO users are re-verified through their SSO session). The deploy runs once your identity is confirmed.
Each tenant is deployed independently, so one tenant failing does not stop the others — you will see any failures on the deployments board.
Check the deployments board. Click the board icon on a template to open Deployments — <template name>, the per-tenant status list. Each row shows the tenant and one of:
| Status | Meaning |
|---|---|
| Deployed | The policy was created (or refreshed) in the tenant and is live there |
| Failed | The deploy to this tenant did not complete; an error summary is shown inline |
| Rolled back | The deployed policy was removed via rollback; the record is retained |
| Pending | The deployment has not completed yet |
[SCREENSHOT PLACEHOLDER: The per-tenant deployments board for a template, showing tenants with Deployed, Failed, and Rolled back status badges and a "Roll back" button on a deployed row]
Roll back a deployment. On the board, click Roll back next to a deployed tenant. After the same identity confirmation step, the policy that the deploy created in that tenant is removed. The deployment record is kept with a Rolled back status, so you retain a full history of where the template has been and when it was withdrawn.
Delete a template. Click the trash icon and type the template name to confirm. Note the warning in the dialog: deleting a template removes only the curated template — policies already deployed into tenants are not removed. Roll back deployments first if you want the tenant copies gone too.
As with org policies, any org admin can view templates and deployment boards, but creating, editing, deleting, deploying, and rolling back require the Org Owner role.
Worked example: baseline plus starter kit
You operate 12 tenants and want two things: a non-negotiable ban on credential entry on newly registered lookalike domains, and a recommended starting configuration for new customers.
The non-negotiable rule becomes an org policy. On Org Policies, create "Block credential entry on flagged domains" with a Block action and mark it Locked to signal it is an org mandate. It now applies to all 12 tenants automatically, and no tenant admin can turn it off. When you refine the conditions next quarter, the edit takes effect everywhere at once.
The starting configuration becomes a template. On Policy Templates, create "Standard onboarding — warn on reuse" with a Warn action for credential reuse. When you onboard a new customer, deploy the template to just that tenant. The customer's tenant admin can then tune the copy — add exceptions for their internal domains, raise it to Block when they finish their rollout — without affecting any other tenant. If the engagement ends during a trial, roll the deployment back; the board keeps the record.
Troubleshooting
A tenant admin says a policy appeared that they can't delete. That is an org policy floor, working as designed. Only an Org Owner can change or remove it, from the Org Policies page.
I edited a template but tenants still have the old behavior. Templates are stamped copies — edits do not propagate. Re-deploy the template to the affected tenants; the existing deployed policy in each is updated in place.
A deploy shows "Failed" for one tenant. The board shows an inline error summary for that tenant. Address the cause and deploy again — only the failed tenant needs to be re-selected, though re-selecting already-deployed tenants is harmless.
Some tenants don't appear in the deploy dialog. You can only deploy into tenants within your access scope. If your account is scoped to a subset of tenants, ask an Org Owner to extend your per-tenant access.
Why am I asked for my password when I'm already signed in? Deploying and rolling back change live enforcement inside customer tenants, so the console requires a fresh identity confirmation for each action.
Related pages
- Security Policies — the tenant-level policy model, actions, and most-restrictive-wins resolution that both tools build on
- Admins & Access — the Org Owner role and per-tenant access scoping that govern who can use these pages
- MSSP overview — how the organization console relates to tenants