What a CERT-In Empanelled Auditor May and May Not Do

A CERT-In empanelled auditor is bound by published rules about how the test is run, what may be touched, what must be approved in writing first, where your data may be stored, and who may sign the report. Those rules are written for auditors, which is why almost nobody on the auditee side reads them. Read as an auditee, they convert into procurement terms, approval gates and acceptance criteria.

Two instruments do most of the work: the Guidelines for CERT-In Empanelled Information Security Auditing Organizations (version 3.0, May 2018), and the Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025), which §2 of the latter states are binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions.

A CERT-In empanelled auditor is an information security auditing organisation that CERT-In has assessed and listed to carry out audits, vulnerability assessments and penetration testing. Two published documents govern how it works: the Guidelines for CERT-In Empanelled Information Security Auditing Organizations (v3.0, May 2018) and the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025). Between them, an auditor may test almost anything — with your written approval obtained in advance, in an environment both sides have named, and with your data held only in India.

The restrictions are narrower than the permissions and easier to remember. Every item in both columns below is published guidance rather than a negotiating position, and every one of them is set out in full, with its full wording, further down this page.

The reason to read these documents as a buyer is structural. CERT-In empanelment is granted to the organisation, and the quality control that follows runs between CERT-In and that organisation — you are not a party to it, and clause 2.1 of the empanelment terms says an auditor is contracted by a customer directly, with CERT-In not a party to such contracts. What you get instead is a set of published expectations you can convert into contract terms, approval gates and acceptance criteria. The guidelines bind the auditor. §14.1(ii) of the 2025 guidelines requires the agreed terms to be documented in an audit engagement letter signed by authorised representatives of both organisations — and that letter is how you get leverage. If you are earlier in the process than that — still working out what the certificate is and who may issue one — start with what a safe-to-host certificate is and who is permitted to issue one.

§2 of the 2025 guidelines states that they are binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions — and then never says which provisions, or what makes an entity covered. So the honest answer is assembled from four routes, and most readers arrive by one of them.

None of those four is a general rule that every Indian organisation must hold a CERT-In empanelled audit, and the 2025 guidelines do not enumerate the covered provisions. Read your own instrument — the tender, the contract, the regulator’s circular, the hosting policy — and treat this page as the description of what the engagement looks like once you are in one. §2’s formula appears once more on this page, in the FAQ, and is cross-referenced rather than repeated in between.

Indian security auditing has no single professional standard in the way that financial auditing does. What it has is a stack: a short conduct code from 2018, a long operational policy from 2025, the empanelment contract between CERT-In and the firm, and a five-page data-handling policy from 2014 that the 2025 document incorporates by name. Read together they are considerably more prescriptive than most proposals assume.

The statutory chain is short, and §2 of the 2025 guidelines sets it out. Section 70B(1) of the Information Technology Act, 2000 provides for the appointment of a national agency. CERT-In was appointed by notification dated 27 October 2009. Rule 9 of the Information Technology (CERT-In and Manner of performing functions and duties) Rules, 2013 prescribes information security assurance and audit among its activities. Section 70B(6) empowers CERT-In to call for information and give directions, with non-compliance attracting punitive action under section 70B(7). That is the same provision the CERT-In Directions of 28 April 2022 were issued under — and §15.2.1(iv) now requires verification of compliance with those Directions in every audit assignment, with findings and relevant evidences in the report.

Business logic flaws, broken authorisation between two legitimate user roles, an export endpoint that honours a stale token, a workflow that can be driven backwards: none of these are findings a scanner produces, and all of them are findings that end up in incident reports. §8(ii) then does something more unusual and rules out the shortlist as a standard.

