Empanelment is eligibility. It is granted to a named organisation, for a defined period, to perform information security audits and to sign the report and certificate that follow. It is not a certification, not an endorsement, and not something anyone can inherit — and it carries obligations most buyers never hear about until an engagement goes wrong.
The sentence that tells you most: an empanelled auditor may use the words “This Organization is empanelled by CERT-In for providing information Security Auditing Service” — and no other words to describe its relationship with CERT-In without prior written permission, nor the CERT-In logo on publicity or promotional material. You can check that from your desk in a minute.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · Empanelment Terms and Conditions v7.2 (April 2024) · CERT-In Auditor Guidelines v3.0 (May 2018) · IT Act 2000, section 70B · Last reviewed September 2026
CERT-In empanelment means one thing: a named information security auditing organisation has cleared CERT-In’s empanelment process and, for a defined period, is eligible to perform information security audits and to sign the audit report — and, where the engagement calls for one, the audit certificate a government project needs before go-live, or that a tender or a regulator’s own clause calls for. That is the whole of it. It is a status held by an organisation, for a period, that can lapse or be withdrawn. What it is not: a certification, an accreditation, a government endorsement of the firm, a quality rating, a statement about your systems, or anything that transfers to an auditee, a product, an individual auditor, a reseller or a group company. Almost every dispute this hub exists to prevent begins with someone treating the status as one of those things.
The rules are published, and they sit in three documents rather than one. CERT-In was appointed as the national agency under section 70B of the Information Technology Act, 2000 by a notification dated 27 October 2009, and the Information Technology (CERT-In and Manner of performing functions and duties) Rules, 2013, notified on 16 January 2014, prescribe information security assurance and audit to it at rule 9. That is where the empanelment scheme comes from. What empanelment then requires is set out across:
- The Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, dated 25 July 2025. Twenty sections that state, in one place, what an audit is, what it covers, who may perform and sign it, how it is planned and reported, and the graded consequences when an auditing organisation falls short. Their own authority section says they are binding on all CERT-In empanelled auditing organisations and on auditee entities covered under the relevant provisions — which means this document reaches you as well as your auditor. It is the current instrument, and where it differs from older material it is the one to read.
- The Terms and Conditions for Empanelment, Version 7.2, April 2024. The contract between CERT-In and the auditing organisation. It carries the five-day reporting clause at 3.2.2, the branding restriction at 4.1 and 4.2, CERT-In’s right to review and to witness audits at 8.1, and the grounds for terminating empanelment at 9.1. Two annexures to it — the auditee’s expectations of an auditor, and the audit report content format — are the most quietly useful procurement documents in Indian cyber security.
- The Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018. The conduct rules: how an auditor behaves on your systems, across people, technical practice and process. Background checks and the NOC on movement, the verification team, the written approvals and tool control, data handling, the quarterly return, and the claims rule of exactly one permitted sentence — which the 2024 terms and the 2025 guidelines both repeat in the same words.
The three do not contradict each other, but they are not interchangeable either, and the difference matters in two places this page flags as it goes. Declared manpower was scoped to Government and critical sector audits in 2018, but the 2025 guidelines state it without that qualification. And independence from remediation was not spelled out in 2018. The 2025 guidelines define it as a conflict of interest and make it a binding principle. Anyone reading only the older document will get both of those wrong.
Key Takeaways
- Empanelment is eligibility, not certification. CERT-In empanels an organisation, for a defined period, to perform information security audits and sign the report. It makes no statement about the auditee and no promise about the auditor’s commercial quality.
- It is earned by practical test, not by paperwork: a documentation review, an offline practical skill test of the technical people, a hands-on VAPT practical test, and a personal interaction session with CERT-In. That is why it cannot be bought, and why it is worth verifying at the level of named individuals rather than the badge.
- It attaches to a legal entity. Not to a person, not to a product, not to a brand, not to a group. Find the entity on the list CERT-In publishes on cert-in.org.in, and get the empanelment period from the auditor in writing — then check it against the date your report will be signed, not the date you award.
- The organisation must deploy only manpower declared to CERT-In in the snapshot information form, and reports may be signed only by that declared manpower. CERT-In publishes the snapshot — manpower, experience, audit categories, audits by sector over twelve months, and tools used — and expects auditees to use it to compare competence.
- A report carries three signatures and a certificate carries two: the auditors who did the work, a reviewer outside the audit team from mid-management, and the head of the auditing organisation. On the certificate, the Lead Auditor and the Head.
- The audit report and audit metadata go to CERT-In within 5 days of completion — and so do critical vulnerabilities you left unfixed after follow-up, with your organisation named. The auditor is required to tell you this before the assignment starts.
- Empanelment can be suspended or withdrawn. CERT-In publishes a graded ladder — watch list, suspension, withdrawal with debarment, penal and legal action — and auditee feedback on technical competency is one of the named triggers.
- One sentence is permitted: “This Organization is empanelled by CERT-In for providing information Security Auditing Service”. No other words describing the CERT-In relationship, and no CERT-In logo, without prior written permission — which makes a vendor’s own marketing the cheapest integrity test you can run.
How CERT-In empanelment is actually granted
Nearly every page on this subject says an organisation “cleared CERT-In’s empanelment process” and stops there, which leaves the reader with a word instead of a standard. It is worth knowing what the process consists of, because it is the only thing that tells you what the status actually screens for — and because it explains why the checks later on this page are pitched at named individuals rather than at the badge.
CERT-In maintains a panel of information security auditing organisations to audit — including vulnerability assessment and penetration testing — the computer systems, networks and applications of Government organisations, critical infrastructure organisations and organisations in other sectors of the Indian economy. Applications are accepted in advertised windows announced on cert-in.org.in, with a stated opening and closing date and time. CERT-In states that applications received after the closing time are not accepted. An organisation applying then passes through four stages.
Documentation review
The application and its supporting evidence on paper: the organisation’s standing, its declared manpower, its methodologies, and its prior work.
What ends an application here: A thin technical bench, or a methodology that exists as marketing rather than as a documented procedure. This stage closes before anyone touches a keyboard.
Offline practical skill test
The organisation’s technical people, tested rather than described. This is an assessment of demonstrated capability, not of a capability statement.
What ends an application here: A firm whose named experts cannot do the work the brochure describes. It is the stage that makes empanelment something other than a paperwork exercise.
VAPT practical skill test
A hands-on vulnerability assessment and penetration testing exercise. The skills tested are the skills the empanelment covers.
What ends an application here: Tooling without method. This is the stage a buyer should keep in mind when a bidder’s answer to “how do you test” is a list of scanners.
Personal interaction session with CERT-In
The final stage, conducted with CERT-In itself. Results and interaction records are published by CERT-In as part of the empanelment cycle.
What ends an application here: Nothing formally, but it is the point at which the organisation is assessed as an organisation rather than as a set of test results.
Read stages two and three again, because they are the whole point. Empanelment cannot be bought as a certification, because two of its four stages are practical tests of named people rather than assessments of a document. That is what makes the status worth verifying at the level of the individual as well as the entity — and it is why the rules that follow from it are about people: manpower declared to CERT-In, background checks, a no-objection certificate when someone moves between empanelled firms, and a report that may be signed only by the declared names. The panel is a list of organisations whose people were tested. If the people on your engagement are not those people, you have the list’s comfort without its substance.
Two practical notes on the period. First, empanelment is granted for a defined period rather than indefinitely, and the length of that period is set by the cycle an organisation was empanelled under — so the number is not a general fact to be memorised but a specific one to be obtained. Ask the auditor for the period, or the empanelment letter reference, in writing. One of the published specimen safe-to-host certificates carries an empanelment letter number on its face for precisely that reason. Second, empanelment is not a one-time gate. CERT-In requires the snapshot information and point-of-contact details to be kept current, the declared manpower to be updated when people join or leave, the audit metadata to flow after every audit, and it reserves the right to review the work, take samples, and depute representatives to witness an audit — with continued empanelment expressly dependent on the quality of the auditing services rendered.
What CERT-In empanelment actually means when a vendor says it
Five constructions cover most of what buyers encounter. Only the first describes a real status, and even that one means less than it is usually made to carry. Read what is actually true as the answer to “what am I being told here”, and what to ask as the question that settles it.
| The claim | What is actually true | What it does not mean | What to ask |
|---|---|---|---|
| The organisation is empanelled by CERT-In. | A named legal entity cleared CERT-In’s empanelment process — a documentation review, two practical skill tests and a personal interaction session — and sits on the list CERT-In publishes on cert-in.org.in, for a defined empanelment period. Within that period it is eligible to perform information security audits and to sign the audit report — and, where the engagement calls for one, the audit certificate a government project needs before go-live, or that a tender or a regulator’s own clause calls for. Read the clause, because they do not all name the same instrument or the same issuer. | It is not a quality rating, a price band or a government endorsement of the firm as a business. It says the organisation was found eligible to do the work. It says nothing about whether the four people who turn up on your engagement are any good — which is why CERT-In separately requires declared manpower, background checks, a verification team, and publishes snapshot information so that you can compare competence rather than assume it. | The exact legal entity name, and the empanelment period in writing. Then check that the entity that will sign your report is the entity that is empanelled — not a sister concern, not a holding company, not a local branch trading under a similar name. |
| Our auditors are CERT-In certified. | Nothing. Empanelment attaches to an organisation, not to a person. There is no individual CERT-In certification and no personal empanelment that an auditor carries between employers — the guidelines instead require the organisation to run background checks before employment and, where a person moves from another empanelled organisation, to obtain a NOC or relieving letter from that previous organisation. | An auditor who leaves an empanelled firm does not take anything with them. A consultancy that hires three ex-empanelled testers is not empanelled and cannot become so by describing its staff that way. | Which organisation is empanelled, and whether that organisation signs. If the answer is a person rather than an entity, the claim has already failed. |
| We are CERT-In approved / accredited / authorised. | Nothing — these are not statuses CERT-In grants, and using them breaches the claims rule the guidelines set out. The only wording an empanelled auditor may use, without prior written permission, is a single prescribed sentence. | It is not a harmless paraphrase. The organisation making it is either not empanelled, or is empanelled and has chosen to describe its relationship with CERT-In in words it was told not to use. Both are relevant to a buyer weighing whether this firm follows rules it finds inconvenient. | For the permitted sentence, verbatim, in writing. A firm that is genuinely empanelled can produce it in seconds. A firm that cannot will negotiate about wording instead. |
| We are empanelled, so your systems are CERT-In compliant. | Nothing about your systems. Empanelment is a status of the auditor. Compliance obligations sit on you directly — for example the reporting, logging and retention duties in the CERT-In Directions of 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000. | No auditor’s status makes an auditee compliant, and no audit certificate is a certification of the organisation. A clean certificate says a stated application, in a stated environment, at a stated point in time, was found free of the vulnerabilities the audit looked for. | What exactly the certificate will say, against what the testing was performed, and which build and environment it will name. Read the wording before the engagement rather than after. |
| Our platform is CERT-In empanelled. | Nothing. Empanelment cannot attach to a product, a SaaS tool, a scanner or a managed service. Only an information security auditing organisation is empanelled. | A tool that produced findings an empanelled auditor later reviewed does not inherit anything. Nor does a reseller, integrator or hosting provider that engages an empanelled firm for its customers. | Who signs, and whether every name in the signature block appears in the organisation’s declared manpower. Everything in this area resolves to that question, because the signature is the only thing empanelment actually enables. |
The pattern across all five rows is the same. Empanelment answers one narrow question — who may sign — and every misuse works by stretching it into a broader claim: about quality, about approval, about the auditee, about a product. When a conversation gets complicated, return to the narrow question. For the certificate side of it, see how to verify a CERT-In audit certificate and who can issue safe-to-host certificates.
What a CERT-In empanelled organisation has to do
Empanelment is usually sold as a badge. Read the instruments and it is closer to a set of duties, most of which have direct consequences for the buyer: who may be on your engagement, who may sign, where your data may live, what leaves your building and when, and what standard the work has to meet. Twelve obligations matter commercially. The right-hand column is what to put in the procurement pack.
| Obligation | What the instrument says | What it means in practice | What the buyer should ask for |
|---|---|---|---|
| Deploy declared manpower | Under the 2025 audit policy guidelines the auditing organisation must only deploy manpower declared to CERT-In in the snapshot information form — stated without qualification, so it reaches every audit and not only public-sector work. The 2018 auditor guidelines had already made it explicit for Government and critical sector audits, and added that CERT-In may verify it independently, or through the auditing organisation or the auditee. | The people who test your systems come from a named pool the organisation has declared to CERT-In and which CERT-In publishes. Substitution is a compliance question rather than a staffing convenience — and a Government or critical-sector audit is where CERT-In is most likely to verify it. | Named auditors and their roles before kick-off, written confirmation that each appears in the organisation’s declared manpower, and an obligation in the contract to notify and re-confirm on any substitution. Then check the names on the report against the names in the proposal, and both against the published snapshot. |
| Sign through three hands, and only with declared manpower | The 2025 audit policy guidelines state that audit reports shall be signed only by the manpower declared to CERT-In as listed in the organisation’s snapshot information on the CERT-In website, and that the report must be signed by the auditors who conducted the audit, then reviewed and signed by a designated reviewer who is not part of the audit team and is drawn from mid-management, and finally authorised and signed by the head of the auditing organisation — a director, partner or CEO. The audit certificate must be signed by both the Lead Auditor and the Head of the Auditing Organization. The rule is repeated three times in that document, and it is not limited to government audits. | This turns “who signs” from a slogan into a checkable structure. A report with one signature, or a reviewer who was on the test team, or a name that is not in the declared manpower, is defective on its face — before anyone reads a finding. | A redacted specimen report and certificate, so you see the signature block before you commission one. Three signatures on the report, two on the certificate, each with a role, every name traceable to the declared manpower of the entity on your contract. |
| Background checks and the NOC on movement | A background check is required before employment. Where a person moves between CERT-In empanelled organisations, a NOC or relieving letter from the previous organisation forms part of that check. | This is why the answer to “can we just hire their lead auditor” is no, or at least not quietly. The rule exists because auditors carry other clients’ vulnerabilities in their heads, and a clean exit from the previous empanelled firm is part of the trust chain. | Written confirmation that background verification is complete for every person on your engagement, including anyone added mid-engagement. Ask specifically about recent joiners from other empanelled organisations. |
| Tell you about the 5-day submission, then make it | Two limbs, and the second is the one that gets missed. Clause 3.2.2 of the empanelment terms and conditions (version 7.2, April 2024) makes it mandatory for the auditor to share the audit report and audit metadata within 5 days of completion of the audit, in the format CERT-In provides — repeated at §10.6 of the 2025 audit policy guidelines. The same clause then makes it mandatory to report all the critical vulnerabilities along with auditee details to CERT-In within 5 days of completion of audit which the auditor pointed out but which the auditee did not fix, even during follow-up audits. And under §13.2.1(iii) of the 2025 guidelines the auditor must tell you all of this before the assignment starts. | Your report leaves your organisation by design, on a clock, to the national agency — and if you leave critical findings open, your organisation is named alongside them. That converts closing findings before report issue from good practice into a commercial matter. The purpose is stated: capacity building, the audit framework, benchmarking and audit quality control, which is the pipeline AMBAK sits on top of. | Nothing, if the auditor did its job — the disclosure is owed to you before the engagement starts, so an auditor who never raised it has already missed an obligation owed to you. Then agree the retest and closure window explicitly, so the criticals that travel to CERT-In with your name attached are the ones you chose not to fix rather than the ones nobody scheduled. |
| File quarterly returns | A quarterly report to CERT-In covering the number of audits performed, the sectors audited, high-level findings, and new areas encountered. This one comes from the process section of the 2018 empanelled-auditor guidelines rather than from the empanelment terms. | Your engagement is counted and categorised by sector into a national picture of what auditors are finding. Nothing is asked of you — but it is why claims about what “most audits find” are better sourced from CERT-In than from a vendor. | Nothing directly. Treat it as one more reason the report should say precisely what it means: aggregated findings travel further than the document on your desk. |
| Accept CERT-In’s reserved right to look — and tell you when it is exercised | CERT-In reserves the right to seek or audit information on any project within the empanelment period, and can be part of the audit team to assess the quality and maturity of the audit. Under the 2025 audit policy guidelines, where CERT-In exercises that right the auditing organisation must communicate it to the auditee clearly and in writing. | A third party may review, or take part in, the work on your systems — and you are entitled to be told in writing when that happens. It is not something that goes on around you, and it is why the standard of the working papers matters to you as much as to the auditor. | Confirmation in the engagement letter that the auditor will notify you in writing if CERT-In exercises that right, and agreement on who receives the notice. Then hold the method to a standard that survives it: timestamped artefacts, a stated environment, a tool list, findings traceable to reproducible steps. |
| Keep the data in India, and destroy it after | The auditor must ensure there is no mirroring of data outside the country. Auditee data is stored only on systems located in India, encrypted on auditor laptops, and wiped after completion so that it cannot be retrieved by any known forensic technique. It may not be shared with an overseas partner unless specifically authorised by the auditee. | This constrains the delivery model, not just the paperwork. A firm running its testing platform, ticketing or report drafting on an offshore team or an overseas-hosted tenant has a problem to solve before it touches a Government or critical-sector engagement. | Where testing data, evidence and draft reports are stored and processed, whether any part of delivery involves an entity outside India, and the data disposal commitment with a date. If an overseas partner is involved, your specific authorisation is required — so make it a decision, not a discovery. |
| Keep CERT-In out of the contract | The auditor must ensure that CERT-In is not made a part of any contract between auditee and auditor. | CERT-In empanels the organisation. It is not a party to your engagement, does not guarantee the auditor’s performance, and cannot be invoked in a dispute between you and your auditor. A draft contract that names CERT-In as a party, guarantor or escalation route is drafted wrong. | Legal review of any clause that refers to CERT-In as anything other than the source of the auditor’s empanelment. Reference the empanelment as a fact about the auditor. Do not make the agency an actor in your agreement. |
| Test properly, not just with tools | Auditors must use industry-standard methodologies and best practices for security testing, and solely tools-based testing should be discouraged. A verification team — a red team — should be deployed to verify the work performed by the audit team, the white team. | The distinguishing mark of a real engagement is manual work: business-logic abuse, authorisation testing across roles, chained findings that no scanner reports. The verification team is the quality gate that catches a tester who ran a scan and wrote it up. | How manual testing is split from automated, who reviews the findings before issue, and what the verification team changed. Ask to see one finding that no scanner could have produced. |
| Get written approvals, control the tools | Written approvals are required before penetration tests and before installing tools. Tools are installed in the presence of the auditee’s system administrator, removed afterwards with the auditee’s acceptance, and accompanied by a tool list plus written confirmation of IPR and licensing. Auditors are to refrain from Distributed Denial of Service testing over the Internet and from any form of flood testing — the 2025 audit policy guidelines permit either only on explicit written permission — and from testing or exploiting high-risk vulnerabilities such as discovered breaches or anything that may put lives at immediate risk. | These are the clauses that keep a security audit from becoming an incident. They also set the shape of the engagement: a named window, an approved scope, an agreed rules-of-engagement document, and an exit where the tooling comes back off your estate. | The tool list with licence confirmations, the written approval record, and the removal sign-off. A proposal that offers flood or DDoS testing over the Internet without that written permission on file is the problem — not the test itself. For the exploitation boundary, agree in advance what happens if the team finds evidence of an existing compromise: that is an incident-response trigger, not a finding to write up quietly. |
| Write a report that can be acted on | Observations must be supported by objective evidence, compiled with the report. The report should state appropriate timelines for closure of vulnerabilities according to severity. The deliverable structure is agreed with the auditee before commencement, the audit team composition is shared and documented approval obtained before formal commencement, and the expectation gap is to be reduced or eliminated by explaining the audit process, the collection of artifacts and the deliverables in detail upfront. | Every argument that happens at the end of a bad engagement is traceable to one of these being skipped at the start. The deliverable structure, the team, and what evidence will look like are all pre-agreed items — not things to discover when the draft arrives. | A sample redacted report before award, the deliverable structure in the SOW, the severity-to-timeline mapping the report will use, and the named team with approval recorded before work begins. |
| Stay independent of the remediation | The 2025 audit policy guidelines define conflict of interest to cover the same entity implementing controls and auditing them, or auditing while responsible for remediation, and list Independence and Objectivity among the basic principles binding on empanelled auditing organisations. The same principle is explicit about money: payments should not be contingent upon the outcome of the audit, favourable or unfavourable, nor tied to the submission or approval of any closure report, and fees should be based on predefined scopes, deliverables and timelines. | A published rule rather than a matter of taste, which matters when a bidder offers to fix what it finds and sign for the fix. That can still be the right shape for ordinary testing, but where a certificate is the deliverable it is a named conflict, to be disclosed and structured rather than assumed away. | A written statement of which party performs remediation and which party audits and signs, before award. And read your own payment schedule: a milestone named “on issue of clean certificate” is the exact arrangement the independence principle rules out. |
Four of these are worth pulling out, because they are the ones buyers are most often surprised by. The people on your engagement are supposed to have been declared to CERT-In in advance, and only those people may sign. The report has to pass through three hands before it is issued, and the certificate through two. The report and its metadata leave your organisation on a five-day clock — along with any critical finding you chose not to close. And CERT-In can decide to look at, or take part in, the audit of your project, in which case you are entitled to be told in writing. None of the four is a reason to avoid an empanelled auditor. All four are reasons to run the engagement with the paperwork straight from the beginning.
One sentence, and no others
Of everything in the guidelines, one rule is both unambiguous and checkable by anyone. It governs how an empanelled organisation may describe its relationship with CERT-In, and it is worth reading in the original rather than in paraphrase.
“Auditor shall not use the CERT-In logo, nor make any reference to the Auditors association with CERT-In on any publicity material, promotional material or product without the prior written permission of CERT-In.”
“An Auditor may use the words ‘This Organization is empanelled by CERT-In for providing information Security Auditing Service’. No other words shall be used to describe the Auditors relationship with CERT-In without the prior written permission of CERT-In.”
Read it twice, because it is stricter than it first appears. The permitted sentence describes the organisation, not a person. It says empanelled, not approved, certified, accredited, authorised, recognised or partnered. It names the service — information security auditing — without elaborating into categories, specialisms or sectors. The logo prohibition covers publicity material, promotional material and products, which in modern terms means the website, the deck, the tender response, the brochure, the report cover, the email signature and the badge on a product screen — and the terms require the wording and presentation to be submitted to CERT-In before any permission is given. The same clause set adds two things people miss: the auditor must ensure CERT-In is not made or projected to be a part of any contract between auditee and auditing organisation, and an organisation whose empanelment has been terminated must stop claiming the status altogether.
Eight constructions, and what each one tells you
This is the practical use of the claims rule. You are comparing three or four auditors, all of whom say they are empanelled, and you cannot yet tell them apart on method. Open their websites and read how they describe CERT-In. The rule is a single sentence long, it is published, it applies to every empanelled organisation equally, and compliance costs nothing — so a firm that breaks it has chosen to.
| Construction | Verdict | Why |
|---|---|---|
| “This Organization is empanelled by CERT-In for providing information Security Auditing Service” | Permitted, verbatim | This is the sentence the guidelines expressly allow. Reproduced exactly — including its own capitalisation — it needs no permission and carries no risk. A firm that uses it and nothing else has read the document that governs its status. |
| The CERT-In logo on a website, brochure, report cover, tender response or product screen | Prohibited without prior written permission | Both the 2018 auditor guidelines and clause 4.1 of the empanelment terms bar use of the CERT-In logo on any publicity material, promotional material or product without prior written permission — and require the wording and presentation to be submitted to CERT-In first. This is the easiest check a buyer can run, and the most visible form the breach takes. |
| “CERT-In approved”, “CERT-In certified”, “CERT-In accredited”, “CERT-In authorised” | Not permitted | None of these describe a status CERT-In grants, and each describes the relationship in words other than the permitted sentence. Approval and accreditation imply a judgement about quality that empanelment does not make. |
| “Our consultants are CERT-In empanelled auditors” | Not permitted, and not true | Empanelment attaches to an organisation for a period. Individuals are covered by background checks, declared manpower and the NOC requirement — none of which is a personal empanelment that travels with them between employers. |
| “Empanelled by CERT-In for VAPT / cloud / application security” | Grey — verify before relying on it | Empanelment is granted to the organisation, and a firm elaborating on categories in its own words has stepped outside the permitted sentence. The useful question is not how the firm words it, but what it is actually competent and equipped to test, evidenced by method rather than adjective. |
| “In association with CERT-In” / “working with CERT-In” / “CERT-In partner” | Not permitted | These describe a relationship that does not exist. The duties an empanelled organisation owes CERT-In — report sharing, quarterly returns, accepting review — are obligations flowing one way, not a partnership to advertise. |
| “Audit performed and report signed by <named empanelled organisation>, empanelled by CERT-In” | The correct construction for a non-empanelled party | It is factual, it names who actually holds the status, and it tells the reader who signs. |
| “Backed by CERT-In” / “CERT-In recognised” / “Government recognised auditor” | Not permitted | Each implies an endorsement. Empanelment is eligibility to do defined work, granted for a period, revocable — the opposite of a backing. Language like this in a tender response is a self-inflicted disqualification risk. |
The inference is not that a firm with a logo on its homepage does bad testing. Plenty of capable engineers work at firms with careless marketing departments. The inference is narrower and more useful: this organisation treats a published, unambiguous rule about its own status as optional when following it is inconvenient. You are about to rely on the same organisation’s judgement about when a finding is closed, when a test is complete and when a system is safe to host — judgements nobody outside the engagement will check. A rule this easy to keep is the cheapest possible evidence about how the harder ones will be handled. Run it as a two-minute step in shortlisting, before the technical evaluation, and record what you find with the date and a screenshot in the procurement file. It is not a disqualification on its own — but it is a question the bidder should answer, and the answer is informative either way.
Empanelment is not transferable
Most bad claims in this area are attempts to move the status somewhere it cannot go. Six directions it does not travel, and each one is an argument this page exists to prevent.
It does not transfer to you
Being audited by an empanelled organisation does not make your company empanelled, certified or approved. The correct thing to say in your own documents is what happened: that a named empanelled organisation performed the audit and issued the report or certificate on a stated date. Your suppliers will try the other construction on you, and your customers will try it on you too.
It does not transfer to a reseller or subcontractor
A reseller or subcontractor does not acquire the status of the empanelled organisation it works with. The signature has to come from the empanelled organisation, and the buyer is entitled to know who signs before award rather than at the certificate stage.
It does not transfer between group entities
Empanelment names a legal entity. A subsidiary, a sister concern, a holding company or a similarly named entity in another state is not covered by the parent’s empanelment. This is a failure mode that survives because the trading name on the proposal is rarely the entity name on the list — reconcile them with the CIN or GSTIN on the proposal rather than by eye.
It does not extend beyond the period
Empanelment is granted for a defined period and can lapse or be withdrawn. What matters for your project is the status on the date the report is signed and the certificate issued — not the date you signed the contract, and not the date on a screenshot the vendor took last year.
It is not a warranty of the work
CERT-In is not a party to your contract and does not guarantee the auditor’s performance. If the audit is poor, your remedy is contractual and commercial. Empanelment tells you the organisation is eligible to sign, but it does not underwrite what the organisation signs.
It is not a security rating of the auditee
A certificate attests a stated scope tested in a stated environment at a point in time against the vulnerabilities the audit looked for. It is not a statement that your organisation is secure, that your controls are mature, or that you meet any framework. Treat it as the gate it is, and keep the programme separate.
The unifying rule is short: empanelment describes an organisation, for a period, and enables a signature. Anything a claim adds beyond that — about your company, about a product, about a person, about a reseller, about quality — has been added by the person making the claim. That includes claims made about you: when a customer or a tender evaluator reads your compliance page, the accurate construction is that a named empanelled organisation performed the audit and issued the report on a stated date.
How to verify a CERT-In empanelled auditor, in eleven steps
Every step here is something a buyer can do before award, and most take minutes. The expensive failures in this market are not sophisticated frauds — they are ordinary mismatches between the entity that bid, the entity that signed and the period that had lapsed, none of which anybody checked because everyone assumed somebody else had. The right-hand column is the one to read first: it is what the failure actually looks like when the check is skipped.
| Step | What you ask for | Who supplies it | What a failed check looks like |
|---|---|---|---|
| 01 Fix the legal entity | The exact registered name of the entity that will sign, plus its CIN or GSTIN — not the brand, not the trading name, not the group. | The bidder, in the proposal itself, so it is on the record before evaluation. | A brand letterhead with no entity name anywhere on it, or a covering letter whose signature block names a different entity from the commercial annexure. |
| 02 Find the entity on CERT-In’s own list | A match, character by character, against the list of empanelled information security auditing organisations published by CERT-In on cert-in.org.in. | CERT-In’s site, read at source in the current version — never a PDF forwarded by the vendor, which is a point-in-time copy the vendor chose when to take. | A near-match. “Technologies Pvt Ltd” on the list, “Technologies India Pvt Ltd” on the contract. Reconcile it with the CIN or GSTIN. If you cannot, the entity you are contracting is not the entity that is empanelled. |
| 03 Get the empanelment period in writing | The empanelment period, or the empanelment letter reference, stated by the auditor in writing — then checked against the date your report and certificate will be signed rather than the date you award. | The auditor. The published list tells you the organisation is empanelled, but it is the auditor who has to put the period on the record, and one published specimen certificate carries an empanelment letter number for exactly this reason. | “We are in the current cycle” or “renewal is in progress”. Get the position in writing, with the period claimed. A signature dated outside a period nobody can evidence is unusable regardless of the assurance given. |
| 04 Read the published snapshot information | The organisation’s snapshot information — manpower and skillsets, relevant experience, categories of audit conducted, audits carried out in the last twelve months by sector, technical manpower deployed, and tools used. | CERT-In publishes it, and the 2025 audit policy guidelines tell auditees and sectoral regulators to use it to match their requirement against an organisation’s competence. | Your sector does not appear in the last twelve months, or the tool list has nothing for the estate you are asking them to test. Neither disqualifies a bidder. Both are questions to put before award rather than after the first draft. |
| 05 Ask for the permitted sentence, verbatim | One line: “This Organization is empanelled by CERT-In for providing information Security Auditing Service”. | The bidder, in writing, by return. | A paraphrase, a logo, a scanned certificate image, or a negotiation about wording. A genuinely empanelled firm produces the sentence in seconds, because it is the only wording it is allowed to use. |
| 06 Read the bidder’s own marketing | Nothing. Open the website, search every page for “CERT-In”, and look for the logo, wording other than the permitted sentence, and any claim that individuals hold the status. | The bidder’s public site, before you speak to them again. Record findings with the date and a screenshot. | “CERT-In approved” in a footer, a logo on a report template, an “our CERT-In empanelled consultants” line on a team page. None of it is permitted. |
| 07 Check the signature chain, not just the letterhead | A redacted specimen report and certificate. On the report: the auditors who conducted the audit, a designated reviewer from mid-management who was not on the audit team, and the head of the auditing organisation. On the certificate: the Lead Auditor and the Head of the Auditing Organization. | The bidder. Then cross every individual name against the declared manpower in the published snapshot, and the entity name against your contract. | One signature where there should be three. A reviewer who also appears in the test team. A signatory who is not in the declared manpower. An entity in the signature block that is not the entity on your contract — at which point stop, because nothing downstream fixes it. |
| 08 Name the team before kick-off | The named auditors and their roles, written confirmation that each appears in the declared manpower, and a substitution clause requiring notice and your consent. | The bidder, as a contract schedule rather than an email. You may also interview and select the resources, verify their technical credentials, and verify identity, ID cards and designations. | Two senior names in the bid and two juniors on site. The 2025 guidelines go further than seniority: auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice — and the auditee is expected to verify compliance, which means the check is yours to run. |
| 09 Settle data location and disposal | Where testing data, evidence and draft reports are stored and processed, whether any entity outside India touches delivery, encryption on auditor devices, and a dated disposal commitment. | The bidder, in the proposal. Sharing with an overseas entity or partner requires your specific written authorisation. | An offshore testing team, an overseas-hosted ticketing tenant, or a report drafted elsewhere — discovered in week two rather than decided in scoping. Where no retention period is agreed the auditor keeps the data a year, so silence is itself a decision. |
| 10 Read the certificate wording before the engagement | Exactly what the certificate will say: scope, environment, application version and hash, date, and the validity condition. | The bidder, as a specimen. The auditor must test on the staging environment provided by the hosting service provider before issuing, and include the hash values and version numbers obtained from you. | A certificate that names the wrong environment, or omits the hash and version, and is rejected by the department that has to accept it. Where the scope stopped at staging the report must say so explicitly. |
| 11 Write the lapse clause | A representation that empanelment is current and will be current at signature, a duty to notify you in writing within a stated number of days of any lapse, suspension or withdrawal, and an agreed remedy. | Your own legal team. This is a two-line clause. | Nothing visible — which is the point. It fails silently, at the end, when the signature you were buying is no longer available and the fieldwork is already done. |
Where the list is, and what a listing does not tell you
CERT-In publishes the list of empanelled information security auditing organisations on cert-in.org.in, together with snapshot information about each organisation. Read both there, in the current version. A PDF forwarded by a vendor is a point-in-time copy taken on a date the vendor chose, which is exactly the property you are trying to check.
The listing settles one question: whether this legal entity is on the panel. It does not, by itself, settle the question your engagement turns on, which is whether the status holds on the date the report and certificate will be signed. Treat the list as a point-in-time publication, get the empanelment period from the auditor in writing, and re-check both before signature rather than only at award. Two situations come up constantly and are worth having a script for:
“Our renewal is in progress.”
Ask for the position in writing, naming the period claimed and the status of the application. Then apply the rule that actually governs the deliverable: a signature from an organisation that is not empanelled on the date of signature is not the signature your requirement asked for, regardless of how confident the assurance is or how good the testing was. If the timing is genuinely tight, the answer is a schedule change or a second signatory arrangement agreed in advance — not a hope that the renewal lands first.
“That is our trading name — same company.”
Sometimes true, and easy to settle: reconcile the name on the proposal to the entity on the list using the CIN or the GSTIN, character by character, and keep the reconciliation in the file. Where the reconciliation fails — a subsidiary, a sister concern, a similarly named entity registered in another state — the answer is not a comfort letter. It is to contract with the listed entity, or to have the listed entity join the agreement as the party that signs.
Read the snapshot information before you shortlist
This is the instrument most buyers never open, and it is the answer to the objection that empanelment tells you nothing about competence. CERT-In publishes snapshot information on the skills and competence of each empanelled organisation, and the 2025 audit policy guidelines say it should be used by organisations and by sectoral regulators to identify and select auditing organisations — that is, to match a requirement against a firm’s actual capability. Six fields, and the question each one settles:
| Published field | The question it settles |
|---|---|
| Manpower and skillsets | Whether the bench is deep enough for your scope, and whether the named individuals on your proposal are actually in the declared pool. This is the field the signature rule points at: reports may be signed only by manpower declared here. |
| Relevant experience | Whether the organisation has done work resembling yours, in the form CERT-In records rather than in the form a case study describes. |
| Categories of audit conducted | Whether the category you need — application and API testing, cloud, OT, source code review, AI systems — is one this organisation actually performs, rather than one it is willing to attempt. |
| Audits carried out in the last twelve months, by sector | Whether your sector is routine work for this firm or a first. Not a disqualifier, but a question to ask before award, and one you can ask with a number in front of you. |
| Technical manpower deployed, with details | Whether the organisation deploys the people it declares, at the volume it declares. Read it next to the named team in your proposal. |
| Tools used | Whether the tooling matches the estate. A tool list with no cloud posture tooling on a cloud-native scope, or nothing for mobile on a mobile scope, is a gap you can see before the kick-off call. |
Then use the rights that sit alongside it. The 2025 guidelines say the auditee may interview and select the resources put forward, verify their technical credentials against CERT-In’s qualification requirements, and verify identity, official identity cards and designations. They also state plainly that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving their notice period — and that the auditee organisation should verify compliance. That is a disqualifying list you can run against a named team in an afternoon, and it is the concrete version of the vaguer advice that status is not competence.
The three signatures, and the two on the certificate
“Who signs” is the question everything on this page resolves to, and CERT-In answers it precisely enough to check. The 2025 audit policy guidelines state that audit reports shall be signed only by manpower declared to CERT-In as listed in the organisation’s snapshot information on the CERT-In website, and then set out a chain of three. The rule is repeated at three separate points in that document, which is usually a sign that it was being ignored.
The auditors who conducted the audit
Signs the Report
Signed by the people who actually did the work, and only by manpower declared to CERT-In in the organisation’s published snapshot information. A name on the report that is not in the declared manpower is a defect in the report, not a formality.
A designated reviewer outside the audit team
Signs the Report
Reviewed and signed by a designated reviewer who is not part of the audit team and is drawn from mid-management. Maker-checker applied to the deliverable rather than to the testing — and the reason a reviewer who also appears in the test team is a finding about the report.
The head of the auditing organisation
Signs the Report and certificate
Authorised and signed by the head of the auditing organisation — a director, partner or CEO — certifying completeness, accuracy and integrity. The audit certificate must carry two signatures: the Lead Auditor and the Head of the Auditing Organization.
What the signature block should look like
On the audit report
_______________________
Auditor(s) who conducted the audit — named, and declared to CERT-In
_______________________
Reviewer — mid-management, not a member of the audit team
_______________________
Head of the Auditing Organization — Director / Partner / CEO
On the audit certificate
_______________________
Lead Auditor
_______________________
Head of the Auditing Organization
Illustrative layout only — the point is the roles and the count, not the formatting. The reciprocal check is the one that matters: cross each individual name against the declared manpower in the published snapshot, and the entity name against the entity on your contract.
Three of the eleven steps deserve emphasis because they fail silently. The empanelment period against the signature date catches the long project that crossed an expiry, and nothing in the engagement will surface it until the certificate is rejected. The signature chain catches the group that bids under a brand and signs through an entity that is not the empanelled one, and the individual name that is not in the declared manpower. The snapshot catches the firm whose sector experience and tool list do not reach your estate. None of the three is exotic. All three are unrecoverable at the point they are discovered.
Document the check. A short note in the procurement file — entity name, source, date checked, period claimed, snapshot observations, screenshot — converts an assumption into a record, and a record is what an auditor, an internal reviewer or a department’s own compliance cell will ask for two years later. The certificate side of this is covered separately in how to verify a CERT-In audit certificate.
Three bidders, four hours, three problems found before award
An illustrative composite — not a client. A state department is procuring a pre-go-live audit for a citizen-facing portal, and runs the checks above across a three-bidder shortlist. The point of the example is the cost: every problem below was found with an email, a website and a list, before any money moved.
| Day 1 | Three bids, three entity names The department is buying a pre-go-live audit for a citizen-facing portal. Three bidders, all describing themselves as CERT-In empanelled. The procurement officer asks each for the registered entity name and the CIN on the covering letter, and gets three answers in under a day. Cost: one email. |
| Day 2 | Bidder A — listed parent, contracting subsidiary The parent entity is on CERT-In’s published list. The proposal, the commercial annexure and the draft contract all name a subsidiary with a similar name and a different CIN, which is not on the list. Bidder A’s account manager is confident it makes no difference. It makes all the difference: the entity that would sign is not the entity that is empanelled. The department asks bidder A to re-bid through the listed entity, which it is able to do. Cost: two days and one amended bid. |
| Day 2 | Bidder B — listed and clean, marketing is not The entity matches the list exactly. The website carries the CERT-In logo in the footer of every page, and the team page names two “CERT-In empanelled consultants”. Neither is permitted: the logo needs prior written permission, and empanelment attaches to the organisation rather than to individuals. Worse for the evaluation, both named consultants are absent from the declared manpower in the published snapshot, and one of them is the proposed lead auditor. The department asks the question in writing. Cost: twenty minutes on the website, one written question. |
| Day 3 | Bidder C — listed, but the period runs out first The entity matches. Asked for the empanelment period in writing, bidder C supplies it — and it expires about six weeks before the date the report and certificate are scheduled to be signed, because the project plan runs a remediation cycle and a retest after the first pass. Bidder C says renewal is in progress. The department does not treat that as an answer: it asks for the position in writing, and adds a clause requiring notice of any lapse plus an agreed remedy. Cost: one written exchange. |
| Day 5 | What the department actually did Bidder A was allowed to re-bid through the listed entity and was evaluated on method. Bidder B was asked to explain the logo and the two undeclared names. The answer — that marketing had run ahead of the empanelment team — was accepted for the logo but the lead auditor was replaced with a declared individual before award. Bidder C was scored down on schedule risk rather than excluded. Total diligence effort across all three: under four hours, entirely before award. Every one of those three problems is unrecoverable at certificate stage. |
Notice what the department did not do. It did not disqualify anyone for the logo, it did not treat a trading-name mismatch as dishonesty, and it did not assume a renewal would fail. It converted three assumptions into three written positions, and priced the remaining risk into the evaluation. That is the whole method: get the claim in writing, check it at source, and write the consequence into the contract.
When CERT-In empanelment is suspended or withdrawn
This page says repeatedly that empanelment can lapse or be withdrawn, and a hazard you cannot describe is a hazard you cannot weigh. CERT-In publishes a graded matrix of consequences in the 2025 audit policy guidelines, with named triggers at each grade. Read it twice: once for what could happen to a bidder, and once for the fact that adverse auditee feedback on technical competency is itself a named trigger — which makes the feedback you give after a poor engagement consequential rather than cathartic. The feedback channel is published, and the guidelines describe it as both a right and a duty of the auditee.
| Grade | What triggers it | What CERT-In does | What it means for a live engagement |
|---|---|---|---|
| Watch list, with warning and written commitment | Inadequate closure of non-conformities. No relation between the noting and the issue raised. Inadequate sample details, issues covered or improper conclusions. Minor violations of the terms and conditions. A first adverse report missing a maximum of two vulnerabilities. Conflict with an auditee. A first instance of non-compliance with CERT-In’s data collection framework. | CERT-In issues a show cause, takes a corrective action report from the auditing organisation, and issues a warning with a written commitment. | The organisation is still empanelled and can still sign. Read the trigger list from your side: most of those failures are ones you, holding the report, are best placed to notice — and the auditee feedback channel exists because CERT-In cannot read every report. |
| Suspension | Adverse feedback from an auditee on technical competency or auditor attributes. Repeated failure in audit planning or audit coverage. Issues appearing soon after the conduct of an audit. Major violations of the terms and conditions. Multiple adverse reports of missed vulnerabilities. Multiple instances of non-compliance with the data collection framework. | Suspension, revoked only on satisfactory submission of corrective actions and, where needed, witnessing of the organisation’s work. | This is the grade your contract has to contemplate, because it can land mid-engagement and it is not public knowledge the day it happens. That is what the notification duty and the remedy clause are for. |
| Withdrawal of empanelment | Auditing malpractices, substandard services, failure to cover the scope of work. | De-empanelment by CERT-In, with debarment under the General Financial Rules and Department of Expenditure O.M. No. F.1/20/2018-PPD dated 2 November 2021. On termination the auditor must refrain from advertising or claiming the empanelment status. | The signature you were buying is gone. Work already signed inside the period is not retrospectively void, but nothing further can be signed — which is why the period matters against the signature date rather than the award date. |
| Penal and legal action | Breach of trust, digital break-in, damage or attempted damage to the auditee’s interests and infrastructure. | As per applicable penal and legal Acts and laws. | Beyond the panel entirely. The empanelment terms also name involvement in any cyber security assessment, unannounced access or penetration without the prior written consent of the target entity as a ground for terminating empanelment — which is the rule behind every written-approval requirement on this page. |
The empanelment terms add the other half of the picture: CERT-In may review audit work and qualifications, take samples for analysis, depute representatives to witness an audit, and seek the auditee’s opinion — with continued empanelment status expressly dependent on the quality of the auditing services rendered. The terms also list grounds for termination directly, including involvement in any cyber security assessment, unannounced access or penetration without the prior written consent of the target entity, and failure to notify changes in foreign tie-ups or in manpower. Two things follow for a buyer. First, this is why the de-empanelment clause in your contract is worth the two lines it costs. Second, it is why every written-approval requirement on this page exists: unapproved testing is not a process irregularity in this regime, it is a ground for losing the panel place.
What an empanelled CERT-In audit covers — VAPT, cloud, OT and AI
Empanelment is often discussed as though it were only about government websites and the safe-to-host certificate. That is one important output of one kind of engagement. The status is for information security auditing, and the 2025 audit policy guidelines enumerate the engagement classes it covers — twenty-six of them, from vulnerability assessment and red teaming through cloud, ICS and OT, source code review and bills of materials to AI system audits and blockchain. The same section opens by saying auditees are expected to ensure a comprehensive audit covering all aspects of their ICT systems at least once a year, which is a wider expectation than most scopes are written to.
What follows groups those classes the way the guidelines do, and adds the column this page exists to add: what to ask a bidder to prove it can actually do that work. Empanelment is eligibility, not competence in every row — an organisation eligible to sign is not automatically equipped to red-team a model or to test a substation safely. Method, tooling, named people and prior work establish that, and the published snapshot is where you read three of the four.
Testing the attack surface
| Audit class | What it covers | What to ask a bidder to prove |
|---|---|---|
| Vulnerability assessment and penetration testing | VAPT is two named categories, not one word. Vulnerability assessment examines a system or product to determine the adequacy of its security measures, identify deficiencies, and confirm adequacy after remediation. Penetration testing actively tests components, or the application as a whole, to identify and exploit vulnerabilities and determine whether they can be used to compromise the application, reach sensitive data or affect the underlying infrastructure. | Ask for the split between manual and automated effort, and for one finding no scanner could have produced. Solely tools-based testing is discouraged in both the 2018 and 2025 guidelines, and the 2025 document adds that limited lists such as OWASP Top 10 and SANS Top 25 are not standards or references for an audit. |
| Red team assessment | A named engagement class in its own right: an exercise reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities in an enterprise’s information systems. Distinct from a penetration test in objective — detection and response are part of what is measured. | Ask what is in scope for detection, who inside your organisation is briefed, and what the stop conditions are. Notification of the test is to be limited to key personnel, and the exercise sits behind written approvals like every other active test. |
| Wireless and physical security testing | Wireless testing evaluates a wireless network by simulating attacks against unauthorised access and data exposure. Physical security testing assesses the measures protecting facilities, equipment and personnel. | Ask how it is bounded. Social engineering and process testing must use anonymised or statistical techniques, must not identify or penalise an individual, must stay inside the agreed employee scope, and must not involve customers, partners, vendors or other third parties without specific written consent. |
Applications, APIs and code
| Audit class | What it covers | What to ask a bidder to prove |
|---|---|---|
| Application security testing — web, mobile and APIs | Assessing an application’s architecture, components and configuration to identify vulnerabilities. The 2025 guidelines name web applications, mobile applications and APIs together, which closes the gap left by a scope written only against a browser-facing front end. Version-specific details of web and mobile applications must be in the scope and in the report. | Ask for the API inventory the scope was derived from, and for the environment to be named — Test, Development, UAT, Pre-Production or Production. Where a certificate is the deliverable the auditor tests on staging first, and the hash value and version number come from you into the report. |
| Source code review — DAST and SAST | Examining source code for security vulnerabilities, coding errors and inefficiencies against best practice, coding standards and regulatory requirements. For identified critical applications the 2025 guidelines expect both dynamic and static application security testing, and expect SAST by the developer or system integrator to be written into the RFP. | Ask which applications you have classified as critical, and whether your own RFP obliges the supplier to perform SAST. An application built without secure design practice is not supposed to be put forward for assessment at all — and the auditor is to say so in writing, with a copy to CERT-In. |
| SBOM, QBOM and AIBOM auditing | Evaluating the Software, Quantum and Artificial Intelligence Bills of Materials for transparency, traceability and integrity of components — known vulnerabilities, licensing issues and supply chain risk in open-source and third-party components. | Ask whether a bill of materials exists before you ask for it to be audited. Most estates discover at this point that the artefact the audit category assumes has never been produced for the applications in scope. |
Infrastructure, cloud and platform
| Audit class | What it covers | What to ask a bidder to prove |
|---|---|---|
| Network infrastructure audits | A review of firewalls, endpoint devices, servers, routers, switches, IPS and IDS, with their software, configurations and access controls. Flood and Distributed Denial of Service testing over the Internet sit outside ordinary scope — the 2025 guidelines permit either only on explicit written permission. | Ask for the asset inventory the scope was derived from, and its last-updated date. The 2025 guidelines require scope to be derived from a consolidated, updated inventory vetted by internal audit with the CISO. That one date settles most later arguments about coverage. |
| Cloud security testing | Evaluating the security measures, configurations and vulnerabilities of cloud systems, applications and infrastructure — identity and access configuration, storage exposure, key and secret handling, network controls, logging coverage, and the managed services a modern estate runs on. The 2025 guidelines name the CSA Cloud Controls Matrix as the reference framework. | Ask which CCM domains the assessment will cover and where the shared-responsibility line falls for each service in scope. Then ask the separate question the 2022 Directions force: whether your 180 days of logs are inside Indian jurisdiction, because an observability platform hosted abroad is a cloud architecture decision with a compliance consequence. |
| ICS, OT, IoT and IIoT | Industrial control systems and operational technology networks evaluated for vulnerabilities that could disrupt critical industrial processes and affect safety, production and availability. Connected devices in IoT and industrial IoT networks evaluated for vulnerabilities and attack vectors. Attacks on critical infrastructure, SCADA and OT systems, and attacks on IoT devices, are separately named reportable incident classes under the 2022 Directions. | Ask how availability is protected during testing. In critical environments where availability is a top priority, the 2025 guidelines say testing should be conducted in a passive manner to avoid downtime or service disruption — and the prohibition on testing that may put lives at immediate risk is not a formality on a plant floor. |
| Endpoint and log management audits | Endpoints evaluated on configuration, patching, malware protection, encryption, access control and monitoring. Log management audited on generation, retention, integrity and monitoring — also how compliance with the 180-day log direction is tested in practice. | Ask for the log audit to be scoped against the Directions explicitly, with the jurisdiction requirement as a separate test from the retention period. They fail independently, and only one of them is visible in a retention setting. |
Emerging domains
| Audit class | What it covers | What to ask a bidder to prove |
|---|---|---|
| AI system audits | Evaluation of AI systems for security, ethical alignment, transparency, data integrity and resilience to adversarial manipulation — a named class of engagement in the 2025 audit policy guidelines. In practice the surface is the application, API and infrastructure around the model, the data paths into and out of it, and the model-facing failure modes: instruction override, unsafe tool and plugin invocation, training and retrieval data exposure, and output handling downstream. | Ask what the method is, in writing, and who has done it before. The compliance hook is already live and is worth stating to your own board: item (xx) of Annexure I to the 2022 Directions makes attacks or malicious activity affecting systems related to artificial intelligence and machine learning a mandatorily reportable incident class, at any severity. |
| Blockchain security audit | A structured assessment of blockchain systems including smart contracts and infrastructure — identifying vulnerabilities, verifying cryptographic integrity, evaluating access controls and consensus mechanisms, and confirming compliance with security best practice and regulatory requirements. | Ask for prior work in the same consensus and contract environment. Item (xix) of Annexure I already covers incidents affecting blockchain, virtual assets, exchanges and custodian wallets, so the reporting duty does not wait for the audit category to mature. |
| Digital forensic readiness | Evaluating preparedness to collect, preserve and analyse digital evidence in the event of a security incident. Where a forensic investigation would be constrained by missing or inadequate logs, the report is required to say so and to recommend the log detail that should be captured. | Ask for this one explicitly, because nobody buys it until after the incident that needed it. It is also the category that most directly tests whether the six-hour reporting clock is achievable with the evidence you actually hold. |
Governance, process and third parties
| Audit class | What it covers | What to ask a bidder to prove |
|---|---|---|
| Compliance audits and policy review | Evaluation of security practices against relevant standards, regulations and policies, with CERT-In’s own guidelines and directions in scope by default. Review of IT security policy against best practice, with the auditor expected to suggest the improvements. | Ask which standards will be named in the report. The 2025 guidelines name ISO/IEC standards, CERT-In’s Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM3, the OWASP Web Security Testing Guide, ASVS, MSTG and the DevSecOps Maturity Model, plus applicable regulatory frameworks — and are explicit that a top-ten list is not one of them. |
| Vendor and supply chain risk audits | Assessment of third-party and vendor cyber security practices to identify supply chain risk. Third-party, vendor and supply chain risk assessment is named as something that should be part of the audit scope, not an optional extra. | Ask where your scope boundary sits against a hosted or managed component. Where a website runs on a server owned by another organisation, responsibility for auditing that server, its operating system, the hosting software and the backend database software lies with the organisation that owns and operates it — while you remain responsible for having the website data and software audited. |
| Risk assessments and operational audits | Identifying and evaluating risks from cyber threats, vulnerabilities and potential attacks affecting operations, assets, individuals and connected entities. Evaluating security operations, processes and controls for efficiency, effectiveness and alignment with security objectives. | Ask who accepts the risk. Risk treatment — retain, avoid, transfer or reduce — must be authorised and accepted by the head of the auditee organisation, and exceptions authorised by the head of the organisation who owns the application. That is your signature, not the auditor’s. |
Two constraints run across every row. Solely tools-based testing is discouraged, a separate verification team is expected to review and validate the audit team’s work, and flood or Distributed Denial of Service testing over the Internet needs explicit written permission rather than being assumed into a network scope. And the standards the work is measured against are named: ISO/IEC standards, CERT-In’s own Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix, OSSTMM3, the OWASP Web Security Testing Guide, ASVS, MSTG and the DevSecOps Maturity Model, plus applicable regulatory frameworks. The 2025 guidelines add a sentence worth quoting in a scope of work: limited lists such as OWASP Top 10, SANS Top 25 and similar should not be considered as standards or references for audits. A proposal whose entire methodology section is a top-ten list has answered a different question from the one CERT-In asks.
Several of these rows deserve pages of their own — CERT-In VAPT, cloud security testing and AI red teaming in particular — and this table is the parent of that cluster until they exist. Where an engagement of yours sits in more than one row, say so in the scope of work rather than letting the auditor infer it: the 2025 guidelines require scope to be derived from a consolidated and updated asset inventory and vetted by the internal audit team in consultation with the CISO, which is a standard your own scoping document has to meet before the auditor’s does.
Where the national agenda is heading, and what it already touches
CERT-In SAMVAAD 2026 — the three-day national annual conference held from 27 to 29 April 2026 at the BITS Pilani K. K. Birla Goa Campus, on the theme “Securing Digital Bharat through Future-Ready Audits: Adapting, Assuring, Advancing” — carried over 87 presentations selected from more than 200 submissions. The figures, the dates and the topic list below come from the Government of India’s own account, Press Information Bureau release ID 2256581 of 29 April 2026. A conference programme is not a binding instrument, so the right-hand column maps each theme onto the rule or audit class that already applies today.
| Domain | Presented at SAMVAAD 2026 | Where it touches an empanelled audit today |
|---|---|---|
| AI-driven red teaming, and frontier AI models | AI-driven red teaming methodologies, and AI-driven cyber risks including emerging frontier AI models with advanced cyber capabilities. | AI System Audits are already a named class of engagement in the 2025 audit policy guidelines, and an incident affecting AI and machine learning systems is already mandatorily reportable under item (xx) of Annexure I to the 2022 Directions. |
| Cloud, APIs and operational technology | Auditing cloud systems, APIs and operational technology. | All three are existing audit categories: cloud security testing with the CSA Cloud Controls Matrix named as the reference framework, application security testing covering APIs alongside web and mobile, and ICS and OT security testing. |
| The bill-of-materials family | Implementation of SBOM, CBOM, QBOM and HBOM — the set named in the conference account. | The audit category named in the 2025 guidelines is SBOM, QBOM and AIBOM auditing. The two lists are not the same set and come from different documents, so cite whichever matches the instrument you are relying on. |
| Automated audit tooling | Emerging tools for automated audits. | Runs directly into the standing rule that solely tools-based testing should be discouraged — and into the 2025 guidelines’ sharper point that limited lists such as OWASP Top 10 and SANS Top 25 should not be treated as standards or references for an audit. |
| Supply chain | Supply chain audits. | Third-party, vendor and supply chain risk assessment is named as part of audit scope in the 2025 guidelines, alongside vendor risk management audits as a category in their own right. |
| IoT, blockchain, quantum and space assets | IoT, blockchain, quantum communication and post-quantum cryptography, and the cyber security of space assets such as UAVs and satellites. | IoT and IIoT security testing and blockchain security audit are existing categories. Quantum and space are the forward edge — present in the national conversation, not yet a named audit category, and worth reading as direction rather than as a requirement. |
AMBAK — Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions — was launched at the same conference, and it is best understood as the visible end of a pipeline this page has already described. Every empanelled audit sends its report and metadata to CERT-In within five days, in a prescribed format, for capacity building, the audit framework, benchmarking and quality control. Every organisation files quarterly returns on audits, sectors and high-level findings, and CERT-In reserves the right to look at any project or join any audit team. AMBAK is what monitoring, benchmarking and analysis of that material is called. What the official release confirms is the name, the expansion and the launch. The operational detail is still being published, and the sensible posture for a buyer is to follow CERT-In’s own announcements rather than the dates and features circulating on vendor pages. We cover what is confirmed, and what merely circulates, on the AMBAK page. The direction it points — audit quality monitored and benchmarked rather than assumed — is the direction the metadata obligation was always pointing.
How a CERT-In empanelled engagement actually runs, in twelve stages
Order matters, because the guidelines put several things before commencement that teams routinely leave until the end: the deliverable structure, the team composition, the written approvals, and the explanation that closes the expectation gap. An engagement that starts in the right order rarely produces an argument in month three. Read the last two columns as the procurement artefact set — if a stage produces nothing signed, it did not happen.
| Stage | What must be agreed before it starts | The artefact it produces | Who signs it off |
|---|---|---|---|
| 01 Settle scope and eligibility together | What has to be tested, and whether the deliverable actually needs an empanelled signature at all. Most security testing does not. | One line naming the document the deliverable must satisfy, and who has to sign it. | Whoever inside your organisation will have to defend the procurement. |
| 02 Verify the entity, the period and the snapshot | Entity name matched on CERT-In’s published list, empanelment period obtained in writing and checked against the planned signature date, snapshot read for sector, categories and tooling. | A procurement-file note: entity, source, date checked, period claimed, screenshot. | Procurement. A file that cannot show the check is a file that gets questioned later. |
| 03 Agree the deliverable structure | Report format, the evidence that accompanies observations, the severity model — CVSS supplemented by EPSS, every observation mapped to a CWE and a CVE — and closure timelines by severity. | The deliverable structure as a contract schedule, plus a redacted specimen report. | Both parties, before commencement. The guidelines put it here so it is not argued about around a draft. |
| 04 Approve the team in writing | Team composition shared and documented approval obtained before formal commencement, every person drawn from declared manpower. You may interview the resources and verify credentials, identity, ID cards and designations. | A named-team schedule with roles, and a substitution clause requiring notice and consent. | You. Verifying who is fielded is expressly the auditee’s job. |
| 05 Sign the NDA and set the data rules | A legally enforceable NDA before commencement — CERT-In publishes a model NDA that may be customised. Then: where data lives, no mirroring outside India, encryption on auditor devices, retention, disposal. | The executed NDA, a data-handling annexe, and a dated destruction commitment. | Legal, both sides. Silent on retention means the auditor keeps it a year from completion. |
| 06 Write the rules of engagement | Windows, approved targets, exclusions, the escalation matrix, and the trigger that turns a suspected live compromise into an incident call. Written approval before testing and before any tool is installed — and explicit written permission if DoS, flood or social-engineering testing is genuinely in scope. | A rules-of-engagement schedule, a tool list with licence confirmations, the approval record. | The system owner, not the project manager. |
| 07 Hold the onboarding presentation | The auditor presents scope, methodology and timelines to your board or senior management — and discloses that the report and metadata go to CERT-In within five days. | The onboarding pack, and a written record of that disclosure. | Senior management, whose acceptance of scope makes a later coverage argument resolvable. |
| 08 Stand up the environment the certificate will name | Where a certificate is to be issued, the auditor tests on the staging environment provided by the hosting service provider first. It has to exist, mirror production, and be reachable on the agreed dates. | A reachable staging environment, plus hash value, hash algorithm and version recorded at handover. | Engineering. Get the algorithm and the value together — published specimens differ on whether the algorithm is even named. |
| 09 Run the audit, then run the verification | Manual testing against industry-standard methodology, with a separate verification team validating the audit team’s work. Critical and high findings notified as and when found, not held for the draft. | Working notes, evidence captured as the work happens, interim critical notifications. | The verification team. Provision for the working notes belongs in the contract. |
| 10 Close the findings, then retest | Closure timelines by severity. Remediation by you, since patching is expressly the auditee’s responsibility. A follow-up audit whose scope was in the original scope of work. | A retest report, with previous-cycle observations revalidated and anything unresolved recorded as a repeat. | Your risk owner — who should know that criticals still open after follow-up go to CERT-In with your name on them. |
| 11 Issue the final report and the certificate | Issued after closure of vulnerabilities and completion of the follow-up audit on production. If the scope stopped at staging, the report must say so explicitly. | Three signatures on the report, two on the certificate, every name traceable to declared manpower. | The auditors, an independent reviewer and the head of the organisation. Lead auditor and head on the certificate. |
| 12 Close the engagement properly | Tools removed with your acceptance, licences on file, data wiped beyond forensic recovery, and an exit conference presenting findings, posture and risk. | A removal sign-off, a formal certificate of deletion, the exit-conference record, and the CERT-In submission date. | You, on removal and destruction. The five-day submission happens whether or not anyone mentions it again. |
The guidelines describe the third and fourth stages as the mechanism for reducing or eliminating the expectation gap — explaining the audit process, the collection of artifacts and the deliverables in detail upfront. That phrase is worth borrowing into your own kick-off agenda. Most disputes about an audit are not disagreements about a vulnerability. They are disagreements about what was going to be delivered, by whom, in what form, and against what definition of done. For the certificate route specifically, the full sequence is set out in how to get a safe-to-host certificate, and the reasons applications fail it in why applications fail safe-to-host.
Clauses that turn obligations into something you can enforce
The auditor’s duties to CERT-In are not owed to you, and you cannot enforce them. What you can do is write the same substance into your own agreement, so that the obligations become contractual promises with consequences. Ten clauses cover the ground.
| Clause | Why it exists | Drafting note |
|---|---|---|
| Empanelment representation and continuity | Empanelment is granted for a period and can lapse or be withdrawn. The value to you crystallises on the date of signature, not the date of award. | Require a representation naming the empanelled legal entity and the period, plus a duty to notify you in writing within a stated number of days of any lapse, suspension or withdrawal, with a defined remedy. |
| Named team and substitution control | The organisation must deploy only manpower declared to CERT-In in the snapshot information form, the team composition is approved before formal commencement, and the auditee is expected to verify that freelancers, interns, freshers, moonlighters, third-party consultants and employees serving notice are not fielded. | List the named auditors and roles as a schedule. Require written notice and your consent for substitutions, and a confirmation that any replacement is declared manpower and has completed background verification. |
| Scope, environment and rules of engagement | Written approvals are required before penetration tests and tool installation. Flood and Distributed Denial of Service testing are out unless permitted in writing. High-risk exploitation is restricted. | Attach the rules of engagement as a schedule: targets, windows, exclusions, escalation contacts, and the trigger that converts a suspected live compromise into an incident-response call rather than a finding. |
| Data location, protection and disposal | No mirroring of data outside the country. Auditee data stored on systems located in India and encrypted on auditor laptops, and wiped after completion. No sharing with an overseas partner without the auditee’s specific authorisation. | State the permitted locations and processing entities by name, require encryption, and set a disposal deadline with a written confirmation of destruction. Make any overseas involvement a matter of prior written consent. |
| Reporting obligations to CERT-In | The audit report and audit metadata are shared with CERT-In within 5 days of completion, and critical vulnerabilities raised but left unfixed after follow-up are reported within the same window with the auditee’s details. Quarterly returns separately cover audit numbers, sectors and high-level findings. | Acknowledge the obligation expressly so the confidentiality clause does not contradict it, agree what the auditor tells you about what was submitted and when, and make the retest and closure window explicit — that is the lever that decides what travels with your name on it. |
| Deliverables and evidence standard | Observations must be supported by objective evidence compiled with the report, and the report should state closure timelines by severity. The deliverable structure is agreed before commencement. | Specify the report structure, the evidence standard, the severity model and its timelines, the retest scope, and the form of the certificate — including exactly what it will name. |
| CERT-In is not a party | The auditor must ensure that CERT-In is not made a part of any contract between auditee and auditor. | Reference empanelment as a representation about the auditor’s status only. Do not name CERT-In as a party, guarantor, escalation route or dispute forum anywhere in the agreement. |
| Independence between remediation and attestation | A CERT-In rule, not merely a structural preference. The 2025 audit policy guidelines define conflict of interest to cover the same entity implementing controls and auditing them, or auditing while responsible for remediation, and make Independence and Objectivity binding principles for empanelled auditing organisations. | Where one supplier runs remediation and an empanelled organisation audits and signs, set out in the agreement which activities sit with which party, and require disclosure of any overlap. Then check the payment schedule: fees are to be based on predefined scopes, deliverables and timelines, and not contingent on the outcome or tied to approval of a closure report. |
| Signature chain and declared manpower | Audit reports are to be signed only by manpower declared to CERT-In: by the auditors who conducted the audit, then a designated reviewer outside the audit team from mid-management, then the head of the auditing organisation. The certificate carries the lead auditor and the head. | Specify the signature block the deliverable must carry, and require that every signatory appears in the organisation’s declared manpower on the date of signature. It converts an assumption into an acceptance criterion you can refuse a deliverable against. |
| Notice when CERT-In exercises its right | CERT-In may seek information on any project in the empanelment period or join the audit team, and the auditing organisation must communicate the exercise of that right to the auditee clearly and in writing. | Name the person inside your organisation who receives that notice, and the timeframe. This is a right you hold, and it is easier to exercise if somebody is already named to receive it. |
Illustrative wording
Eligibility representation
The Auditor represents that [full legal entity name] is an information security auditing organisation empanelled by CERT-In, and that its empanelment is current and will remain current on the date each report and certificate under this Agreement is signed and issued. The Auditor shall notify the Client in writing within three working days of any lapse, suspension or withdrawal of that empanelment.
Named team
The audit shall be performed by the personnel named in Schedule 2. The Auditor confirms that each named person forms part of the manpower declared by it to CERT-In. No substitution shall be made without the Client’s prior written consent, and the Auditor shall confirm in respect of any replacement that background verification is complete and that the person is declared manpower.
Data location and disposal
All Client data collected or generated in the course of the audit shall be stored and processed only on systems located in India, shall be encrypted at rest on Auditor devices, and shall not be mirrored, replicated or otherwise transferred outside India. No such data shall be shared with any partner or affiliate outside India without the Client’s specific prior written authorisation. The Auditor shall securely destroy all such data within thirty days of issue of the final report and shall confirm the destruction in writing.
Acknowledged reporting to CERT-In
The Client acknowledges that the Auditor is required to share the audit report and audit metadata with CERT-In within five days of completion of the audit, and to include the engagement in its periodic returns to CERT-In. Nothing in the confidentiality provisions of this Agreement restricts that submission. The Auditor shall inform the Client of the date on which the submission was made.
Illustrative only, and not legal advice. Wording has to be fitted to the agreement it sits in and reviewed by your own counsel — and CERT-In must not be made a party to the contract between auditee and auditor.
Ten ways a CERT-In audit goes wrong, all of them preventable
None of these involves a dishonest auditor. Each is an ordinary gap between what a buyer assumed and what the engagement was actually set up to deliver, and each is closed by a question asked before award rather than after.
The proposal team and the delivery team are different people
Two senior names win the work. Two juniors run the test. This is not only a service-quality complaint: the 2025 guidelines require the organisation to deploy only manpower declared to CERT-In, without limiting the rule to public-sector work, and they add a disqualifying list — no freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice, with the auditee expected to verify compliance. Fix it at contract stage: named auditors, written notice of substitution, and the right to refuse a substitution that lowers the seniority of the team.
The empanelment lapsed between award and signature
Empanelment runs for a period. Long projects — a phased rollout, a delayed UAT, a remediation cycle that slips two quarters — can cross an expiry, and the document you need is the one signed at the end. Check the period against the signature date, not the award date, and put a notification duty on the auditor.
The entity on the contract is not the entity that is empanelled
A group trades under one brand and contracts through several entities. The proposal arrives on the brand’s letterhead, the contract names an entity nobody checked, and the certificate arrives from a third. Verify the entity name character by character, and make the empanelled entity a party to the agreement that produces the signature.
The audit is a scanner run with a cover page
Findings that are all CVE identifiers and default severities, no business-logic issues, no authorisation testing across roles, no chained finding. The guidelines discourage solely tools-based testing and expect a verification team to review the audit team’s work. Ask for one finding no scanner could have produced. The answer separates firms quickly.
There was never a staging environment
Where an audit certificate is to be issued, the auditor is required to test on the staging or testing environment provided by the hosting service provider before issuing it. Projects that skip building one end up either testing in production or delaying the certificate. Stand the environment up in the plan, not in the week the audit starts.
Nobody told legal about the 5-day submission — or about its second half
The report and its metadata are shared with CERT-In within 5 days of completion of the audit, and the auditor is supposed to have told you that before the assignment started. The half that surprises people is the other limb of the same clause: critical vulnerabilities the auditor raised and you did not fix, even after follow-up, go to CERT-In with your organisation’s details attached inside the same five days. Discovered late, the whole thing reads as a breach of confidence. Disclosed early, it is a known obligation the NDA is drafted around and the retest is scheduled against.
Delivery quietly involves an entity outside India
An offshore testing team, an overseas-hosted ticketing tenant, a report drafted in another jurisdiction. The auditor is required to ensure there is no mirroring of data outside the country, to keep auditee data on systems located in India, and not to share it with an overseas partner unless specifically authorised by the auditee. Ask where the data actually goes before the first scan runs.
The same party tests, fixes and attests
This is a named conflict of interest, not a matter of taste: the 2025 audit policy guidelines define conflict of interest to include auditing while responsible for remediation, and make Independence and Objectivity binding principles. The same principle catches the payment schedule — fees are not to be contingent on the outcome or tied to approval of a closure report. Separate the roles deliberately, disclose the split in the bid, and read your own milestone names before you sign them.
The certificate names a build that no longer exists
Code ships between the retest and the go-live. A certificate is tied to what was tested — a scope, an environment, a version, a hash. The 2025 guidelines close it from the other side: a developer should avoid making code changes to the audited application after issue of the certificate, and every major change must undergo a cyber security audit before implementation. Freeze the build for the certificate, or plan the re-audit into the release calendar.
The vendor’s own marketing breaks the claims rule
The CERT-In logo on the homepage, “CERT-In approved” in the footer, an auditor described as personally empanelled. None of it is permitted, all of it is visible before you speak to anyone.
The five arguments that come up every time
These surface in procurement meetings, in legal review, and in the conversation where a department explains to a vendor why its bid does not answer the clause. In each case the answer that works describes the mechanism rather than defending a position.
“Our auditor says the report goes to CERT-In. Is that a confidentiality breach?”
No, and the empanelment terms are explicit that it overrides your consent: an empanelled auditing organisation should not share a client’s data without the auditee’s written permission, but it shall provide the audit reports and data to CERT-In without it. The obligation runs within 5 days of completion, in the format CERT-In prescribes, and the auditor was supposed to tell you before the assignment started. The part worth raising with your own risk owner is the second limb of the same clause: critical vulnerabilities the auditor raised and you did not fix, even after follow-up audits, are reported to CERT-In with your organisation’s details. So the useful conversation is not about whether to permit the submission. It is about the retest window, the closure timelines, and who inside your organisation owns the decision to leave a critical finding open.
“Their website says CERT-In approved, but the panel list matches. Does the wording matter?”
Yes, and the mismatch is the finding. The guidelines permit one sentence — “This Organization is empanelled by CERT-In for providing information Security Auditing Service” — and state that no other words may be used to describe the auditor’s relationship with CERT-In without prior written permission, nor the CERT-In logo used on publicity or promotional material or a product. An organisation that is genuinely empanelled and still writes “approved” has decided a rule about its own status is optional. That is a reasonable thing to weigh when the deliverable you are buying is the firm’s judgement about rules.
“Why can’t our regular testing vendor issue the certificate?”
Because eligibility attaches to the issuer, not to the quality of the testing. A vendor that knows your systems intimately may well produce better findings than an unfamiliar empanelled firm — but where the requirement names an empanelled organisation, only such an organisation can sign. The workable arrangement is to keep continuity of testing and remediation with the team that knows the estate, and bring the empanelled organisation in to audit and sign, with the split disclosed up front rather than discovered at certificate stage.
“Empanelment means CERT-In has vetted the people on our engagement, doesn’t it?”
Not directly, and the gap is where your own work sits. The vetting duty is on the organisation: a background check before employment, a NOC or relieving letter where a person moves from another empanelled organisation with revised snapshot information communicated to CERT-In, an NDA at joining, and competency in security technology, processes, controls, trends, fact collection and reporting. What CERT-In holds is the declared manpower in the snapshot information form, which it publishes and which reports may be signed only by — and it reserves the right to seek information on any project in the empanelment period, or to join the audit team. Your part is explicit in the 2025 guidelines: you may interview and select the resources put forward, verify their technical credentials, and verify identity, official identity cards and designations, and you are expected to verify that the organisation is not fielding freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice. Ask for the names, then check them against the published declaration.
“The tender says CERT-In empanelled auditor. Does an ISO 27001 certificate cover it?”
No. They answer different questions and neither substitutes for the other. An ISO/IEC 27001 certificate concerns a management system certified by an accredited certification body, while empanelment concerns eligibility to perform information security audits and sign the resulting report. A tender clause naming an empanelled auditor is asking who may sign, and only the empanelment answers it. Where both appear in the same tender, treat them as separate line items with separate evidence.
Where this gets contested
The rules above settle most questions. These are the ones that generate arguments — between buyer and auditor, and inside the buyer’s own organisation between the team that wants the project live and the team that has to sign for it.
The auditor is suspended or de-empanelled mid-engagement
Empanelment is granted for a period, and CERT-In publishes a graded ladder of consequences that can interrupt it: a watch list with a show-cause and a written commitment, suspension revoked only on satisfactory corrective action, withdrawal with debarment under the General Financial Rules, and penal and legal action. Suspension is the grade your contract has to contemplate, because it lands mid-engagement and is not public knowledge the day it happens. If the status ends before the report is signed, the signature you were buying is no longer available, and a certificate signed after it lapsed does not become valid because the fieldwork happened earlier — the terms require a terminated auditor to stop claiming the status at all. This is why the notification duty and remedy belong in the contract: who tells you, within how many days, whether the work product transfers, and how a replacement signature is procured without re-running the whole audit.
A key auditor joins from a rival empanelled firm mid-engagement
Movement between empanelled organisations is contemplated but controlled: the background check includes a NOC or relieving letter from the previous organisation. For you, the practical points are whether the person is now declared manpower, and whether their prior engagements create any conflict with yours. Both are fair questions to put in writing before they are added to the team.
Your scope spans India and an overseas estate
The data rules bind the auditor: no mirroring outside the country, auditee data on systems located in India, and no sharing with an overseas partner unless you specifically authorise it. A multinational scope therefore needs a delivery design, not an assumption — which entity tests what, where evidence is stored, and what you are authorising in writing. Decide it in scoping, because retrofitting it after the first week of testing is expensive.
The application changes after the certificate is issued
A certificate speaks to what was tested: a scope, an environment, a build, a hash, a date. Published specimen certificates state a validity condition in their own words — one reads on the hash value and dynamic content or one year from issue, whichever is earlier, while another states a one-year maximum and adds that the opinion holds only while the source of the tested application is unchanged. The wording is set by the issuing body, so read the one you are being given. The independent anchor is CERT-In’s own cadence rule: an audit at least once a year, and an audit of every major change before implementation — where “major” is defined by risk rather than size, expressly including configuration adjustments that affect sensitive data or critical infrastructure. Plan the release calendar around that rather than discovering at go-live that the certificate no longer describes the system.
You want the auditor to fix what they found
Start from the actual position rather than from convenience. CERT-In’s audit policy guidelines define conflict of interest to cover the same entity implementing controls and auditing them, or auditing while responsible for remediation, and list Independence and Objectivity among the principles binding on empanelled auditing organisations. So combining the roles is not a neutral commercial choice: it has to be disclosed, and where a certificate is the deliverable the roles need to be separated rather than merely documented. The workable shape is the one many buyers land on anyway — continuity of testing and remediation with the team that knows the estate, and an empanelled organisation brought in to audit and sign. Whatever the arrangement, it belongs in the bid rather than in a conversation at certificate stage, and the payment schedule has to match: fees based on predefined scope, deliverables and timelines, and never contingent on a clean outcome.
The requirement is a regulator’s, not a department’s
Sectoral regulators write their own audit requirements, and they do not all point to the same instrument or the same issuer. Read the actual clause: some name an empanelled auditor, some name a category of audit, some name neither and simply require an independent assessment. Matching the deliverable to the clause that demands it is the whole job — buying an empanelled signature the regulator never asked for is as much a scoping failure as missing one it did.
A single habit prevents most of these: write down, before award, which document the deliverable has to satisfy and who has to sign it. Everything else — entity checks, period checks, team confirmations, data rules, retest scope — follows from that one sentence, and projects that cannot produce it are the projects that discover a problem at go-live. The distinction between the two documents an engagement can produce is worked through in safe-to-host versus a security audit certificate, and the rules the auditor works under in an empanelled auditor’s rules of engagement.
The auditor’s status and your own obligations
A surprising number of conversations conflate the two. Hiring an empanelled auditor does not by itself discharge the duties CERT-In places on you directly, and discharging those duties perfectly does not produce the signature a tender asks for. They are separate obligations with separate instruments — and, as the third block below sets out, they meet inside the audit itself in a way that catches departments out.
What sits on the auditor
Empanelment and everything that follows from it: deploying only manpower declared to CERT-In, background checks and the NOC on movement between empanelled organisations, testing discipline and the verification team, written approvals and tool control, independence from the remediation it audits, data kept in India and destroyed afterwards, observations evidenced and closure timelines stated, a report signed through three hands and a certificate through two, the audit report and metadata shared with CERT-In within 5 days of completion along with any critical vulnerability left unfixed after follow-up, quarterly returns, and the single permitted sentence about the CERT-In relationship. These are conditions of the auditor’s status. You benefit from them, but they are not yours to discharge.
What sits on you
The CERT-In Directions issued on 28 April 2022 under sub-section (6) of section 70B of the Information Technology Act, 2000 — effective 60 days after issue — apply to service providers, intermediaries, data centres, body corporate and Government organisations, and they are addressed to you rather than to your auditor. They require synchronisation of ICT system clocks to the NTP server of NIC or NPL, or to servers traceable to them. They require mandatory reporting of the cyber incidents listed in Annexure I to CERT-In within 6 hours of noticing them or being made aware of them. They require a designated point of contact kept current, with CERT-In able to order information up to and including near real-time. They require logs of all ICT systems enabled and maintained securely for a rolling period of 180 days, within Indian jurisdiction. And, for data centres, virtual private server providers, cloud service providers and VPN service providers, they require registration and retention of specified subscriber records for five years or longer as mandated by law, after any cancellation or withdrawal of registration. Virtual asset service providers, virtual asset exchange providers and custodian wallet providers carry an additional five-year KYC and transaction-record duty. Non-compliance may invite punitive action under sub-section (7) of section 70B of the IT Act, 2000 and other laws as applicable.
The overlap worth knowing is the incident list. Annexure I runs to twenty mandatorily reportable classes, and it is broader than most teams assume — it reaches targeted scanning or probing of critical networks, website defacement, attacks on servers and network devices, identity theft, spoofing and phishing, denial-of-service attacks, data breach and data leak, attacks on IoT devices, digital payment systems, malicious and fake mobile applications, unauthorised access to social media accounts, attacks affecting cloud computing systems, and attacks or malicious activity affecting systems related to Big Data, blockchain, virtual assets, robotics, drones, and Artificial Intelligence and Machine Learning. An organisation running AI systems is already inside a mandatory reporting regime, which is a useful thing to know before commissioning the testing rather than after an incident. The Directions are worked through in full on the CERT-In Directions page, and the agency itself on what CERT-In is.
Where the two meet
Here is the part that surprises buyers, and the reason the two columns above cannot simply be managed in separate workstreams. Under the 2025 audit policy guidelines, an auditing organisation must include verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with the findings and the supporting evidence included in the audit report — working from CERT-In’s published method-of-verification document. The obligations in the right-hand column are therefore tested by default, whether or not you put them in scope and whether or not anyone mentioned them at kick-off.
In practice that means your clock source, your 180 days of logs and their jurisdiction, your designated point of contact and your six-hour reporting process will appear as findings in the report you commissioned for something else. Two consequences follow. A buyer who cites the separation of duties to argue that the Directions were out of scope is wrong, and will lose that argument in front of whoever has to accept the report. And — the genuinely useful advice — map and remediate those duties before the audit window rather than discovering them as findings in it. A Directions finding is the one most likely to delay a certificate, because it is rarely an application fix: an unmonitored contact mailbox, an observability platform that ships logs abroad, or a clock synchronised to a public pool rather than to NIC or NPL are architecture and process problems, and none of them closes inside a retest window.
Why the distinction pays
Because the two produce different work plans. The auditor’s status is procured — you verify it, contract for it, and receive a signature. Your obligations are engineered: clock synchronisation, log retention with an Indian jurisdiction constraint, a monitored contact point, an incident process that can actually make a six-hour report with facts in it, and the retention duties that fall on you if you are a data centre, cloud, VPS or VPN provider. A department that buys the audit and never builds the second half has a certificate, an unmet duty, and a set of findings in its own report saying so. The practical sequence is to map your own obligations first, then commission the testing that evidences the controls behind them.
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.
If you are running the comparison this page describes across a shortlist, the questions that separate bidders fastest are narrow ones. Who signs, and is that entity empanelled on the date they will sign. Are the individual signatories in the declared manpower. Does the published snapshot show work in your sector and tooling for your estate. Everything after that is method, and method is evaluated on evidence. Our penetration testing and VAPT services set out how we work.
Frequently Asked Questions
What does CERT-In empanelment mean?
How do I get CERT-In empanelment for my company?
How long does CERT-In empanelment last, and how does renewal work?
Why does CERT-In suspend or withdraw empanelment?
How many CERT-In empanelled auditors are there, and where is the list?
Is CERT-In empanelment a certification?
What is a CERT-In empanelled auditor allowed to say, and can it use the CERT-In logo?
Can a CA firm or an ISO 27001 certification body perform a CERT-In audit?
What does a CERT-In empanelled audit cost compared with ordinary VAPT?
How do I verify that a firm is CERT-In empanelled?
Does hiring an empanelled auditor make my organisation CERT-In compliant?
What exactly goes to CERT-In after our audit, and when?
Can CERT-In take part in the audit of my systems?
Is empanelment granted to individual auditors?
Can a non-empanelled firm do the testing?
Does empanelment cover VAPT, cloud security and AI red teaming?
What is AMBAK and does it change empanelment?
Our auditor has been suspended mid-engagement. What do we do now?
How should we describe the audit on our own compliance page?
Related Reading
What Is CERT-In?
The national agency under section 70B of the IT Act — what it does, and what empanelment actually means.
Read moreWho Can Issue Safe-to-Host Certificates
NIC, STQC, an STQC empanelled laboratory, or a CERT-In empanelled laboratory — and how to check before award.
Read moreRules of Engagement for an Empanelled Auditor
What the auditor must do, must not do, and needs your written permission for.
Read moreHow to Verify a CERT-In Audit Certificate
Check the issuer, the signatures, the environment and the hash — before you accept the document.
Read moreWhat a Safe-to-Host Certificate Is
The audit clearance certificate GIGW 5.3.1 requires before a government application is hosted in production.
Read moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read more