Security tags
What this page is — need-to-know markings, and the list of people granted each one. A document carrying a tag is invisible to everyone without a grant — administrators included.
What it is for — so a handful of genuinely sensitive documents can be restricted without changing anybody's role or the project's membership.
The problem it solves — restricting a few sensitive documents otherwise means reshaping roles or project membership for everyone.
Route: /org/settings?tab=papers → Security tags · Permission: the organisation Papers settings
permission. Tags are attached to documents from each document's Security tags card.
1. What it is
Three parts:
| Part | Where | Holds |
|---|---|---|
| Tag | This screen | A permanent code and a display name |
| Grants | This screen | The users cleared for the tag |
| Assignment | The document | Which tags a document carries — up to ten |
The rule: a user sees a document only if they hold a grant on every tag it carries. Missing one grant hides it everywhere — lists, search, the Repository, the workspace.
| Security tags | Permissions | Project membership | |
|---|---|---|---|
| Effect | Remove access | Add capability | Scope what a person sees |
| Administrators exempt? | No | — | — |
| Granular to | One document | A role | A project |
2. Why you would use it
- Sensitive documents stay in their project. A board resolution does not need its own project to be private.
- Need-to-know is enforced, not requested. Administrators do not bypass it — which is the point.
- Access is a list you can read. People with access shows exactly who can see tagged documents.
- Removing a tag is a real undo. Deleting a tag makes documents protected only by it visible again.
3. Step by step
- + Tag → Code and Name → save. The toast says what to do next: "Security tag created — now grant access, then attach it to documents".
- People with access → add every user who needs it — including yourself.
- On a document, attach the tag from its Security tags card. If nobody holds a grant yet, a loud warning appears — confirming would hide the document from everyone.
There is no override. If you attach a tag you do not hold, the document disappears from your own view, and administrators cannot see it either. Only someone holding a grant — or deleting the tag — brings it back.
4. Field reference
| Field | Rules | Refusal |
|---|---|---|
| Code | Lowercase letters, digits, _ and -; up to 64 characters; unique; cannot be changed | code is required · code exceeds 64 characters · code may contain only lowercase letters, digits, '_' and '-' · a security tag with code "x" already exists |
| Name | Up to 255 characters; renameable | name is required · name exceeds 255 characters |
| Grant | A user in the organisation | user not found in this organization |
| Per document | At most 10 tags | a document can carry at most 10 security tags |
| Action | Effect |
|---|---|
| Rename | Changes the display name only |
| Delete | Removes grants and document links; documents protected only by this tag become visible again |
5. Designing a tag scheme
Every tag is a list of people someone has to keep current. The scheme that works is the smallest one that expresses your real audiences.
| Principle | Because |
|---|---|
| Few broad tags beat many narrow ones | Ten tags are ten grant lists to maintain through every joiner and leaver |
| Name codes after the audience, not the document | board-only, hr-confidential, deal-team still make sense next year; buyback-2026 does not |
| Tags combine with AND | A document carrying board-only and legal is visible only to people holding both |
| There is no OR | To reach "the board or legal", create one tag and grant both groups |
| Give every tag an owner | Somebody must add and remove grants when membership changes |
| Stay well under ten per document | The hard limit is ten, and every extra tag shrinks the audience further |
Patterns
| Need | Pattern |
|---|---|
| Board papers visible to directors and the company secretary | One tag, board-only, granted to all of them |
| Payroll contracts restricted to HR | hr-confidential |
| A live acquisition: only the deal team, and only until closing | deal-team; delete the tag at closing to release the documents |
| Board and legal must both be cleared | Two tags on the document; only people holding both see it |
Grants over time
| Event | Do |
|---|---|
| A new director joins | Add their grant before they need a board paper |
| Someone leaves | Remove their grants — they are not removed automatically |
| A matter becomes public | Remove the tag from its documents, or delete the tag if nothing else uses it |
| An audit asks who can see a document | Read People with access for each tag it carries |
6. Worked example
A company secretary needs board resolutions visible only to the directors and themself.
- Creates tag
board-only, name Board eyes only. - Grants the three directors and themself.
- Attaches
board-onlyto the Board Resolution — Share Buyback document. No warning — grants exist.
The general counsel, an administrator in the same project, reports the document has vanished. That is correct: they hold no grant. The secretary adds them.
Later a draft carries both board-only and m-and-a. A director with only board-only cannot see it — they
need both. After the deal closes, the secretary deletes m-and-a; documents that carried only that tag
reappear for everyone in the project.
7. The admin contract
| Must be true | Where | What breaks without it |
|---|---|---|
| Every tag has at least one grant before use | This screen | Tagged documents vanish for everyone |
| Grants are maintained when people change roles | This screen | Leavers keep clearance; joiners cannot see |
| The role can manage tags | Role editor | The section is missing |
| Taggers understand the lockout | Training | Documents are hidden from the person who tagged them |
8. Downstream
| When you… | Then |
|---|---|
| Attach a tag | Users without a grant lose the document everywhere immediately |
| Grant a user | They see every document carrying that tag, provided they hold its other tags |
| Delete a tag | Documents protected only by it are visible again |
9. Don't confuse this with…
| Confidentiality | A classification stamped on a document. A tag controls who can open it |
| Redaction | Hides parts of an outbound copy. A tag hides the whole document internally |
| Project access | Decides which project's documents you see. A tag narrows within that |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| A document vanished from my own list | You attached a tag you do not hold |
| An administrator cannot see a document | Tags do not exempt administrators |
| A director with the tag still cannot see it | The document carries another tag they lack |
| The code cannot be changed | Codes are permanent — rename instead |
| Deleting a tag made documents visible | Expected |
| …at most 10 security tags | The per-document limit |