What CERT-In Is, and What It Actually Does.

CERT-In is the Indian Computer Emergency Response Team — the agency the Central Government appointed under section 70B of the Information Technology Act, 2000 to serve as India's national agency for cyber security incidents. It collects and analyses incident information, issues alerts and advisories, coordinates response, publishes guidelines, empanels the organisations that perform information security audits in India, and issues directions that are binding on the entities it names.

The distinction the whole hub turns on: CERT-In empanels auditors. It does not certify auditees. There is no CERT-In certificate issued to your company, no CERT-In accreditation of a business, and no register of CERT-In-certified organisations — there is a list of empanelled auditing organisations, and the report is signed by one of them.

CERT-In — the Indian Computer Emergency Response Team — is the agency of the Government of India appointed under sub-section (1) of section 70B of the Information Technology Act, 2000, by a notification dated 27 October 2009, to serve as the national agency for cyber security. It functions under the administrative control of the Ministry of Electronics and Information Technology, and it is headed by a Director General — section 70B(2) requires the Central Government to provide the agency with one. On its own website CERT-In describes itself as “the national nodal agency for responding to computer security incidents as and when they occur”, and states that it “is operational since January 2004”. It publishes its own description of itself in the standard CSIRT format — RFC 2350, version 1.0 of 17 March 2022 — and that document states the constituency plainly: the Indian cyber community and Indian cyberspace, with services to organisations in the Government, public and private sectors, and to individuals and home users as well. In that document CERT-In puts its authority in one sentence: “CERT-In is designated as the National Nodal Agency for Incident Response under Section 70(B) of the Indian Information Technology Act 2000.”

CERT-In is short for the Indian Computer Emergency Response Team. The acronym reads oddly because it is not built from the words in order: it is CERT — Computer Emergency Response Team, the international name for this class of body, used by national teams worldwide — with “In” for India appended. CERT-In and ICERT are both used for the same agency. CERT-In’s own 2025 audit policy guidelines note that the agency appointed by the 2009 notification “is now referred as CERT-In or ICERT”, and CERT-In is the form used throughout the Directions, the guidelines and the email addresses. The Act itself uses the full name, not the acronym.

Both dates you will see are right, and they answer different questions. CERT-In has been operational since January 2004 — that is CERT-In’s own wording on cert-in.org.in, and it is the date the national CSIRT began work, before there was a section of the Act to put it in. Its statutory footing dates from 27 October 2009: section 70B was inserted into the Information Technology Act, 2000 by the Information Technology (Amendment) Act, 2008, which the published Act records as coming into force with effect from 27 October 2009, and CERT-In’s own instruments describe the agency as appointed under sub-section (1) “vide notification dated 27th October 2009 published in the official Gazette”. So: operating from 2004, statutory from 2009. A source that gives you only one of those is not wrong, it is answering half the question — and the half that matters for compliance is the 2009 one, because obligations run from the statute rather than from the help desk.

What it does is set out in sub-section (4) of section 70B, in six clauses: collection, analysis and dissemination of information on cyber incidents; forecast and alerts of cyber security incidents; emergency measures for handling cyber security incidents; coordination of cyber incidents response activities; issue guidelines, advisories, vulnerability notes and whitepapers relating to information security practices, procedures, prevention, response and reporting of cyber incidents; and such other functions relating to cyber security as may be prescribed. Sub-section (6) then gives it the power to call for information and give directions to service providers, intermediaries, data centres, body corporate and any other person, in order to carry out those activities — and sub-section (7) attaches punitive consequences to failure. That chain, from (1) through (4) to (6) and (7), is the whole legal architecture, and almost every practical question about CERT-In resolves by asking which link in it you are standing on.

The part that generates the most confusion is the audit ecosystem, and it is worth stating the mechanism before the detail. Sub-section (5) says the manner of performing CERT-In’s functions shall be as prescribed, and the Rules made under it — the Information Technology (The Indian Computer Emergency Response Team and Manner of performing functions and duties) Rules, 2013, notified on 16 January 2014 — prescribe information security assurance and audit to CERT-In at rule 9. That is the origin of the empanelment scheme: CERT-In assesses and lists information security auditing organisations, those organisations perform audits under commercial contracts with auditees, and CERT-In sets the rules those organisations must follow and the consequences when they do not. CERT-In is the referee and the rule-maker. It is not the auditor, and it is not a certification body.

