How to Avoid Regulatory Rejection: Preparing a CERT-In Compliant VAPT Report for RBI & SEBI Submissions

Why VAPT Reports Get Sent Back  

It is the second week of July. A mid-size stockbroker uploads its annual VAPT report to the exchange portal three weeks ahead of the 31 July deadline, and the compliance head breathes out. Four days later, the submission comes back. The auditor’s declaration doesn’t state the CERT-In empanelment period, and two scope areas marked “excluded” have no IT Committee minutes behind them. The testing itself was fine. The paperwork wasn’t, and now the team has days, not weeks, to get a revised declaration signed, call a committee meeting and resubmit.

That story repeats across banks, NBFCs, brokers and depository participants every cycle, and it nearly always comes down to the same thing. People assume a report from an empanelled auditor is automatically “CERT-In compliant” and will satisfy every regulator. It would not, because three different rulebooks are at work.

CERT-In’s audit guidelines of 25 July 2025 set what an empanelled auditor’s report must contain. SEBI adds a fixed report format and calendar deadlines on top. RBI sets how often you test and how quickly you close findings but publishes no template at all. A report can pass one of these tests and fail the other two.

This guide is for the compliance, risk and CISO teams who own that submission. It breaks the CERT-In-compliant VAPT report requirements section by section and then shows how RBI’s 2026 Directions and SEBI’s Annexure-A shape the final pack. You’ll also get the safe-to-host certificate rules, the incident reporting clocks that run alongside the report, the common rejection triggers, a tested script which checks a report pack before it goes out, and a step-by-step timeline you can plan the year around.

What “CERT-In Compliant” Actually Means for a VAPT Report

The term is used loosely, so it helps to clarify what CERT-In does and doesn’t do before looking at the report.

CERT-In has constituted a panel of audit bodies. It does not review, approve or stamp individual VAPT reports or issue VAPT certificates. A report is called ‘CERT-In compliant’ if the CV is signed and written in accordance with SUUB-Lu guidelines.

Those guidelines are the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, dated 25 July 2025. They bind the empanelled auditors and the auditee organisations covered by them and replace a patchwork of older baseline documents with a single set of rules for planning, testing, reporting, data handling, and follow-up.

A few points in them change how a report should look:

Frequency:

Section 13.1.2(i) requires a minimum annual audit. Sectoral regulators may ask for more, and a major change to an application or infrastructure triggers a new audit.

Method:

Section 8(ii) is a disincentive for tool-only audits. The text also states that OWASP Top 10 and SANS Top 25 are not audit standards. These are awareness lists, while the OWASP testing guides (WSTG and MASTG) are methods. So a depository can still mention them in its scope annex without any conflict.

Sharing with CERT-In: 

Under section 10.6, the auditing organisation shares audit information with CERT-In within 5 days of finishing the audit, and section 13.2.1(iii) says it must tell you the details before work starts. This data is audit information, not your full report going to CERT-In.

Describing empanelment:

Section 10.5 fixes the only wording an auditor may use about its empanelment and bans the CERT-In logo on reports, letterheads and marketing.

AZB & Partners’ review of the guidelines makes the same point: the 2025 document shifts responsibility onto auditees as well as auditors.

Two commercial rules in the guidelines also show up in reviews. Section 7(i) says the auditor’s fee must not depend on the outcome of the audit or on closure of findings and should be based on predefined scope, deliverables and timelines. Section 12.4(i) suggests engaging auditors for critical applications on contracts of two to three years so that follow-up audits and revalidation stay with the firm that found the issues. If your engagement letter pays a bonus for a “clean” report, expect questions.

So “CERT-In compliant” describes how an empanelled firm did the work and wrote it up, not a badge that CERT-In hands out.

The Report Elements CERT-In’s 2025 Audit Guidelines Expect

1. The Core Report Elements: What CERT-In 2025 Expects vs. Weak Reports

This section lists what the 2025 guidelines expect to see inside the report, with the section number for each, so you can hold any draft against it.

2. Governance, Evidence, and Data Handling

The sign-off chain matters as much as the content. Under sections 9.5(iii) and 16.1(vi), the report is signed only by auditors who were declared to CERT-In for the engagement, reviewed by an independent reviewer from outside the audit team, and signed by the head of the auditing organisation. A report signed by a consultant who wasn’t on the declared list is an unambiguous return.

Section 18 expects evidence and working notes to be in an appendix. Include screenshots here rather than in the findings narrative. Include request and response pairs here and tool output.

