DORA and Privileged Access: Prove ICT Controls That Stand Up to Audit

The audit question is not “do you have PAM?” — it is “can you prove control?”

A bank can spend €400,000 on a privileged access management stack and still fail a DORA review if auditors cannot trace who approved access, why it was granted, and whether the session was monitored. In 2026, regulators are not impressed by policy PDFs; they want evidence that survives incident pressure, vendor churn, and cloud sprawl.

That is the real test of DORA and privileged access: not whether your controls exist, but whether your ICT access controls are demonstrable, repeatable, and recoverable when the environment is under stress. For financial entities, privileged access is where operational resilience becomes measurable.

What DORA expects you to demonstrate about ICT access controls

DORA does not prescribe one vendor or one architecture. It requires you to show that ICT risk is controlled across people, process, and technology, and that access to critical systems is tightly governed. For privileged access, that means your evidence must answer five questions:

• Who can access privileged systems?
• Why do they have that access?
• How is access approved, time-bound, and revoked?
• What did they do during the session?
• Can you recover control if the access path is compromised?

A mature DORA and privileged access program should produce evidence in minutes, not days. If your team needs three analysts and two spreadsheets to answer a basic access question, the control is too weak for an audit-heavy environment.

The evidence set auditors actually ask for

Expect requests such as:

• Privileged access inventory for production, backup, cloud, and identity systems
• Approval workflows for standing and just-in-time access
• Session logs with timestamps, commands, and video or command replay
• MFA enforcement for admin access, including break-glass paths
• Access review records showing recertification and removals
• Exception registers with business justification and expiry dates

A practical benchmark: if you cannot export a complete privileged access evidence pack for a tier-1 application in under 30 minutes, you are not operating at DORA-ready speed.

Build privileged access around traceability, not convenience

The fastest way to fail DORA and privileged access expectations is to treat admin access as a productivity shortcut. Engineers need speed, but regulators need traceability, and your architecture has to satisfy both.

Use just-in-time access for almost everything

Standing admin access should be the exception, not the default. In 2026, most financial entities are moving to just-in-time elevation with approval, time limits, and session recording. The pattern is simple:

1. A user requests elevation for a named system.
2. The request is approved by a manager, app owner, or automated policy.
3. Access is granted for 15 to 120 minutes.
4. The session is recorded and correlated to the request ID.
5. Access expires automatically.

A European payments provider that moved from permanent Unix sudoers access to JIT elevation cut its privileged user count by 68% and reduced quarterly access review effort from 11 days to 3 days.

Separate identity, authorization, and session control

Do not let one tool do everything poorly. A robust DORA and privileged access design separates:

• Identity: central IdP with MFA and conditional access
• Authorization: policy engine for role, risk, and time-based approval
• Session control: proxy, broker, or gateway that records activity

That separation matters because it creates independent evidence. If the IdP says access was granted, the session broker should prove the session happened, and the target system should show the action occurred.

[User] -> [IdP + MFA] -> [Approval Workflow] -> [PAM Broker] -> [Target System]
                           |                         |
                           v                         v
                    [Ticket ID / CMDB]        [Session Recording]
                           |
                           v
                   [SIEM / GRC Evidence Store]

Enforce least privilege with measurable thresholds

Least privilege is not a slogan. It is a measurable reduction in access scope. Good programs define thresholds such as:

• No shared admin accounts except documented break-glass accounts
• 100% of production admin access time-bound or session-brokered
• 0 direct SSH or RDP to critical assets from unmanaged endpoints
• 100% of cloud root or subscription-owner actions logged and reviewed
• All privileged access recertified every 90 days for tier-1 systems

If you cannot measure these thresholds, you cannot defend them in a DORA review.

What strong DORA evidence looks like in practice

You need artifacts that show control operation, not just control design. For DORA and privileged access, that means evidence should be tied to real systems, real users, and real dates.

Example: a privileged access approval record

A good record includes the request, approver, expiry, and session link.

{
  "requestId": "PA-2026-004812",
  "user": "maria.ionescu@bank.example",
  "target": "prod-oracle-19c-finance",
  "role": "db_admin_elevated",
  "reason": "Patch validation after PSU deployment",
  "approvedBy": "app-owner@bank.example",
  "approvedAt": "2026-04-18T09:12:44Z",
  "expiresAt": "2026-04-18T11:12:44Z",
  "sessionId": "sess-88f1c2",
  "recordingUrl": "https://evidence.example/sess-88f1c2"
}

This is the kind of artifact that makes audits faster. It also helps incident response, because you can correlate the access event to a change ticket, a patch window, or a suspicious action.

Example: Linux sudoers without permanent broad rights

# /etc/sudoers.d/dbops-jit
Cmnd_Alias DB_MAINT = /usr/local/bin/rotate_logs, /usr/local/bin/check_replication, /usr/bin/systemctl restart oracle-db
%dbops ALL=(root) NOPASSWD: DB_MAINT
Defaults!DB_MAINT log_output, use_pty
Defaults timestamp_timeout=0

This is not enough on its own, but it shows a pattern auditors like: narrow commands, command logging, and no cached privilege. Pair it with session recording and a ticket reference, and you have evidence that supports DORA and privileged access claims.

