User access auditing in a bank is a documented, repeatable check of who can reach which systems and data, whether each person still needs that access, and whether every action can be traced to one individual. In the EU, the Digital Operational Resilience Act (DORA) turned this from good practice into a regulated duty. If you run or supervise a payment institution, an e-money institution or a bank in Lithuania, you need a written access policy, a review calendar and evidence that you follow both.

This guide explains what the rules require, how a review runs step by step, where audits usually find gaps, and how to prepare. It also covers what business clients should check in the bank or payment provider that holds their money.

Demivoltdemivolt.comManage Business Access with ControlDemivolt offers role-based user management and segregated accounts for businesses seeking clearer control over financial access.Visit Demivolt

TL;DR

DORA has applied since 17 January 2025 and requires access based on need-to-know, need-to-use and least-privilege principles.
Access rights must be recertified at least yearly, and at least every six months for systems supporting critical or important functions.
Joiner-mover-leaver discipline, individual accountability and written evidence are the three most common audit pressure points.
Audits must be performed by independent, competent auditors, and results go to the management body for approval.
For business clients, role-based user management and segregated accounts are practical signs that a provider takes access control seriously.

What user access auditing means in a bank
The regulatory frame in Lithuania
Review cadence: annual and six-month cycles
How a user access review runs, step by step
The four-eyes principle
Joiner, mover, leaver: where audits usually fail
Individual accountability and shared accounts
Privileged and emergency access
Documentation is as important as configuration
Who audits the audit: internal and independent review
Common findings and how to prevent them
Our perspective: access control is a client-facing feature
What business clients should check in their bank
Start with a business account built for controlled access
A 30-day preparation checklist
FAQ
Sources

What user access auditing means in a bank

The Lithuanian phrase naudotojų auditavimas covers two related activities. The first is the review of user accounts and permissions inside the institution: employees, contractors, administrators and service accounts. The second is the audit trail, the log that shows who did what and when. A bank needs both. A permission review without logs cannot prove what happened. Logs without a review only prove that excessive access was used.

It is also not only an IT task. The Bank of Lithuania’s information security policy treats security management as a set of governing principles applied across all activities, and the same logic applies to supervised institutions: business owners approve access, IT implements it, and internal audit tests it.

Three questions sit behind every review:

Who has access? Every account, human or technical, mapped to a named owner.
Should they? Each right matched to a current job function.
Can you prove it? Approvals, logs and review sign-offs that an outsider can verify.

The regulatory frame in Lithuania

The Bank of Lithuania explains that Regulation (EU) 2022/2554 (DORA) entered into force on 16 January 2023 and applies from 17 January 2025. It covers credit institutions, payment institutions, electronic money institutions and other financial entities supervised in Lithuania.

The detailed access rules sit in the technical standard on ICT risk management. Article 21 of the DORA RTS requires financial entities to develop, document and implement an access control policy. Under the Bank of Lithuania’s summary, access must follow need-to-know, need-to-use and least-privilege principles, with formal procedures for managing the user account lifecycle and timely withdrawal of rights when employment ends or access is no longer required.

The EBA’s earlier guidelines on ICT and security risk management add the audit layer. Institutions should have their ICT and security arrangements audited periodically by independent auditors with sufficient expertise in ICT, security risks and payments. Frequency and scope should be proportionate to the inherent risk, and the management body approves the results.

Review cadence: annual and six-month cycles

The single most missed detail is the difference between two review cycles. According to the DORA access control article, access rights are recertified at least once a year for standard ICT systems and at least every six months for systems that support critical or important functions. Businesses often apply the annual rhythm to everything and receive a finding for it.

A practical calendar looks like this:

System type	Minimum recertification	Event-driven review
Core banking, payment processing, card processing, customer onboarding	Every 6 months	On any role or status change
Supporting systems (HR, office tools, internal wikis)	Every 12 months	On any role or status change
Privileged and emergency access	Per use, plus the cycle of the system it touches	After every task

A change in a user’s role or status should trigger an immediate review of that person’s privileges. Do not wait for the next scheduled campaign.

How a user access review runs, step by step