VAPT — vulnerability assessment and penetration testing — is the term the Indian market uses for almost any offensive security engagement, which is precisely why the guidelines refuse to let it stand alone. §13.2.3(i)(a) requires the scope to state the type of audit explicitly: VAPT, EAPT (External Attack Penetration Testing), DLA (Device Level Audit), Configuration Audit, Process Audit, Mobile Application Security Audit, Web Application Security Audit, API Security Audit or Compliance Audit. §6 treats vulnerability assessment (item iii) and penetration testing (item iv) as two separate classes with two separate definitions: a vulnerability assessment examines a system to determine the adequacy of security measures and identify deficiencies. A penetration test actively tests components or the application as a whole to identify and exploit potential vulnerabilities and determine whether they can be used to compromise the application, access sensitive data or affect the underlying infrastructure. A proposal that says “VAPT” and prices one figure has not yet told you which of those it will do, to what depth, against which of your assets.

The rules of engagement for a VAPT in India are therefore the rules on this page, applied to whichever of those classes you named: the methodology requirement above, per-class written permissions, the tool procedure, the environment statement, the data-handling chain, the reporting contents and the three signatures. There is no lighter-touch regime for a VAPT because it is called a VAPT.

Two of those entries are easy to miss and expensive to discover late. A department auditing a critical application holding sensitive personal data is not choosing a scope, it is inheriting the 282-point checklist. And the requirement to verify compliance with the 2022 Directions in every audit assignment means the audit reaches beyond the application into your logging, your clock synchronisation and your incident-reporting arrangements. If your infrastructure has not been set up for 180 days of logs held within Indian jurisdiction and a six-hour incident reporting path, the audit will say so.

§6 lists twenty-six kinds of engagement, items i to xxvi, and the opening line adds the cadence: auditee organisations are expected to ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, and may also opt for additional assessments and audits during the year. The list below gives each class as §6 names it, with its item number — which is the number to put in your scope of work — and the gates that attach to it beyond the rules that apply to every engagement.

Two of those classes repay a longer look, because they are where the general rules stop being etiquette.

One consequence for buyers falls out of that list. Empanelment is not a single competence. An organisation empanelled by CERT-In has been assessed as an auditing organisation, not as an expert in your particular estate, which is exactly why §12.1(ii) describes the snapshot information published for each firm as showing categories of audit conducted and audits in the last twelve months sector-wise. Ask which of the twenty-six classes your engagement falls into, then check the answer against the snapshot. For the wider reorganisation of the national audit machinery, see what AMBAK is and how CERT-In empanelment works.

This is the sharpest unresolved question in a modern engagement, and the guidelines answer it in three separate places that have to be read together.

Start with what is in scope. Cloud Security Testing is §6 item xviii — evaluating and assessing the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures — and §13.1.1 requires the audit scope to cover cloud architecture and APIs as part of the entire cyber infrastructure. So a department running a SaaS or a managed platform does not get to scope the audit around the servers it can see.

Then read §13.1.5, which splits the responsibility where a website is hosted on a web server owned by another organisation: the web server, its operating system, the web hosting application software and the backend database software are audited by the organisation that owns and operates the server, while the content owner remains responsible for ensuring its own website data and software are audited by a CERT-In empanelled organisation. Applied to a cloud tenancy that is the shared-responsibility model in the guidelines’ own vocabulary, and written approval to test must come from whoever controls the target — which is not always the person signing your engagement letter.

The collision is with §10.3(ii) and §16.6(i): auditee data only on systems located in India, no mirroring outside the country, nothing to an overseas entity without your written authorisation. A control plane, an identity provider, a log sink or a managed database console that lives outside India will produce evidence — screenshots, exports, configuration dumps, log extracts — that the auditor must then hold somewhere. And the moment the auditor downloads a configuration export from an offshore console onto a laptop, the data rules attach to the copy even though the source was never yours to relocate.

Three things resolve it, and all three belong in the engagement letter rather than in the testing window. First, separate the source from the evidence: the India rule constrains where the auditor stores auditee data, not where your provider runs its service. Name the India-resident repository the audit evidence will live in, and require every export to land there and nowhere else. Second, name what you actually control — your tenant configuration, your identity and access policies, your key management, your network policies, your application and its data — and scope the audit to that, with the provider’s own assurance artefacts referenced rather than re-tested. Third, write down what happens where evidence genuinely cannot be brought into India — a console that will not export, a log platform with no India region. §16.1(ii) requires exemptions, limitations and other constraints to be stated in the report, and §10.1(ii) requires an inaccessible in-scope asset to be named with the reason and brought to CERT-In’s notice. A limitation recorded in the report is a known gap, but an export quietly taken offshore is a breach of §10.3(ii) that nobody has decided to commit.