One date is deliberately not in that table because it is not a recurring clock: when the 2022 Directions started to bite. They became effective 60 days after 28 April 2022 generally, on 25 September 2022 for MSMEs, and on 25 September 2022 for the validation limb of direction (v)(a) and (v)(f), for all four provider classes. The second and third of those come from a separate extension order of 27 June 2022, which is linked from CERT-In’s own Directions page and is missing from almost every summary of the Directions in circulation.

Read the list again with a specific question in mind: where is certification? It is not there. Nothing in sub-section (4) empowers CERT-In to certify an organisation, and CERT-In does not do it. What clause (f) permits is extension by Rules, and the extension that was actually made — rule 9 of the 2013 Rules — is information security assurance and audit. That is the empanelment of auditors, which is a different thing from the certification of auditees, and the difference is the single most consequential misunderstanding in the Indian market. See CERT-In empanelment explained for how the scheme works, and who can issue safe-to-host certificates for where the signing authority actually sits.

Mixing these up costs time in the hour you can least afford it. An incident report sent to the information desk is not a filing under direction (ii), and a vulnerability disclosure sent to the incident help desk lands in a 24x7 queue built for something else.

This question is going to get more common, not less, now that AMBAK is being invoked in vendor pitches and a CERT-In letterhead carries weight in a procurement conversation. CERT-In gives you more to check against than most agencies do. Four checks, and three negatives.

And the negatives, which do most of the work. CERT-In issues no certificate to an auditee — an email offering you one is not from CERT-In. CERT-In charges no fee for a compliance status, because there is no status to charge for. The empanelment terms even instruct auditors to ensure CERT-In is not made or projected to be a part of any contract. And as at 18 September 2026, CERT-In has published no portal for auditees to register on — including under AMBAK, which neither official account of its launch describes as a registration or verification service. If a message asks you to register, pay or claim a certificate, those three sentences settle it. On certificates specifically, see how to verify a CERT-In audit certificate and CERT-In AMBAK.

Two of these deserve a note. The Comprehensive Cyber Security Audit Policy Guidelines, version 1.0 dated 25 July 2025, are the most significant change to the Indian audit landscape in years: a twenty-section document that sets out, in one place, what an audit is, what it must cover, who may perform it, how it is planned, how it is reported, and what happens to an auditing organisation that falls short. It states in its own authority section that it is binding on all CERT-In empanelled auditing organisations and on auditee entities covered under the relevant provisions. And the Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0 of May 2018 remain the source of the conduct rules that govern how an auditor behaves on your systems — and of the branding restriction that limits what any auditor may claim about its relationship with CERT-In. Both are read in detail in the rules of engagement for an empanelled auditor.

“All their ICT systems” is the demanding half, not the 180 days. CERT-In’s FAQ at Q37 gives an indicative list of what it has in mind — firewall logs, intrusion prevention system logs, SIEM logs, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, ATM switch logs, SSH logs, VPN logs — and says explicitly that the list is not exhaustive but is meant to give a flavour of what should be maintained. It adds the requirement most log pipelines get wrong: “From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded.” A pipeline tuned to drop failed authentication noise is a pipeline missing the events an investigation needs.

The direction says logs shall be maintained within the Indian jurisdiction. CERT-In’s FAQ then answers the obvious follow-up at Q35 — “Is it required to store copy of logs in India only?” — with: The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time. Q36 then narrows it back: any service provider offering services to users in the country needs to enable and maintain logs and records of financial transactions in Indian jurisdiction.

Read together, the defensible reading is: an India-resident copy, plus a demonstrated ability to produce logs quickly. Q38 names who can ask — the requisition for logs may be given by an officer of CERT-In not below the rank of Deputy Secretary to the Government of India — which tells you the request will be formal and will not wait. CERT-In has not published a numeric definition of “reasonable time”, and this page will not invent one.

