VAPT in Banks: Vulnerability Assessment and Penetration Testing Explained

For any bank auditor or IT officer preparing for the IIBF IT Security paper, VAPT in banks is a heavily tested topic. It sits between technology risk and board-level assurance. Vulnerability Assessment and Penetration Testing (VAPT) is how a bank finds, rates, and fixes weaknesses in its network, apps, and infrastructure. It does this before an attacker can strike. This guide covers scope, the three test methods, CVSS severity scoring, and the fix timelines regulators expect banks to follow.

🛡 What Is VAPT and Why Banks Need It

VAPT is really two separate exercises. Vulnerability Assessment (VA) is a broad, mostly automated scan of systems, networks, and apps. It produces a list of known weak points — missing patches, weak settings, old protocols — ranked by severity.

Penetration Testing (PT) goes further. A skilled tester tries to actually exploit chosen weaknesses. They chain flaws together to show real business impact, such as access to a core banking database or a customer's internet-banking session. Banks run both tests. A VA tells you what could be wrong. A PT tells you what is truly exploitable in your own systems.

For a bank, the test scope usually covers the core banking system (CBS), internet and mobile banking apps, and APIs shared with fintech partners. It also covers ATM switches, payment gateways, internal and DMZ network zones, wireless setups, and cloud workloads. Physical and environmental controls around data centres are checked separately. They still feed into the same overall risk register — a topic covered in depth under physical and environmental security controls.

A VAPT report is not just a technical document. It feeds the bank's risk committee, its cyber-security policy review, and its regulatory reporting. That is why examiners treat VAPT as a governance topic, not just a technical one.

🔍 Black-Box, Grey-Box, and White-Box Methodology

Examiners often ask candidates to tell these three methods apart, so the definitions matter. In a black-box test, the assessor gets no internal information — no source code, no network diagrams, no credentials. They approach the target exactly as an outside attacker would, using only recon and public data. This is closest to a real-world attack on an internet-facing banking portal.

A white-box test is the opposite. The tester gets full architecture diagrams, source code, config files, and often admin-level access. This depth lets the assessor find logic flaws, unsafe coding patterns, and control gaps that no outside probing would ever reveal. It is the most thorough option, but also the slowest. Banks use it for core banking or payment-critical apps before go-live.

A grey-box test sits in between. The tester gets limited information, such as a normal customer login or a basic network map. This mirrors the risk from a semi-privileged insider, a hacked customer account, or a vendor with partial access.

Most bank VAPT programmes blend all three types across different assets. Black-box suits the internet perimeter. White-box suits the CBS and payment stack. Grey-box suits internet-banking and mobile-app tests, where a real customer login is a realistic starting point for an attacker. The method, sample, and asset criticality should always be set out in the rules of engagement before work starts, and mapped back to controls in network controls.

💡 Exam Tip: If a question describes a tester with "no prior knowledge simulating an external hacker," the answer is black-box. "Full source code and architecture access" means white-box. "A standard user account only" means grey-box.

📊 CVSS Scoring and Severity Bands

Once found, vulnerabilities must be ranked. The industry standard for this is the Common Vulnerability Scoring System (CVSS). Most bank security teams and CERT-In empanelled auditors now use version 3.1.

CVSS gives a score from 0 to 10. It looks at exploit factors (attack vector, complexity, privileges needed, user interaction) and impact factors (confidentiality, integrity, availability). The score then maps to a severity band. This is the common language of every VAPT report. It is also how a bank's security committee decides which findings need board attention, and which just need routine tracking.

Boards rarely see the raw CVSS number. Instead, VAPT reports are usually summed up as counts of critical, high, medium, and low findings. These counts are tracked release over release, so repeat findings and old open items stand out.

A rising count of unresolved high or critical findings, across cycles, is itself a governance red flag — no matter what any single flaw's technical detail says. Findings from unsafe coding are usually cross-checked against the bank's controls in software development and maintenance. This fixes the root cause in the SDLC, not just the symptom in production.

