Administrative Tier Model & Separation Matrix
Defines administrative tiers and which accounts may operate in each, preventing credential exposure across tiers.
Available soon
- Format
- Excel
- Size
- 67 KB
- Length
- 13 sheets
- Version
- 2.0
- Updated
What's inside
What changed
- 2.0
Rewritten to the depth of the other CISO Times packs: the three tiers side by side with their elevation limits, review cadence and approvers; every system and directory group with its tier; the separation matrix by formula; every enabled account's rights checked against it, flagging an account that reaches two tiers; the rules with their built-in enforcement; and a breach register with the steps, deadlines and completion.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Read the Tier model sheet first: the three tiers, what each covers and why. Check the longest elevation for each tier against the Privileged Access Standard (PA-06). |
| 2 | On System tiers, give every system its tier: the tier of the most important thing it can control. Anything that can change the directory, the cloud identity tenant, the backups or the device management consoles is Tier 0, wherever it sits. Then give each directory group the tier of the systems its members can change. |
| 3 | The Separation matrix shows what an account of each tier may do on a system of each tier. It calculates from the tier numbers; you should not need to change it. |
| 4 | On Account assignments, enter one row per right of every enabled privileged account: the account, its tier, the system and the right. The permitted use comes from the matrix, and the check flags any account that reaches two tiers (split it, SR-1) or a right the matrix refuses. |
| 5 | Read the Separation rules sheet for how to enforce each rule with tools you already have: separate accounts named by tier, sign-in denied by group policy, administration devices per tier. |
| 6 | Record every tier breach on Tier breaches the day it is found: the account, its tier, the system, when it happened and when it was found. Follow the steps beside it; their deadlines run from the day it was found. |
| 7 | Review the tiers when a system is added or changes role, and at each control review (Privileged Access Control Review Workbook, CT-12). |
| 8 | To clear the EXAMPLE, delete the contents of the Example column and of every yellow cell on the working sheets. Keep the tiers, the rules and the formulas. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026. Its 9 systems are in three tiers, 4 in Tier 0, 4 in Tier 1, 1 in Tier 2. Of 21 rights held by enabled accounts, two belong to one account: adm-pshah holds Backup Operators (Tier 0) and Server Admins (Tier 1). On 24 Sep 2026, with its Tier 0 elevation (E-04) active, it signed in to FS-02, a Tier 1 file server. The first weekly session review found it (AN-01); the password was changed the same day, the server checked the next, and the account is being split (PF-03).
Adapting for a small organisation: three tiers still apply, though one person may hold an account in each. The rule that matters most is SR-2: never sign in to an ordinary server or PC with a Tier 0 account.
Adapting for a regulated entity (NIS2, DORA): the matrix and the assignments are the record that administration accounts are individual, restricted and used only for administration (Implementing Regulation (EU) 2024/2690 Annex 11.3.2 and 11.4). Keep each reviewed version.
Adapting where a service provider runs your IT: the provider's engineers get one named account per tier they work in, and the provider's own tools that can reach your directory are Tier 0. Ask how its remote support tool is separated by tier.
Tier model
The tier model
A simplified form of the administrative tier model: Tier 0 controls everything, Tier 1 holds the data and services, Tier 2 is where users work. An administrator account belongs to one tier (SR-1). Yellow cells are settings from the Privileged Access Standard.
| Tier 0 | Tier 1 | Tier 2 | |
|---|---|---|---|
| Title | Identity and control plane | Servers, applications and cloud workloads | End-user devices and user support |
| What it covers | The systems that control every other system: the directory and the cloud identity tenant, the identity provider and certificate services, the backup system and its console, the endpoint protection and device management consoles, the password vault, and whatever hosts any of these. | Servers and the business applications on them, databases, network and security devices, cloud subscriptions and their workloads, and the administrator roles inside business applications. | Office PCs and laptops, mobile devices and printers, and the service desk's rights over ordinary user accounts (password resets and unlocks). |
| Why it matters | Whoever controls Tier 0 controls everything. One stolen Tier 0 credential is a compromise of the whole estate. | Where the organisation's data and services live. | Where phishing lands and malware runs first. |
| How its rights are held (PA-06) | Just-in-time only | Just-in-time only | Standing allowed, on a separate Tier 2 account |
| Longest elevation, hours | 4 | 8 | 8 |
| Session review (PA-09) | Weekly, every event. Weekly, done within 2 working days of the period's end: every privileged event: elevations, group and role changes, sign-ins by Tier 0 accounts, vault openings and changes to logging. | Monthly, a sample and every event without a ticket. Monthly, done within 5 working days of the period's end: every event without a matching ticket, and a sample of [[20]] elevations. | Quarterly, a sample. Quarterly, done within 10 working days of the period's end: a sample of [[20]] uses of local administrator passwords and service desk resets. |
| Control review every, months (PA-16) | 6 | 12 | 12 |
| Who approves (PA-07) | AP-1 Tier 0 elevation: Head of IT; the Head of Information Security when the requester is the Head of IT or the Head of IT is unavailable. AP-4 New Tier 0 administrator account, or any standing right in Tier 0: Head of IT and Head of Information Security, both | AP-2 Tier 1 elevation: The system owner, or the Head of IT. AP-5 New Tier 1 administrator account or application administrator role: The system owner and the Head of IT | AP-3 Tier 2 administrator account: IT Operations Manager |
| Systems in the tier (calc) | 4 | 4 | 1 |
Tier 2 may hold standing rights on a separate Tier 2 account; Tier 0 and Tier 1 rights are just-in-time only. Read-only monitoring, break-glass and service accounts are the exceptions PA-06 allows, each recorded in the Privileged & Service Account Inventory.
System tiers
System tiers
Every system and directory group with its tier. A system takes the tier of the most important thing it can control; a service account takes the tier of the most important system it can change (SR-5). Yellow cells are yours.
| System ID | System | Tier | System owner | Suppliers with access | Access review system (P07) | Tier title (calc) |
|---|---|---|---|---|---|---|
| PS-01 | Directory and its administrator groups | 0 | Head of IT | SUP-001, SUP-006 | SYS-03 | Identity and control plane |
| PS-02 | Cloud identity tenant (email and office, P06 SUP-005) | 0 | Head of IT | SUP-005 | None | Identity and control plane |
| PS-03 | Backup service console (P06 SUP-011) | 0 | Head of IT | SUP-011 | None | Identity and control plane |
| PS-04 | Endpoint protection and device management consoles | 0 | Head of IT | SUP-006 | None | Identity and control plane |
| PS-05 | ERP (hosted, P06 SUP-004; P07 SYS-01) | 1 | Chief Financial Officer | SUP-004 | SYS-01 | Servers, applications and cloud workloads |
| PS-06 | Warehouse management system servers (P07 SYS-02) | 1 | Head of Logistics | SUP-010 | SYS-02 | Servers, applications and cloud workloads |
| PS-07 | Online ordering admin console (P07 SYS-04) | 1 | Chief Operating Officer | None | SYS-04 | Servers, applications and cloud workloads |
| PS-08 | File and application servers, and the firewalls | 1 | Head of IT | SUP-001 | None | Servers, applications and cloud workloads |
| PS-09 | Office PCs and laptops | 2 | Head of IT | SUP-001 | None | End-user devices and user support |
Directory groups
| Group | Tier | System it controls | Read-only | |
|---|---|---|---|---|
| Domain Admins | 0 | PS-01 | No | |
| Backup Operators | 0 | PS-01 | No | |
| Server Admins | 1 | PS-08 | No | |
| Event Log Readers | 1 | PS-08 | Yes | |
| Helpdesk Admins | 2 | PS-09 | No | |
A read-only group may hold standing rights (PA-06); its members still sign in only within its tier.
Separation matrix
Separation matrix
What an account of each tier may do on a system of each tier (PA-13). The tier numbers in yellow drive the formulas: an account administers only its own tier, never signs in to a lower one, and holds no rights in a higher one. A daily account has no tier.
| Account | Account tier | Tier 0 system | Tier 1 system | Tier 2 system |
|---|---|---|---|---|
| System tier | 0 | 1 | 2 | |
| Daily account | Use, no administration | Use, no administration | Use, no administration | |
| Tier 0 administrator account | 0 | Administer | Never sign in | Never sign in |
| Tier 1 administrator account | 1 | No rights | Administer | Never sign in |
| Tier 2 administrator account | 2 | No rights | No rights | Administer |
What each word means
| Word | Rule | Meaning | ||
|---|---|---|---|---|
| Administer | SR-1 | An administrator account belongs to one tier and administers only that tier. A person who works in two tiers holds one account for each. | ||
| Never sign in | SR-2 | An account of a higher tier never signs in to a system of a lower tier, not even to look something up: its credential could be captured there. | ||
| No rights | SR-3 | A lower-tier account holds no control over a higher tier: no membership of its groups, no rights on its systems, and no control of the devices its administrators work from. | ||
| Use, no administration | SR-6 | A daily account holds no administrator rights in any tier. | ||
A Tier 0 credential typed on a Tier 1 server can be captured there by anyone who controls that server: that is why "Never sign in" is the strictest word.
Account assignments
One row per right of every enabled privileged account, from the Privileged & Service Account Inventory. The account's tier is the tier it administers; an account that reaches two tiers must be split (SR-1).
| Example | Account | Account type | Account tier | System ID | Right on the system | System tier (calc) | Permitted use (calc) | Tiers reached (calc) | Check (calc) |
|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | adm-mellis | Named administrator account | 0 | PS-01 | Domain Admins | 0 | Administer | 1 | OK |
| EXAMPLE | adm-mellis | Named administrator account | 0 | PS-02 | Global Administrator (eligible) | 0 | Administer | 1 | OK |
| EXAMPLE | adm-jnovak | Named administrator account | 0 | PS-01 | Domain Admins | 0 | Administer | 1 | OK |
| EXAMPLE | adm-jnovak | Named administrator account | 0 | PS-02 | Global Administrator (eligible) | 0 | Administer | 1 | OK |
| EXAMPLE | adm-pshah | Named administrator account | 0 | PS-08 | Server Admins | 1 | Never sign in | 2 | Split the account (SR-1) |
| EXAMPLE | adm-pshah | Named administrator account | 0 | PS-01 | Backup Operators | 0 | Administer | 2 | Split the account (SR-1) |
| EXAMPLE | adm-dmorgan | Named administrator account | 2 | PS-09 | Helpdesk Admins | 2 | Administer | 1 | OK |
| EXAMPLE | adm-lchen | Named administrator account | 2 | PS-09 | Helpdesk Admins | 2 | Administer | 1 | OK |
| EXAMPLE | ext-msp-aturner | Supplier administrator account | 1 | PS-08 | Server Admins | 1 | Administer | 1 | OK |
| EXAMPLE | ext-msp-bowen | Supplier administrator account | 1 | PS-08 | Server Admins | 1 | Administer | 1 | OK |
| EXAMPLE | ext-soc-nfield | Supplier administrator account | 1 | PS-08 | Event Log Readers | 1 | Administer | 1 | OK |
| EXAMPLE | svc-backup | Service account | 0 | PS-01 | Backup Operators | 0 | Administer | 1 | OK |
| EXAMPLE | bg-emergency | Break-glass account | 0 | PS-01 | Domain Admins | 0 | Administer | 1 | OK |
| EXAMPLE | elena.lopez | Application administrator role | 1 | PS-07 | Store administrator | 1 | Administer | 1 | OK |
| EXAMPLE | helen.carter | Application administrator role | 1 | PS-07 | Store administrator | 1 | Administer | 1 | OK |
| EXAMPLE | bg-cloud-01 | Break-glass account | 0 | PS-02 | Global Administrator | 0 | Administer | 1 | OK |
| EXAMPLE | bg-cloud-02 | Break-glass account | 0 | PS-02 | Global Administrator | 0 | Administer | 1 | OK |
| EXAMPLE | svc-wms-db | Service account | 1 | PS-06 | Local administrator, both warehouse system servers | 1 | Administer | 1 | OK |
| EXAMPLE | fw-admin | Shared or built-in administrator account | 1 | PS-08 | Firewall administrator | 1 | Administer | 1 | OK |
| EXAMPLE | Built-in Administrator, each server | Shared or built-in administrator account | 1 | PS-08 | Local Administrators | 1 | Administer | 1 | OK |
| EXAMPLE | Built-in Administrator, each office PC | Shared or built-in administrator account | 2 | PS-09 | Local Administrators | 2 | Administer | 1 | OK |
Separation rules
Separation rules, and what to do after a breach
The six rules the matrix applies (PA-13), how each is enforced with tools the organisation already has, and the steps after an administrator account is used outside its tier or for email or browsing. Change a rule in the Privileged Access Standard, never here.
| Rule | Requirement | Where this workbook applies it | Without a PAM platform |
|---|---|---|---|
| SR-1 | An administrator account belongs to one tier and administers only that tier. A person who works in two tiers holds one account for each. | Account assignments: the check flags an account that reaches two tiers. | Separate administrator accounts (PA-02, PA-04): Create a second account per person per tier in the directory, named by tier (for example a0-, a1-, a2-). Give it no mailbox and no office licence. |
| SR-2 | An account of a higher tier never signs in to a system of a lower tier, not even to look something up: its credential could be captured there. | Separation matrix: "Never sign in" below the diagonal; Tier breaches: every sign-in to a lower tier. | Tier separation (PA-13): Use group policy to deny sign-in by higher-tier administrator groups on lower-tier systems (console, Remote Desktop, batch and service logon), and add Tier 0 accounts to the directory's protected users group. |
| SR-3 | A lower-tier account holds no control over a higher tier: no membership of its groups, no rights on its systems, and no control of the devices its administrators work from. | Separation matrix: "No rights" above the diagonal; System tiers: the tier of each group. | Tier separation (PA-13): Use group policy to deny sign-in by higher-tier administrator groups on lower-tier systems (console, Remote Desktop, batch and service logon), and add Tier 0 accounts to the directory's protected users group. |
| SR-4 | Administrator accounts sign in only from an administration device of their own tier, never from a device used for email or web browsing. | Tier model: administration devices per tier; checked at the control review (CT-02). | Administration devices (PA-04): A dedicated administrator workstation per tier, or a hardened jump host reached from one. At the least, a separate hardened virtual machine with no email and browsing limited to the administration portals. |
| SR-5 | A service account takes the tier of the most important system it can change, and runs only on systems of that tier. | System tiers: a service account takes the tier of the system it can change. | Service accounts (PA-11): Use the platform's managed service accounts or managed identities, which change their own passwords; deny interactive and Remote Desktop logon to every other service account by group policy. |
| SR-6 | A daily account holds no administrator rights in any tier. | Separation matrix: the daily account row. | No administrator rights on daily accounts (PA-03): Remove daily accounts from every local and directory administrator group through device management or group policy, and let support use the local administrator password solution. |
After a tier breach, in order (PA-13)
| Step | What to do | Within |
|---|---|---|
| 1 | Stop the use and end the account's sessions | At once |
| 2 | Change the account's password and revoke its sessions and tokens | At once for Tier 0; within [[1]] working day for Tier 1 and 2 |
| 3 | Check the system or mailbox it touched for signs of compromise; if there are any, it is an incident under the incident management pack (P09) | [[1]] working day |
| 4 | Review what the account did since the breach | [[1]] working day |
| 5 | Fix the cause: the right-tier account for the person, and a policy that blocks the sign-in next time | [[1]] month |
| 6 | Record it in the session review record, and as a finding if the policy failed | In the next review |
An administrator account used outside its tier, or for email or browsing. Treated as a possible exposure of that account's credential (PA-13). The deadlines run from the day the breach is found; Tier breaches calculates them.
Tier breaches
Tier breaches
Every use of an administrator account outside its tier, or for email or browsing, recorded the day it is found, with the steps that follow it. Treat each as a possible exposure of the account's credential (PA-13). Yellow cells are yours.
| As-at date | 30 Sep 2026 | EXAMPLE: the quarter end. Step statuses are judged on it. |
The breach register
| Breach ID | Found in | Elevation | Account | Account tier | System | System tier | Occurred at | Found on | Permitted use (calc) | Result (calc) | Finding |
|---|---|---|---|---|---|---|---|---|---|---|---|
| AN-01 | SR-2026-W39 | E-04 | adm-pshah | 0 | FS-02 (PS-08) | 1 | 24 Sep 2026 | 28 Sep 2026 | Never sign in | Tier breach (PA-13) | PF-03 |
Copy this block for each breach. The deadlines run from the Found on date in the register's first row, and step 2 is at once for a Tier 0 account.
The steps for AN-01
| Step | What to do | Within | Deadline (calc) | Done on | Evidence | Status (calc) | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Stop the use and end the account's sessions | At once | 28 Sep 2026 | 28 Sep 2026 | PF-03 action 1: change the account's password and end its sessions | Done | |||||
| 2 | Change the account's password and revoke its sessions and tokens | At once for Tier 0; within [[1]] working day for Tier 1 and 2 | 28 Sep 2026 | 28 Sep 2026 | PF-03 action 1: change the account's password and end its sessions | Done | |||||
| 3 | Check the system or mailbox it touched for signs of compromise; if there are any, it is an incident under the incident management pack (P09) | [[1]] working day | 29 Sep 2026 | 29 Sep 2026 | PF-03 action 2: checked FS-02 for signs of compromise. No sign of compromise | Done | |||||
| 4 | Review what the account did since the breach | [[1]] working day | 29 Sep 2026 | 28 Sep 2026 | SR-2026-W39 reviewed every Tier 0 event of the week to 27 Sep 2026, including the account's | Done | |||||
| 5 | Fix the cause: the right-tier account for the person, and a policy that blocks the sign-in next time | [[1]] month | 28 Oct 2026 | PF-03 action 3, due 28 Oct 2026: split the account into a Tier 0 and a Tier 1 account, and deny Tier 0 groups sign-in on Tier 1 servers | Open | ||||||
| 6 | Record it in the session review record, and as a finding if the policy failed | In the next review | In the next review | 28 Sep 2026 | Recorded in SR-2026-W39 as AN-01, and raised as PF-03 | Done | |||||
Lists
| Tiers | TierTitle | YesNo |
|---|---|---|
| 0 | Identity and control plane | Yes |
| 1 | Servers, applications and cloud workloads | No |
| 2 | End-user devices and user support |
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Tier | A group of systems that give the same level of control over the organisation. An administrator account belongs to one tier (A08). |
| Control plane | The systems that control identities and every other system: the directory, the cloud identity tenant and anything that can change them. Tier 0. |
| Administrator account | A separate account, named for one person and one tier, used only for administration (PA-02). It has no mailbox and is never used for email or web browsing. |
| Daily account | The account a person uses for email, web browsing, chat and ordinary work. It holds no administrator rights anywhere (PA-03). |
| Administration device | A device used only for administration: a dedicated administrator workstation, or a hardened jump host reached through one. No email and no web browsing beyond the administration portals it needs. |
| Service account | An account used by software, not a person: to run a service, a scheduled task or an integration. It has a named owner and cannot sign in interactively (PA-11). |
| Interactive logon | Signing in as a person would: at the console, through Remote Desktop, or through a remote support tool. A service account must not be able to. |
| Just-in-time | Privileged rights that are eligible but not active. They are switched on for one task, after approval, for no longer than the tier's maximum, and switch off by themselves. |
| Elevation | One activation of just-in-time rights: who, which rights, which system, why, who approved, when it started and when it ended. |
| Tier breach | An administrator account used outside its tier, or for email or browsing. Treated as a possible exposure of that account's credential (PA-13). |
| Administer | An administrator account belongs to one tier and administers only that tier. A person who works in two tiers holds one account for each. (SR-1) |
| Never sign in | An account of a higher tier never signs in to a system of a lower tier, not even to look something up: its credential could be captured there. (SR-2) |
| No rights | A lower-tier account holds no control over a higher tier: no membership of its groups, no rights on its systems, and no control of the devices its administrators work from. (SR-3) |
| Use, no administration | A daily account holds no administrator rights in any tier. (SR-6) |
| Account tier | The tier an administrator account administers. An account with rights in two tiers is counted in the higher one (the lower number) and must be split. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.2 — Privileged access rights | Tier model and Account assignments: privileged rights restricted to one tier per account, held just-in-time above Tier 2 |
| ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Separation matrix and rules: administration of each tier kept apart so one credential cannot reach every system |
| NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Account assignments: each account's permissions checked against the matrix, with breaches recorded and followed up |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | The Implementing Regulation binds only the digital providers its Article 1 names; for others it shows what the regulator expects |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.3.2 — the policies shall “(a) establish strong identification, authentication such as multi-factor authentication, and authorisation procedures for privileged accounts and system administration accounts; (b) set up specific accounts to be used for system administration operations exclusively, such as installation, configuration, management or maintenance; (c) individualise and restrict system administration privileges to the highest extent possible, (d) provide that system administration accounts are only used to connect to system administration systems.” | Separation rules: specific administration accounts, individualised and restricted, used only from administration systems |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.4 — the use of system administration systems is restricted and controlled: they are used “only … for system administration purposes, and not for any other operations”, separated logically “from application software not used for system administrative purposes”, and access to them is protected “through authentication and encryption” | SR-4 and the Tier model: administration systems used only for administration and separated from other software |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | Separation matrix: administration duties of each tier segregated (financial entities) |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 21, on point (e)(ii) — “financial entities shall, where possible, use dedicated accounts for the performance of administrative tasks on ICT systems. Where feasible and appropriate, financial entities shall deploy automated solutions for the privilege access management.” | Account assignments: dedicated accounts for administrative tasks, one per tier (financial entities) |
ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.