Create & Manage Policies

A policy is a complete, named detection ruleset — every data type set to Off, Alert, or Block, plus your custom rules and file-handling behavior. Your organization starts with one policy, the Default Policy, which applies to everyone. Additional policies let different teams work under different rules: Finance can block credit-card data outright while Engineering only gets alerts on source code.

Everything happens on the Policies page in the sidebar, which has four tabs: Policies, Groups, Templates, and People. This guide covers the Policies and Templates tabs; assigning policies to teams is covered in Assign Policies to Teams with Groups. Only owners and admins can create or edit policies.

What a policy contains

• Detection modes — every built-in data type (credit cards, API keys, personal data, source code…) set to Off, Alert, or Block. The modes work exactly as described in Configure Detection Rules.
• Custom rules — your own detectors (a name, a pattern, and a mode), for internal project names, customer identifiers, or anything else specific to you.
• File handling — whether attached files are held back when they trigger an alert.

Creating a policy

On the Policies tab, click New policy and pick a starting point:

• Blank — every data type starts on Alert: full visibility, no blocking, nothing missed.
• Duplicate an existing policy — start from a policy you have already tuned.
• From a template — start from a ready-made ruleset (see below).

Policy templates

The Templates tab ships ready-made rulesets for common situations: Finance & Accounting, Human Resources, IT & Development, Sales & Marketing, and GDPR. Each template pins the modes that matter for that context and explains why rule by rule; anything a template does not pin inherits the value from your Default Policy, so templates layer cleanly on top of your baseline.

A policy created from a template always starts in Simulation — it never enforces anything until you have seen it run against real traffic and published it yourself.

The policy lifecycle

Every policy moves through four states:

• Draft — being written; not applied to anyone.
• Simulation — the policy runs against real traffic and records what it would have done, but never blocks: any rule set to Block behaves as Alert. This is how you check a policy for false positives before it can interrupt anyone (see Roll Out Safely).
• Active — enforced for every group the policy is assigned to.
• Archived — retired, kept for history.

Active policies are versioned. You do not edit an active policy's rules in place: the dashboard moves it through Simulation while you edit, and Publish freezes the previous rules as an immutable version and activates the new ones. The version history is always available on the policy, and every incident records the exact policy and version that produced it — so you can always answer "what rules were in force when this happened?"

The Default Policy is special

• It covers everyone who is not matched into another group, so nobody is ever unprotected.
• Editing it applies immediately — changes publish in place (with a version snapshot) rather than passing through Simulation, so an organization-wide change takes effect right away.
• It cannot be archived or deleted.

Safety rails

• A policy that is still assigned to a group cannot be deleted — reassign the group first.
• Deleting normally archives; permanent deletion is a separate, explicit action.
• Every create, edit, publish, and delete is written to the audit log.

Next step: put a policy in front of the right people — Assign Policies to Teams with Groups.