⚠️ Common Mistake: Candidates often assume a "Medium" CVSS finding can be ignored. In practice, several chained medium findings can combine into a critical business impact. Showing this is exactly what a penetration test — not a vulnerability scan — is designed to do.

⏱ Remediation SLAs and RBI/CERT-In Expectations

Regulatory rules for VAPT in Indian banks come mainly from the Reserve Bank of India's Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices. This Direction updated and merged earlier IT and cyber-security framework rules for regulated entities.

The Direction expects banks to run VA/PT of critical and internet-facing systems on a regular basis. How often depends on how critical the asset is, not on one fixed number for everyone. Internet-facing and payment-critical systems get tested far more often than low-risk internal systems. RBI also requires that VA/PT of critical infrastructure be done by CERT-In empanelled auditors. This is a separate, specific list from general IT auditors.

Fix timelines are usually set by each bank's own board-approved policy, not by one number from the regulator. Still, most bank policies follow a similar pattern. Critical findings close within days. High findings close within weeks. Medium and low findings close within a set quarter or release cycle. Any exception needs a documented risk-acceptance sign-off from a named authority.

Candidates should not memorise one "correct" number of days for each band. RBI leaves the exact SLA to each bank's own risk appetite and board policy. What examiners test is whether a bank has ANY documented, monitored SLA, and whether it escalates ageing critical findings.

It helps to separate this from incident-reporting timelines, which exam answers often confuse with VAPT fix SLAs. CERT-In Rules set a 6-hour reporting window for specified cyber incidents. RBI's own cyber-security circular expects incident reporting within 2 to 6 hours, depending on severity. Neither of these is the same as how long a bank has to fix a VAPT finding. Related threat-handling and response steps are covered under IT security threats and incident management.

📌 Remember: CERT-In empanelment is mandatory for auditors doing VA/PT of a bank's critical systems — a non-empanelled vendor's report will not meet RBI's assurance bar, no matter how sound the testing was.

🏦 Reporting, Retesting, and Board Oversight

A VAPT job is not done when the technical report lands. It is done when every finding has a named owner, a target closure date set by its severity band, and proof of closure from a re-test.

Good practice calls for the final report to cover four things. First, an executive summary in plain business language for the risk committee. Second, a technical annexure with proof-of-concept evidence for each finding (without exposing exploit code outside the engagement team). Third, a count of findings by severity. Fourth, a comparison against the last cycle's open items. Banks that outsource core apps or use fintech partners must also test vendor-side components in scope. A weak partner API is still the bank's risk, from the customer's view.

Inside the bank, most teams track this on a vulnerability-management or GRC platform. Each finding is a ticket with a severity, an owner, an SLA due date, and an audit trail of fix evidence. Repeat findings across cycles, or findings that breach their SLA with no documented risk acceptance, get escalated to the IT Strategy Committee. Material items go to the Board.

This governance loop is what separates a mature VAPT programme from a one-off compliance box-tick. It is exactly the control area auditors are trained to test, alongside related topics such as security standards and best practices and asset classification and controls. Asset criticality is, after all, what sets VAPT scope and frequency in the first place.

Candidates should also see how VAPT links to other ITSEC topics on this blog. Cloud security in banks changes what a bank can even test, since shared responsibility limits scope. VPN security for banks and cryptographic key management in banks are both common VAPT finding categories in their own right.

Risk-quantification skills carry over from other papers too — much like the discounting logic behind yield to maturity calculation in the Treasury syllabus. Both skills ask you to turn a technical or financial number into a decision a committee can act on.

🧠 Practice MCQs: VAPT in Banks

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

❓ Frequently Asked Questions

VAPT is one of the clearest IT Security topics judged purely on governance discipline. Scope, method, severity scoring, and SLA tracking matter more than any single exploit trick. For more IT Security exam guides like this one, browse the IT Security tag hub. When you're ready to test your recall under exam conditions, take a free chapter-wise quiz at iibf.store/tests.