Data handling should be in the engagement letter, not left to good faith. Section 10.3 requires that audit data be stored only in India and retained for one year unless otherwise agreed, and then deleted with a certificate of deletion provided to you.

Two smaller rules trap auditees. Section 13.2.2(ii) expects the audit plan to show calendar time as well as man-hours, so a reviewer can see if a large estate was tested in a credible amount of effort. Under Section 10.5(vii), the auditing organisation is barred from subletting the work. If the people who tested your systems work for a different firm than the one that signed the report, that’s an issue for the auditor and one that’s uncomfortable for you. Section 19 provides for graduated penalties for auditors who breach the guidelines, and a report from an auditor under penalty is difficult to defend before any regulator.

This is what many teams miss. Section 16.1(i) allows the report format to be “mutually agreed upon” by the auditor and the auditee. While submitting, CERT-In will define the minimum content, and your regulator will decide on the format for laying out that content.

RBI Cyber Security Audit Report Template: What RBI’s Directions Actually Require

Regulatory Framework & Applicable Directions

RBI’s rules drive the testing cycle and the closure discipline, so the report has to demonstrate evidence of both.

Let us begin with the truth. There is no official RBI cyber security audit report template. RBI has not prescribed any form like SEBI. What people call the template is really the set of things that the RBI’s directions say should be tested, recorded, reported and closed, and a good report is built around those paragraphs.

For commercial banks, the existing text is the RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, dated 31 July 2026. They do not cover small finance banks, payments banks or local area banks, so check which directions apply to your entity before you build on them. Components that affect VAPT reporting:

Frequency (paras 149 to 151):

Vulnerability assessment at least every six months and penetration testing at least every 12 months for critical systems and for DMZ systems with a customer interface. Testing also happens before implementation, after implementation and after changes.

Environment (para 152):

Tests run in production. If that’s not possible, a documented deviation approved by the Information Security Committee (ISC) is needed.

Who tests (para 155): 

Testers must be independent and trained. Para 159 says CERT-In’s audit guidelines apply where the auditor is CERT-In empanelled. It doesn’t make empanelment mandatory for every RBI test, so quote it as written.

Closure (paras 153 and 161):

Findings close within set timelines, and status goes to the IT Strategy Committee (ITSC) and the ISC at least quarterly.

Red teaming (para 162):

Optional, not required.

Incidents (para 182):

These incidents must be reported on the DAKSH portal within six hours.

DSCI’s brief on the 2026 Directions gives a useful plain-language walk-through of the wider framework.

NBFCs in the Top, Upper and Middle layers, credit information companies and all-India financial institutions fall under para 26 of the Master Direction on IT Governance, Risk, Controls and Assurance Practices of 7 November 2023. Confirm with your compliance team that it still covers your entity type.

Practical Report Structure & Environment Verification

Because there’s no RBI cyber security audit report template, banks usually build one from the paragraphs above. This structure works:

The environment row deserves care. If testing ran in pre-production because production couldn’t take the load, record the ISC approval reference and date in the report, and say how closely the test environment matches production in version and configuration. A hash comparison between the tested build and the deployed build is the cleanest way to show that match.

For RBI, the report needs to prove the cycle: right frequency, right environment, independent testers and closure tracked up to board committees.

SEBI VAPT Compliance Report Format: The CSCRF Annexure-A Submission

Regulatory Basis & Core Submission Rules

SEBI is the regulator most likely to send a report back over format alone, as it publishes one and enforces deadlines through the exchanges and depositories.

The basis is the Cybersecurity and Cyber Resilience Framework (CSCRF), circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 of 20 August 2024, with clarifications issued on 31 December 2024, 28 March 2025, 30 April 2025 and 28 August 2025, and an FAQ of 11 June 2025. Clause 4.3.2 asks regulated entities (REs) to plan VAPT at the start of each financial year. Annexure L sets the scope, and Annexure A sets the SEBI VAPT compliance report format. Cyril Amarchand Mangaldas’ client alert on the CSCRF summarises the circular and its annexures if you need the wider picture.

Two rules frame the whole submission. An external audit must be done by a CERT-In-empanelled auditor, except for REs allowed to self-certify. Frequency is yearly for most REs and half-yearly for qualified stockbrokers (QSBs) and REs identified as protected systems or critical information infrastructure.

The 10-Step Annexure-A Structure & Filing Calendars

The Annexure-A structure (Part III of the CSCRF) runs in this order:

1. Cover details: entity type, category and the rationale for it, audit period, auditor, and the date the report went to the IT Committee.
2. A declaration from the RE’s authorised signatory is required.
3. The auditor’s declaration on letterhead, with the CERT-In empanelment period, a checklist of areas covered and a no-conflict statement.
4. Executive summary.
5. Scope, in 10 rows: infrastructure VA, application VA, external PT, Wi-Fi, API, network segmentation, mobile, OS and database, cloud, and configuration audit.
6. Tools used.
7. Exclusions, each with IT Committee approval.
8. VA and PT summaries by severity, with closure timelines.
9. A detailed report, submitted only when SEBI asks for it.
10. Risk rating definitions, with an EPSS or SSVC score in the findings table.

The calendar comes from the depository and exchange circulars, which is why dates can differ slightly by intermediary type. For FY 2025-26, the NSDL circular of 15 September 2025 and the MSE circular of 29 September 2025 set:

Critical Review Focus Areas & Rejection Pitfalls

The severity summary (item 8) is where most of the reviewer’s attention goes. Show the count of findings at each severity for VA and PT separately, how many are closed, and the closure timeline for those that are still open. Exclusions (item 7) should each carry a reason, the IT Committee meeting date and the minutes reference, not a single line saying “agreed with client”. REs allowed to self-certify follow the same format, but the declaration comes from their side rather than from an empanelled auditor.

Check your own depository or exchange for the current year’s circular, as the dates are set there, not in the CSCRF.

A handful of other rules decide whether a report in the SEBI VAPT compliance report format is accepted:

• The IT Committee approves the report before it’s submitted, and the cover page shows that date.
• Findings open for more than three months need IT Committee approval and must be closed before the next VAPT.
• No part of the audit period may be left uncovered between cycles.
• Detailed vulnerabilities aren’t sent unless SEBI asks, and they’re kept for three years.

Get the order, the declarations, and the committee dates right, and the SEBI VAPT compliance report format stops being a reason for rejection.

CERT-In Safe to Host Certificate Guidelines and the VAPT Certificate

Certificates cause more confusion than reports do, partly because two different documents share similar names.

A safe-to-host certificate is audit clearance for a government website or app before it goes into production hosting. The CERT-In safe-to-host certificate guidelines most teams refer to come from GIGW 3.0, the Guidelines for Indian Government Websites and Apps, which ask for a security audit before hosting (guideline 5.3.1). The certificate can be issued by NIC, STQC, STQC-empanelled labs or a CERT-In empanelled auditor, as TCSA’s explainer also sets out. Your internal team can’t issue one, and CERT-In doesn’t issue or countersign them.

A certificate that will hold up when a hosting provider or department checks it carries these fields:

Validity Rules, Hashing Practices, and Verification Standards: –

On validity, the CERT-In safe-to-host certificate guidelines do not mandate a national format. Specimens are usually one year or until the code changes, whichever is first. Under CERT-In section 13.1.2, a major change requires a new audit anyway, so a certificate based on a hash makes the “has the code changed?” question, an easy one to answer.

For mobile apps, hash the exact package that gets sent to the store (the signed APK, AAB or IPA), not a debug build. For websites, the hash typically covers the deployed release artefact. In any case, the algorithm should be named, with SHA-256 being the safe default.

The “VAPT certificate” is a different document for banks, NBFCs and SEBI REs. The usual form is a certificate or letter of attestation from the auditing organisation, issued when fixes have been verified in a retest, confirming what was tested and that the findings it lists are closed. it backs up the report. It does not replace it. No regulator will accept a certificate in place of the full report and Annexure-A.

Apply the same tests from the CERT-In Safe to Host Certificate Guidelines to any VAPT certificate: who signed it, which build it covers, and when it stops being valid.

All VAPT certificates need to go through the same tests as the CERT-In Safe to Host Certificate Guidelines. This includes checking who signed the certificate, what build it covers, and when it expires.

Secure Your Business with a Expert-Led Security Assessment

Partner with certified security specialists to identify, prioritize, and remediate real-world risks across your systems.

Book a Security Assessment →

CERT-In Incident Reporting Rules That Sit Alongside the Report

1. Core Incident Reporting Mandates (28 April 2022 Directions)

Incident reporting is a separate duty from the VAPT report, but auditors are asked to check it, and a finding during testing can trigger it.

The base rules are set by CERT-In’s Directions dated 28 April 2022 under section 70B(6) of the IT Act, and Trilegal’s summary of the Directions takes you through each of them. Thus in short,