Two questions the Directions do not answer, stated as open rather than resolved. Whether the 180 days runs per system or across the estate is not addressed. The text says “logs of all their ICT systems” and a rolling period, which reads naturally as per-system coverage for the full period. And nothing says what happens to logs older than 180 days — the direction sets a floor, not a ceiling, and your own retention schedule and data-protection obligations govern the rest. Where CERT-In has not published a position, say so in your own documentation rather than adopting a vendor’s.

One observation about direction (iii) that is worth carrying into your own preparation. The point of contact is the cheapest of the six obligations to satisfy and the one whose failure costs most during a live incident, and it is also the one that produces the least evidence: a filing is a sent email, and a sent email from three years ago proves only that somebody once did it. If you want it tested properly, put the artefacts in front of the auditor yourself — the filing, its date, the re-filing trigger, and a recent test message with a recorded response time.

The narrower obligations in directions (v) and (vi) are additive, not alternative — a cloud service provider that also operates a custodian wallet is subject to both. And the classes overlap by design: an MSP is a service provider and its customer is a body corporate, and both are inside the perimeter for the same incident. CERT-In’s own FAQ at Q7 gives the consolidated addressee list — service providers, intermediaries, data centres, body corporate, Virtual Private Server providers, Cloud service providers, VPN Service providers, virtual asset service providers, virtual asset exchange providers, custodian wallet providers and Government organisations — and ends with the line nobody quotes: “Individual citizens are not covered by these Directions.”

Two things run through the whole table and are worth stating on their own. The reporting obligation cannot be moved by contract. FAQ Q13 deals with the case where a consumer-facing business and its outsourcing partner are both affected, and answers that any entity which notices the incident shall report it, and that the obligation “is neither transferrable nor indemnified or dispense with”. And a confidentiality clause does not override it either — FAQ Q22 says the obligation is statutory in nature and overrides any confidentiality clause in any contract, by virtue of section 81 of the IT Act, under which the Act has effect notwithstanding anything inconsistent contained in any other law for the time being in force.

The cleanest way to hold all six in your head: CERT-In regulates the audit market. It does not participate in it. It decides who is competent to audit, publishes the rules those auditors must follow, collects the metadata afterwards, and penalises the ones who fall short. The audit itself is a commercial engagement between you and an empanelled organisation, and the signature on the report belongs to that organisation and its named people.

A CERT-In filing does not discharge the DPDP duty, and a DPDP intimation does not discharge the CERT-In one. They come from different statutes, are owed to different bodies, and are triggered by different facts. A ransomware event that touched no personal data is a CERT-In incident and not a personal data breach. A misconfigured bucket that exposed customer records with no attacker involvement is plainly a personal data breach under the DPDP Act’s definition, and is also a data leak under Annexure I item (xii). Most serious incidents are both, and the six-hour clock is the one that runs first. Build the decision into your incident process as two independent questions asked at the same moment, not as one question with two answers.

One caution about this table, in the spirit of the rest of the page. What each sectoral regulator requires is published by that regulator, and the version circulating in vendor summaries is frequently out of date. The only statement this page will make about sectoral regulators and CERT-In empanelment is the one the guidelines actually make, at section 12.1(i): the snapshot information CERT-In publishes should be used by organisations or sectoral regulators to identify and select auditing organisations. Anything stronger than that — a named regulator mandating a CERT-In empanelled auditor — should be read in that regulator’s own circular before it goes into a bid.

Empanelment is not a one-time gate. CERT-In requires each empanelled organisation to keep its snapshot information and point-of-contact details current, to deploy only manpower declared to CERT-In on that snapshot, to obtain a no-objection certificate or relieving letter when hiring from another empanelled organisation and to update the snapshot accordingly, and to share the audit report and audit metadata for every audit with CERT-In within five days of completion, in the format CERT-In prescribes from time to time. Section 11(ii) also reserves CERT-In’s right to seek or audit information from an auditing organisation about any project done within the empanelment period, and section 11(i) lets it join an audit team as a quality-assurance measure — the clause set out in full further up this page. Clause 8.1 of the empanelment terms and conditions adds the blunt version: continued empanelment status depends on the quality of auditing services rendered.

