The reader in mind is an IT manager or business owner at a mid-size firm in India or the GCC. The aim is to judge how well the firm controls administrator and service accounts. Its tests are yes or no questions about those accounts. They ask who holds them, how people use them, where their secrets sit, what happens in an emergency and what the logs record. This privileged access management checklist has 15 checks and a top total of 30. Each test runs from lists and logs a firm already holds, whether it relies on built-in controls or a dedicated tool.
Last reviewed 2026-11-01 by Manish Sharma.
The glossary also explains what makes an account privileged. Nothing here is an audit finding, an attestation or legal advice. This page comes with no file. A sheet you keep yourself can hold the tables, with a column each for the owner, the run date and the mark.
Key Takeaway A yes with no proof kept stays at 1.
Which Accounts Count, and How to Mark the Privileged Access Management Checklist
NCSC’s Introduction to identity and access management (UK; published and reviewed 22 January 2018; for cyber security professionals, large organisations and the public sector) says that anyone whose access can affect change felt beyond their immediate job role “could be considered” a privileged user. Its examples are administrators of business-critical systems, such as database and system admins; people who approve financial payments in systems used for a critical function; and developers who can commit changes to code the business relies on. We also count shared logins, supplier-held admin logins and emergency accounts. A service account belongs to a program or a scheduled job, not a person, and we count those too.
How the Marks, Samples and N/A Work
Score each check out of 2: 2, 1 or 0. A 2 needs a yes from each sampled account and proof dated to the test run. Give a 1 when only some accounts say yes, or all do but nothing is on file. A 0 means a no, or a test that has not been run.
The 15 checks add up to a top total of 30 (Signisys’ own sum), but nothing sets a pass line. Add the marks only after reading each group on its own: a run of 0s in one group can hide behind a healthy-looking total.
Where a check needs a sample, draw up to three accounts from the complete list and note which ones. Draw a fresh set when the next run comes. Test a list of no more than three entries in full. A check with nothing to test gets N/A, and the top total drops by 2. The person marking the privileged access management checklist should not hold any of the accounts under test.
In an illustration with no client behind it, take check 12 and three recent task grants. Two show the rights removed on or before the end date, while the third has no end date on file. That check scores 1, not 2. The marks and pass tests are Signisys’ own, and no source supplies them.