• Report an incident to CERT-In within six hours of noticing it or being told about it.
• The incident types are listed in Annexure I of the Directions.
• Reports go through the channels CERT-In lists on its website.
• Nominate a point of contact and share their details with CERT-In.
• Keep logs of ICT systems for 180 days, stored in India.
• Synchronise system clocks to NIC or NPL NTP servers, or to servers that are traceable to them.
• Failing to comply can bring a penalty under section 70B(7): up to one year’s imprisonment, a fine of up to ₹1 lakh, or both.

15.2.1(iv) of the audit guidelines requires the auditor to verify that you have complied with these instructions and to keep evidence of the same. In practice, this translates to displaying the NTP configuration on the in-scope servers, retaining logs for a minimum of 180 days, storing them in India, having the nominated point of contact, and an incident response procedure that names the six-hour clock. If the auditor cannot see that evidence, the gap will be recorded as a finding in your report.

2. In-Audit Notification Obligations

The audit guidelines add duties during an engagement. Critical and high findings go to the auditee as they are found, not at the end (section 16.3). High-risk issues are reported immediately (16.4). Suppose the auditor finds evidence of a breach while testing; it is reported to both the auditee and CERT-In (15.2.2(i)). Your report should show that these notifications occurred, including the dates.

3. Regulatory Clock Alignment: A Unified Playbook

The regulators’ clocks overlap, so map them once and build a single playbook:

One incident playbook with all four clocks, plus dated evidence of in-audit notifications in the report, covers this area.

Why Regulators Reject VAPT Reports: The Common Triggers

Most returns aren’t about weak testing. They’re about something missing that a reviewer can spot in a few minutes.

The Real-World Causes of Report Rejection

A note from the testing side. In my experience, the most common trigger is not technical. It is the scope table. The client asks us to test “the trading app and the website”, the engagement letter says the same, and nobody looks at the 10 rows of Annexure-A until the draft report lands.

At that point, Wi-Fi, cloud configuration and network segmentation are untouched. So we have to make a choice between hurrying through additional testing or not testing those areas at all. That would require some last-minute IT Committee approval. The kick-off call is how we now start each regulated engagement with the client, filling in Annexure-A scope rows before any test is executed. Saves weeks; takes 20 minutes. The hash is the second most common problem I see. Teams test a build. Fix 3 findings. Redeploy and forget; the report still has the old hash. The certificate describes software that’s no longer running. That fills the gap. You ask for the last hash after the retest, not before.

Every trigger in that table can be checked before submission, which is what the next section does.

Pre-Submission Check: Validating the Report Before It Leaves

A simple script can catch the paperwork gaps that cause the majority of returns. It’s not a replacement for a reviewer, but it does stop obvious misses from reaching the exchange.

Code example: a pre-submission checker for CERT-In and SEBI fields

The checker below reads a small JSON file describing the report pack (not the report itself) and tests it against CERT-In 2025 fields and SEBI Annexure-A cover and scope rows.

We also verify that the auditor empanelment date is valid on the signing date, the environment is mentioned, the hash is provided in SHA-256 format, the IT Committee holds its meeting before submission, the entity category sets the deadline, and the finding remains open for more than 90 days. It ran on Python 3.13 and used only the standard library.

Two sample packs were run through the system. Broker A’s pack mirrors the introduction: an auditor whose empanelment had lapsed before signing, testing only in UAT, an MD5 hash, missing Wi-Fi and API rows, cloud excluded without minutes, and a submission two days late.

Real output:

Broker B’s pack, with production testing, a SHA-256 hash, all 10 scope rows, a valid empanelment, committee approval a week before submission and no stale findings, passes cleanly.

Be clear about the limits. The script checks that the pack is complete and consistent. It can’t tell you whether the testing was any good, whether a finding was scored correctly, or whether the empanelment dates you typed in match CERT-In’s list. Someone still has to check those against the source. The deadline table also needs updating each year from your depository’s or exchange’s circular.

Run a check like this a week before the IT Committee meeting, and fix what it flags while there’s still time.

Building the Report Pack: A Step-by-Step Timeline

Therefore, working backwards from the submission date is the simplest way to avoid revalidation and prevent the ATR from being squeezed into the last fortnight.