Define the scope. List the systems in scope and classify each one as critical or important, or not. This classification decides the cadence.
Extract the current entitlements. Pull the full list of accounts and permissions from each system, including service and generic accounts, directly from the system and not from memory or an old spreadsheet.
Reconcile with HR data. Match every account to an active employee or contractor. Orphan accounts and accounts of departed staff are the first findings.
Send to reviewers. Line managers confirm that each person still needs each right. System owners confirm the technical meaning of the right.
Remove or adjust. Anything not confirmed is removed. Record the date and time of each change.
Test the result. A second person, ideally from risk or internal audit, samples the removals to confirm they happened.
Report and approve. Summarize findings, exceptions and remediation for management sign-off.
Retain evidence. Keep the extracts, approvals, tickets and logs in a place the auditor can reach.

The EBA’s standard on access control and authentication reflects the same process principles: access is granted only on a formal request, and every change to access administration is logged so it can be audited.

The four-eyes principle

No single person should be able to initiate, authorize and execute a critical financial or administrative action alone. The Bank of Lithuania’s security policy sets out the principle of segregation of duties, and the four-eyes approach is its everyday form. In an access context it means:

The person who requests a privileged role is not the person who approves it.
The administrator who grants a right cannot also review that right in the recertification.
Payment release above a set threshold needs a second approver.

When you audit, test these separations explicitly. A common finding is a single administrator who can create a user, assign the approver role and release payments, because each permission was added at a different time for a different reason.

Joiner, mover, leaver: where audits usually fail

Auditors look closely at the joiner-mover-leaver (JML) lifecycle. The DORA access control playbook describes what they check: timestamps showing that access was removed without undue delay after a departure, and a link between HR or IT termination tickets and the revocation workflow. A manually maintained spreadsheet is rarely enough on its own.

What to document for each stage:

Joiner: the request, the approver, the role template applied and the date access started.
Mover: the old role, the new role, the removal of rights that no longer apply, and the date. Movers are the main source of privilege accumulation, because new rights are added and old ones stay.
Leaver: the termination date, the revocation timestamp for each system, and confirmation that tokens, keys and cards were also withdrawn.

The time gap between the termination ticket and the revocation timestamp is the metric an auditor will compute. Measure it yourself first.

Individual accountability and shared accounts

The regulator treats untraceable actions as a significant risk. Under the access control article, institutions should keep shared or generic accounts to the absolute minimum. Where one is unavoidable, the system must still identify the individual user behind every action, for example through a check-out process that records who used the credential and when.

Test this in practice: pick five actions from the logs of a critical system and ask who performed each. If the answer is a team name or a shared login, you have a finding.

Privileged and emergency access

Administrator access is not a standing entitlement. As the same playbook explains, privileged and emergency access should be granted on an ad-hoc, need-to-use basis, and auditors often ask for time-bound access records or tickets that show the access ended once the task was complete. Strong or multi-factor authentication should protect remote and privileged access.

For technical credentials such as API keys, the same logic applies: named owners, rotation, and revocation when the integration or person changes. Our article on secure API key management for fintech integrations covers this in more detail.

Documentation is as important as configuration

An institution can have strong technical controls and still receive a negative finding. Compliance practitioners note that auditors review written policies and the evidence that they are followed, such as logs, tickets and approval workflows. Without a documented joiner-mover-leaver policy and a verifiable audit trail, even good controls may be flagged. The source for this is the same DORA access control guide.

Keep an evidence pack per review cycle:

The access policy with version and approval date.
System extracts taken on the review date.
Reviewer confirmations and exceptions.
Removal tickets with timestamps.
The management report and its approval.

Who audits the audit: internal and independent review

Two layers exist. Internal audit is the third line of defense. The Bank of Lithuania describes its own internal audit unit as one that independently tests the effectiveness and efficiency of operations, risk management and control processes. Supervised institutions mirror this with an internal audit function or an outsourced equivalent.

The second layer is the independent ICT and security audit that the EBA guidelines describe. Pick auditors with real experience in payments and ICT. Give them the evidence pack rather than a verbal walkthrough, and have the management body review the findings formally.