Not by asking for the letter. Empanelment runs for a period and can be suspended or withdrawn inside it under the graded framework below, and none of those events is announced to the market. Four steps, in order.

A PDF of the list forwarded by the vendor proves what was true on the day the vendor saved it. A letter proves what was true on the day it was written. Neither is the check.

Section 19 of the 2025 policy guidelines publishes a graded matrix of consequences, triggered by adverse reports, violation of the guidelines and the terms and conditions of empanelment, and poor quality of audits. The grades and the indicative parameters below are transcribed from that matrix. Auditee feedback to CERT-In is one of the inputs, and section 11(iv) says actions under the Deter and Punish framework may be taken without any reminder or notice.

Read the first row again from the auditee’s side. “Inadequate sample details, issues covered, improper conclusions” and “lack of relation between noting and issues raised” are quality failures that you, holding the report, are in the best position to notice. The feedback mechanism exists because CERT-In cannot read every report, and the graded consequences only work if somebody says something.

VAPT stands for vulnerability assessment and penetration testing, and in India it is the ordinary term for the thing a CERT-In empanelled organisation does. It is worth noticing that CERT-In treats the two halves as separate scope classes with separate definitions, not as one acronym. A vulnerability assessment, at item (iii), is the examination of a system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed measures, and confirm their adequacy after implementation. A penetration test, at item (iv), actively tests individual components or the application as a whole to identify and exploit potential vulnerabilities, with the objective of determining whether they can be exploited to compromise the application, access sensitive data, or affect the underlying infrastructure and environment. The first tells you what is wrong. The second tells you what an attacker could do with it.

A red team assessment, at item (xvi), is a third thing again: 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. The distinction that matters commercially is objective. A penetration test is scoped to a system and asks how far an attacker gets into it. A red team assessment is scoped to an outcome and asks whether the organisation — including the people and the detection — would notice and stop it. The 2018 auditor guidelines use “red team” in a narrower internal sense as well, requiring an auditing organisation to deploy a verification team to check the work of its own audit team, and section 15.2.5(iii) of the 2025 guidelines restates that as a maker-checker requirement. Two meanings, one phrase, and a scope of work that does not say which one it means is a scope of work with a hole in it.

What the guidelines require of a VAPT specifically: the type of audit must be named before commencement under section 13.2.3(i)(a), which lists VAPT, external attack penetration testing, device level audit, configuration audit, process audit, mobile application security audit, web application security audit, API security audit and compliance audit as separate things you can buy. Testing must not be solely tools-based. Written permission is needed before DoS, DDoS or flood testing over the internet. Severity comes from CVSS, supplemented by EPSS, and every observation is mapped to a CWE and a CVE. And the environment tested — test, development, UAT, pre-production or production — must be stated in the report.

AI red teaming is adversarial testing of an AI system: attempting, as an adversary would, to make a model or the application around it produce harmful output, disclose data it should not, or take actions it should not, and then reporting what worked. It is the red team assessment of item (xvi) pointed at the system class of item (xxiii).

The Indian position on this is stronger than most people realise, and it does not depend on anything new. Item (xx) of Annexure I to the CERT-In Directions of 28 April 2022 makes attacks or malicious or suspicious activities affecting systems, servers, software and applications related to artificial intelligence and machine learning a mandatorily reportable incident class, on the six-hour clock. That was written into a 2022 instrument, before the current wave of deployment. It is on the official incident reporting form as a tick-box. An AI incident in India is not a novel regulatory question. It is item twenty.

On the audit side, section 6(xxiii) of the 2025 guidelines makes AI system audits a named scope class: evaluation of AI systems for security, ethical alignment, transparency, data integrity and resilience to adversarial manipulation. That last phrase is the one that carries red teaming. Section 6(xxvi) adds AIBOM — the artificial intelligence bill of materials — alongside SBOM and QBOM, and CERT-In publishes technical guidelines on the bill-of-materials family at version 2.0 covering SBOM, QBOM, CBOM, AIBOM and HBOM.

