Types of
Security Audit
Two different things are called "the type of audit": what is being examined, and how much the tester is told. Regulators specify the first in detail and leave the second to you — which is the opposite of how most procurement conversations start.
The distinction
Two axes, and they are independent
A penetration test can be black box or white box. So can an application audit, a configuration review or a source code audit. The access level is not a type of audit — it is a setting on whichever audit you are buying, and confusing the two is why scopes arrive that ask for "a black box audit" without saying of what.
Getting this right changes the quote you receive. It also changes whether the engagement produces the evidence your regulator asked for.
Axis one
What is being examined
This is the axis regulators name, and the one that decides what the report can be used for.
Vulnerability assessment
Which known weaknesses are present across a defined estate, enumerated and scored.
The RBI Directions define it at clause 5(32) as a "systematic examination of an information system or product to determine the adequacy of security measures". Breadth over depth — it tells you what is there, not what an attacker could do with it.
Penetration test
Whether those weaknesses can actually be chained into impact, demonstrated rather than asserted.
Depth over breadth. A vulnerability assessment that reports 400 findings and a penetration test that reports 6 are not measuring the same thing, and a report that confuses them is the most common thing we are asked to re-read.
Application security audit
Business-logic flaws, authorisation gaps and injection classes in a specific application.
Scoped to one application and its APIs. This is where authorisation logic gets tested properly, because a scanner cannot know which user is supposed to see which record.
Source code audit
Defects in the code itself, including paths no running instance exposes.
RBI ¶91 says a bank "may consider" source code audits for critical business applications — and ¶92 places the certificate that an application is free of known vulnerabilities on the developer or vendor, not on the auditor.
Configuration and hardening review
Where the deployed configuration departs from the standard it is supposed to meet.
Usually the cheapest audit per finding, and the one most often skipped. A correctly written application on a permissive configuration fails anyway.
Compliance or framework audit
Whether controls exist, are operating, and can be evidenced against a named instrument.
This one produces an opinion against a standard rather than a list of defects. It answers "can we demonstrate this control" — a different question from "is this system secure", and the two are routinely bought as though they were one.
Axis two
How much the tester is told
Black, grey and white box describe the starting information, not the subject. Each is a trade between realism and coverage.
Black box
A target and nothing else.
A realistic view of what an unauthenticated outsider reaches. It also buys a discovery phase you are paying for twice if you already hold the information.
Grey box
Credentials, and usually an architecture briefing.
Coverage of everything behind the login, which on most business applications is where the interesting authorisation logic lives. This is the sensible default for a first engagement.
White box
Source, architecture, configuration and access.
Depth in exchange for realism. Worth its cost where the asset is critical enough that the question is "what is wrong with this" rather than "what would an attacker find".
The trade-off between the three, and the argument about which to choose for a first engagement, is covered at length on VAPT India — including why paying for a discovery phase you could have handed over is usually a poor trade.
What is actually specified
The regulator sets scope, cadence and environment
From the Reserve Bank of India (Commercial Banks — Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, in force from 31 July 2026. Cited by clause so you can check each against your own copy.
RBI ¶151
For critical information systems and those in the DMZ with a customer interface: VA at least once every six months, PT at least once every 12 months. For non-critical systems, a risk-based approach decides requirement and periodicity.
RBI ¶150
VA / PT of critical, internet-facing web and mobile applications, servers and network components throughout their lifecycle — pre-implementation, post-implementation, and after changes.
RBI ¶152
Post-implementation VA / PT is performed on the production environment. Where a PT must run in test, the version and configuration have to resemble production, and any deviation is documented and approved by the Information Security Committee.
RBI ¶154
A documented approach covering scope, coverage and the vulnerability scoring mechanism — CVSS is named as an example — applying equally to systems hosted in a cloud environment.
RBI ¶91–92
Source code audits are a "may consider" for critical business applications. The certificate that an application is free of known vulnerabilities, malware and covert channels comes from the developer or vendor.
The access level sits outside all of this. Which of black, grey or white box you choose is a commercial and methodological decision, and the instrument leaves it to the regulated entity — so it is worth deciding on the merits above rather than on what a scope template happened to say.
Common questions
What is the difference between a black box and a white box security audit?
How much the tester is told before starting. Black box begins with a target and nothing else; white box begins with source, architecture and configuration. Grey box sits between them, typically credentials plus an architecture briefing. The choice changes what the engagement finds and what it costs — it does not change which type of audit it is, which is set by what is being examined.
Which type of security audit do Indian regulators require?
They specify the object and the cadence. The RBI Directions, 2026 require vulnerability assessment at least six-monthly and penetration testing at least annually for critical and DMZ customer-interface systems (¶151), performed on the production environment (¶152), against a documented scope and scoring approach (¶154). The access level — black, grey or white box — is a commercial and methodological decision left to the regulated entity.
Is a vulnerability assessment the same as a penetration test?
No, and the RBI Directions define them separately. A vulnerability assessment enumerates known weaknesses across a defined estate. A penetration test establishes whether those weaknesses can be chained into demonstrated impact. One is breadth, the other is depth, and a report that presents scanner output as a penetration test is the most common defect we are asked to review.
Who signs a security audit report in India?
For work that has to satisfy a regulator, a CERT-In empanelled organisation. Security Brigade has been empanelled since 2008. For an application to be certified free of known vulnerabilities under RBI ¶92, the certificate comes from the developer or vendor rather than from the auditor.
Not sure which one your scope needs?
Most scopes that arrive here name an access level and leave the object implicit. Tell us the system and the instrument you are answering to, and we will tell you which audit produces the evidence.
Talk to an engineer