SOC 2, ISO 27001, PCI DSS 4.0, NIS2 and DORA, read for the access controls

Read the major security frameworks side by side and the access-control sections say remarkably similar things in different words. Give people only the access their role needs. Approve it before it is granted. Give privileged access extra care. Remove it when it is no longer needed. Review it periodically. And keep records that prove all of this happened. What differs is the vocabulary, the level of detail, and how hard the auditor or regulator will look.

This post reads SOC 2, ISO/IEC 27001:2022, PCI DSS 4.0, the EU’s NIS2 Directive and the Digital Operational Resilience Act (DORA) for what they ask of privileged access, then sets out the records an access programme must be able to produce. It is a guide for boards and senior management, not legal advice. Control numbering and wording below are summarised; confirm the exact text and its interpretation for your organisation with your auditor or adviser.

The five expectations every framework shares

Before looking at each framework, it helps to see the common core. Across all five, an auditor or supervisor is looking for evidence of the same five properties, applied with particular rigour to privileged access — administrator rights, database owners, cluster-wide roles, and anything that can change other people’s access.

Expectation	In plain words	What the auditor asks for
Least privilege	People get the access their job needs and no more	Role or entitlement definitions; evidence that grants match them
Authorisation	Access is approved by someone accountable before it is granted	A sample of grants, each with a recorded approval by an appropriate person
Privileged access managed	Powerful rights are restricted, justified, time-bound and monitored	The list of privileged users, the reason for each, and how use is monitored
Timely removal	Access ends when it is no longer needed	A sample of leavers and movers, and evidence of removal within policy
Periodic review	Someone accountable re-confirms access at a set interval	Completed reviews, who reviewed, what was removed as a result

SOC 2: the Common Criteria for logical access

SOC 2 reports are built on the AICPA’s Trust Services Criteria. Access control sits mainly in the CC6 series, “logical and physical access controls”. Three criteria do most of the work for privileged access:

• CC6.1 — the entity implements logical access security over protected information assets, including restricting access and managing credentials and privileged access.
• CC6.2 — before issuing credentials and granting access, the entity registers and authorises users, and removes access when it is no longer authorised.
• CC6.3 — the entity authorises, modifies or removes access based on roles and responsibilities, considering least privilege and segregation of duties.

SOC 2 does not prescribe a review interval or a technology. The auditor tests whether your own described controls operated across the period, typically by sampling. For a Type 2 report, that means a sample of access grants with their approvals, a sample of removals, and evidence that reviews took place as your policy says. Monitoring criteria in the CC7 series are often tested alongside, for how anomalous activity is detected.

ISO/IEC 27001:2022: Annex A controls

The 2022 revision reorganised Annex A into four themes. The access controls an auditor will read against a privileged access programme are chiefly:

Annex A control	Subject	What it expects, in summary
5.15	Access control	Rules to control access to information and assets, based on business and security requirements
5.16	Identity management	The full life cycle of identities is managed
5.18	Access rights	Access rights are provisioned, reviewed, modified and removed in line with policy and rules
8.2	Privileged access rights	Allocation and use of privileged access rights is restricted and managed
8.5	Secure authentication	Authentication technologies and procedures appropriate to the access
8.15	Logging	Logs that record activities and other relevant events are produced, kept and reviewed

The guidance in ISO/IEC 27002:2022 for control 8.2 is direct about the behaviours an auditor will look for: an authorisation process for privileged rights, allocation on a need-to-use and event-by-event basis, expiry requirements, and logging of privileged use. Time-limited, per-task access is close to a literal reading of that guidance. As always, the certification auditor tests against your Statement of Applicability and your own policies.

PCI DSS 4.0: requirements 7 and 8

The Payment Card Industry Data Security Standard is the most prescriptive of the five. Version 4.0 (with its 4.0.1 update) has been the only active version since the end of 2024, and requirements that were “future-dated” became mandatory from 31 March 2025.

