On Atlas Enterprise, every classification points at a security policy. Policies decide who can discover, read, change, archive and manage each part of your data. This article explains how they work; The five access levels covers the levels themselves.
What a policy is
A security policy is a named set of access rules that your organization writes once and uses wherever it’s needed. It has:
- A name, such as Field Crew Access.
- A description, shown under the policy dropdown when you create a classification.
- An authorization mode: Explicit or Inherit.
- Default access rights — rules that apply to every classification using the policy.
Any number of classifications can share one policy.
Authorization modes
Explicit means the policy carries rules, and only the people those rules name get through.
Inherit means the policy has no rules of its own, so Atlas looks to the nearest parent instead. At the top of the tree there’s no parent, so an inherit policy there adds no restriction. In the tutorial organization that’s the Common policy, described simply as Anyone.
Where policies are written
Policies are written in your organization’s Account settings, under Security Policies — an Enterprise feature. Each policy is a tab. Its configuration holds the name, the description and the mode, and below that are its Default Access Rights: the rules that apply to every classification using the policy.
Create policy opens a short form for a name, a description and a mode.
Seeing a policy at work
Open a classification and choose Security. The Security Policy section names the policy and its mode. Below it is the Access Rights table, with a row for each rule: who receives access, what kind of grantee they are, which level, and whether the rule is inherited or explicit.
Inherited rows are dimmed. They were written on the policy itself, so they apply to every classification that uses it. In the tutorial, a Crew Lead rule on Field Crew Access means Crew Lead can discover Service Properties without anyone doing anything on the classification.
Adding a rule to one classification
To go further for one classification alone, choose Create a rule:
- Pick the level of access.
- Pick the type of grantee — a role, a user group or a single user. (Choosing Manage switches the type to Group and locks it, because Manage is only ever given to a user group.)
- Pick the grantee, then Select, and Create.
The new rule is explicit. It belongs to this classification only, and it covers everything beneath it.
Atlas also warns when a top-level data module has no user group with Manage access, because that’s the group its work is raised to. See Why every topic needs an owner.
A worked policy set
A small services business might need only three policies:
| Policy | Mode | Default access rights | Used by |
|---|---|---|---|
| Common | Inherit | None of its own | Classifications anyone may reach |
| Office Staff Access | Explicit | Office role: Read, Write, Archive | Customers, invoicing-related modules |
| Field Crew Access | Explicit | Crew Lead role: Discover, Read | Properties, equipment |
Each classification then points at one of the three, with explicit rules added only where something genuinely differs — for example, giving a particular user group Manage on the properties module.
Reading the Access Rights table
The table tells you, at a glance, how someone got their access:
- Grantee — who receives access.
- Type — role, user group or user.
- Level — one of Discover, Read, Write, Archive, Manage.
- Inherited or explicit — inherited rows (dimmed) come from the policy’s default access rights and apply everywhere that policy is used; explicit rows were created on this classification.
When troubleshooting “why can this person see that?”, start with the dimmed rows: inherited rules apply to every classification sharing the policy.
Changing policies safely
- Check what else uses the policy before editing its default access rights, since changes apply everywhere it’s used.
- Prefer an explicit rule when only one classification needs a change.
- Create a new policy when several classifications need the same new pattern.
- Review after reorganizations, when roles and groups change.
Frequently asked questions
Where do I create policies? In your organization’s Account settings, under Security Policies — an Enterprise feature. Each policy is a tab, and Create policy opens a short form for a name, a description and a mode.
What does an Inherit policy do at the top of the tree? Nothing restrictive: at the top there’s no parent to inherit from, so it adds no restriction. That’s how the Common policy described as “Anyone” works.
Can a classification have no policy? No — every classification needs one, chosen when it’s created.
Can I change a classification’s policy later? Yes, from its details panel in the File System.
Do explicit rules cover child items? An explicit rule belongs to that classification and covers everything beneath it.
Designing a policy set
A small number of well-named policies usually beats one per classification:
- A permissive default (an inherit policy like Common) for information anyone in the organization may see.
- Role-based policies like Field Crew Access or Office Staff Access that grant specific levels to specific roles.
- Per-classification explicit rules only where one classification genuinely needs something different.
Write policies around who needs what, and let classifications share them. For the principle behind this, read Least-privilege access for business data.