Example: cloud admin access with policy guardrails

# Azure-style conditional access / privileged role policy example
privileged_role_policy:
  role: Subscription Owner
  assignment: just_in_time
  max_duration_minutes: 60
  mfa_required: true
  compliant_device_required: true
  approval_required: true
  session_logging: enabled
  break_glass_exceptions:
    - account: bg-admin-01
      monitor: 24x7
      rotate_secret_hours: 24

In cloud estates, the biggest failure mode is standing subscription-owner access that nobody can explain. In a 2026 internal benchmark from a multinational insurer, moving to JIT and approval for cloud owners reduced permanent privileged assignments by 74% and cut over-privileged identities by 51%.

How to prove resilience when privileged access is the failure point

DORA is not only about access governance. It is also about operational resilience, which means your privileged access controls must continue to function during outages, incidents, and vendor failures.

Design break-glass access as a controlled emergency path

You need a break-glass process, but it must be more controlled than your normal admin path. A good emergency model includes:

• Two named emergency accounts per critical platform
• Offline or hardware-backed secret storage
• Mandatory post-use review within 24 hours
• Real-time alerting to SOC and duty managers
• Quarterly test of the full recovery path

A financial entity that tested break-glass quarterly found its median emergency access activation time was 4 minutes 20 seconds, but only after fixing a failed MFA fallback and a stale contact list. Before that, the same process took 19 minutes and often required manual password resets.

Test the control under failure conditions

You should be able to demonstrate access control behavior when:

• The IdP is degraded
• The PAM broker is unavailable
• The network segment to production is isolated
• The approver is on leave
• The SIEM pipeline is delayed by 15 minutes

If your controls collapse in those scenarios, the architecture is not resilient enough for DORA and privileged access expectations.

Failure test matrix
----------------------------------------------------
Scenario                     | Expected outcome
----------------------------------------------------
IdP outage                   | Break-glass only, fully logged
PAM broker outage            | No admin elevation for non-emergency tasks
Approver unavailable         | Secondary approver or policy-based routing
SIEM delay                   | Local immutable logs retained for 30 days
Compromised admin endpoint    | Conditional access blocks session start
----------------------------------------------------

Common Pitfalls

Most DORA findings around privileged access come from predictable mistakes, not exotic attacks. The same patterns repeat across banks, insurers, and payment firms.

1. Treating access reviews as a spreadsheet exercise

If reviews happen in Excel with no system-of-record linkage, you will miss orphaned accounts and false approvals. Use a GRC or IAM workflow that ties every attestation to an identity, a system, and a timestamp.

2. Leaving shared admin accounts unmonitored

Shared accounts destroy accountability. If you must keep one for emergency use, wrap it in a vault, rotate the secret after every use, and require dual control.

3. Allowing direct admin paths from unmanaged devices

A contractor with a personal laptop should not reach production admin consoles directly. Conditional access should require device compliance, certificate trust, and MFA phishing resistance.

4. Logging sessions but not correlating them

A recording without request ID, asset ID, and approver context is weak evidence. Correlation is what turns logs into audit proof.

5. Ignoring non-human privileged identities

Service accounts, automation bots, CI/CD runners, and cloud deployment roles often have broader access than human admins. Inventory them, scope them, and rotate their secrets or keys on a defined cadence.

A common benchmark: organizations that inventory non-human privileged identities often discover 1.5 to 3 times more privileged principals than they expected.

A practical operating model for 2026

If you are building or remediating DORA and privileged access controls this year, use a model that combines governance, engineering, and evidence automation.

Minimum control stack

• Central identity provider with phishing-resistant MFA
• PAM or privileged session broker for production access
• JIT elevation with policy-based approval
• Immutable logging to SIEM and evidence repository
• Quarterly recertification for privileged roles
• Break-glass accounts with monitored offline recovery

Suggested implementation sequence

1. Inventory all privileged accounts, including cloud, database, endpoint, and automation identities.
2. Classify systems by criticality and map privileged paths to each tier.
3. Remove standing access where JIT is feasible.
4. Enforce session recording for all tier-1 and tier-2 admin activity.
5. Automate evidence export into your GRC or audit repository.
6. Test break-glass, revocation, and recovery quarterly.

What good looks like operationally

A strong target state is achievable. For a 2,000-user financial entity with 180 privileged identities, a mature program can typically:

• Reduce permanent admin assignments by 60-80%
• Cut access review effort by 50-70%
• Bring privileged session start latency to under 20 seconds for approved users
• Produce complete audit evidence for a critical system in under 15 minutes

Those numbers are realistic when identity, workflow, and logging are integrated. They are not realistic when controls are scattered across email, tickets, and local server configs.

Key Takeaways

• DORA and privileged access is about proof, not policy: every admin action should be traceable to a request, approver, and session record.
• Replace standing admin rights with just-in-time access for production, cloud, and database systems wherever possible.
• Separate identity, approval, and session recording so you can independently prove each control worked.
• Test break-glass access quarterly and document recovery time, logging, and post-use review.
• Eliminate shared and unmanaged admin paths, especially for contractors and cloud owners.
• Automate evidence collection now; if you cannot export a complete privileged access pack in 30 minutes, your control design is not audit-ready.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.