Note that the Lithuanian law on financial statement audit, which dominates search results for this topic, concerns the audit of annual accounts. It is a different subject from the access and ICT audit discussed here.

Common findings and how to prevent them

Finding	Typical cause	Prevention
Departed employee still active	Manual offboarding	Link HR termination to automatic revocation and log the timestamp
Annual review only	One cadence for all systems	Classify systems; six-month cycle for critical ones
Accumulated rights after role change	Rights added, never removed	Role templates and a mover review
Shared admin login	Convenience	Individual accounts or a checkout process that identifies the user
One person controls the full payment chain	Rights added over time	Separate request, approval and execution roles
No proof of review	Verbal sign-offs	Written confirmations stored with the extract

Our perspective: access control is a client-facing feature

We see access auditing from two sides. As a regulated platform, we have to run these controls ourselves. As a provider of business accounts, we also see how our clients structure access to their own money, and that structure is often the weakest part of a small company’s finance function.

Most SMEs share one login between the founder, the bookkeeper and an assistant. Nobody can later say who approved a transfer. When someone leaves, nobody knows which cards, integrations or approvals they held. A company does not need a bank-grade audit department to avoid this. It needs separate users, roles that match job functions, a second approver for payments and a short review once or twice a year.

That is why we built our business accounts around multi-account structures and role-based user management, and why we hold client funds in segregated accounts. When you evaluate any provider, ask how it handles roles, how it separates your funds and whether you get a dedicated client manager to help you restructure access when your team changes. Our article on permission hierarchy in finance, licenses and user roles goes deeper on role design.

— dd

What business clients should check in their bank

If you are a company rather than a bank, you are on the other side of the audit. You rely on your provider’s controls, and you must run your own. A short due diligence list:

Is the provider regulated in the EU, and can you verify the license on the supervisor’s register?
Can you create several users with different roles, and can you restrict who may approve payments?
Are client funds segregated from the provider’s own funds?
Can you remove a user or freeze a card immediately, without a support ticket?
Do you have a named contact for changes in authorized persons?

Cards are part of access control too. Spending rights, merchant restrictions and card ownership should follow the same joiner-mover-leaver logic, and our guide on merchant blocking on business cards shows how category rules limit exposure.

Start with a business account built for controlled access

Demivolt offers regulated business accounts with dedicated IBANs, multi-account structures and role-based user management. Account opening, verification, monthly maintenance and the Dedicated Client Manager carry no fee, according to our published fee schedule. If your team issues spending cards, our card programmes page explains virtual and physical Visa business cards. To discuss how to set up roles for your team, contact us through the Demivolt site and get started.

A 30-day preparation checklist

Week 1: Inventory. List systems, classify critical ones, and extract all accounts. Identify shared and service accounts.

Week 2: Policy. Write or update the access policy and the joiner-mover-leaver procedure. Define roles and who approves what.

Week 3: Review. Run one full recertification on the critical systems, remove surplus rights and log every change with a timestamp.

Week 4: Evidence and reporting. Assemble the evidence pack, test a sample of removals, and present the results to management for approval. Set the next review dates in a calendar: six months for critical systems, twelve for the rest.

FAQ

How often must a bank review user access rights?

Under the DORA technical standard, at least once a year for standard ICT systems and at least every six months for systems supporting critical or important functions. A change in someone’s role or status should trigger an immediate review of that person’s rights, outside the regular cycle.

Who must perform the audit of access governance?

Periodic ICT and security audits should be performed by independent auditors with sufficient expertise in ICT, security risks and payments, according to the EBA guidelines. Results are approved by the management body, and the frequency and scope are proportionate to the institution’s inherent ICT and security risks.

Are shared accounts allowed in a regulated financial institution?

They should be limited to the absolute minimum. Where a generic account cannot be avoided, the system must still make the individual user identifiable for every action, because untraceable actions are treated as a significant risk to operational resilience.

What evidence will an auditor ask for?

Expect the written access policy, system extracts of current permissions, reviewer sign-offs, removal tickets with timestamps, and logs of privileged access. Auditors look at whether the policies are followed consistently, not only at how systems are configured.

User Access Auditing in Banks: What Regulators Expect