Naming “the India-resident repository” in a letter is only useful if both sides agree what has to go into it. This is the enumeration — seven classes of artefact, what produces each one, where it must end up, and who controls that store.

One more clause is worth putting in the letter for cloud work: §13.1.1 brings third-party, vendor and supply-chain risk into scope, and §6 item xxiv makes vendor risk management audits their own class. Where your provider is itself the risk, the honest scope is a vendor risk management audit alongside the cloud security testing, not a penetration test pointed at infrastructure you have no permission to attack.

§6 item xxiii defines Artificial Intelligence (AI) System Audits as evaluation of AI systems for security, ethical alignment, transparency, data integrity and resilience to adversarial manipulation. Item xxvi adds AIBOM auditing alongside SBOM and QBOM, aimed at transparency, traceability and integrity of the components used in software, quantum computing and AI systems, and at identifying known vulnerabilities, licensing issues and supply chain risks in open-source and third-party components. Item xvi — Red Team Assessment — is the class most AI red-teaming work will actually be sold under.

The 2025 guidelines write no separate rules of engagement for AI work, which means the existing ones apply unchanged. Four questions come up every time, and each has an answer in the general rules.

One obligation exists already and is routinely missed. Annexure I to the CERT-In Directions of 28 April 2022 lists twenty mandatorily reportable incident types, and item (xx) is attacks or malicious or suspicious activities affecting systems, servers, software or applications related to Artificial Intelligence and Machine Learning. An AI incident has been a mandatorily reportable class since 2022, on the same six-hour clock as everything else — so an AI audit that says nothing about your reporting path has assessed the model and missed the obligation.

The direction of travel is on the official record too. In a Press Information Bureau release issued by the Ministry of Electronics and Information Technology on 29 April 2026, the Government of India reported the conclusion of CERT-In SAMVAAD 2026 — a three-day national annual conference held from 27 to 29 April 2026 at the BITS Pilani K. K. Birla Goa Campus — and named among the subjects of selected presentations AI-driven cyber risks, AI-driven red teaming methodologies, SBOM, CBOM, QBOM and HBOM implementation, and the auditing of cloud systems, APIs and operational technology. That conference is also where AMBAK — Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions — was launched. What the official record does and does not say about it is set out in what AMBAK is.

Note what the words mean here, because they are not the ones the market uses. In vendor marketing a “red team” is an adversary simulation sold as a premium service, and §6 item xvi does define Red Team Assessment that way. In the 2018 conduct rule, red team means something narrower and more useful to you: the internal verification team that re-performs and validates the work of the people who ran your audit, before the report reaches you.

What does compliance look like from your side? Three things. The report carries a reviewer signature from someone who is not on the audit team and is drawn from mid-management. The findings have been reproduced rather than accepted. And false positives have been filtered: a report that hands you fourteen scanner findings, two of which do not reproduce, has not been through a verification step, and it will cost your engineers more to disprove than it cost the auditor to include.

This is the one quality control on the whole stack that is invisible in the deliverable. The approvals leave a ledger, the tools leave a record, the data rules leave a deletion certificate — verification leaves a signature and nothing else, which is why it is worth asking for the record behind it. Put a line in the engagement letter requiring the verification record to be produced on request, so that it exists before you need it rather than being reconstructed afterwards.

An unverified report has a look to it once you know what to check for. Findings arrive in the scanner’s vocabulary verbatim, including its boilerplate remediation text. Two or three of them do not reproduce when your engineers try. Severity is asserted without the CVSS and EPSS apparatus §16.2(ii) requires. And the reviewer signature block is missing, or carries a name that also appears in the audit team list a page earlier — which is not a maker-checker split, it is the same person twice.