Requirement	Subject, summarised	Why it matters for privileged access
7.2.1 – 7.2.3	An access control model; access assigned on job classification and least privilege; approval by authorised personnel	Every grant to the cardholder data environment needs a defined basis and an approval
7.2.4	All user accounts and their access privileges reviewed at least once every six months, with management acknowledging the result	A recurring, documented review — not just for leavers
7.2.5 – 7.2.5.1	System and application accounts limited to least privilege, and their access reviewed periodically	Service and CI roles, not only people, are in scope
8.2.6	Inactive user accounts removed or disabled within 90 days	Standing accounts nobody uses are a finding in their own right
8.4.2	Multi-factor authentication for all access into the cardholder data environment	Step-up at the moment of privileged access supports this
10.2	Audit logs capture user activities, including all actions by anyone with administrative access	The trail must show what privileged users did, not only that access existed

A practical reading for a payments business: every administrator in the cardholder data environment is a line in a six-monthly review, every grant needs an approval, and every action under administrative access must be logged. The fewer standing administrators there are, the shorter and more defensible each of those becomes.

NIS2 and DORA: access control in law

The two EU instruments differ from the standards above in one important way: they are law, and they make management accountable. NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across many sectors. DORA (Regulation (EU) 2022/2554) applies to financial entities and has applied since 17 January 2025.

Instrument	Where access appears	What it expects, in summary
NIS2, Article 21(2)	Points (i) and (j) of the list of risk-management measures	Human resources security, access control policies and asset management; and the use of multi-factor or continuous authentication where appropriate
NIS2, Article 20	Governance	Management bodies approve the cybersecurity risk-management measures, oversee their implementation and can be held liable
NIS2 implementing rules	Commission Implementing Regulation (EU) 2024/2690, for certain digital-infrastructure and digital-provider entities	More detailed requirements, including for privileged and system administration accounts and access review
DORA, Article 9	Protection and prevention	Policies that limit physical and logical access to ICT assets to what is required for legitimate and approved functions, and strong authentication
DORA RTS on the ICT risk-management framework	Commission Delegated Regulation (EU) 2024/1774, access-control provisions	Least privilege and need-to-know, management of privileged accounts, timely revocation and periodic review of access rights, with logging

The records you need to be able to produce

Every one of these frameworks ultimately asks to see records. The practical test of an access programme is whether, for any privileged grant in the audit period, it can produce the full story without anyone reconstructing it from chat history and cloud logs.

One record per grant, from request to review. An auditor sampling any grant should be able to follow it end to end.

Record	What it should contain	Frameworks it supports
Request	Requester, resource, access level, duration, ticket, reason in their words	SOC 2 CC6.2; ISO 5.18; PCI 7.2
Decision	Who approved or that it was approved automatically by which rule; the risk score and why; second factor if used	SOC 2 CC6.2–CC6.3; ISO 8.2; PCI 7.2.3, 8.4.2
Grant	The exact permission created, where, and its expiry	SOC 2 CC6.1; ISO 8.2; DORA access-control RTS
Activity	What was done under the grant, with anything out of scope flagged	SOC 2 CC7; ISO 8.15; PCI 10.2
Removal	When and how access ended, and by whom or what	SOC 2 CC6.2; ISO 5.18; PCI 8.2.6
Review	Each line kept or removed, reviewer, date, reason	ISO 5.18; PCI 7.2.4; NIS2 and DORA review expectations

InsightKeys keeps that record by default. The audit trail describes in words every request, approval, grant, revocation, instruction to the broker and agent action. Grants and access reviews can be exported to InsightAssure, VerticalServe’s compliance product, as evidence for access-control controls, and reviews can be exported as CSV for any other tool.

Periodic review that a reviewer can actually do

Access reviews are where many audit findings start, and where many organisations quietly fail. A spreadsheet of hundreds of lines with no usage data cannot be reviewed meaningfully, so it is approved wholesale, and the review becomes evidence of a process rather than of a decision. PCI DSS 7.2.4’s requirement for management to acknowledge that access remains appropriate is hard to meet honestly that way.

A review becomes credible when each line carries evidence. In InsightKeys, review campaigns are created per scope — for example, all production access, standing plus grants from the last ninety days. Each line is pre-filled with last use, number of uses in ninety days, and an agent recommendation to keep or remove with its reason. The reviewer still decides. Removing a line sends the revocation through the broker, so the review and the removal are one record.

What the board should ask

Keep reading