Where the distinction matters in a scope of work: an AI system audit is an assessment against criteria — is the system transparent, is the data pipeline sound, are the controls in place. AI red teaming is an attempt to break it. You can pass the first while failing the second, which is exactly why CERT-In’s own SAMVAAD 2026 programme carried presentations on AI-driven red teaming methodologies as a distinct topic. And the two obligations run on different clocks: the audit is annual, and the incident report is six hours.

Section 6(xviii) defines cloud security testing as evaluating and assessing the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures. Section 8(ii) then names the framework: the CSA Cloud Controls Matrix for cloud security, alongside ISO/IEC standards and the rest — and expressly not the OWASP Top 10 or SANS Top 25, which the guidelines say should not be considered standards or references for audits.

Cloud is not confined to one scope item. Section 13.1.1 puts cloud inside the general audit scope alongside web and mobile applications, APIs, OT and ICS, databases and hosting infrastructure. Annexure I item (xviii) of the 2022 Directions makes attacks and suspicious activity affecting cloud computing systems, servers, software and applications reportable — by you, for your tenancy, not merely by your provider. And direction (iv)’s log obligation lands hardest here, because a cloud estate is where logs most often leave the country by default.

One cloud-specific answer worth having in writing, because it comes up in every scoping call. CERT-In’s FAQ of May 2022 addresses time synchronisation in cloud environments at Q42: customers in cloud environments may use the native time services offered by the cloud, or set up their own NTP server within their cloud environment. Entities relying on native cloud time services may continue to use them. And where an entity runs its own NTP service synchronising with something other than native cloud time, the NTP servers of NPL, NIC or another accurate and standard source may be used as long as accuracy is maintained and the source does not deviate from NPL and NIC. That is a more workable answer than the bare text of direction (i) suggests, and it is CERT-In’s own.

A VAPT is a scope, not a synonym. The guidelines require the type of audit to be stated explicitly before commencement — VAPT, external attack penetration testing, device level audit, configuration audit, process audit, mobile application security audit, web application security audit, API security audit, compliance audit. A purchase order that says only “VAPT” has not yet specified what is being bought, and the difference surfaces when an API or a mobile client turns out to have been outside the tested surface.

The scope is supposed to come from an asset inventory, not from a wishlist. The guidelines say the scope must be derived from the organisation’s consolidated and updated asset inventory, vetted by the internal audit team in consultation with the CISO, and that assets in testing, UAT, development and production environments should all be included. Section 13.2.3(ii)(b) adds the detail that makes it checkable: the auditing organisation may advise the auditee to state explicitly the date up to which the scope or asset inventory has been updated, and “this date must be reflected in the audit reports”. An audit scoped from memory has a hole in it, and that date in the report is where the hole becomes visible.

Top-ten lists are not the standard. This surprises people, so it is worth quoting: limited lists such as the OWASP Top 10 and SANS Top 25 “should not be considered as standards or references for audits”. Audits should instead discover all known vulnerabilities against comprehensive frameworks — ISO/IEC standards, the Cyber Security Audit Baseline Requirements, the CSA Cloud Controls Matrix for cloud, OSSTMM3, the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, the OWASP Mobile Security Testing Guide, and the OWASP DevSecOps Maturity Model for CI/CD pipeline security — along with applicable regulatory frameworks and the directions and guidelines issued from time to time by CERT-In, Government and regulators. Solely tools-based testing is to be discouraged, because a tool-driven audit tends to cover the automatable parts of an estate and miss the rest.

There is also a baseline that applies specifically to government work. For audits of critical applications, databases or platforms of Ministries, Departments, Secretariats and Offices where sensitive personally identifiable information is involved, the auditing organisation must verify compliance with the Comprehensive Audit Program Checklist — Cyber and Information Security Audit, set out in the Guidelines on Mandatory Features of Cybersecurity Architecture to be Ensured in all Ministries and Departments issued by the Cyber Security Division of the Ministry of Electronics and Information Technology. That checklist comprises 282 control points and forms the default mandatory audit scope for such entities. If you run a departmental application holding PII, that number is your floor, not your ceiling — see GIGW compliance before go-live for how it sits alongside the pre-production audit requirement.