Both, in that order. §15.2.3(ii) requires the auditing organisation to audit and test the website on the staging server or testing environment provided by the hosting service provider prior to issuing the Audit Certificate, and to obtain application hash values and version numbers from the auditee for inclusion in the report. §15.2.3(i) requires the environment to be specified — Test, Development, UAT, Pre-Production or Production. And §16.3(v) requires the final audit report to be issued after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment, with an explicit statement where the scope was limited to the staging platform that the audit was not conducted on production.

Read as a sequence rather than as a rule, it makes sense. Testing happens where breaking things is survivable. The certificate is issued against a build that has been tested and remediated. Where availability is the overriding concern, §15.2.2(iv) tells auditors to test passively rather than actively, to avoid any potential downtime or service disruption.

The practical failure is drift. A staging environment that was a faithful replica in March is a different system by August — different patch levels, different configuration, a different reverse proxy, a WAF that exists in one place and not the other. The defence is mechanical: capture the hash, hash algorithm, version and timestamp of what was tested, print them on the certificate and the report, and avoid code changes to the audited application after the certificate is issued. Note that this is a separate question from how long the certificate lasts, which is set by the issuing body on the certificate’s own face — published specimens state a one-year maximum, or validity until the hash or the tested source changes, whichever is earlier. Separately again, §13.1.2 sets the audit cadence: a cyber security audit at least once in a year, and a fresh audit before implementation of any Major Change, where a Major Change is defined by risk rather than by size — high-risk, impactful to security, expressly including configuration adjustments that affect sensitive data or critical infrastructure. Those two rules are often collapsed into one sentence and they should not be. The detail is in how long a certificate stays valid, and the ways a build fails the test in why applications fail safe-to-host.

Not as a routine part of an audit, and not at all without your explicit written permission. The 2018 guidelines contain a flat instruction to refrain from carrying out Distributed Denial of Service testing over the Internet, repeated at items 17 and 18 of Annexure I to the empanelment terms. §15.2.2(ii) of the 2025 guidelines converts it into a permission gate: explicit written permission must be obtained from the auditee prior to conducting DoS, DDoS or flood testing over the Internet, to prevent disruption of services. Either way the default answer is no. Four restrictions do most of the work in this area, and each exists because the alternative once happened to somebody.

The tooling rules read like an inventory procedure because that is exactly what they are. An auditor brings software onto systems you are responsible for, runs it with elevated privileges, and then leaves. Every step of that sequence is governed by §13.2.2(iii) to (v) of the 2025 guidelines and by the Technical section of the 2018 guidelines.

Step five is the one that fails. Agents installed for convenience during a two-week window are still running months later, holding credentials nobody rotated, on a host nobody patched, outside the change record. The fix costs nothing: one row per tool, one form for both events, with the system administrator signing the installation line and the removal line.

The tool list has a second use most auditees miss. §12.1(ii) says the CERT-In website lets an auditee evaluate an organisation on manpower and skillset, relevant experience, categories of audit conducted, audits in the last twelve months sector-wise, technical manpower deployed with details, and tools used. Comparing the tools named in a proposal against the tools declared in the snapshot CERT-In publishes is a two-minute check.

No. During an audit an outside firm accumulates the most sensitive description of your estate that exists anywhere: architecture, credentials used for testing, unpatched hosts, working exploits, screenshots of live data. Three instruments govern how it is held — §10.3 and §16.6 of the 2025 guidelines, the Technical section of the 2018 guidelines, and the 2014 Policy Guidelines for Handling Audit related Data, which §10.3(vii) requires auditing organisations to adhere to by name.

§14.1(ii) requires the agreed terms to be documented in an audit engagement letter, reviewed and signed by authorised representatives of both organisations, serving as a binding reference point throughout the engagement. These are drafting starting points, not legal advice, and each tracks a clause of the published guidance so that an auditor reading them recognises what is being asked. Have your own counsel settle the final wording.