1. Plan at the start of the financial year, as CSCRF clause 4.3.2 asks, with the submission and ATR dates already in the calendar.
2. Freeze the scope and the asset inventory, and fill in all 10 Annexure-A scope rows.
3. Sign the engagement letter. It should cover the NDA, storage of data in India, disclosure of the 5-day CERT-In information sharing, a follow-up audit clause, and fees tied to scope and deliverables rather than outcome, as CERT-In section 7(i) requires.
4. Test in production where possible or with the deviation approved.
5. Get critical and high findings notified as they’re found, with dates recorded.
6. Receive the draft report and check it against sections 3 to 5 of this guide.
7. Fix the findings, starting with critical and high.
8. Revalidate. The auditor retests and confirms closure.
9. Receive the final report and certificate, with the version history updated.
10. Get IT Committee or ISC approval, and record the date on the cover.
11. Submit before the deadline for your category.
12. File the ATR by its due date.
13. Retain the evidence: the detailed findings for three years under the CSCRF, and confirm the auditor’s wipe-out certificate once its one-year retention ends.

For a non-QSB on the FY 2025-26 calendar, testing must be completed by mid-May, fixes must be made through early June, the retest must be finished by 30 June, committee approval must be obtained in mid-July, and submission must occur a week before 31 July. Therefore, Steps 7 and 8 take the longest and are the ones most often cut short, so the plan should give them the most room.

How Qualysec Supports Regulator-Ready VAPT Reporting

Qualysec is a specialized penetration testing company, and much of our work is with banks, fintechs and software providers that answer to Indian regulators. That makes the report the part of the engagement that clients care about most.

We build reports according to the CERT-In 2025 fields and then lay them out in the regulator’s required format. For example, a SEBI RE receives an Annexure-A structure, while a bank gets the paragraph-mapped structure from Section 4. In addition, critical findings are notified as they are identified, and retests are built into the engagement. Once the fixes are verified, an attestation letter is issued. As a result, the ATR includes clear evidence supporting the closure of each finding. You can read more on our SEBI CSCRF compliance and RBI CSITE pages.

Prepare for Your Next Cybersecurity Audit with Qualysec

Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.

Talk to an Expert→

Case study: banking software provider, testing for a banking licence

Aicura Solutions, a banking software provider, worked with us from November 2025 to January 2026. The scope covered the customer journey, the back office and the Azure cloud environment. Their verified Clutch review described the testing as necessary for a banking licence. Eight issues were found; all were resolved, and multiple retests confirmed the fixes before sign-off. This wasn’t an RBI or SEBI VAPT submission, but it followed the same pattern regulated entities need: a defined scope, findings tracked to closure, and retest evidence ready for the reviewer.

That find, fix, retest and attest pattern is what turns a test into a submission that holds up.

Conclusion and Next Steps

The pattern in almost every VAPT report returned is the same. Good testing documents its work as if only one standard applied, when in fact three apply. CERT-In’s 2025 guidelines lay down the minimum requirements for a report. SEBI Annexure-A and the exchange calendar decide the layout and due date. RBI’s directions set the cycle and require that board committees track closure. Think of the format of the regulator as the skeleton of the report and the fields of CERT-In as what goes inside of it, and most of the reasons for rejection never crop up.

The other half is time. Teams most often squeeze revalidation, committee approval and the ATR, and reviewers check those steps first. Plan the cycle backwards from your submission date, fill the scope table before testing starts, and run a completeness check before the committee meets.

If you do one thing this week, pull last year’s report and hold it against the tables in sections 3 to 5. The gaps you find there are the ones most likely to come back this year.

Frequently Asked Questions

1. What are the official CERT-In guidelines for VAPT report submissions?

The main document is CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, dated 25 July 2025. It sets out the requirements for an empanelled auditor’s report that should contain an executive summary, assets, environment, hashes, CVSS and EPSS scoring, repeated observations and sign-offs.

2. What should a professional, audit-ready VAPT report include for RBI and SEBI?

It should include everything mentioned in CERT-In’s 2025 guidelines, as per the regulator’s format. That is Annexure-A for SEBI with both declarations, 10 scope rows, approved exclusions and IT Committee dates. In terms of RBI, it should cover system criticality, environment testing, tester independence, closure dates, and quarterly status reporting to ITSC and ISC.

3. What is a VAPT certificate and who officially issues it?

Review names, facts, and commitments before sending. The Lead Auditor and the head of the organisation sign it. CERT-In does not issue VAPT certificates. The certificate endorses the complete report but never supersedes it.

4. What are the mandatory guidelines for CERT-In incident reporting?

CERT-In’s Directions of April 28, 2022, mandate reporting within six hours of becoming aware of an incident, using the incident types in Annexure I. Organisations will have to name a point of contact, keep ICT logs for 180 days in India and sync clocks to NIC or NPL servers. Failure to comply can lead to imprisonment for up to one year, a fine of ₹1 lakh or both.