One caution that belongs here rather than anywhere else. Material circulates online that is attributed to CERT-In and is not from CERT-In — summaries with invented deadlines, consultancy blogs restating requirements that were never issued, and social posts announcing platform features with dates attached. The check is mechanical and takes a minute: the document is on cert-in.org.in, or it is on meity.gov.in or pib.gov.in, or it is not a CERT-In document. A reference number, an issue date and a statement of the provision it is issued under are the three things a genuine instrument always carries.

A page that tells you to file within six hours and never says what a filing looks like has not helped you. There are two artefacts, and both are short. The first is the one to send today, and the second is the one you will send under pressure.

Annexure II to the 2022 Directions is a form with eight fields, sent by email to info@cert-in.org.in, and updated from time to time. All communications from CERT-In seeking information and providing directions for compliance are sent to the point of contact you designate. You can complete this this afternoon, and there is no reason not to.

Then keep three things, because the filing alone only proves you did it once. Keep the sent item and its date, which is the artefact an auditor asks for. Keep evidence that the named mailbox is monitored — a rota, an alerting rule, or a test message with a recorded response time, refreshed quarterly. And write down the re-filing trigger: the person leaves or changes role, the mobile number changes, the office moves. Direction (iii) requires the information to be updated from time to time, and a three-year-old filing naming someone who left is the failure mode, not the absence of a filing.

CERT-In publishes an incident reporting form on cert-in.org.in, and its own note on that form is the most useful sentence in the whole reporting regime: it is not mandatory to fill and/or sign this form. Incidents may also be reported by providing relevant information in the communication itself or in any other readable form. An email containing the right facts is a compliant report. The form matters because it tells you what the right facts are.

One more thing the FAQ settles, at Q30. Asked what to do if the full information on the form is not available within six hours, CERT-In answers that entities may provide information to the extent available at the time of reporting, and that additional information may be reported later within reasonable time. The same answer then names the categories that should certainly be reported inside the six-hour window. Incidents of a severe nature such as denial of service, distributed denial of service, intrusion or the spread of a computer contaminant including ransomware on any part of the public information infrastructure including backbone network infrastructure. Data breaches or data leaks. Large-scale or most frequent incidents such as intrusion into a computer resource or website. And cyber incidents impacting the safety of human beings.

Worth noting that the incident obligation and the audit obligation converge. An empanelled auditor is required to test compliance with the 2022 Directions in every assignment, and the testing of incident response capability is named in the guidelines as something an auditee should include in scope. Whether your six-hour process works is therefore not a question you get to answer only to yourself.

Two claims about AMBAK appear widely in vendor posts and social commentary: that AMBAK is blockchain-enabled, and that security audit reports and audit certificates become verifiable through AMBAK from a specific date in July 2026. Neither appears in the Press Information Bureau release, and neither appears in CERT-In’s own 666-page conference proceedings. The word “blockchain” occurs in the proceedings only in the list of conference discussion topics and in paper titles, never connected to AMBAK. No verification service, portal, access rule or commencement date is described anywhere. The July 2026 date does not appear in connection with AMBAK at all — in a document whose own file metadata records it as produced after that date.

Both accounts were read in full, and both negative findings are stated as at 18 September 2026. A negative finding is only as good as the date attached to it, so check CERT-In directly if you are reading this much later. Neither claim is asserted here, and neither should be asserted in a bid document, a customer assurance pack or a board paper on the strength of a vendor blog. What the official accounts support is the name, its expansion, CERT-In’s own framing of the purpose, the fact of the launch and the occasion. The operational detail is still being published. A fuller treatment is in CERT-In AMBAK, and the conference itself in CERT-In SAMVAAD 2026.

The more useful signal in the release is the agenda. The topics selected from more than two hundred submissions are the Government’s own statement of what the national audit ecosystem is now concerned with: space assets including UAVs and satellites, automated audit tooling, IoT, AI-driven cyber risk including frontier models with advanced cyber capabilities, blockchain, quantum communication and post-quantum cryptography, the SBOM, CBOM, QBOM and HBOM family, AI-driven red teaming methodologies, supply chain audits, and the auditing of cloud systems, APIs and operational technology. Several of those map directly onto named scope classes in section 6 of the 2025 policy guidelines — AI system audits at (xxiii), blockchain at (xxv), red team assessment at (xvi), SBOM, QBOM and AIBOM auditing at (xxvi), cloud security testing at (xviii), application security testing including APIs at (xii), and ICS and OT at (xix). Others, including space assets and post-quantum cryptography, appear in the conference programme without a corresponding scope entry, and the CBOM and HBOM members of the bill-of-materials family sit in CERT-In’s separate technical guidelines rather than in section 6. The direction of travel is not subtle, and it lines up with the technology estates Indian companies are actually building. A fuller account sits at CERT-In AMBAK.