This set covers conduct, data and independence — the terms that govern how the engagement is run. It deliberately does not cover the entity-and-empanelment terms: which legal entity is contracting, what happens if its empanelment lapses between award and signature, and how the named team may be substituted. Those belong in the same letter and are set out in the contract clauses on how CERT-In empanelment works. An empanelment that lapses mid-engagement invalidates the signature chain this page spends a whole section on, so it is worth a clause even though it is somebody else’s risk.

Two entries deserve a note. The requirement to record sampling decisions is unusual in a technical report and enormously useful: it converts “we tested the environment” into a statement about how many of what was examined, which is the difference between a coverage claim and a coverage fact. And the severity apparatus rewards understanding rather than skimming. CVSS produces a score describing the characteristics of a vulnerability, while EPSS produces a probability that it will be exploited in the wild. A high-CVSS finding with a negligible EPSS and a compensating control can wait behind a medium-CVSS finding that is being exploited this month, and a report built to §16.2(ii) carries the numbers to justify that ordering to an auditor, a regulator or a board.

Only manpower declared to CERT-In, and three of them in sequence. This is the fastest defect check available to a reviewing authority, because it can be done from the document alone, before anyone reads a finding.

Note that this signature rule is unscoped in the 2025 document — it is not limited to government audits. The step-by-step version of the check is on how to verify a CERT-In audit certificate.

Yes, within five days of completion. §10.6 makes it mandatory for the auditing organisation to provide the information pertaining to audits carried out by them to CERT-In within 5 days of completion of audit, in the format CERT-In prescribes from time to time, to enable CERT-In to act in the matters of capacity building, audit framework, benchmark, quality control and other measures as may be required — and states that the audit data submitted will be kept confidential.

What the submission contains cannot be stated with certainty, and it is worth being honest about that rather than guessing: §10.6 says the format is as CERT-In prescribes from time to time, and that format is not published. What the empanelment terms do add is specific. Clause 3.2.1 requires details of each and every audit conducted along with auditee details, and the critical vulnerabilities pointed out during the audit but not fixed by the auditee even during follow-up audits. Clause 3.2.2 puts both on the same five-day clock.

Read that clause slowly, because it is the most consequential sentence on this page for a buyer: your unfixed critical vulnerabilities are reported to CERT-In with your organisation named. Not the fact of an audit — the findings you did not close, attributed. That is a strong argument for treating the remediation window as part of the engagement rather than as something that happens afterwards, and for making sure the follow-up audit in §16.3(iv) actually runs before the auditor calls the audit complete.

§13.2.1(iii) makes advance disclosure of all of this the auditor’s duty: you must be told, before the assignment starts, that audit metadata and reports go to CERT-In within five days of completion. Two operational lines follow. Ask in the engagement letter for a copy of what is submitted about your engagement — the guidelines do not require it, and a firm that agrees is telling you something useful about how it works. And diarise the date, because “completion of audit” is the auditor’s determination and you will want to know when the clock started.

CERT-In’s national audit-monitoring initiative, AMBAK, launched at CERT-In SAMVAAD 2026, is covered separately in what AMBAK is and what CERT-In SAMVAAD 2026 was. Note that §10.6 does not mention AMBAK, and nothing on the official record connects the five-day submission to it.

This is the only rule on the page that you are more likely to break than your auditor is, and you will break it without deciding to. It does not arrive as a decision. It arrives as a procurement template — the standard payment schedule that releases the final tranche “on issue of the audit certificate”, drafted years ago for a construction contract, applied to an audit by a finance system that treats every supplier the same way. Nobody in the room intends to make the auditor’s revenue depend on your build passing. The template does it for them.

The fix is on your side of the table and needs nobody’s agreement. Pay against the phases §7 contemplates — planning and scoping, assessment, reporting, revalidation — each of which is delivered whether the findings are good or bad. §5(xvii) adds the structural half of the same rule, and it is worth checking against your own supplier list rather than against the auditor’s: conflict of interest expressly covers the same entity implementing controls and auditing them, or auditing while responsible for remediation. Where the pressure runs the other way — an auditee leaning on an auditor to reclassify a finding before a go-live date — §7 sends the auditor to CERT-In.

