Where the Requirements Come From

Much of what a PAM programme does is required rather than discretionary, and the framing affects how it gets funded.

General orientation. Requirements differ by jurisdiction, sector and framework, and change. Take advice for yours.

What frameworks commonly require

Restriction of privileged access to those who need it, with documented justification.

Unique identification of individuals performing privileged actions, which shared accounts defeat.

Multi-factor authentication for privileged access, increasingly as a hard requirement rather than a recommendation.

Logging of privileged activity, retained for a defined period and protected from alteration by the people it records.

Periodic review of who holds privileged access, with evidence.

Removal on role change or departure, with evidence for a sample.

Credential management, including rotation and protected storage.

Segregation of duties in some frameworks, meaning the same person cannot both perform and approve certain actions.

Where sector rules go further

Financial services commonly impose specific requirements on access to systems handling transactions and customer data, with regulator expectations about evidence.

Healthcare regimes address access to patient records specifically, with logging and review requirements.

Payment card environments have detailed and prescriptive requirements on privileged access and logging.

Critical infrastructure and government frameworks frequently mandate specific technical controls rather than outcomes.

Check what applies to you rather than adopting a general framework and hoping it covers the specific rules.

The monitoring side

Requirements pull in both directions, which is the part most often missed.

Security frameworks require recording of privileged activity.

Data protection and employment law constrain how that recording is done, requiring notice, proportionality, purpose limitation and defined retention.

Excessive retention is a compliance problem, not a safe default.

Both sets apply simultaneously, and designing for one while ignoring the other creates exposure in the other direction.

Building evidence into operation

Approval records from the request workflow.

Grant and expiry records from just-in-time.

Rotation records with timestamps.

Review outputs, including findings and their absence.

Periodic inventory snapshots, dated.

Testing results, with findings tracked to closure.

All produced by operating the programme, which is the argument for operating it properly rather than assembling evidence annually.

The framing point

Presenting the programme as a regulatory obligation rather than as a security improvement changes how it is funded.

Obligations compete against nothing. Security improvements compete against every other security improvement.

Both framings are true, and which one is used should be a deliberate choice rather than an accident of who wrote the paper.

Mapping once

Requirements repeat across frameworks and mapping them individually wastes years.

List the frameworks that apply to you.

Extract their privileged access requirements.

Map each to a control you operate, noting the evidence it produces.

Identify the controls satisfying several requirements, which is most of them.

Identify the genuine gaps, which is usually a short list.

Maintain the mapping as frameworks update, rather than rebuilding it before each audit.

The two directions of pressure

Security requirements and privacy requirements pull opposite ways on recording, and both apply.

Security frameworks require privileged activity to be recorded and retained.

Data protection and employment law require notice, proportionality, purpose limitation and defined retention.

Excess retention is a compliance failure, not a safe default, in several jurisdictions.

Design for both: record what is justified, retain for a period you can defend in both directions, restrict access tightly, and document the reasoning.

An organisation optimising for one auditor creates an exposure the other will find.