The audit process cannot be delegated. The guidelines state that the complete audit process of the information infrastructure must be undertaken by the auditee organisation itself — defining the scope, selecting the auditing organisation, providing access, and ensuring closure of all observations — and that this responsibility must not be delegated. External support may be engaged for specialised expertise, but full ownership and accountability for the security of the infrastructure stays with the owner. A department that hands the whole exercise to a systems integrator has not complied with that, however good the integrator is.

Risk acceptance is a decision for the head of the organisation. Treatment of any reported vulnerability or observation — retain, avoid, transfer or reduce — must be authorised and accepted by the head of the auditee organisation, and any exception to a reported vulnerability in an application must be authorised by the head of the organisation who owns the application. That is a named human being signing a risk acceptance, not a spreadsheet column.

Do not change the code after the certificate. The guidelines ask developers to avoid making code changes to the audited application or infrastructure after issue of the audit certificate, and recommend that hash values, versions and timestamps be captured and featured prominently in the certificate and reports. A major change must undergo a cyber security audit before implementation, while minor changes go through normal change management without one. The classification decision is therefore a compliance control, and it belongs in your change process rather than in someone’s judgement on the day — see how long a certificate stays valid and how to verify a CERT-In audit certificate.

If one row earns its place it is the third. “CERT-In certified” is the phrase that travels furthest and means least, and it turns up in tender language, in vendor marketing and in customer security questionnaires. The correct construction for a bid is factual and slightly longer: name the CERT-In empanelled organisation that performed the audit and signed the report, name the certificate and its date, and let those do the work. That formulation is also the only one an empanelled auditor is itself permitted to use about its own status.

Named by the guidelines, but not retrievable. Section 15.2.1(iv) of the audit policy guidelines points auditors at a document called “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” and gives a URL for it on cert-in.org.in. As at 18 September 2026 that URL does not serve the document. It returns a short page reading “The requested URL is not found.” This page therefore cites the document as the guidelines name it and asserts nothing about its contents. The Information Technology (The Indian Computer Emergency Response Team and Manner of performing functions and duties) Rules, 2013 are in the same position: they are quoted here as CERT-In itself reproduces rule 9 in the authority section of the 2025 guidelines, because we could not retrieve the notified text from an official source on that date.

This page also states several negative findings — that no register of prosecutions is published, that no verification portal has been described, that two widely circulated AMBAK claims appear in neither official account. Each is stamped 18 September 2026 where it appears. A negative finding is only as good as the date attached to it: if you are reading this well after that date, check the CERT-In sources above before relying on one. If the position has moved, we would rather be told and correct the page than be quoted accurately on something that has changed.

If your question is about the binding obligations

The 2022 Directions explained takes the six directions clause by clause, at more length than this page has room for. CERT-In AMBAK separates what the Government has published about the platform from what circulates about it.

If your question is about auditors and empanelment

CERT-In empanelment explained covers how the scheme works and what it does and does not confer. Rules of engagement for an empanelled auditor is the conduct side: what an auditor may and may not do on your systems, and what it may say about its relationship with CERT-In.

If your question is about certificates

What a safe-to-host certificate is, how to get one, how long it stays valid, who can issue one, how it differs from a security audit certificate, how to verify one you have been handed, and why applications fail the first time.

If you are taking a government application live

GIGW compliance before go-live covers the guidelines your evaluator will actually work from, and where the audit clearance certificate sits inside them.

If you are scoping the testing itself

Penetration testing and VAPT is where the scoping conversation starts — web, mobile, API, cloud and network surfaces.

If you need a CERT-In audit

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