For an auditee this resolves into a structural question, asked before the contract rather than after the finding: is anyone in this arrangement being asked to audit their own work? If the firm that built the application is testing it, or the firm that tested it is being retained to fix it and then to re-test its own fixes, the defect is in the shape of the engagement and no amount of testing skill cures it. The same logic runs through auditor independence in SOC 2, where the rule is written for a different profession and arrives at the same place.

Both documents carry a rule with no equivalent in most professional codes. §13.2.4(i) requires the auditing organisation to ensure there is no expectation gap in the conduct of the audit — the difference between what the auditee perceives or expects from the audit and what the audit professionals understand the engagement to entail — reduced or eliminated by clearly explaining, at the outset, the audit process, required artifacts and expected deliverables. §13.2.4(ii) adds the other half: clear communication to the auditee about any exemptions, limitations and other constraints related to the audit. The 2018 guidelines carry the same duty, in materially shorter terms, under Process.

In practice the gap is almost always one of three beliefs, and each is worth confronting at kickoff rather than at delivery. That a clean report means the system is secure — when §10.1(i) limits the auditor’s responsibility to reviewing and reporting on the state of security at the point in time of the audit, and §9.1(ii) leaves the posture with you. That the auditor will fix what they find — when §9.3(iii) makes patching and correction of vulnerabilities the auditee’s responsibility. And that the audit covers everything — when it covers the scope you defined and derived from an asset inventory you maintained.

§17(iii) gives the gap-closing its own ceremonies. At the entry conference the auditing organisation should deliver a formal presentation to your board and senior management, outlining its understanding of the scope, the audit methodology to be adopted, the key phases of the engagement and expected timelines. At the exit conference it presents preliminary findings, key risks and the overall security posture, reviews remediation recommendations, answers your questions and outlines next steps with agreed remediation actions and timelines. Both are to be organised and attended by senior management on the auditee side — and both are, incidentally, the most useful security briefing most leadership teams get all year.

§17(i) goes one step further and asks for written rules of engagement from auditee management: clear and unambiguous direction, a clearly defined scope for the security audit, and input on what is required for planning and assessment, requirement analysis, test execution and analysis, results and documentation. That phrase is worth borrowing verbatim into your own engagement letter.

For government projects heading towards a hosting clearance, everything above sits inside the wider go-live path — accessibility, content, security and hosting requirements together — which is set out in GIGW compliance before go-live and, for the certificate itself, in how to get a safe-to-host certificate.

Most advice about bad audits is written for the post-mortem. This is the version for week three, when you can still change the outcome. Work down it in order and stop when the problem is fixed.

The rules above settle most engagements. These are the situations that generate the arguments — and in each case the guidelines have an answer most people on both sides of the table have not read.

The rule behind each of these is stated in full further up the page. What follows is the reply — what to actually do when the sentence is said to you in a meeting.

Yes. We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.

For our testing practice, see penetration testing and VAPT. For the assurance stack these engagements usually sit inside, see ISO 27001 and the DPDP Act.

Every §-locator on this page was checked against the instruments named below on 18 September 2026. The 2025 guidelines are version 1.0 and will be superseded. Where an instrument is revised, this block is where it will change first. Two documents the guidelines name are deliberately absent from this list because they cannot be retrieved: the “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” cited at §15.2.1(iv), and the Deter and Punish Framework cited at §11(iv) and §19. As at 18 September 2026, both cert-in.org.in paths printed in the guidelines served the CERT-In home page rather than a document. They are named on this page as the guidelines name them, and not linked.

Related reading: what CERT-In is, how empanelment works, who can issue safe-to-host certificates, safe-to-host versus security audit certificate, the CERT-In Directions of 2022, what AMBAK is, CERT-In SAMVAAD 2026, how to verify a CERT-In audit certificate, penetration testing and SOC 2, and why applications fail safe-to-host.