Identity and Access Management in Banks: IIBF IT Security Guide

Identity and access management is the backbone of every layered defence a bank builds around its core banking system, SWIFT interface and mobile banking channels. For IIBF IT Security candidates, understanding how banks provision, monitor and revoke user access is not optional — it directly maps to exam questions on access control, segregation of duties and audit findings. This guide breaks down the IAM lifecycle, its core components, a comparison of manual versus automated controls, and the regulatory expectations examiners test most often, so you walk into the exam hall with a clear working model rather than isolated definitions.

🔐 What Is Identity and Access Management in Bank IT Systems

Identity and access management (IAM) is the set of policies, processes and technologies a bank uses to establish who a user is, verify that identity at login, and control precisely which systems, screens and transactions that user is permitted to touch. In a bank, "users" is a wide category — branch staff, relationship managers, IT administrators, DBAs, vendors doing AMC support, and even customer-facing self-service channels all sit inside the same identity governance umbrella. IAM is not a single tool; it is a discipline that spans HR onboarding, the core banking system's user-creation module, the Active Directory or LDAP layer, and the audit trail that proves who did what and when.

IAM sits close to broader organisational security and risk management practice because access decisions are ultimately risk decisions — every additional privilege granted widens the bank's attack surface and its potential for insider fraud. A weak IAM programme is one of the most commonly cited findings in IS audit reports, precisely because it touches every application in the technology stack rather than a single system, and because gaps here are exploited both by external attackers using stolen credentials and by employees misusing legitimate access.

👤 Core Components of a Bank's IAM Framework

A mature bank IAM framework rests on three pillars: authentication, authorisation, and lifecycle management. Authentication answers "are you who you claim to be," typically combining two or more of something you know (password/PIN), something you have (hardware token, OTP on registered mobile), and something you are (fingerprint or facial biometric). Multi-factor authentication (MFA) is now mandatory for privileged sessions, remote access and most customer-facing digital channels precisely because password-only authentication is trivially defeated by phishing and credential-stuffing attacks.

Authorisation answers "what are you allowed to do," and banks almost universally implement this through role-based access control (RBAC) — access is tied to a job role (teller, branch manager, DBA) rather than assigned ad hoc to each individual, which keeps entitlements consistent and auditable. High-risk roles such as system administrators and database administrators require an additional layer known as privileged access management; if you want the deep-dive on how banks isolate, vault and session-record these accounts, see our dedicated guide on privileged access management in banks.

💡 Exam Tip: If a question asks which control best enforces "need-to-know" access, the answer is almost always role-based access control combined with the principle of least privilege — not password complexity or firewall rules.

The third pillar, lifecycle management, is what turns static role definitions into a living, auditable system, and it is where most real-world IAM failures actually occur — not in the technology, but in the process discipline of keeping access current as people join, move and leave.

📋 The IAM Lifecycle: Joiner, Mover, Leaver and Access Review

Banks manage the identity lifecycle through what is commonly called the Joiner-Mover-Leaver (JML) process. When an employee joins, HR onboarding triggers a request for baseline access mapped to their role, ideally with each entitlement independently approved rather than copied wholesale from a colleague's profile — a shortcut known as "access cloning" that auditors flag repeatedly because it silently propagates excess privilege across teams. When an employee moves to a new role or branch, their old access must be actively revoked, not simply supplemented with new access; failing to do this creates "privilege creep," where staff accumulate rights from every role they have ever held. When an employee leaves — the "leaver" event — access must be disabled the same day, ideally the same hour, tied directly to the HR separation trigger rather than a periodic batch job.

Underpinning JML is periodic access recertification, where line managers formally re-confirm that each of their team's system entitlements is still required. Asset owners rely on an accurate inventory to do this well, which is why IAM governance is closely linked to the asset classification and controls framework — you cannot certify access to a system whose criticality and ownership were never formally classified. The table below summarises how automated the common IAM controls typically are inside a core banking environment.

⚠️ Common Mistake: Candidates often assume access recertification is a one-time onboarding activity. It is a recurring control — RBI-supervised banks are expected to run it at least half-yearly for privileged accounts.

🌐 Regulatory Expectations and Common IAM Gaps in Indian Banks

The Reserve Bank of India's cyber security and IT governance guidance requires regulated entities to maintain documented, auditable identity and access management controls, including formal provisioning and de-provisioning procedures, mandatory MFA for privileged and remote access, and periodic access reviews — banks can consult the RBI's official guidance directly at rbi.org.in for the current circulars applicable to their category. These expectations are verified in practice through information systems audit, which routinely samples user-access lists against HR exit records to check for orphaned "ghost" accounts belonging to former employees — a finding serious enough to appear in almost every IS audit report; you can read more on how examiners approach this in our chapter on information systems audit.

IAM does not operate in isolation — it is one layer in a defence-in-depth model that also includes network monitoring to catch misuse of even correctly provisioned credentials, which is exactly the territory covered in our guide to intrusion detection systems in banks. Similarly, the credentials and session tokens IAM relies on are only as safe as the cryptography protecting them at rest, a topic explored fully in our piece on encryption key management in banking systems. It is worth noting that this same regulatory pressure extends beyond commercial banks — RBI-regulated non-banking financial companies in India face parallel expectations around identity governance under their own IT framework circulars, so JAIIB and CAIIB candidates studying financial system structure will see the same control themes recur.

📌 Remember: Orphaned accounts, cloned access and skipped recertification are the three IAM findings examiners and real auditors cite most often — know all three by name.

For more exam-focused breakdowns across this subject, browse our full IT Security exam guide archive, which is updated as new chapters and circulars are released.

🧠 Practice MCQs: Identity and Access Management

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

Key Takeaways for Your IIBF IT Security Exam

Identity and access management is tested less as a definitions exercise and more as a scenario exercise — expect questions that describe a lapse (an orphaned account, cloned privileges, a skipped recertification) and ask you to name the control that should have caught it. Anchor your revision around the three pillars — authentication, authorisation, lifecycle — and the JML process, and you will be able to answer almost any IAM question the exam throws at you. To build exam-day speed and confidence, work through timed, chapter-wise practice sets on iibf.store/tests, where every question is mapped back to the IIBF IT Security syllabus.