Privileged Access Request, Elevation & Revocation Procedure
Defines how privileged access is requested, time-bounded, approved, used and removed.
Available soon
- Format
- Word
- Size
- 65 KB
- Length
- 20 pages
- Version
- 2.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Requirements
- Inputs and prerequisites
- Approval authority
- Request to removal
- Emergency elevation
- Leavers, movers and suppliers
- Resetting privileged credentials
- Service accounts without owners
- Responding to a tier breach
- Elevation record
- Timing targets
- Records and retention
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 2.0
Rewritten to the depth of the other CISO Times packs: each step from request to removal now names who does it, when and what it leaves behind, with the approver's questions in order; the out-of-hours route, removal for leavers, movers and suppliers, privileged resets, unowned service accounts and tier breaches each have their steps and a worked example from the quarter; inputs, the elevation record, timing targets and records are added.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure runs the Privileged Access Standard day to day. The standard sets the rules PA-01 to PA-18; this procedure says who does what, in which order and by when, whenever someone needs privileged rights, uses them, loses them, or needs a privileged credential reset, and when a review finds a service account nobody owns or an administrator account used outside its tier.
It is written for the people who ask for privileged rights, the people who approve them, and the service desk. Each step names its owner, its time and what it leaves behind, so the session review can match every use of privileged rights to an approval.
Scope
This procedure covers:
- every elevation to privileged rights in Tier 0 and Tier 1, and every new privileged account in any tier;
- emergency elevation out of hours, through the on-call approvers;
- removal of privileged access when a person leaves or moves, or a supplier engineer no longer needs it;
- resets of a privileged account's password or second factor;
- service accounts found with no owner, and administrator accounts used outside their tier.
It does not cover break-glass accounts, used only when the normal route itself is unavailable: the Break-Glass Account Control Checklist sets their use and the steps after it. The general joiner, mover and leaver steps are the Joiner-Mover-Leaver Operating Procedure's (Joiner-Mover-Leaver & Access Provisioning pack); this procedure adds their privileged side.
Roles
Role | What they do in this procedure |
|---|---|
Head of IT [[e.g. Head of IT]] | Owns the standard and the inventory, approves Tier 0 elevation, and is the default owner of break-glass accounts. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Approves the standard, approves the Head of IT's own elevation, reviews every break-glass use and receives the metrics. |
Session reviewer [[e.g. Information Security Manager]] | Reviews privileged sessions and runs the control review. Holds no administrator rights in the tier reviewed. |
IT Operations Manager [[e.g. IT Operations Manager]] | Runs day-to-day administration, approves Tier 2 rights and owns service accounts that no business owner claims. |
System owner [[the manager accountable for the system]] | Approves Tier 1 elevation on their system and reviews its privileged access every quarter (P07). |
Administrator [[each person who holds an administrator account]] | Requests elevation, uses it only for the task approved, and signs in only from an administration device of the tier. |
Service desk [[internal service desk, or the managed IT provider's]] | Resets passwords and second factors, with the stricter checks of PA-17 for any privileged account. |
Supplier engineer [[the supplier's named engineer]] | Uses a named account for the agreed window only, under the supplier contract's access clause (P06 CL-09). |
Approving and granting are kept apart: whoever approves an elevation or a new privileged account never receives it and never grants it by hand (PA-07, P02 SOD-IT-01).
Requirements
The rules of the standard this procedure carries out:
PA-01 Every privileged account, human and non-human, must be in the inventory with a named owner, its tier, its purpose, where its credential is kept and when it was last changed. An account found that is not in the inventory is disabled unless an owner claims it within [[5]] working days. For a service account, assign an interim owner within that window to control its use while dependencies are checked under PA-11; the 30-day limit is not permission to leave it uncontrolled.
PA-06 Privileged rights in Tier 0 and Tier 1 must be just-in-time: eligible, activated for one task and ended after no more than [[4]] hours in Tier 0 and [[8]] hours in Tier 1. Standing rights are allowed only for break-glass and service accounts, Tier 2 support on separate Tier 2 accounts, read-only monitoring, and application roles the application cannot assign for a time, each recorded in the inventory.
PA-07 Every elevation and every new privileged account must be approved as the approvals table sets, by someone other than the person who will use it. The segregation-of-duties conflicts of the P02 matrix apply.
PA-10 Shared, service and break-glass credentials must be kept in the vault or managed by the platform, and changed as the rotation table sets, after every use where it says so, and at once on suspicion of compromise.
PA-11 Every service account must have a named owner, do one job with the least rights it needs, and be denied interactive logon. A service account with no owner found within [[30]] days is disabled, and deleted [[90]] days after that if nothing breaks.
PA-13 Every system must have a tier, and administrator accounts must follow the separation rules. An administrator account used outside its tier, or for email or browsing, is treated as a possible exposure of its credential.
PA-14 Privileged access must be removed on the day a person leaves or moves, or at once for an urgent departure. Shared, service and break-glass credentials the person could read are changed within [[1]] working day.
PA-15 A supplier's staff must use named accounts, enabled only for the agreed window and logged; shared supplier accounts are not allowed. Where a supplier administers a system on its own platform, the contract clauses of P06 cover it (TP-07, CL-09).
PA-17 A privileged account's password or second factor must never be reset on a call alone: identity is confirmed face to face or on video against the HR record, with a call back to the number held there, and a second administrator approves.
PA-18 Any departure from this standard must be a P02 exception, scored and approved by the approver its band sets (EX-05); a Critical exception is approved by the board or its equivalent. The headline measures are reported monthly to the security and IT leadership team.
Inputs and prerequisites
Check each before the first elevation, and again when a system or an approver changes.
Input | Check before starting | Held in |
|---|---|---|
Privileged account inventory | Every privileged account, with owner, tier, purpose, credential location and last change. | Privileged and service account inventory |
Tier of every system | Each system the elevation touches has a tier, and the account's tier matches it. | Tier model and separation matrix |
Eligible rights | Tier 0 and Tier 1 rights are set up as eligible, with the tier's maximum duration configured. | The directory or cloud tenant; the inventory |
Ticket system | Every elevation and every new privileged account has a ticket before it starts. | [[Service desk tool]] |
On-call approver list | Names and phone numbers of the approvers who can be reached out of hours, never including the requester. | [[On-call list]] |
Vault | Shared, service and break-glass credentials are in it, open only to named administrators, with its access log kept. | [[Password vault]] |
Central log store | Privileged events arrive, and administrators cannot change or delete them. | [[Log store run by the monitoring provider]] |
Approval authority
Who approves each request, and the longest window it may cover. Nobody approves their own access.
Ref | Request | Approver | Longest window |
|---|---|---|---|
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 | [[4]] hours |
AP-2 | Tier 1 elevation | The system owner, or the Head of IT | [[8]] hours |
AP-3 | Tier 2 administrator account | IT Operations Manager | Not a time window |
AP-4 | New Tier 0 administrator account, or any standing right in Tier 0 | Head of IT and Head of Information Security, both | Not a time window |
AP-5 | New Tier 1 administrator account or application administrator role | The system owner and the Head of IT | Not a time window |
AP-6 | Supplier access window | The system owner sets the window; the Head of IT as well for Tier 0. The Tier 0 maximum still applies | [[8]] hours; Tier 0 [[4]] hours |
AP-7 | Emergency elevation out of hours | Any approver on the [[on-call approver list]], by phone, never the requester; the approval is recorded on the ticket within [[1]] working day | [[4]] hours |
AP-8 | An exception to this standard | The P02 approver for the exception's band (EX-05): for a Critical exception, the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | Not a time window |
The longest elevation, by tier:
Tier | Access | Longest elevation |
|---|---|---|
Tier 0: Identity and control plane | Just-in-time only | [[4]] hours |
Tier 1: Servers, applications and cloud workloads | Just-in-time only | [[8]] hours |
Tier 2: End-user devices and user support | Standing allowed, on a separate Tier 2 account | [[8]] hours |
EXAMPLE: the Tier 0 elevations of the week 21 Sep 2026 to 27 Sep 2026.
Elevation | Account (holder) and right | Approved by, and when | Window | Why |
|---|---|---|---|---|
E-01 | adm-jnovak (Jana Novak) Domain Admins | Mark Ellis 5 minutes before | 09:10 to 11:05 1 hour 55 minutes, of [[4]] hours | Set up the time-limited membership of the Tier 0 groups |
E-02 | adm-mellis (Mark Ellis) Domain Admins | Ruth Okafor 20 minutes before | 14:00 to 14:50 50 minutes, of [[4]] hours | Add the Tier 0 groups to the protected users group |
E-03 | adm-pshah (Priya Shah) Backup Operators | Mark Ellis 15 minutes before | 10:00 to 13:30 3 hours 30 minutes, of [[4]] hours | Quarterly restore test of the directory backup |
E-04 | adm-pshah (Priya Shah) Backup Operators | Mark Ellis 10 minutes before | 09:30 to 12:30 3 hours, of [[4]] hours | Check the directory backup job after the restore test |
E-05 | adm-jnovak (Jana Novak) Global Administrator | Mark Ellis 10 minutes before | 15:00 to 15:40 40 minutes, of [[4]] hours | Test the sign-in policy change that caused the 5 September lock-out before re-applying it |
E-06 | adm-mellis (Mark Ellis) Global Administrator | Ruth Okafor 10 minutes before | 11:00 to 11:30 30 minutes, of [[4]] hours | List the tenant's role assignments for the control review |
E-07 | adm-jnovak (Jana Novak) Domain Admins | Mark Ellis 5 minutes before | 02:20 to 04:05 1 hour 45 minutes, of [[4]] hours | Directory replication failure between the two domain controllers, out of hours |
Every one was approved before it started, by someone other than the account's holder, and ended within the Tier 0 maximum. The Head of IT's own elevations (E-02, E-06) were approved by the Head of Information Security, as AP-1 sets. (EXAMPLE)
Request to removal
Seven steps, from the request to the review that checks it.
Step | What to do | Who | When | Output |
|---|---|---|---|---|
1. Request | Name the account, the system, its tier, the rights, the ticket, the business reason, and the start and end. List the rights the account already holds. | Administrator | Before the work starts | Ticket with the request |
2. Check | Confirm the account is in the inventory and of the system's tier, the sign-in method is phishing-resistant, and the administration device is of the tier. A supplier engineer has a named account and an approved window. | Administrator | Before approval is asked for | Checks recorded on the ticket |
3. Approve | Approve or refuse, as the approval table sets. The approver is never the person who will use the rights, and never the person who grants them by hand. | Head of IT; System owner; Head of Information Security | Before the start | Approval, with time and approver, on the ticket |
4. Activate | Switch the eligible rights on for the approved task only. Set the end to the earlier of the approved end and the tier's maximum, and check that the right will switch off by itself. | Administrator | At the approved start | Elevation with its start and automatic end |
5. Use | Sign in from the administration device of the tier. Stay within the approved system and task, and record what was changed against the ticket. | Administrator | Within the window | Change record on the ticket |
6. End | End the sessions and confirm the rights have switched off. An unfinished task needs a new approval; the window is never extended on the same ticket. | Administrator | At the approved end, or the tier's maximum | Actual end recorded |
7. Review | The session reviewer compares the protected logs with the ticket, and follows up any activity outside the window, the system or the task. | Session reviewer | At the tier's session review | Session review record |
Decision points
The approver asks these in order, and stops at the first that settles it.
Question | Yes | No |
|---|---|---|
Is the ticket complete: account, system, tier, rights, reason, start and end? | Next question. | Return it with what is missing. |
Am I independent: not the person using the rights, not the person granting them, not someone they approve for? | Next question. | Pass it to another approver on the approval table. |
Is the account of the system's tier, and is the administration device of the same tier? | Next question. | Refuse: a cross-tier elevation is a tier breach waiting to happen. |
Is the window no longer than the task needs, and within the tier's maximum? | Next question. | Shorten it, or split the task. |
Does the change create a conflict of duties in the P02 matrix? | Refuse, unless an exception has been approved. | Approve. |
Setting the end time
The rights end at the earlier of the approved end and the tier's maximum, switched off by the system, never by someone remembering to remove them. Where the directory cannot time-limit a group membership, the right is added by ticket with an end time, a scheduled task removes it, and a daily report lists any right older than its ticket (the built-in controls of the Privileged Access Standard).
EXAMPLE: E-03, the quarterly restore test of the directory backup, was approved by Mark Ellis at 09:45 for 10:00 to 13:30 on 23 Sep 2026: 3 hours 30 minutes, inside the Tier 0 maximum of [[4]]. Had the task overrun, the rights would have ended at the approved time, and finishing it would have needed a new approval. (EXAMPLE)
Guidance — delete before approval
Ask for the window the task needs, not the tier's maximum. A short window is easier to approve, easier to review, and less useful to anyone who steals the session.
Emergency elevation
When privileged rights are needed out of hours and the normal approver cannot be reached, use the on-call approver route (AP-7). It still needs an independent approver: urgency is never approval. The window is no more than the Tier 0 maximum of [[4]] hours, and the phone approval is recorded on the ticket within [[1]] working day.
Step | What to do | Who | When |
|---|---|---|---|
E1 | Open a ticket with the reason, even a one-line one, before asking for approval. | Administrator | At once |
E2 | Phone an approver on the on-call list. Never approve your own request, and never treat silence or urgency as approval. | Administrator | At once |
E3 | The approver approves by phone, with the window, and notes the time. | Head of IT; Head of Information Security | On the call |
E4 | Activate the rights for the approved window, no longer than the Tier 0 maximum, from the administration device of the tier. | Administrator | After approval |
E5 | Record the approval on the ticket: who approved, when, and the window. | Administrator; Head of IT | Within the working day set for it |
E6 | The elevation goes into the next session review like any other. | Session reviewer | At the review |
This is not break-glass. Break-glass is for when the normal administration route itself is down, for example when every administrator is locked out; it uses a sealed account, alerts on every sign-in, and is reviewed within [[1]] working day (PA-12).
EXAMPLE: E-07, Saturday 26 Sep 2026.
Time | What happened | Against the procedure |
|---|---|---|
02:15 | Directory replication failure between the two domain controllers, out of hours. Mark Ellis approves by phone. | Step E3: an approver on the list, not the requester |
02:20 | adm-jnovak elevated to Domain Admins (ticket IT-25163). | 5 minutes after approval |
04:05 | Replication restored; the rights switch off. | 1 hour 45 minutes, within [[4]] hours |
28 Sep 2026 | The phone approval is recorded on the ticket. | 1 working day after the elevation (limit [[1]]) |
Leavers, movers and suppliers
Privileged access must be removed on the day a person leaves or moves, or at once for an urgent departure. Shared, service and break-glass credentials the person could read are changed within [[1]] working day. The joiner, mover and leaver event comes from the Joiner-Mover-Leaver Operating Procedure; this procedure removes the privileged side of it, faster.
Ref | When | Privileged access removed |
|---|---|---|
RV-1 | A planned leaver | All privileged accounts disabled by the end of the last working day, at the latest when the daily account is |
RV-2 | An urgent leaver, or one leaving on bad terms | All privileged accounts disabled at once, before the person is told, and their sessions ended |
RV-3 | A mover whose new role does not need the access | Removed on the day the move takes effect |
RV-4 | A supplier engineer who leaves or no longer needs access | The supplier must remove access within [[1]] working day of a person leaving the supplier or no longer needing it (P06 CL-09, 9.3). Where we hold the account, we disable it the same day we learn of the leaver. |
RV-5 | Anyone who could read a shared, service or break-glass credential | Each such credential changed within [[1]] working day of the leaving or move |
Step | What to do | Who | When |
|---|---|---|---|
L1 | From the joiner-mover-leaver event, or the day we learn a supplier engineer has left, list every privileged account the person holds, in the inventory and in each system. | Head of IT | On the day the event is recorded |
L2 | Disable each privileged account, end its sessions and revoke its tokens. For an urgent leaver, do this before the person is told. | Administrator | As the removal table sets |
L3 | List every shared, service and break-glass credential the person could read, from the vault's access log and the safe list. | Head of IT | The same day |
L4 | Change each of those credentials, and reseal break-glass credentials. | Administrator; Head of IT | Within the working day the rule sets |
L5 | Remove the person from the on-call approver list and the safe list. | Head of IT | The same day |
L6 | Update the inventory and record the times on the leaver checklist. | Head of IT | The same day |
A removal decided in an access review is made within [[1]] working day of the decision (P07). The supplier must remove access within [[1]] working day of a person leaving the supplier or no longer needing it (P06 CL-09, 9.3). Where we hold the account, we disable it the same day we learn of the leaver.
EXAMPLE: the privileged accounts the quarter's access review removed. Each one should have gone earlier.
Account | Holder | Why it was still there | Removed |
|---|---|---|---|
adm-kwalsh Named administrator account | Kieran Walsh | Left on 2026-06-30 (HR leavers list). His everyday account was disabled; this administrator account was missed. | 9 Sep 2026 |
adm-migration Shared or built-in administrator account | Nobody | No owner found. Created for the 2025 server migration and never removed. | 9 Sep 2026 |
adm-rpatel Named administrator account | Ravi Patel | Moved from infrastructure to application support in May; no longer administers servers. | 9 Sep 2026 |
j.harper Application administrator role | Nobody | Console account whose email matches no current or former employee. Nobody claims it. | 11 Sep 2026 |
adm-kwalsh, a Tier 0 account, belonged to an engineer who left on 30 Jun 2026. His daily account was disabled that day; his administrator account was found 51 working days later. Under RV-1 it would have gone by the end of his last working day, and every credential he could read changed within [[1]] working day. (EXAMPLE)
Resetting privileged credentials
A privileged account's password or second factor must never be reset on a call alone: identity is confirmed face to face or on video against the HR record, with a call back to the number held there, and a second administrator approves.
The service desk's general checks (Joiner-Mover-Leaver Operating Procedure) are not enough for a privileged account. Every privileged reset follows these steps, in order:
Step | Check | Who | Output |
|---|---|---|---|
1 | Never on a call, chat or email alone, whatever the caller knows | Service desk | Request refused on the call; ticket opened |
2 | Identity confirmed face to face, or on a video call with photo identity checked against the HR record | Service desk | Identity check recorded, with how it was made |
3 | A call back to the number held in the HR record, never one the caller gives | Service desk | Call back recorded, with the number used |
4 | A second administrator approves the reset before it is made, and nobody resets their own account | Administrator | Second administrator's approval on the ticket |
5 | A lost security key is replaced by the spare, never by a weaker method, even for a day | Administrator | Spare key registered; lost key revoked |
6 | The account's owner and the Head of Information Security are told once it is done, and the reset is in the next session review | Service desk; Session reviewer | Owner and security told; reset flagged for the session review |
Each person with a security key holds [[2]]. A lost key is replaced by the registered spare and the lost one revoked; there is no fallback to a text message or an app code, even for a day. The general rule, for comparison: "VM-03, or VM-01 and VM-02 together. The new factor is enrolled by the person, never by the service desk on their behalf." That is the floor for ordinary accounts, never for privileged ones.
EXAMPLE: no privileged reset was made in the first weekly Tier 0 review's period; SQ-7 was answered "No". (EXAMPLE)
Guidance — delete before approval
Callers who impersonate an administrator to get a second factor reset are behind some of the largest recent breaches. The video check and the second administrator cost minutes; they are the control that stops it.
Service accounts without owners
Every service account must have a named owner, do one job with the least rights it needs, and be denied interactive logon. A service account with no owner found within [[30]] days is disabled, and deleted [[90]] days after that if nothing breaks. An account found that is not in the inventory is disabled unless an owner claims it within [[5]] working days (PA-01); for a service account, an interim owner is named in that time, so the account is controlled while its dependencies are checked.
Step | What | How |
|---|---|---|
1 | Find them | List every account whose password never expires, that runs a service or scheduled task on any server, or that sits in an administrator group, and compare the list with the inventory. |
2 | Name an owner | Ask the system owners and the suppliers. Assign an interim owner within [[5]] working days under PA-01, or disable it. An account with no permanent owner within [[30]] days is disabled, with the date, and deleted [[90]] days later if nothing breaks (PA-11). |
3 | Stop interactive logon | Deny console, Remote Desktop and remote support sign-in by policy. If people have been signing in with it, give them named accounts first (PA-02, PA-15). |
4 | Change and store the credential | Move it to a managed service account where the platform allows; otherwise change the password in a change window and put it in the vault (PA-10). |
5 | Cut its rights | Take it out of any group it does not need, and out of any tier above the systems it runs on (SR-5). |
6 | Watch it | An alert on any interactive sign-in by a service account goes to the session reviewer (SQ-5). |
EXAMPLE: PF-01, svc-wms-db, found by the control review on 24 Sep 2026. The warehouse system's database service account had no owner and was not in the inventory. It could sign in interactively, its password had not changed since the system was installed on 14 Mar 2019, and the supplier's support staff used it to sign in through the remote support tool, most recently on 16 Sep 2026. Its password was due for a change on 14 Mar 2020 under its rotation row. The actions, as at 30 Sep 2026:
Action | Owner | Due | Status |
|---|---|---|---|
Name an owner (IT Operations Manager) | Head of IT | 25 Sep 2026 | Done 25 Sep 2026 |
Give the supplier's two support engineers named accounts, enabled only for approved windows | IT Operations Manager | 9 Oct 2026 | Open |
Change the password in the Sunday change window and put it in the vault | IT Operations Manager | 4 Oct 2026 | Open |
Deny interactive and remote support logon to the account | IT Operations Manager | 9 Oct 2026 | Open |
Take the finding into the supplier's assessment, with the access clause (P06 CL-09) | Information Security Manager | 20 Oct 2026 | Open |
The owner was named the day after the finding, inside the [[5]] working days. Interactive logon is to be denied only after the supplier's engineers have named accounts, so their support does not stop (step 3). (EXAMPLE)
Responding to a tier breach
An administrator account used outside its tier, or for email or browsing, is treated as a possible exposure of its credential (PA-13). Act on these steps when a session review, an alert or the person finds one:
Step | What to do | When |
|---|---|---|
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 |
EXAMPLE: PF-03. One account held Tier 0 rights (Backup Operators) and Tier 1 rights (Server Admins). With the Tier 0 elevation active, it signed in to a Tier 1 file server, where the Tier 0 credential could have been captured.
Step | What happened | Against the procedure |
|---|---|---|
Breach | adm-pshah, elevated to Backup Operators (E-04), signed in to FS-02, a Tier 1 file server (PS-08) at 11:10 on 24 Sep 2026. | SR-2: a higher-tier account never signs in to a lower-tier system |
Found | By the weekly Tier 0 review SR-2026-W39, on 28 Sep 2026. | 2 working days after the breach: the review cadence is the detection time |
Step 2 | Change the account's password and end its sessions: Head of IT. | Due 28 Sep 2026; done 28 Sep 2026 |
Step 3 | Check FS-02 for signs of compromise: Information Security Manager. No sign of compromise. | Due 29 Sep 2026; done 29 Sep 2026 |
Step 5 | Split the account into a Tier 0 and a Tier 1 account, and deny Tier 0 groups sign-in on Tier 1 servers: Head of IT. | Due 28 Oct 2026; open |
Step 5's [[1]] month from the finding ends on 28 Oct 2026; the fix is due on 28 Oct 2026, within it. (EXAMPLE)
Elevation record
The ticket holds these fields for every elevation. A ticket system with these fields is enough; the record does not need its own form.
Elevation record | |||
Ticket | [[ticket]] | Account named administrator account | [[named administrator account]] |
Person | [[person]] | System and tier | [[system and tier]] |
Rights in the system's own words | [[in the system's own words]] | Purpose the task | [[the task]] |
Approver | [[approver]] | Approved at date and time | [[date and time]] |
Approved start | [[approved start]] | Approved end | [[approved end]] |
Automatic end how the rights switch off | [[how the rights switch off]] | Tier maximum hours | [[hours]] |
Actual start | [[actual start]] | Actual end | [[actual end]] |
Log reference | [[log reference]] | Session review reference | [[session review reference]] |
Deviation anything outside the window, system or task | [[anything outside the window, system or task]] | Finding reference | [[finding reference]] |
Timing targets
What | When | Rule |
|---|---|---|
Tier 0 elevation | No more than [[4]] hours | PA-06 |
Tier 1 elevation | No more than [[8]] hours | PA-06 |
Phone approval recorded on the ticket | Within [[1]] working day | AP-7 |
Planned leaver's privileged accounts disabled | By the end of the last working day | PA-14 |
Urgent leaver's privileged accounts disabled | At once, before the person is told | PA-14 |
Mover's privileged access removed | On the day the move takes effect | PA-14 |
Shared, service and break-glass credentials a leaver could read changed | Within [[1]] working day | PA-14 |
Supplier engineer leaves: the supplier removes their access | Within [[1]] working day (P06 CL-09, 9.3); an account we hold is disabled the same day we learn of the leaver | PA-15 |
Unknown privileged account claimed, or an interim owner named | Within [[5]] working days, or disabled | PA-01 |
Service account without a permanent owner | Disabled after [[30]] days; deleted [[90]] days later | PA-11 |
Tier breach: password changed, sessions revoked | At once for Tier 0; within [[1]] working day for Tier 1 and 2 | PA-13 |
Records and retention
Record | Kept |
|---|---|
The ticket for every elevation: requester, account, system, tier, rights, reason, approver, approved and actual start and end | [[The period your records policy sets, and at least until the next audit]] |
Privileged sign-ins, elevations, group and role changes and vault openings | At least [[12]] months, where administrators cannot change them (PA-08) |
Removal times for leavers, movers and supplier engineers, with the credentials changed | With the leaver checklist |
Each privileged reset, with the checks made and the second administrator | With the ticket |
Each service account decision: owner, rights, interactive logon, credential | In the inventory |
Each tier breach, with the steps taken and any finding | In the session review record |
Related documents
Document | Relationship |
|---|---|
Privileged Access Standard | The rules this procedure carries out (PA-01 to PA-18) |
Privileged & Service Account Inventory | Every privileged and service account; updated at each step that adds, changes or removes one |
Break-Glass Account Control Checklist | Break-glass use, which this procedure does not cover |
Privileged Session Review Record | The session review that checks every elevation against its ticket (step 7) |
Administrative Tier Model & Separation Matrix | The tier of every system, checked at step 2 |
Joiner-Mover-Leaver Operating Procedure | The joiner, mover and leaver events, and the general reset checks (Joiner-Mover-Leaver & Access Provisioning pack) |
Access Review Campaign Operating Procedure | The access review that finds what this procedure missed (User Access Review pack) |
Segregation of Duties Conflict Matrix; Security Exception & Waiver Standard | The conflicts checked before approval, and exceptions (Security Exception, Waiver & Segregation of Duties pack) |
Supplier Contract Security Clause Library | The supplier access clause (Third-Party Security Risk Management pack) |
Incident Response Plan | A tier breach with signs of compromise (Security Incident Management pack) |
Adapting this template
Guidance — delete before approval
Small organisation: with one or two administrators, the Head of Information Security or a director approves the Tier 0 elevations, and an outside reviewer looks at the sessions. Keep the ticket for every elevation, the automatic end and the stricter reset; they are what stops a stolen administrator credential from being used for long.
Regulated entity (NIS2, DORA): for the digital providers its Article 1 names, Implementing Regulation (EU) 2024/2690 asks for strong authorisation procedures for privileged accounts and administration privileges individualised and restricted (Annex point 11.3.2). A DORA financial entity assigns privileged, emergency and administrator access on a need-to-use or ad-hoc basis (Delegated Regulation (EU) 2024/1774, Article 21(e)(ii)) and removes access without undue delay (21(e)). The ticket, the approval and the automatic end are the record of each.
IT run by a service provider: your managed IT provider's engineers follow the same steps, with your approvers. Agree the on-call approver list with the provider, and make its engineers' leaving notice a contract term.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. 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. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.2 — Privileged access rights | Request to removal; approval authority; emergency elevation |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Approval authority; leavers, movers and suppliers |
ISO/IEC 27001:2022 | Annex A 6.5 — Responsibilities after termination or change of employment | Leavers, movers and suppliers |
ISO/IEC 27001:2022 | Annex A 5.17 — Authentication information | Resetting privileged credentials |
ISO/IEC 27001:2022 | Annex A 5.19 — Information security in supplier relationships | Supplier engineers' accounts and windows |
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” | Approval authority; request to removal |
NIST CSF 2.0 | PR.AA-01 — “Identities and credentials for authorized users, services, and hardware are managed by the organization” | Service accounts without owners; resetting privileged credentials |
NIST CSF 2.0 | DE.CM-03 — “Personnel activity and technology usage are monitored to find potentially adverse events” | Step 7 and responding to a tier breach |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole procedure; regulated-entity tailoring |
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 | Regulated-entity tailoring: the entities the Implementing Regulation binds |
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.” | Approval authority; request to removal; resetting privileged credentials |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(c) — policies that limit access to information and ICT assets to what is required for legitimate and approved functions, with controls that ensure sound administration of access rights | Request to removal: access limited to the approved task |
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 | Approval authority: approving and granting kept apart |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(e) — account management: roles for granting, reviewing and revoking access; privileged access on a need-to-use basis; removal without undue delay; review at least every six months for systems supporting critical or important functions and at least yearly for others | Leavers, movers and suppliers: removal without undue delay |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(e)(ii) — “assignment of privileged, emergency, and administrator access on a need-to-use or an ad-hoc basis for all ICT systems” | Request to removal; emergency elevation: access on a need-to-use or ad-hoc basis |
Definitions
Term | Meaning in this procedure |
|---|---|
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. |
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. |
Break-glass account | An emergency account used only when the normal administration route is unavailable, such as when every administrator is locked out. Sealed, watched, tested and reset after every use (PA-12). |
Daily account | The account a person uses for email, web browsing, chat and ordinary work. It holds no administrator rights anywhere (PA-03). |
Elevation | One activation of just-in-time rights: who, which rights, which system, why, who approved, when it started and when it ended. |
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. |
Privileged account | Any account that holds privileged access, standing or when elevated: a named administrator account, a supplier's administrator account, an application administrator role, a service account, a shared or built-in administrator account, or a break-glass account. |
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). |
Standing rights | Privileged rights an account holds all the time, whether or not the person is doing administration. |
Tier | A group of systems that give the same level of control over the organisation. An administrator account belongs to one tier (A08). |
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). |
Vault | Where shared, service and break-glass credentials are kept: a password manager or vault that records who opened which credential and when, open only to named administrators. A break-glass credential is also sealed in a safe. |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |