Types of Security Controls in Banks: A 2026 IIBF Exam Guide

Every IIBF IT Security paper carries at least a few questions on types of security controls in banks — the preventive, detective, corrective and compensating measures that keep a bank's systems, data and customers safe. Candidates often memorise the names but stumble when asked to classify a real-world example, which is exactly how the exam tests this topic. This guide breaks the classification down control-by-control, maps each type to the IIBF syllabus chapters, and closes with practice questions built in the exam pattern.

Banks run hundreds of controls across people, process and technology layers, but every single one of them falls into one of four buckets by when and how it acts. Understanding that timing — before, during or after an incident — is the fastest way to answer classification-style MCQs correctly, and it is also how auditors and RBI examiners actually think about a bank's control environment.

🛡️ What Are IT Security Controls and Why They Matter

An IT security control is any safeguard — technical, administrative or physical — put in place to protect the confidentiality, integrity and availability (the CIA triad) of a bank's information assets. Controls are selected after a risk assessment identifies which assets need protection and what threats they face, which is why asset inventories sit right at the start of most security frameworks.

The IIBF syllabus groups this material under asset classification and controls, which pairs each information asset with a sensitivity label and a matching control strength. A core banking database, for instance, needs far tighter controls than a public marketing webpage, even though both sit on the same network.

Regulators do not prescribe one universal control list; instead they expect banks to run a risk-based mix guided by recognised frameworks such as ISO 27001 and RBI's cyber security circulars. What examiners want candidates to know is the logic of classification — preventive controls stop an event, detective controls flag it once it has started, and corrective controls repair the damage afterward. A fourth category, compensating controls, steps in when the ideal control cannot be deployed for cost or technical reasons.

💡 Exam Tip: If a question describes an action taken "after" an incident is confirmed, it is corrective. If it describes something that "flags" or "alerts" during an ongoing event, it is detective — not preventive.

🚧 Preventive Controls: Stopping Threats Before They Strike

Preventive controls are designed to stop a security incident from happening at all. They are the first line of defence and the cheapest controls to justify, because preventing an incident is almost always less costly than recovering from one.

Common preventive examples in a bank include firewalls, access control lists, encryption at rest and in transit, security awareness training, background checks on staff, and physical measures such as biometric door locks and CCTV-monitored data centres. The chapter on physical and environmental controls covers the non-technical half of this category — power backup, fire suppression, and access badges — which examiners like to test alongside purely digital controls.

On the network side, segmentation, VPN gateways and hardened configurations on routers and switches all sit under the chapter on network controls. Device-level preventive work — patching, disk encryption, application whitelisting — overlaps closely with what our sibling article on endpoint security in banks covers in more depth if you want the full hardening checklist.

⚠️ Common Mistake: Students often classify an antivirus scan as "detective" because it scans and reports. Real-time antivirus that blocks a file before execution is preventive; a scheduled scan that reports infections after the fact is detective. Read the question carefully.

🔍 Detective Controls: Spotting Incidents in Real Time

No control set is 100% preventive — some threats will always get through, whether it is a zero-day exploit, a phished credential, or an insider misusing legitimate access. Detective controls exist to catch these events as early as possible, minimising the window of exposure.

Typical detective controls in a bank's stack include intrusion detection and prevention systems, log monitoring and SIEM correlation rules, file integrity monitoring, CCTV review, and transaction monitoring for fraud patterns. A bank's Security Operations Centre is the operational home for most of this activity — our companion piece on security operations centre in banks walks through SOC tiering, alert triage and the metrics regulators expect to see.

The IIBF chapter on IT security threats is worth revising alongside this section, because most exam questions pair a specific threat (malware, DDoS, phishing) with the detective control best suited to catching it. Audit trails and exception reports also fall here — they do not stop fraud, but they make sure it cannot stay hidden for long.

🩹 Corrective and Compensating Controls: Containing the Damage

Corrective controls activate once an incident has already been confirmed. Their job is to limit further damage and restore normal operations — patching a newly discovered vulnerability, isolating an infected endpoint, restoring data from backup, or forcing a password reset after a credential leak are all corrective actions.

Incident response plans, forensic investigation procedures, and the post-incident root-cause review that feeds back into the risk register are the process backbone of this category. Getting this sequence right — contain, eradicate, recover, review — is a recurring theme in IIBF case-study questions, so candidates should be able to name which step a given action belongs to.

Compensating controls are the fourth, often-forgotten category. They are alternative safeguards used when the primary control is not feasible — for example, a legacy system that cannot support modern encryption might instead be isolated on a restricted network segment with tighter monitoring. Auditors accept compensating controls only when they are documented, approved, and demonstrably reduce the same risk to an acceptable level.

📌 Remember: Preventive → stops it. Detective → spots it. Corrective → fixes it. Compensating → substitutes for a control that cannot be applied directly.

📋 Mapping Controls to the Software Development Lifecycle

Controls are not only an operations concern — they belong inside every phase of how a bank builds and maintains its own software. Weak controls baked into an application at the design stage are far more expensive to fix once the system is in production and handling live customer data.

The IIBF chapters on software security control and controls in software development and maintenance map preventive checks (secure design review, input validation, code review gates) against detective checks (static analysis, automated test suites) at each SDLC stage. For the coding-standard side of this — OWASP checklists, SAST gates and secure branching policy — see our related article on secure coding practices in banks.

Change management is the compensating layer here: even a well-tested release needs a rollback plan, because no amount of pre-release testing eliminates production risk entirely. Banks that skip this step routinely fail internal audit on the "segregation of duties between development and production" checkpoint.

Candidates preparing for the Risk in Financial Services elective should note that the same before/during/after logic used to classify IT controls also underpins how central counterparties structure their default waterfall — our RFS-focused piece on margining and clearing corporation risk is a useful cross-reference if you are studying both papers together.

🧠 Practice MCQs: Types of Security Controls in Banks

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

✅ Conclusion: Turn Control Classification Into Exam Marks

Once you can reliably sort any given safeguard into preventive, detective, corrective or compensating, a large share of IIBF's IT Security scenario questions become straightforward — the trick is always in the timing of the action described, not the technology itself. Revise the underlying chapters on security standards and best practices, work through the classification examples above a few times, and cross-check yourself against fresh case studies from RBI's own guidance at rbi.org.in.

For more IT Security explainers in this series, browse the IT Security blog tag, or move straight into a full-length mock at iibf.store/course/caiib to see how these questions actually show up under exam timing.