Privileged access rights

Plain-language summary

Restricting and controlling administrator-level access — domain and cloud global admins, database owners, firewall and ERP superusers — so that the accounts that can change everything are few, separately authenticated, granted only when needed, and watched.

What the clause is really asking

Privileged accounts are what attackers hunt for, because one compromised admin credential turns a single infected laptop into a company-wide incident. The control asks you to know who holds privileged rights on each system, grant them only through a recorded authorisation and only to the extent the job needs, and remove them when the need ends. Admin work should be done from a separate account from the one used for email and browsing, protected by stronger authentication — MFA at minimum, phishing-resistant where you can — and, where the tools allow, granted just in time rather than permanently. Generic shared accounts such as 'admin' should be avoided or tightly controlled, with emergency break-glass accounts kept sealed and monitored. Privileged activity is logged and reviewed. The common misunderstanding is limiting this to IT staff: the finance manager with full rights in the accounting system and the MSP technicians signed into your tenant are privileged users too. Under POPIA section 19, unmanaged admin rights over systems holding personal information are hard to defend as a reasonable safeguard.

What auditors look for

Auditors ask for a list of every privileged account across the main systems — directory, cloud tenant, firewall, ERP, database — and compare it with the people who should have them. They ask for the approval record for a sample of admins and when the list was last reviewed. They check whether admins use separate accounts, whether those accounts have MFA enforced, and whether any are shared or simply named 'admin'. They ask how the MSP's access is controlled and logged, and they want to see break-glass credentials stored securely with an alert on use. The hard question: show me what your admins did last week, and who looked at it.

Typical evidence

Privileged access procedure; register of privileged accounts per system with owner and justification; approval records for granting privileged rights; periodic privileged access review records; evidence of separate admin accounts and enforced MFA; just-in-time or privileged access management configuration; break-glass account procedure and sign-in alerting; privileged activity logs with review evidence; supplier and MSP access arrangements.

How to comply — recommendations

Start with a privileged account register: every system, every account with admin-level rights, the named person, the reason and the approver — include the ERP, the firewall, the cloud tenant and the MSP. Cut the list hard; an organisation of this size rarely needs more than two or three global administrators. Give each admin a separate privileged account with no mailbox, enforce phishing-resistant MFA or at least number matching on it, and use just-in-time elevation where your platform offers it. Create two break-glass accounts with long random passwords stored offline and an alert on any sign-in. Review the register quarterly with system owners and remove what is not needed. Send privileged sign-ins and role changes to a log someone reviews.

Common nonconformities

Privileged rights granted without recorded approval; more global or domain administrators than the roles justify; admins using their everyday account for privileged work; shared or generic admin accounts with no individual accountability; MFA not enforced on privileged accounts; MSP or supplier admin access unmanaged; no periodic review of privileged rights; privileged activity not logged or never reviewed.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.