Key Takeaway Thirty points is the ceiling, and nothing marks a pass line.
Checks 1 to 3: Know the Accounts
Here the question is whether the firm can list its privileged accounts. Each service account then needs a job on record, and each full-rights account needs a reason. This group comes first because the administrators sampled in checks 5 and 6 come from the list it builds.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 1. One list holds all privileged accounts: people, shared logins, service accounts and supplier-held admin logins. | The list, with a type column, dated on export. | If each of three accounts found in separate places, such as the directory, a server and an application, is on the list. | NCSC’s Introduction gives administrators of business-critical systems, payment approvers in systems used for a critical function and developers who commit code the business relies on as examples of privileged users, while the list and the three-places test are ours. |
| 2. Each service account names the job that uses it and one person who answers for it. | The list’s job and owner columns. | If the named owner of each of three sampled service accounts can say which job uses it. | Our check. |
| 3. Each full-rights account has a written reason, confirmed with a date by someone other than its owner. | The reason column, with confirmer and date. | If each of three sampled full-rights accounts shows a reason, a confirmer who is not the owner and a date. | NCSC’s 10 Steps says to use full-privilege accounts, such as domain, global or cloud admin, “when absolutely necessary” and to review for unnecessary privileges, while the reason, confirmer and date are ours. |
Checks 4 to 6: From Where, and How, Do Administrators Sign In?
NCSC’s 10 Steps to Cyber Security (UK; published 11 May 2021; for cyber security professionals) is the source. For an administrator’s second check, see the wider employee-access checklist.
A phishing-resistant method, such as a hardware key, resists fake sign-in pages (our description).
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 4. Admin work starts from a device reserved for it. | Reserved devices list and admin sign-in log. | If the source device of each of three sampled admin sign-ins is on the reserved list. | NCSC’s 10 Steps gives separate devices or a browse-down approach for keeping admin and everyday accounts apart, while the log sample is ours. |
| 5. An administrator’s everyday account is refused admin tasks, and the admin account is blocked from mail and browsing. | A dated test note per administrator. | If, for each of three sampled administrators, an admin console refuses the everyday account and mail refuses the admin account. | NCSC’s Introduction says privileged accounts should not read email or browse the web unless protections keep those actions in a less privileged context, while the tests are ours. |
| 6. Administrators sign in to admin tools with a phishing-resistant method. | The sign-in rule and each sampled administrator’s method. | If each of three sampled administrators uses a hardware key or another FIDO or PKI method. | The CISA and NSA guide says privileged users with operating system or database administration rights should have strong, phishing-resistant authentication, with FIDO and PKI forms listed, while the wider test is ours. |
Privileged Access Management Checklist, Checks 7 to 9: Secrets and Defaults
This group covers how a firm stores privileged passwords and keys, known as secrets.
A password vault holds secrets in one locked store.
The CISA and NSA best-practices guide for administrators (US agencies, for IAM administrators; advisory in nature) says default and shared accounts that have to stay enabled can have passwords changed to highly random values protected in a password vault.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 7. Default and shared accounts are disabled, or hold a long random password kept in a password vault. | The default and shared account list, marked disabled or vaulted. | If each of three sampled accounts is shown disabled, or has a vault entry set to a random value. | The CISA and NSA guide, as set out above, on random passwords kept in a vault, while the sample is ours. |
| 8. When a person who knew a service-account secret leaves, the secret is changed. | The leaver list and the change record for each secret. | If each of the last three leavers who knew a secret shows it changed on or before the leaving date. | Our check. |
| 9. A new system’s vendor login is changed or disabled before first use. | The new-system record, with the date the vendor login was dealt with. | If each of the last three systems added shows that date before the system went into use. | Our check. |
Checks 10 to 12: Emergency Access and Time Limits
An emergency account is a login kept for use when normal sign-in fails. Check 12 tests whether rights end on a date.
Emergency access is Signisys’ addition, because the three documents read for this page do not cover it.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 10. An emergency account exists, its sign-in details are sealed, and two named people can reach them. | The custody record naming both people, with the date of the last test of the account. | If the sealed details are held as the record says, both people confirm they can reach them, and the last test is dated. | Our check. |
| 11. Use of the emergency account sends a message to someone other than the user and ends with a written reason. | The message and the reason note for the last use or a test use. | If the last use, or a test use made for this check, shows a message to a second person and a written reason. | Our check. |
| 12. Rights raised for a task end on a set date. | Three recent task grants, with the end date and the removal date. | If each of three recent task grants shows the rights removed on or before the end date. | CISA and NSA describe just-in-time provisioning, a feature of dedicated tools, in which users are temporarily granted privileged access to complete a specific task, while the end-date test is ours and needs no product. |
Key Takeaway Service accounts and emergency access get checks of their own.
Privileged Access Management Checklist, Checks 13 to 15: Watching the Trail
The last group tests that privileged use leaves a trail someone reads. A wider IT risk checklist has one row on watching privileged actions, and these three checks go further.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 13. Each privileged action in the log traces to one named person. | A log extract with names matched. | If each of three admin actions in the log maps to one named person, not to a shared login. | NCSC’s 10 Steps says to ensure you can associate all actions with the person or account that performed them, while the one-person test is ours. |
| 14. A named person reads the privileged-action log and records what they followed up. | The reader’s note, with its date. | If the latest note names the reader, carries a date and lists the follow-up or says none was needed. | NCSC’s Introduction says monitoring privileged actions goes beyond logging to rules that could detect suspicious activity and active review of events, while the note is ours. |
| 15. A new privileged account or role grant sends a message to someone who did not make it. | The message rule and the messages for the last three changes. | If the rule names a recipient who is not allowed to make such changes and each of the last three changes produced a message. | The CISA and NSA guide says attackers who compromise privileged accounts may create further accounts to keep access after the first is disabled, while the message rule is ours. |
What Your Privileged Access Management Checklist Total Means, and What to Fix First
The total is a prompt for action, not a verdict, and no target comes with it. In our view, fix checks 1 to 3 first, because the samples for several later checks, such as the administrators in checks 5 and 6, come from that list, and a 0 there makes those marks less reliable. Next take the group holding the greatest number of 0s, and inside it fix the 0s before the 1s.
Next to each 0, note who will act, what will change and when you will test again. Keep each completed sheet of the privileged access management checklist, then compare the next run with it. For a lighter first pass, start with the page on securing privileged accounts.

Where This Self-Check Stops, and Who Can Give a Second Reading
This self-check is not an audit and applies no India or GCC rule. The sources are government guidance, NCSC from the UK and CISA with NSA from the US. They inform the ideas here, although neither sets rules for your firm. A top total says something about the accounts you sampled, but nothing about those you did not.
Why attackers want admin accounts has its own article, while the order of work to put controls in place, the choice of tool and the scheduled review of everyone’s access are separate subjects. In our view, a second reader helps in three situations: 0s sit in several groups, a service account has an owner nobody can identify, or a customer or auditor asks for records the firm does not keep.
Signisys’ Identity and Access Management solution includes privileged access management: controlled, monitored access for administrators and critical systems. The exact scope is agreed for each engagement. Our Solution: Identity and Access Management (IAM). Our Service: Cybersecurity Services.
Privileged Access Management Checklist FAQ
What belongs on a checklist for privileged accounts?
Can the person who administers the systems score their own accounts?
How should a service account with no known owner be marked?
Does the emergency account count as a privileged account?
Can I copy these checks into my own sheet?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.
