Introduction

Policies come from two places. UnifyApps ships packs built around published frameworks; your team writes the rest. Both are the same object and behave identically — the difference is authorship, and what that implies about who is responsible for keeping them right.

Where to find it

AI Governance > Policies > the System Policies and Custom Policies tabs. System Policies requires the STANDARD permission; without it you see Custom Policies only.

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

The difference

Neither governs anything on arrival. A system policy ships with controls but covers no assets, so installing a framework pack is the beginning of compliance work, not the end of it.

System policies

Each pack maps a published framework onto controls that can actually run: a set of rules, already configured, that correspond to the obligations that framework imposes.

The value is the translation. Turning a regulatory clause into "detect this, at this point, and do that" is the expensive part of compliance work, and the packs have done it.

What they cannot do is know your organisation. A pack does not know which of your agents are customer-facing, what your risk appetite is, or which of its controls should block rather than flag. Those decisions stay yours.

"A framework pack tells you what to check. It cannot tell you what you are willing to stop."

Adopting a system policy

1. Read its controls before covering anything — Open the pack's Controls tab and see what it will evaluate. Some will be obviously right; some will need tuning for your traffic.

2. Cover a small set first — Hand-pick two or three representative agents rather than writing a rule across the estate. You are measuring noise, not achieving coverage.

3. Read the incidents for a week — This is the real adoption step. A pack that generates thousands of unactioned incidents has not improved your posture.

4. Grade the severities — Packs ship focused on detection. Grading their controls for your organisation is part of adopting one.

5. Widen coverage by rule — Once tuned, switch to rule-based targeting so new agents are covered as they appear. See Apply a Policy to Assets.

Custom policies

Everything a framework does not cover: the topics specific to your business, the data your agents must never emit, the tools they must not call.

Start one when you can name the risk in a sentence. If the sentence needs an "and", it is probably two policies — and two policies each named for one risk are far easier to review than one named for both.

Using both together

The two answer different questions, and most programmes need both answered.

1. System policies for the audit — They map to something an assessor recognises, which is what makes evidence export meaningful.

2. Custom policies for the business — The risks nobody wrote a standard about, because they are specific to what you do.

Remember that coverage overlaps duplicate incidents. If a pack already checks for something, a custom policy checking the same thing on the same assets doubles the queue without doubling the safety.

Important considerations

1. Both need explicit coverage — Installing a pack changes nothing until you point it at assets.

2. Both can be disabled — A policy is Active or Inactive the same way on either.

3. Controls are shared — A control used by a system policy and a custom one is one object. Editing it affects both.

4. A pack is a starting point, not a certification — Applying it does not make you compliant; it gives you the instrumentation to demonstrate that you are.