Learn · CERT-In & Audit Assurance

AMBAK: CERT-In’s Audit Monitoring and Benchmarking Platform

AMBAK stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. CERT-In launched it at CERT-In SAMVAAD 2026, and two official accounts of that launch exist: a Government of India press release of 29 April 2026, and CERT-In’s own conference proceedings. Between them they give the name, the purpose and nothing operational — which is why so much of what is written about AMBAK elsewhere has no source behind it.

Two claims to be careful with: that AMBAK is blockchain-enabled, and that audit reports and certificates become verifiable through it from a date in July 2026. Both circulate widely. Neither appears in either official account. This page reports them as reported, attributes them, and then sets out the verification method that works today without any platform.

Talk to a Compliance Advisor What a Safe-to-Host Certificate Is

29 Apr 2026date of the official announcement

Over 500delegates at CERT-In SAMVAAD 2026

5 daysin which an empanelled auditor must send your report to CERT-In

Plain-English explainer · PIB release ID 2256581, 29 April 2026, Ministry of Electronics & IT, and the CERT-In SAMVAAD 2026 conference proceedings · Sources last checked 18 September 2026

Status as at 18 September 2026

As at 18 September 2026, two months after the date circulated in vendor commentary, no verification service for audit reports or audit certificates has been published by CERT-In as indexed, and the 15 July 2026 date has still not appeared in any official source. CERT-In’s own conference proceedings for SAMVAAD 2026 — a 666-page document that gives AMBAK a numbered section and a statement of purpose — contain no verification service, no portal, no commencement date and no reference to blockchain in connection with the platform. This page is dated on purpose: it states when it was last checked against the primary sources, not merely when it was written, so that a later reader can weigh a negative finding rather than guess at its age. If the position has moved since, the sources listed at the foot of this page are where it will move first.

AMBAK stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. It is a platform launched by the Indian Computer Emergency Response Team — CERT-In — at CERT-In SAMVAAD 2026, the agency’s three-day National Annual Conference, held from 27 to 29 April 2026 at the BITS Pilani K. K. Birla Goa Campus in association with BITS Pilani, Goa. The launch was announced by the Government of India in a Press Information Bureau release issued by the Ministry of Electronics and Information Technology on 29 April 2026. The name describes the purpose: central visibility over information security audits, comparison of those audits against one another, analysis of what they collectively show, and action taken on the basis of that analysis. For the people who commission audits, the significant word is the first one. An audit has until now been a transaction between an auditee and an auditor, producing a document that the rest of the world has to take at face value. A platform that monitors audits is a platform that could, in principle, let a third party confirm that a security audit report or an audit certificate is genuine.

There are two official accounts of that launch, and it is worth knowing both, because almost every other page on this subject works from the shorter one. The first is the press release. The second is CERT-In’s own SAMVAAD 2026 conference proceedings, published on cert-in.org.in: 666 pages, the second edition of the conference, in which AMBAK gets a numbered section, 7.1, and a statement of purpose in the agency’s own words. It was launched, that section says, “to support audit monitoring, benchmarking, analysis and targeted interventions”, reflecting “the need for structured mechanisms to strengthen audit effectiveness, improve visibility into audit outcomes and support continuous improvement in cybersecurity assurance”. That is the fullest published description of AMBAK that exists. It is also, notably, the only place the fourth word of the acronym is glossed: CERT-In’s own paraphrase of “kinetic” is “targeted”.

What neither account contains is anything operational: no architecture, no scope, no statement of who may access the platform or what it covers, no portal, and no date from which any service becomes available. This page sets out what the two documents confirm, attributes what merely circulates, and then spends most of its length on the thing that is actually actionable — how to establish that an Indian security audit certificate is genuine, today, using the published empanelment list, the certificate’s own fields and a short written request to the organisation that issued it.

What AMBAK is not

Five questions people arrive with, and the plain answer to each as at 18 September 2026.

There is no published AMBAK portal, URL or login.

Neither official account of the launch gives a web address, and no AMBAK portal is published on cert-in.org.in as indexed. If you have been sent a link, treat it the way you would treat any unverified link that arrived with a compliance claim attached.

There is nothing for an organisation to register for.

No enrolment, onboarding or application process has been published, for auditees or for auditing organisations. An invitation to register for AMBAK is not something CERT-In has published a process for.

It is not a certification, and there is no AMBAK status to hold.

Nothing published describes a mark, a grade, a tier or a criteria set. No organisation can currently be AMBAK-certified, AMBAK-registered or AMBAK-verified, because there is no published thing to be.

It does not replace or alter CERT-In empanelment.

Empanelment remains what it was: a standing held by a named legal entity and published by CERT-In, governed by the empanelment terms and conditions (v7.2, April 2024) and the 2025 audit policy guidelines. Nothing in either account of the AMBAK launch changes how an organisation becomes or stays empanelled.

“AMBAK-verified” is not a claim anyone may currently make.

There is no published verification service to be verified by. Separately, CERT-In constrains claims about its name tightly: an empanelled auditor may use one permitted sentence and no other words without prior written permission. An organisation inventing a badge in that environment is telling you how it handles claims generally.

Key Takeaways

AMBAK stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. The expansion is confirmed twice: in the Government of India press release of 29 April 2026, and in CERT-In’s own SAMVAAD 2026 conference proceedings.
CERT-In calls it a platform and describes it as launched “to support audit monitoring, benchmarking, analysis and targeted interventions” — which makes “targeted” the agency’s own gloss on “kinetic”, and the only official gloss that exists.
It was launched at CERT-In SAMVAAD 2026, the second edition of a three-day national annual conference held 27–29 April 2026 at the BITS Pilani K. K. Birla Goa Campus, in association with BITS Pilani, Goa, with over 500 delegates.
Neither official account describes an architecture, a scope, an access rule, a portal, or a date from which any service becomes operative. There is no AMBAK portal, login or registration published, nothing for an organisation to enrol in, and no status such as “AMBAK-verified” that anyone may currently claim.
Two claims circulate widely and appear in neither official account: that AMBAK is blockchain-enabled, and that reports and certificates become verifiable through it from 15 July 2026. That date has now passed with nothing published behind it.
Audit data already flows to CERT-In. Empanelled organisations share the audit report and audit metadata within five days of completing an audit under clause 3.2.2 of the empanelment terms and §10.6 of the 2025 audit policy guidelines, file a quarterly return, and may be joined on an audit team by CERT-In assessing the quality and maturity of that audit.
A certificate can be verified today without any platform: check the signing legal entity against CERT-In’s published empanelment list — for the dates of the audit, not for today — read the certificate field by field against what you are deploying, and confirm the reference number, build and test window with the issuer using contact details you obtain independently.
The empanelment check fails in four specific ways a glance at the list will not catch: an entity-name variant, an empanelment that had lapsed at the audit date, a group company on the list where the signing entity is not, and an empanelment granted for a different category of work.
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.

What the acronym means

What AMBAK stands for, read component by component

The expansion is official and appears in both accounts of the launch. What each component does in practice is described nowhere public, so the middle column below is a reading of the word rather than a statement of function — except for the fourth, where CERT-In has supplied its own paraphrase. The third column is the useful one: for every part of the name, something already exists in CERT-In’s published framework that such a component would plausibly sit on. That is where an organisation can act today.

Component of the name	What the word plainly says	What already exists that it would sit on	What is not public
Audit Monitoring	Visibility, held centrally, over information security audits as they are commissioned, performed and closed — rather than only over the certificate that emerges at the end.	Empanelled auditing organisations are already required to share the audit report and audit metadata with CERT-In within five days of completing an audit, and to file a quarterly return covering the number of audits performed, the sectors served, high-level findings and new areas encountered.	Whether AMBAK ingests those existing submissions, replaces them with a structured filing, or adds a live channel alongside them. The release names the platform, but it does not describe its interfaces.
Benchmarking	Comparison. A benchmark needs a population and a measure: audits of one kind compared against audits of the same kind, or auditing organisations compared against one another on something measurable.	CERT-In already reserves the right to seek or audit information on any project carried out during the empanelment period, and to sit on the audit team itself in order to assess the quality and maturity of the audit. Quality assessment of empanelled auditors is an existing power, not a new idea.	What is measured, whether results are published, and whether an auditee ever sees where their auditor sits in the distribution. None of that appears in the release.
Analysis	Aggregate reading of audit data: which weaknesses recur across a sector, which classes of finding cluster in which kind of system, where the national picture is moving.	The quarterly return already asks for high-level findings and new areas — the raw material of exactly this kind of analysis, collected today in prose and at low frequency.	Whether analysis stays internal to CERT-In, feeds advisories, or surfaces to auditees and departments in any form.
Kinetic Interventions	The phrase is unusual in an audit context, and it is the one component CERT-In has itself glossed. Its conference proceedings describe AMBAK as launched “to support audit monitoring, benchmarking, analysis and targeted interventions” — so the agency’s own paraphrase of “kinetic” is “targeted”. Read with that gloss, the fourth component is about acting on what monitoring shows, at a chosen recipient, rather than merely recording it.	CERT-In already acts: it issues directions under section 70B(6) of the Information Technology Act, 2000, it can call for information up to and including near real-time, and non-compliance with a direction may invite punitive action under section 70B(7). The Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) also publish a graded ladder of consequences for an empanelled organisation: a watch list with warning and written commitment, suspension, debarment and de-empanelment, and penal and legal action.	What an intervention consists of under AMBAK, who receives one, on what trigger, and with what right of reply. The published ladder above exists independently of AMBAK. Nothing published connects the two.

One observation is worth making about the fourth component, because it is the one commentary tends to skip. “Kinetic interventions” is not ordinary audit vocabulary, and it is the only component of the name CERT-In has itself restated: section 7.1 of the conference proceedings describes the platform as supporting “audit monitoring, benchmarking, analysis and targeted interventions”. Kinetic becomes targeted. In policy writing the word ordinarily marks action that has an operational effect, as distinct from analysis, advisory or reporting. Placed at the end of a sequence running monitoring, benchmarking, analysis, it reads as the step where findings stop being observations. CERT-In already has the statutory instruments for action — section 70B of the Information Technology Act, 2000 empowers it to call for information and issue directions, and attaches punitive consequences to non-compliance — and the 2025 audit policy guidelines publish a graded consequence ladder for empanelled organisations, running from a watch list through suspension and debarment to penal and legal action. What an intervention consists of under AMBAK, who receives one, on what trigger and with what right of reply, is not published, and nothing published connects that ladder to this platform. Reading the name honestly means holding both halves: the word is significant, and its operational meaning is not yet on the record.

The primary source

What CERT-In and the Government of India actually published

There are two primary sources for AMBAK. The first is a Press Information Bureau release issued by the Ministry of Electronics and Information Technology on 29 April 2026, release ID 2256581, reporting the conclusion of CERT-In SAMVAAD 2026. The second is CERT-In’s own conference proceedings for that event, published on cert-in.org.in — the longer and later document, and the one most commentary appears not to have read. Every statement in the table below is in one or both, and the right-hand column says which. Nothing else on this page is presented as a fact about AMBAK unless it is drawn from a published CERT-In instrument and identified as such. Both documents are linked in full at the foot of the page.

Confirmed	Where it appears
AMBAK stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions.	Expanded in full in the PIB release, and again in the proceedings — in the inaugural-ceremony paragraph, as the subtitle to section 7.1, and in the Abbreviations annexure.
CERT-In calls AMBAK a platform.	The proceedings name “AMBAK (Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions) Platform” among the initiatives launched at the inaugural ceremony. “Platform” is the agency’s own word, but nothing published describes what kind.
AMBAK was launched at CERT-In SAMVAAD 2026 to support audit monitoring, benchmarking, analysis and targeted interventions, reflecting the need for structured mechanisms to strengthen audit effectiveness, improve visibility into audit outcomes and support continuous improvement in cybersecurity assurance.	Section 7.1 of the proceedings, in CERT-In’s own words. This is the fullest published statement of purpose that exists — and note that it glosses “kinetic” as “targeted”.
The launch was framed around data-driven approaches to assessing audit maturity, identifying gaps, enabling benchmarking and supporting informed decision-making across the cybersecurity audit ecosystem.	Section 7.1 of the proceedings, second paragraph.
CERT-In SAMVAAD 2026 was the second edition of the conference: a three-day national annual conference held from 27 to 29 April 2026 at the BITS Pilani K. K. Birla Goa Campus, in association with BITS Pilani, Goa, with over 500 delegates.	Dates, venue, partner and attendance in the release. The proceedings cover page adds “2nd Edition” and repeats the dates and venue.
The theme was “Securing Digital Bharat through Future-Ready Audits: Adapting, Assuring, Advancing”.	Quoted in the release and printed on the proceedings cover.
The conference was conceived and executed under Dr. Sanjay Bahl, Director General, CERT-In. The keynote was delivered by Shri S. S. Sarma of CERT-In. It was inaugurated by Dr. Pramod Sawant, Chief Minister of Goa.	Named in the release. The proceedings carry the same names, styling Shri S. S. Sarma as Scientist ‘G’ and the release as Senior Director.
Two further launches were made at the same ceremony: progress reports by CERT-In’s Working Groups on emerging domains, and an advanced cybersecurity certification course for Rural Financial Institutions with BIRD — the Bankers Institute of Rural Development — and NABARD.	Both listed in the release alongside AMBAK. The proceedings give them sections 7.2 and 7.3 and expand BIRD.
A panel titled “Auditing the Future: Securing Emerging Technologies through Next-Generation Cybersecurity Audits”, moderated by Shri S. S. Sarma, featured the Reserve Bank of India, the Satcom Industry Association of India, the Centre for Railway Information Systems (CRIS), BSE Limited and Airtel Payments Bank.	Panel title, moderator and organisations named in the release. The proceedings name each panellist and designation, and the Abbreviations annexure expands CRIS.
Over 87 presentations were selected from more than 200 submissions.	Figures stated in the release, with those hedges. The proceedings reproduce 57 full-length technical papers by domain, plus abstracts of the parallel-track presentations.

Read that list again for what it does not contain. There is no description of how AMBAK is built. There is no statement of which audits it covers, whether it reaches private-sector engagements or only those performed for Government and critical sector entities, who may query it, or whether an auditee, a buyer or the public will ever see a record. There is no commencement date for any service, and no address at which to find one. A launch announcement establishes that a thing exists and what it is called. Everything operational about it — scope, access, coverage, timing — is still being published, and the responsible position is to say so.

The scale of the second document is worth dwelling on, because it is what makes the negative finding sturdy rather than merely cautious. CERT-In’s conference proceedings run to 666 pages and reproduce 57 full-length technical papers. Across all of it, AMBAK appears exactly seven times: a line in the table of contents, one sentence in the account of the inaugural ceremony, the heading of section 7.1, the two paragraphs of purpose quoted above, a photo caption, and an entry in the Abbreviations annexure. An agency that had launched a public verification service, with a portal and a commencement date, would have said so somewhere in those 666 pages. The absence in the press release could be brevity. The absence in the proceedings is harder to explain away.

The distinction that matters

Is AMBAK blockchain-based and does verification start in July 2026?

Those are the two statements repeated almost everywhere AMBAK is discussed. Both are stated flatly, usually without a source, and both have been reproduced often enough to look like common knowledge. Neither is in either official account. This is not a claim that they are false — it is a statement about what is on the record, which is the only basis on which a compliance decision should be taken. The last column carries a checked-on date, so that a reader arriving later can see how old the finding is rather than assume it.

The circulating claim	Where it appears	What the official accounts say	How to treat it	Position as at
AMBAK is blockchain-enabled.	Vendor blog posts, compliance-marketing pages and professional-network commentary published in the days after the launch, generally without a source.	Neither official account describes the platform’s architecture. The word blockchain appears in both documents only as a subject area — one of the technologies discussed at the conference, and the subject of submitted papers. In 666 pages of proceedings, AMBAK appears seven times and blockchain is not connected to it in any of them.	Do not repeat it as fact. A plausible explanation for how the claim arose — a conference that discussed blockchain, and a platform launched at that conference — is not evidence that the claim is true. If the architecture bears on a decision you are taking, ask CERT-In.	Checked 18 September 2026: not stated in the PIB release, not stated in CERT-In’s conference proceedings, not published on cert-in.org.in as indexed.
Security audit reports and security audit certificates become verifiable through AMBAK from 15 July 2026.	Widely repeated in vendor posts and professional-network commentary, usually stated flatly and with the date presented as settled.	Neither account contains that date, any other date, or a commencement statement of any kind for AMBAK. Neither describes a verification service, a portal, an access rule or a scope. Both announce a launch. CERT-In’s own proceedings are the later document of the two, and they add a statement of purpose without adding a service or a date.	The date has now passed. Anything written against it — a calendar entry, a contract clause, a customer commitment — is written against a date that arrived with nothing published behind it. Attribute the date to whoever gave it to you, and confirm the current position with CERT-In before you rely on it again.	Checked 18 September 2026, two months after the circulated date: no verification service for audit reports or certificates published by CERT-In as indexed, and the date itself still absent from every official source.

Blockchain-enabled. Verification from 15 July. Two sentences that travelled faster than the release they were attributed to.

It is worth understanding how this happens, because the mechanism will repeat with the next announcement. A government release reports a conference at which many things were discussed and several were launched. Blockchain, quantum cryptography and artificial intelligence were among the subjects of the more than eighty-seven presentations the release mentions. A platform was launched at the same event. In the compression that happens when a release becomes a summary, and the summary becomes a post, and the post becomes a slide, a subject discussed at a conference becomes a property of a product launched at the conference. Add a plausible-sounding date — and dates are the detail readers most want, so they propagate fastest of all — and within two weeks a claim nobody sourced is being repeated by people who assume somebody else did.

The harm this does is specific. A July date written into a compliance calendar, a customer told their certificate will shortly be centrally verifiable, a proposal citing a capability whose scope nobody has read: each inherits whatever the underlying claim is worth. Where the claim turns out to be accurate, nothing is lost by having waited for the source. Where it turns out to be wrong, or right in substance but different in scope — covering Government engagements only, say, or available to departments rather than to the public — every commitment built on it has to be unwound in front of the people it was made to. The cost of checking is one email to CERT-In. The cost of not checking is paid later and in public, which is a reasonable description of where the July date now sits.

Method

How to check a claim about AMBAK

This is the part worth keeping, because it outlives the current news cycle. The same eight checks apply to the next platform, the next direction and the next set of guidelines.

01 Read the acronym in full before reading anything else about it. Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions is a description of purpose, and most commentary quietly replaces it with a description of features nobody published.
02 Find the source. If a claim about AMBAK cannot be traced to the Press Information Bureau release of 29 April 2026 or to something published by CERT-In, it is commentary. That is not a criticism of commentary — it is a statement about what you may rely on.
03 Ask which official account it appears in, because there are two and they are different lengths. The PIB release is a short announcement. CERT-In’s own conference proceedings are 666 pages and give AMBAK a numbered section with a statement of purpose. A claim absent from both is absent from everything official.
04 Distinguish the conference from the platform. Blockchain, AI and quantum were subjects of presentations at SAMVAAD 2026. That tells you what the ecosystem is thinking about, but it tells you nothing about how AMBAK is built.
05 Notice what a launch is and is not. A launch announces that something exists. It does not, by itself, establish scope, availability, access rights, coverage of private-sector audits, or an operative date.
06 Ask who a capability would be for. Verification is valuable to whoever has to rely on a document they did not produce — a department, an enterprise buyer, a regulator. Assumptions about public access are assumptions.
07 Keep the certificate and the report separate in your head. Anything a central record could confirm is about the engagement. Everything about audit quality is in the report.
08 When in doubt, ask CERT-In, and ask in a form that produces something you can cite. The two routes are set out immediately below this list.

The official sources worth knowing by name are short: cert-in.org.in for directions, empanelment and audit guidance, meity.gov.in for ministry policy, pib.gov.in for the announcements themselves, guidelines.india.gov.in for the Guidelines for Indian Government Websites and Apps, and nic.in. Between them they settle most questions, and a claim that cannot be found in any of them is a claim somebody made. Every document this page relies on is listed with its date and a link in the references at the foot. For the underlying framework those documents set up, see what CERT-In is and what it does and the CERT-In Directions of 28 April 2022.

How to actually get an answer out of CERT-In

“Ask CERT-In” is advice with a mechanism attached, and the mechanism is the part usually left out. There are two routes, and they produce different things. The first is the ordinary one: CERT-In publishes contact channels on cert-in.org.in, including the incident address incident@cert-in.org.in and the toll-free line 1800-11-4949 named in the Directions of 28 April 2022, and an empanelment address, empanelment@cert-in.org.in, named in the 2025 audit policy guidelines for empanelment and auditee-feedback matters. An enquiry about what has been published belongs on the empanelment or general channel rather than the incident line, which exists for reporting incidents.

Put four things in it:

01 The claim you are checking, quoted in the words it reached you in, rather than paraphrased.
02 Where you encountered it — the publication, the proposal, the vendor, the slide — so the agency can see what is circulating under its name.
03 PIB release ID 2256581 of 29 April 2026, and the CERT-In SAMVAAD 2026 conference proceedings published on cert-in.org.in, named as the documents you have already read. This is what separates a genuine enquiry from a request to be spoon-fed, and it tends to get better answers.
04 The decision the answer bears on — a contract clause, a tender response, a customer commitment, a board paper — stated in one line, so the reply can be scoped to what you actually need.

The second route is the one Indian readers have and often forget they have. An application under the Right to Information Act, 2005 to the public information officer of CERT-In, or of the Ministry of Electronics and Information Technology, produces a dated, signed, attributable reply within a statutory timeframe. That is a different class of artefact from an email: it is the thing you put in front of a regulator, a customer or a board when the question is whether a capability exists and from when. Use the ordinary channel when you want to know. Use the RTI route when you will have to prove what you were told. A written answer from the agency is worth more than the twenty search results above it, and it is worth more still when it is signed.

The conference

Where AMBAK was launched, in four lines

CERT-In SAMVAAD 2026 was the second edition of CERT-In’s national annual conference: three days, 27 to 29 April 2026, at the BITS Pilani K. K. Birla Goa Campus in association with BITS Pilani, Goa, with over 500 delegates and the theme “Securing Digital Bharat through Future-Ready Audits: Adapting, Assuring, Advancing”.
Three things were launched at the inaugural ceremony, not one: AMBAK, progress reports by CERT-In’s Working Groups on emerging domains, and an advanced cybersecurity certification course for Rural Financial Institutions with BIRD and NABARD.
Over 87 presentations were selected from more than 200 submissions, and the proceedings name the subjects the Government of India considers the audit ecosystem’s live problems: cloud systems, APIs and operational technology, AI-driven cyber risks and AI-driven red teaming, IoT, space assets, UAVs and satellites, quantum communication and post-quantum cryptography, supply chain audits, and the SBOM, CBOM, QBOM and HBOM family.
That subject list is the clearest published signal of where Indian audit scope is heading, and it is a bigger subject than this page. It has its own: CERT-In SAMVAAD 2026 and what it signals for audit scope carries the programme, the panel, the working groups and a line-by-line reading of every subject area named.

The existing pipe

Audit data already flows to CERT-In

This is the section most commentary omits, and it is the one that makes AMBAK legible. An audit-monitoring platform is not built on nothing: a substantial reporting apparatus already exists, it is published, and it is in force today regardless of what any platform does next. If you want to understand what could plausibly be monitored, benchmarked and analysed, look at what is already required to be sent.

What is reported	Under which instrument	When	What it produces
The audit report and audit metadata, after every audit	Terms and Conditions for Empanelment, version 7.2, April 2024, clause 3.2.2. And the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025, §10.6 — which also require, at §13.2.1(iii), that the auditee be told of this duty before the assignment begins.	Within five days of completion of the audit.	A per-engagement record held by CERT-In: that this audit happened, who performed it, and what it found. Clause 3.2.2 also requires the auditor to report critical vulnerabilities, with auditee details, that were identified but not fixed even during follow-up audits. It is the most substantial existing input to anything called audit monitoring — and it is easily the duty auditees are most often unaware of.
A quarterly return from each empanelled organisation	Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018.	Quarterly.	Number of audits performed, the sectors they were performed in, high-level findings, and new areas encountered. Sector-level pattern data, at a frequency and in a form that limits how much analysis it can carry.
Declared manpower for Government and critical sector audits	Auditor guidelines version 3.0, snapshot information form.	Maintained as a standing declaration, verifiable at any time.	A named roster CERT-In can check against the people who actually turn up. The guidelines state that for Government and critical sector audits, the organisation must deploy manpower declared to CERT-In, and that CERT-In may verify this independently or through either party.
Access to any project, and a seat on the audit team	Auditor guidelines version 3.0.	At CERT-In’s discretion, throughout the empanelment period.	Direct quality evidence. CERT-In reserves the right to seek or audit information on any project carried out during the empanelment period, and may be part of the audit team to assess the quality and maturity of the audit.
Incident reports from the audited organisation itself	CERT-In Directions of 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000.	Within six hours of noticing an incident or being brought to notice about it, for the twenty incident types listed in Annexure I.	The other half of the picture: what actually went wrong, reported by the entity, against a population of audits reported by auditors. Monitoring is far more powerful where those two datasets can be read together.

The five-day submission is the line auditees most often find surprising, and it changes how a client should think about an engagement. When you commission an audit from a CERT-In empanelled organisation, the report and its metadata are shared with CERT-In within five days of the audit being completed. That is not a discretionary courtesy between auditor and agency. It is part of what empanelment obliges. The practical consequence is that the record of your audit does not end at your document management system. It is a reason to care that the work was done properly, and a reason not to treat the report as a document to be negotiated down.

The second line changes how you should read an auditor’s sales pitch. Quality assessment of empanelled auditors is already a CERT-In power: the agency reserves the right to seek or audit information on any project carried out during the empanelment period, and may be part of the audit team to assess the quality and maturity of the audit. An organisation that performs well under that scrutiny has nothing to fear from benchmarking, and one that does not has problems that predate any platform. If you want a single question to ask a prospective auditor about AMBAK, it is not “how will this affect you” — it is “what would CERT-In see if it sat on our engagement”.

The last line is the one that ties this hub together. Incident reporting under the Directions of 28 April 2022 is an obligation on the audited organisation, not the auditor: twenty categories of incident listed in Annexure I must be reported to CERT-In within six hours of being noticed or brought to notice. Audit data tells a national agency what was found by people looking for problems, while incident data tells it what happened to people who were not. The two read together is the whole argument for central monitoring, and it is why an organisation serious about CERT-In compliance treats its six-hour reporting path as infrastructure rather than as a policy document.

Verification

How to verify a CERT-In audit certificate today, without a platform

Here is the problem a verification capability would solve, stated plainly. A security audit certificate is a PDF. It carries a letterhead, a reference number, a scope statement, a date and a signature, and every one of those elements can be produced by anyone with a word processor. The only thing that makes a genuine certificate different from a fabricated one is that a real organisation stands behind it — and the only way to discover that today is to go and ask them, which is often not done. That gap is why the prospect of central verification attracts so much attention, and why the claims about it spread faster than the facts. The rest of this section is the method that closes the gap without waiting: five questions, the four ways the empanelment check fails, the certificate field by field, the request to send the issuer, the file to keep, and a worked example from a procurement pack.

The question	How you answer it today	What central verification would change
Is the organisation that signed this certificate actually empanelled?	Check the signing entity against CERT-In’s published list of empanelled information security auditing organisations. This is the one question that is fully answerable today without anyone’s cooperation, and it is easily skipped because the document usually arrives looking official. It also fails in four specific ways that a quick glance at the list will not catch — set out in the table below.	A platform that records audits against the organisation that performed them makes the check a property of the record rather than a separate lookup — and removes the failure mode where a genuine empanelment is used to dress a report the empanelled entity did not actually produce.
Was this specific report produced by that organisation?	There is no public register of reports. You verify by contacting the issuing organisation directly, using contact details you obtain independently rather than the ones printed on the document, and asking them to confirm the reference number, the scope and the date.	This is the gap a verification service closes, and the reason the prospect attracts attention. A central record turns a phone call into a lookup, and turns a forged certificate from something that works until somebody bothers to check into something that fails on presentation.
Does the certificate cover the build we are about to deploy?	Read the certificate. It names an application, a version or build, an environment and a date. Compare each against what you are deploying. A certificate for a build two releases old does not cover the release in front of you.	Nothing about central monitoring removes this reading. Scope and version are properties of the engagement, not of the register — a verified record of the wrong scope is still the wrong scope.
Were the findings actually closed, or merely reported?	Ask for the report behind the certificate and for the closure or re-test evidence. The guidelines require observations to be supported by objective evidence compiled with the report, and require the report to state timelines for closure of vulnerabilities according to severity.	A record of the engagement is not a record of remediation quality. The report remains the document that tells you how good the audit was, while the certificate only tells you that it concluded.
Is the certificate still valid?	Validity is driven by change, not the calendar. As worded on published specimen certificates, and consistent with the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) §13.1.2 — audit at least once a year, and a cyber security audit before implementation of any major change — a certificate holds until a major change is made to server-side application code, or one year, whichever is earlier. A release can therefore retire a certificate months before its date does. Confirm the position that applies to your project with the issuing body.	Central monitoring could in principle show when an audit was last performed. It cannot know that you shipped on Tuesday. Change classification stays an internal discipline.

Notice the shape of that table. Of five questions, exactly one — was this report really produced by that organisation — is genuinely hard today and genuinely transformed by a central record. The other four are answerable now by anyone willing to read the document and make a phone call, and they stay answerable the same way afterwards. That is the honest assessment of what verification is worth: it closes the authenticity gap, and it does nothing about the scope gap, the quality gap or the currency gap. A verified certificate for the wrong build is still the wrong build, and a verified record of a shallow audit is a verified record of a shallow audit.

Step one: the four ways the empanelment check fails

“Look the organisation up on the list” is the right first move and it is not sufficient on its own, because the check fails in four specific ways and only one of them is visible on the document. Work through all four before you conclude that an issuer checks out.

How the name match fails	What you observe	How to resolve it
The name on the letterhead is not the name on the list	You search the empanelment list for the brand you were given and find nothing, or find something close but not identical: a trading name against a registered name, “Pvt Ltd” against “Private Limited”, an ampersand against “and”, a dropped “Technologies” or “Services”, an old name after a rebrand.	Match the registered legal entity, not the letterhead. Ask the issuer for the exact registered name under which it is empanelled and its empanelment reference, then search the list on that. A specimen certificate that states the empanelment properly will carry the entity name and an empanelment letter number, while one that carries only a brand is asking you to do the reconciliation for it.
The empanelment lapsed between the audit and the certificate	Nothing at all. This is the defect that is invisible on the document: a certificate dated inside a period when the signing organisation was no longer empanelled looks exactly like one that is not. The list tells you about today, but the certificate is about a date in the past.	Ask the question in the right tense. You are not asking whether the organisation appears on today’s list — you are asking whether it was empanelled on the date the audit was performed and on the date the certificate was issued. Empanelment is granted for a stated period, so check the validity stated against the listing and compare it to the audit window on the certificate, not to today. Where the two do not overlap, the signature is not an empanelled signature for that engagement.
A parent, sibling or group company is on the list and the signing entity is not	The group name is unmistakably on the list. The entity in the signature block is a subsidiary, a regional arm, a differently incorporated affiliate, or an entity sharing a brand and a website but not a registration.	Empanelment attaches to a named legal entity and cannot be borrowed, shared or inherited. The entity that signs must itself appear. If the signing entity is not on the list, the correct answer is not “close enough” — it is to ask which empanelled entity is signing, and to have that entity sign.
The empanelment is real but the category of work is not what you bought	The organisation is on the list, on the right dates, under the right name — and the engagement was an audit class the listing does not describe.	CERT-In publishes snapshot information for each empanelled organisation, and the 2025 audit policy guidelines say at §12.1(i) that this information should be used by organisations and sectoral regulators to identify and select an auditing organisation. §12.1(ii) lists what an auditee can evaluate from it: manpower and skillset, relevant experience, categories of audit conducted, audits in the last twelve months by sector, category-wise counts, technical manpower deployed with details, and tools used. Read the snapshot before you sign, not after the report arrives.

The second row is the one worth carrying away, because it is invisible and because almost nobody performs it. You are not asking whether the organisation is on the list today. You are asking whether it was empanelled on the dates it performed your audit and issued your certificate. A document signed during a lapse looks exactly like one that was not.

Step two: read the certificate field by field

The fields below are those observed on security audit and safe-to-host certificates published on Government of India domains, read against what CERT-In’s own instruments require a report and certificate to carry. Take them in order. A document that survives all eleven is a document worth spending a written enquiry on, while one that fails three or four does not need the enquiry to tell you something is wrong.

Field	What a sound certificate states	What a weak or fabricated one states	How you check that field
Issuing legal entity and empanelment reference	The registered legal name of the auditing organisation, with the permitted empanelment sentence and, on better specimens, an empanelment letter number.	A brand or trading name only, “CERT-In certified”, “CERT-In approved”, or the CERT-In logo or emblem on the page. The last is itself a breach: clause 4.1 of the empanelment terms prohibits use of the logo or reference to the association on promotional material without prior written permission.	Search the registered name against CERT-In’s published list of empanelled organisations, applying the four failure modes above. Take the issuer’s contact details from the listing or its own published site — never from the document you are checking.
Certificate number and report reference number	Both present, distinct, and structured — a certificate number that identifies this document and a report reference that identifies the report behind it.	No number at all, a number with no report reference, or a certificate number that appears on other documents from the same issuer.	This is the pair you quote when you contact the issuer. A confirmation that matches both numbers to the same auditee, scope and window is worth far more than one that matches a company name.
Application or system name	The specific application, portal or system, named as your team names it, distinguishable from the issuer’s other work for the same client.	The company name where the application name should be, “the web application”, or a product family rather than a product.	Compare against the thing you are about to deploy, buy or rely on. A certificate naming a sibling product is a genuine certificate about something else.
Version, build or commit, and a hash	A version number or build identifier, and on the stronger specimens a hash value with its algorithm named. The 2025 audit policy guidelines require at §15.2.3(ii) that application hash values and version numbers be obtained from the auditee and included in the report, and at §9.5(i) that hash values, versions and timestamps be prominently featured in the audit certificate and reports.	No version at all, “latest”, or a version that does not correspond to anything in your release history.	Reconcile against your own release record. If a hash is given, recompute it on the artefact you hold. This is the single field that converts a certificate from a statement about a company into a statement about a build.
Environment tested, stated explicitly	Staging, pre-production, UAT or production, named. The 2025 guidelines require at §15.2.3(i) that the environment be specified, and at §16.3(v) that where the scope was limited to the staging platform the report must explicitly say the audit was not conducted on the production environment.	Silence. An environment named nowhere is the most common way a scope question is left open.	Ask what differed between the tested environment and production — authentication, data, integrations, WAF, rate limits. A staging build with authentication disabled tests something other than your application.
Hostnames, IP addresses and URLs in scope	The tested site URL and, on specimens that do this well, the separate testing URL, enumerated rather than summarised.	A single domain standing in for an estate, “and associated systems”, or no interface list where APIs exist.	Compare the list against your own asset inventory. Anything you run that is not on the list was not tested, whatever the conclusion says.
Test window dates	A start and end date for the testing itself, distinct from the issue date.	A single date doing duty for both, or a window that is implausibly short for the stated scope.	This is the date against which you check the issuer’s empanelment — not today’s date. It is also the date against which you check your own change history: what shipped after it is not covered.
Issue date	Stated, and later than the end of the test window.	Earlier than or equal to the start of testing, or absent.	Sequence it against the test window and against the closure evidence. A certificate issued before findings were closed is describing a different thing from one issued after.
The basis of validity	A stated rule, in the issuer’s own words. Published specimens word it as valid until changes are made to the hash value or dynamic content, or one year from issue, whichever is earlier. Others word it as a maximum validity of one year plus a statement that any change to the source of the tested application requires re-audit.	No validity statement, “valid indefinitely”, or a validity that survives a code change.	Read it against your release cadence, and against §13.1.2 of the 2025 guidelines: audit at least once a year, and a cyber security audit before implementation of any major change. Then decide in advance what counts as a major change for your application, and write it down.
Named signatory and designation	Signed by people the issuer can account for. The 2025 guidelines at §9.5(iii) require that reports be signed only by manpower declared to CERT-In in the organisation’s snapshot information, signed by the auditors who conducted the audit, reviewed and signed by a designated reviewer from mid-management who was not part of the audit team, and authorised and signed by the head of the auditing organisation — and that the audit certificate be signed by both the lead auditor and the head of the auditing organisation.	An unnamed signature, a single signature where the rule contemplates a lead auditor and a head of organisation, or a signatory who does not appear in the declared roster on a Government or critical-sector engagement.	Name the signatories when you contact the issuer and ask it to confirm them. On Government and critical-sector work you are entitled to ask which declared people performed the engagement.
Stated exclusions and limitations	An explicit list of what was out of scope and why, and of anything that could not be reached. §10.1(ii) of the 2025 guidelines requires inaccessible in-scope assets to be named in the report with reasons, and brought to CERT-In’s notice.	Nothing. A certificate with no exclusions is either describing a trivially small system or not telling you where it stopped.	Read this before the conclusion. It is the section that tells you what the conclusion is silent about, and it is the section most likely to be missing from a document that was never produced by an audit.

Step three: the verification request

Send it in writing, to the issuing organisation, at an address you obtained from the empanelment listing or the organisation’s own published site — never from the document you are checking. Verification that routes through the party being verified is not verification. Six lines, and one question:

01 The certificate number and the report reference number exactly as they appear on the document.
02 The application or system name as stated on the certificate.
03 The version, build or commit stated, and the hash value if one is given.
04 The test window — the start and end dates of the testing, not the issue date.
05 The names and designations of the signatories on the certificate.
06 One question, in one sentence: did your organisation issue this report and certificate, and does the scope, build and test window stated above match your record of the engagement?

Note the shape of the question. “Is this yours?” is answered yes by a real issuer looking at a document with its own letterhead, whether or not the scope on it has been edited. “Does the scope, build and test window stated above match your record?” is the question that catches an alteration, and it costs the issuer no more effort to answer.

A satisfactory reply

Comes from a person at the issuing organisation, on the organisation’s own domain, reached through contact details you obtained from the empanelment listing or the organisation’s published site. It confirms or corrects each element you quoted rather than answering in general terms, and it is willing to state that the reference numbers correspond to an engagement for that auditee. Legitimate auditors treat this request as routine, because it protects them from having their name used on documents they did not produce.

An unsatisfactory reply

Confirms “yes, that is ours” without engaging with the reference numbers, the build or the dates. Or it arrives from a personal mailbox, a free-mail domain, or the same address printed on the document you are checking. Or it redirects you to the supplier who gave you the certificate — verification that routes back through the party being verified is not verification. Or it declines on confidentiality grounds without offering the one thing confidentiality does not prevent: confirming that a document bearing its name and reference number is genuinely its own.

No reply at all

Not proof of forgery, and not something to ignore either. Escalate once, in writing, to a second published channel. If the organisation is on the empanelment list and simply does not respond, say so to your supplier and ask them to obtain the confirmation — a genuine issuer will answer its own client. If the organisation cannot be reached at any published address, you are holding a document you cannot verify, and that is the finding.

Step four: the verification file

Keep one per certificate, not one per supplier. Eight items, each of which proves something specific — and the value of the file is that it proves those things a year later, when nobody remembers what was checked or against which name.

What you retain	What it proves
The certificate itself, as received, with the date and channel it arrived on	What you were actually given, and by whom — which matters if the document is later amended or replaced.
The audit report behind it, including the exclusions and limitations section	How good the audit was, which the certificate never tells you. This is the artefact that answers scope, method, sampling and severity.
A dated screenshot or note of the empanelment check, recording the exact entity name searched and the validity period shown	That you checked, what the list said on the day, and against which name — the three things you cannot reconstruct a year later.
The issuer’s contact details and where you obtained them	That your verification did not route through the party being verified. Provenance of the contact route is part of the evidence.
The verification request you sent and the reply you received, in full	That the issuer stood behind this specific reference number, build and test window — not merely that the company exists.
The build reference: version, commit or hash, tied to your own release record	That the certificate covers the thing you deployed, and lets you date the release that will retire it.
The closure and re-test evidence for the findings, with the severity-wise timelines the report stated	That findings were closed rather than reported. §16.3(v) of the 2025 guidelines contemplates the final report being issued after closure and completion of the follow-up audit on the production environment.
Your own change log since the test window, with each change classified minor or major	Whether the certificate still describes your system. §13.1.2 makes the classification the operative question, and keeping the log is what makes the answer a fact rather than a recollection.

Worked example: a supplier’s certificate arrives in a procurement pack

A supplier returns a tender response. Inside it, between the insurance certificate and the ISO scope statement, is a one-page security audit certificate. It has a letterhead, a reference number, a conclusion sentence and two signatures. Nobody on the evaluation panel has been asked to look at it closely, and it will be ticked off in the compliance schedule by lunchtime unless somebody spends twenty minutes on it. Here is the twenty minutes.

Minutes one to five. Read the eleven fields. Write down the signing entity exactly as printed, the certificate and report reference numbers, the application name, the version or hash, the environment, the test window and the issue date. Note what is missing: on most documents that will be the version, the environment, or the exclusions.

Minutes six to twelve. Open CERT-In’s published list of empanelled organisations and search the signing entity, working through the four failure modes: the registered name rather than the brand, the validity period against the test window rather than today, the signing entity rather than the group, and the category of audit against the snapshot information.

Minutes thirteen to twenty. Find the organisation’s contact details independently. Send the six-line request. Save everything you have just done into a verification file with today’s date on it.

Then branch on what comes back, because the four outcomes need four different decisions. The signing entity is not on the list at all. Do not treat this as a formality to be cleared. Go back to the supplier and ask which empanelled entity performed and signed the audit. If the answer is that none did, then whatever you were handed, it is not a certificate from an empanelled organisation, and any requirement that specified one is unmet. Present, but not empanelled as at the audit date. Raise it in writing and ask the issuer directly which empanelment the engagement was performed under. There are innocent explanations — a renewal in progress, a listing updated late — and they are the issuer’s to give, not the supplier’s. Present, and confirmed by the issuer. Close the loop: file the reply, then read the report behind the certificate, because you have now established that the document is genuine and learned nothing at all about whether the audit was any good. The issuer does not respond. Escalate once in writing to a second published channel, then put the request to the supplier: a genuine issuer answers its own client. If it still cannot be reached at any published address, write the finding down as what it is — a certificate you were unable to verify — and let the commercial decision be taken with that on the table rather than off it.

Which is why the useful response to the AMBAK announcement is not to wait. Build the file. That file is verification today and reconciliation tomorrow. For the mechanics of doing it on a specific document, see how to verify a CERT-In audit certificate, and for who is permitted to issue one in the first place, who can issue safe-to-host certificates.

Who it changes something for

What AMBAK means for your organisation — four positions, four answers

“What does AMBAK mean for us” has no single answer, because the people asking stand in four different relationships to an audit. The column that matters is the last one: in every row, there is something to do this quarter that does not depend on any detail being published.

Where you stand	What plausibly changes	What to do now, regardless
A Government department or PSU commissioning an audit	You already hold the strongest position of any auditee: your project authority can require the auditor to be empanelled, can require the report as well as the certificate, and can require closure evidence. Central monitoring, if it develops as the name suggests, adds an independent way to confirm what you were handed.	Write the report, the closure evidence and the empanelment check into the tender and the purchase order, not into the review meeting after go-live.
A private company buying a VAPT or security audit	Nothing about AMBAK is addressed to you directly, and nothing in the release suggests private audits are in scope of anything announced. What changes is the market: an ecosystem being measured tends to tighten, and the questions a monitored auditor asks you are usually the questions a good auditor should have asked anyway.	Ask which empanelled entity signs, ask what is in scope, and ask for the report. Those three questions separate a real engagement from a certificate purchase, with or without a platform.
An enterprise buyer relying on a supplier’s certificate	You are the constituency a verification capability would serve most. Today a certificate handed to you in a procurement pack is a document you largely have to take on trust unless you contact the issuer yourself.	Contact the issuing organisation using independently obtained details and confirm the reference, scope and date. Treat this as routine rather than accusatory — legitimate auditors expect it.
A CERT-In empanelled auditing organisation	Reporting duties that already exist become more consequential where they feed a comparison. Five-day report submission, the quarterly return and declared manpower are not new, but being benchmarked on what they contain would be.	Make the submissions accurate and on time, and make the underlying work survive inspection — including the maker-checker requirement at §15.2.5(iii) of the 2025 audit policy guidelines, that a separate verification team reviews and validates the audit team’s work.

The engagement itself

What a benchmarked audit would be benchmarked against

If audits are going to be compared, it is worth knowing what a properly conducted audit is already required to look like. CERT-In publishes guidelines for its empanelled information security auditing organisations, and they are more specific than most auditees realise. Every line below is drawn from those guidelines. Every line is also a question an auditee is entitled to ask before signing.

The expectation	What the guidelines say	What to ask before you sign
Two teams, not one	An empanelled organisation should deploy a verification team — a red team — to verify the work performed by its audit team, the white team. Internal verification of testing is a structural expectation, not an upsell.	Who verified the testing, and what did the verification change? An engagement where the answer is “nobody” has one layer of assurance where the guidelines contemplate two.
Methodology over tooling	Auditors must use industry-standard methodologies and best practices for security testing. Solely tools-based testing should be discouraged.	Which methodology, and what was tested by hand? Business-logic flaws, authorisation boundaries and chained weaknesses do not appear in scanner output.
The environment is stated	The auditor must clearly state the environment in which the application was tested, and the audit is performed on the staging or testing environment provided by the hosting service provider before the certificate is issued.	Does the tested environment match production in configuration, data handling and integrations? A staging build with authentication disabled tests something other than your application.
Written approval before testing, and before tools land	Penetration tests and the installation of testing tools require written approvals. 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 with written confirmation of intellectual-property and licensing status.	Has the approval been given in writing, by someone entitled to give it, for a defined window? This protects the auditee at least as much as the auditor.
Destructive testing is out	Auditors are to refrain from carrying out distributed denial of service testing over the internet, from any form of flood testing, and from testing or exploiting high-risk vulnerabilities such as discovered breaches or those that may put lives at immediate risk.	How will availability-affecting classes of weakness be evidenced without being exercised? A good answer is configuration and architecture review. A bad answer is silence in the report.
Data stays in India, then stops existing	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 the auditee specifically authorises it.	Where will our data live during the engagement, and what is the wipe evidence at the end? Name the platforms, not the policy.
Findings carry closure timelines	Observations must be supported by objective evidence compiled with the report, and the report should state appropriate timelines for closure of vulnerabilities according to severity.	What are the severity-wise timelines, and who owns each finding? A report without them hands you a list instead of a plan.
The expectation gap is closed before work starts	The audit process, the collection of artefacts and the deliverables are to be explained in detail upfront, the deliverable structure agreed with the auditee before commencement, and the audit team composition shared with documented approval obtained before formal commencement.	Do we have the deliverable structure and the team composition in writing before day one? Almost every dispute in an audit engagement traces back to this step being skipped.
Confidentiality binds with or without paperwork	A formal non-disclosure agreement is to be in place prior to the start, and auditors are ethically bound to confidentiality with or without one. Auditors sign an NDA with their employer at joining and may need one with the auditee as well.	Is the NDA executed before scoping, not before delivery? Scoping conversations are themselves sensitive.
CERT-In is not a party to your contract	The guidelines direct auditors to ensure that CERT-In is not made a part of any contract between auditee and auditor, and clause 2.1 of the empanelment terms states that CERT-In is not a party to such contracts.	Does the contract or proposal imply CERT-In endorsement, supervision or involvement? It should not, and a proposal that does is a warning about everything else in it.

Where the next generation of scope is forming

The instruments above describe a practice built around applications and networks. Four subject areas from the conference programme describe where that practice is being asked to go, and they are the four organisations most often leave out of a scope document. AI red teaming is two different engagements under one name — adversarial testing of an AI system, and the use of AI inside conventional testing — and a scope should say which it means. Cloud findings are usually in the control plane rather than the application, which is why a cloud line item needs read access to the accounts and not just a URL and a test user. APIs and machine-to-machine surfaces are the interfaces with no interface: an auditor cannot test what nobody listed, which makes the API inventory an auditee deliverable. Operational technology and IoT break the assumptions an IT audit runs on, and the bill-of-materials family — software, cryptographic, quantum and hardware — is what turns “are we affected” from a week of meetings into a query. Each of the four is treated at length, with what belongs in a scope document and what goes wrong, in CERT-In SAMVAAD 2026 and what it signals for audit scope.

The sequence

What to do now, without waiting for anything

None of these ten steps depends on a detail that has not been published. Run them and you are ready for whatever AMBAK becomes. Skip them and no platform will save the engagement.

01 Separate the two questions before anything else: what has been officially announced about AMBAK, and what you need to be true for a decision you are taking this quarter. The first is one press release. The second is usually answerable today, without a platform, using the empanelment list and the report behind the certificate.
02 Establish which class of work you are actually commissioning. A Government website or application heading for production needs an audit clearance certificate from one of the bodies permitted to issue it. A commercial VAPT is a different engagement with a different deliverable, and conflating the two is a costly scoping error — costly because it is discovered at the end, when the deliverable does not satisfy the requirement it was bought for. The decision table below settles it in one row.
03 Check the empanelment status of the signing organisation against CERT-In’s published list before you sign anything, not after you receive the certificate. Record the entity name exactly as it appears on the list, because that is the name that has to appear on the report.
04 Agree scope in writing, in terms a third party could evaluate: the application and build, the environment, the hostnames and interfaces, the integrations, the exclusions and the reason for each. Scope is the field that determines what the certificate is worth, and it is the field most often left to a sentence.
05 Agree the rules of engagement in the same document: approval windows, tooling and its removal, prohibited test classes, where data will reside, how it will be wiped, and who from the declared roster will perform the work.
06 Prepare the staging environment before the auditor is booked. An audit performed on a build that does not resemble production produces findings that do not resemble your risk, and pressure to test where you should not.
07 Insist on the report, not only the certificate, and insist that observations come with objective evidence and severity-wise closure timelines. Read the limitations and exemptions section first — it tells you what the conclusion is silent about.
08 Close the findings, have the closure verified, and keep the re-test artefacts with the certificate. Closure asserted by the party that did the fixing is not closure evidence, and the follow-up audit is part of the sequence rather than an optional extra.
09 Classify changes from that point on. Validity follows change rather than the calendar: as worded on published specimen certificates, and consistent with §13.1.2 of the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) — audit at least once a year, and a cyber security audit before implementation of any major change — a certificate holds until a major change is made to server-side application code, or one year, whichever is earlier. Build the classification into release management so the question is answered by the process rather than by a person’s memory, and confirm the exact position with the issuing body.
10 Keep a verification file per certificate, to the eight-item specification set out earlier on this page. If central verification becomes available, this file is what you will reconcile against. If it does not, this file is the verification.

Step two in a table: which deliverable do you actually need?

Start from the trigger, not from the service catalogue. Most of the expensive confusion in this field comes from buying a VAPT when the requirement was a clearance certificate, or buying a certificate when what the customer actually wanted to read was the report.

Trigger	What you actually need	Who may issue it	What the deliverable is	Where its validity comes from
A Government website, portal, web application or mobile app going to production	A security audit culminating in an audit clearance certificate — the deliverable the sector calls a safe-to-host certificate.	NIC, STQC, an STQC-empanelled laboratory, or a CERT-In empanelled laboratory. GIGW 5.3.1 names those four and no others.	A report plus a certificate naming the application, version, environment and test window, issued before hosting in the production environment.	From the certificate’s own wording, reinforced by §13.1.2 of the 2025 guidelines: annually, and again before any major change is implemented.
A private-sector VAPT with no Government nexus	Vulnerability assessment and penetration testing, scoped to your risk rather than to a clearance rule.	Any competent testing firm. Empanelment is not a legal requirement here — though buyers increasingly ask for it, and an empanelled auditor is bound by published rules of engagement that an unempanelled one is not.	A report with findings, evidence, severities and remediation guidance, and a retest. There is no statutory certificate at the end of this, and a firm offering one is describing a document with no instrument behind it.	Set by your own policy and release cadence. §6 of the 2025 guidelines states the general expectation that auditees cover all aspects of their ICT systems at least once a year.
An audit demanded by a customer, a sectoral regulator or a tender	Whatever the demanding document actually specifies — read it before scoping anything.	Determined by that document. The only verified link between empanelment and regulators is §12.1(i) of the 2025 guidelines, which says CERT-In’s snapshot information should be used by organisations or sectoral regulators to identify and select auditing organisations.	Usually the report, and often closure evidence, rather than a certificate. Ask the requesting party which artefact satisfies them before you buy one.	Set by the requesting party. Get it in writing at the same time as the requirement.
A cloud or API assessment	A scope that names the control plane and the interface inventory as separate line items, not a web-application test with cloud in the preamble.	As above, by whether a clearance certificate is required. §13.1.1 of the 2025 guidelines puts APIs, cloud, databases and hosting infrastructure inside the audit scope in their own right.	Findings against cloud identity and access configuration, storage and network policy, logging, pipeline reach, and each API surface — including the ones with no user interface in front of them.	Shorter in practice than an application certificate, because cloud configuration changes without a release. Treat configuration drift as the trigger.
An AI system red team	A scope that says which of the two things called AI red teaming it means: adversarial testing of an AI system, or the use of AI inside conventional testing.	As above. §6 of the 2025 guidelines lists AI System Audits and Red Team exercises among its twenty-six classes of engagement, so this is inside the published scope framework rather than outside it.	Findings against prompt injection through untrusted content, extraction of system instructions or training data, safety-layer bypass, and abuse of tool-calling and agentic permissions — plus the conventional findings in the surrounding application.	Model, prompt and tool changes all invalidate prior testing. Tie re-testing to changes in the model version, the system prompt and the tool permissions, not to a date.

Steps two and four are where engagements are won or lost. Commissioning the wrong class of work produces a deliverable that does not satisfy the requirement it was bought for, and a thin scope statement produces a certificate that is true about very little. For the Government-side version of step two, see how to get a safe-to-host certificate and GIGW compliance before go-live, and for the distinction step two turns on, safe-to-host versus security audit certificate.

Evidence

What to ask for, and what does not count

Six statements you will be handed, and what each one is worth before you have checked it. The right-hand column is the important one: in this field, the artefact that gets accepted most readily is usually the artefact that proves least.

The claim you are handed	What to ask for	What does not count
“We are CERT-In certified.”	Which is it — an empanelled auditing organisation, or an organisation that was audited by one? The two are unrelated, and the phrase blurs them.	A logo. CERT-In’s guidelines prohibit an auditor from using the CERT-In logo or referring to its association with CERT-In on publicity or promotional material without prior written permission, and permit exactly one formulation of the relationship in words. An organisation advertising with the logo is telling you something about its compliance culture.
“Our audit was done by an empanelled firm.”	The name of the empanelled legal entity, checked against CERT-In’s published list, and confirmation of who will sign the report and the certificate.	A subcontractor relationship left vague. The entity on the list and the entity that signs should be the same, and you are entitled to know which people from the declared roster performed the work on Government and critical sector engagements.
“Here is our security audit certificate.”	The report behind it. The certificate carries a conclusion, while the report carries the method, the scope, the findings, the sampling, the exemptions and the limitations.	A certificate with no scope statement, no version or build reference, no date and no reference number. Those four fields are what make a certificate checkable at all.
“All findings are closed.”	The closure or re-test evidence, and the severity-wise closure timelines the report was required to state.	A status column in a spreadsheet with no re-test artefact behind it. Closure asserted by the party that had to do the fixing is the claim, not the evidence for it.
“The audit covered the whole application.”	The environment it was performed in, named explicitly, and the list of what was excluded. The guidelines require the auditor to state clearly the environment in which the application was tested.	Silence about exclusions. Unstated scope is a reliable way for a clean certificate to end up describing a system nobody fully examined.
“AMBAK verifies this certificate.”	Where that is published, and from what date. Then check it with CERT-In.	A vendor blog, a professional-network post or a slide. Ask instead for the certificate number, the build and the test window, and verify the document the way this page sets out — that method works today and does not depend on anything being announced.

The first row deserves its own note, because the phrase is everywhere and it is never correct. “CERT-In certified” describes nothing that exists. CERT-In empanels auditing organisations. It does not certify the organisations they audit, and it does not certify the auditors either. The guidelines are unusually precise about the language an empanelled auditor may use: 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. The same guidelines prohibit use of the CERT-In logo, or any reference to the auditor’s association with CERT-In, on publicity or promotional material without prior written permission. An organisation that has put the CERT-In emblem on a slide has told you something useful before you have read a word of its methodology. For the full picture, see what CERT-In empanelment actually means.

Failure modes

What goes wrong around an announcement like this

Nine failure modes, in rough order of how soon they bite. The first is specific to this news cycle. The rest have been failing audits for years and will keep doing so whatever platform exists. Each carries a detection line, because a failure mode you cannot test yourself against is a warning rather than a control.

A date got into a contract before it got into an instrument

The harm from the AMBAK commentary was never going to be a security failure — it was a commercial commitment. A clause promising that certificates would be centrally verifiable from a particular date, or a customer assurance built on that promise, inherits whatever the underlying claim is worth. That date has now passed, and nothing has been published behind it: clauses written against it are clauses written against a date that arrived with nothing attached. Somebody now has to go back to the customer, the board or the regulator and explain a commitment that was never sourced.

How to tell whether you are in it. Search your contract templates, security addenda, customer-facing trust pages and compliance calendar for “AMBAK” and for July 2026. Anything that turns up is a commitment to reconcile now rather than when someone else finds it.

Verification is treated as a substitute for reading

A verified record answers whether an audit happened and who performed it. It does not answer whether the scope matched your system, whether the testing was more than tool output, whether findings were genuinely closed, or whether the environment tested resembled production. Every one of those questions lives in the report. Organisations that stop reading because a lookup went green will fail on the same things they fail on now, slightly faster.

How to tell whether you are in it. Count how many supplier certificates you hold against how many supplier reports you hold. Where the second number is much smaller, you are relying on conclusions you have never seen the basis for.

The empanelment check is skipped because the document looks official

Letterheads, reference numbers, seals and signatures are all trivially reproducible. The published list of empanelled organisations is the cheapest control available to any buyer and the only one that needs nobody’s cooperation — and it is easily skipped, usually because the document arrived inside a procurement pack and therefore felt pre-validated.

How to tell whether you are in it. Pick three certificates you already hold and search the signing entity’s registered name against the list today. If you cannot tell from your own file which exact entity name to search, that is the finding.

The empanelment lapsed between the audit and the certificate

Empanelment is granted for a stated period, and a certificate is about a date in the past. An organisation that appears on today’s list may not have been empanelled when it performed your audit, and an organisation that performed your audit while empanelled may have lapsed since. Neither situation leaves a mark on the document, which is what makes this the defect most likely to survive a diligence review unchallenged.

How to tell whether you are in it. Compare the validity period stated against the listing with the test window on the certificate — not with today’s date. Where the two do not overlap, ask the issuer directly which empanelment the engagement was performed under.

A certificate is treated as covering the organisation rather than the build

A security audit certificate is about a named application at a named version, tested in a named environment, on a stated date. It is not a statement about the company, its other products, or its infrastructure. Departments that file it as an annual compliance artefact rather than a release artefact will be out of date by their third deployment.

How to tell whether you are in it. Put the certificate’s stated version or hash next to your current release tag. If nobody in the room can do that in a minute, the certificate is not being managed as a release artefact.

The audit is scoped to the web application and the finding lives elsewhere

The cloud control plane, the internal API nobody documented, the CI/CD pipeline that can deploy to production, the OT segment reachable from the corporate network. §13.1.1 of the 2025 audit policy guidelines describes a scope covering the entire cyber infrastructure — web and mobile applications, APIs, OT and ICS, cloud, databases, hosting infrastructure, code review and incident-response testing — derived from a consolidated and updated asset inventory. A scope drawn around the login page produces a certificate that is true and useless.

How to tell whether you are in it. Lay the certificate’s scope list beside your asset inventory and mark what is on one and not the other. The gap is your uncovered surface, and it is usually larger than the team expects.

Tool output is mistaken for an audit

Both instruments are direct about this: the auditor guidelines say auditors must use industry-standard methodologies and best practices for security testing and that solely tools-based testing should be discouraged, and §8 of the 2025 guidelines repeats it — adding the 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. A report whose findings are a scanner export with severities copied across has not met that bar.

How to tell whether you are in it. Read the findings for evidence of manual work: business-logic flaws, authorisation boundaries crossed, chained weaknesses, anything requiring a second request to discover. A report with none of those is a scan with a cover page.

Testing happens against production because staging was not ready

Both instruments contemplate the audit being performed on the staging server or testing environment provided by the hosting service provider before the certificate is issued — the 2025 guidelines state it at §15.2.3(ii), and require at §16.3(v) that a report limited to staging say explicitly that the audit was not conducted on production. Teams that treat the staging build as an afterthought create pressure to test somewhere they should not.

How to tell whether you are in it. Ask what the staging environment lacks that production has: authentication providers, real integrations, WAF, rate limiting, representative data volumes. Each gap is a class of finding the audit could not reach.

Nobody checks that data stayed in India

The instruments require the auditor to ensure there is no mirroring of data outside the country, to store auditee data only on systems located in India, to encrypt it on auditor laptops, and to wipe it after completion so that it cannot be retrieved by any known forensic technique — with, under §10.3 of the 2025 guidelines, a formal certificate of deletion to the auditee. Offshore analysis teams and cloud-hosted testing platforms are where this quietly breaks, and the auditee is the party that suffers.

How to tell whether you are in it. Name the platforms, which is the ask one row earlier and is exactly what gets skipped here. Four specific questions. In which region is the scanning or testing platform hosted? Where does the jump host or bastion used to reach our environment sit? In which tenancy region do the ticketing and reporting SaaS tools hold our findings? And what is the wipe evidence at closure, including the certificate of deletion? Ask them in the scoping call, in writing, before access is granted.

How audit certificates are actually faked

This is the part nobody in India sets out plainly, and it is the reason the prospect of central verification generates so much interest. Six modes. Note that they get harder to catch as you go down the list, and that the last three are not forgeries of a document at all — they are true documents put to a false use, which is precisely the class no authenticity check ever built will catch for you.

Mode	What it looks like on the document	The one check that catches it
A wholly fabricated issuer	A plausible security firm, a professional letterhead, a website that exists, and a certificate that says everything it should. Nothing about the document is wrong because nothing about it is real.	The empanelment list. An issuer that does not appear on it under any registered name has no standing to issue a certificate that requires one, and this is settled in two minutes without contacting anybody.
A real empanelled organisation’s name with a fabricated signatory	The entity checks out on the list. The signature block names people who do not work there, or names nobody at all, or carries one signature where the rule contemplates a lead auditor and a head of organisation.	Contact the named entity with the certificate number, the report reference and the signatory names, using contact details from the listing rather than the document. §9.5(iii) of the 2025 guidelines sets out who must sign, and an organisation asked to confirm its own signatories will answer.
A genuine certificate with the scope or build edited	A real document from a real issuer, with the application name, version, hostnames or test window altered — usually to make a narrow engagement appear to cover a wider one, or an old build appear to be the current one.	Quote the reference number back to the issuer and ask it to confirm the scope and build from its own record, rather than to confirm that the document is theirs. The question “is this yours” is answered yes, while the question “does the scope stated here match your record” is what catches the edit.
A genuine certificate for a sibling product presented as covering this one	Entirely authentic and entirely unaltered. The only defect is the mapping: the certificate is real, the audit happened, and it was about a different application in the same portfolio.	Read the application name and version against the specific system you are buying or deploying. This is the failure that survives every authenticity check ever built, including any future central one, because nothing about the document is false.
A genuine certificate whose issuer’s empanelment had lapsed at the audit date	Correct in every field. The entity is on the list today, or was on it once. The test window falls outside the period for which the empanelment was granted.	Compare the empanelment validity period against the test window on the certificate, not against today. This is the check almost nobody performs and the one this page would most like readers to take away.
A non-empanelled subcontractor asserting the empanelled partner’s standing	A consultancy that performed the work presents the empanelled organisation’s status as though it were its own, or issues its own document referencing a partner’s empanelment.	Ask who signs, and require the empanelled entity to sign. On Government and critical-sector work, §10.2(vi) of the 2025 guidelines requires the auditing organisation to deploy only manpower declared to CERT-In in its snapshot information form, and §12.2(iii) tells the auditee to verify identities, ID cards and designations — and states that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving notice.

For the application-side version of these — the specific technical and process reasons a build is turned away — see why applications fail safe-to-host, and for how long a certificate survives a release cycle, safe-to-host certificate validity.

Edge cases

Where this gets awkward in practice

Seven situations that arise in engagements and procurement reviews, and the answer in each.

A supplier sends you a certificate and a screenshot of a verification result

Treat the screenshot as the least reliable element in the package. A screenshot is a picture of a claim. It inherits none of the properties that make a verification meaningful. Where a verification capability exists and you are entitled to use it, perform the lookup yourself. Where it does not, contact the issuing organisation using details you obtain independently — from the empanelment list or the organisation’s own published contact page — rather than from the document you are checking. Verification that routes through the party being verified is not verification.

Your auditor tells you AMBAK requires something new of you

Ask which instrument imposes the requirement. The obligations that exist today are well documented: incident reporting within six hours for the twenty Annexure I categories, logs maintained for a rolling 180 days within Indian jurisdiction, the five-year subscriber-record retention that applies to data centres, virtual private server providers, cloud service providers and VPN service providers, and the auditor-side duties described on this page. A new obligation would arrive as a direction, a rule or a published guideline — not as a paragraph in a proposal.

The audit was performed by a subcontractor of the empanelled organisation

The question is who signs and whose declared people performed the work. For Government and critical sector audits the guidelines require the organisation to deploy manpower declared to CERT-In in the snapshot information form, and CERT-In may verify this independently or through either the auditing or the auditee organisation. Subcontracting that puts undeclared people on a Government engagement is a problem on the day somebody checks, and the certificate is not improved by the fact that nobody has yet.

An auditor moves to another empanelled organisation mid-engagement

The guidelines make this an explicit background-check matter: moving between CERT-In empanelled organisations requires a no-objection certificate or relieving letter from the previous organisation as part of the new employer’s pre-employment checks. For the auditee the practical consequences are continuity and confidentiality — who now holds your data, under which NDA, and does the declared roster for your engagement still describe the people on it.

The finding is in an AI component nobody scoped

Two things are already true and they point the same way. Attacks or malicious or suspicious activities affecting systems, servers, software or applications related to artificial intelligence and machine learning are a mandatorily reportable incident class under the 2022 Directions, and AI-driven cyber risks and AI-driven red teaming methodologies were both named subject areas at SAMVAAD 2026. An organisation running model inference, retrieval pipelines or agentic tooling inside a system it is having audited should scope those components deliberately, because the reporting obligation does not wait for the audit practice to mature.

You are asked to prove an audit happened for a period that predates any platform

Your own file is the answer, and this is the argument for keeping one. The engagement letter, the scope statement, the report with its evidence, the closure artefacts, the certificate and the empanelment check you performed at the time constitute a complete account of the engagement, independent of any register. Organisations that keep this per-certificate file answer diligence questions in an afternoon, while organisations that keep only the certificate spend a week reconstructing a story.

A press release is your only source and you need more certainty

Write to CERT-In, and if the answer has to withstand challenge, use the Right to Information Act, 2005 as well. The agency publishes contact channels and has a statutory remit under section 70B of the Information Technology Act, 2000. An RTI application to the public information officer of CERT-In or of the Ministry of Electronics and Information Technology produces a dated, signed, attributable reply. Both are slower than reading a blog, and between them they are the only methods that produce something you can put in front of a regulator, a customer or a board. The four things to put in the enquiry are set out in the method section above.

Objections

Questions we are being asked about AMBAK and the answers that hold up

Six questions the announcement raises, and the answer that holds up in each. In every case it is the one that separates what is published from what is assumed.

“Our compliance vendor said certificates become verifiable through AMBAK from 15 July 2026. Where does that stand?”

The date has passed. As at 18 September 2026, no verification service for audit reports or certificates has been published by CERT-In as indexed, and the date itself has never appeared in an official source — not in the press release, and not in CERT-In’s own 666-page conference proceedings, which were produced after it. Go back to whoever gave you the date and ask for the source now rather than waiting. If an official one exists, this page would rather be corrected than be comfortable. In the meantime, audit the commitments that date has already been written into: contract clauses, security addenda, trust pages, compliance calendars. Reconciling those yourself is considerably cheaper than having a customer do it for you.

“Is AMBAK blockchain-based? Everyone says so.”

Everyone saying so is not a source, and here there are two official accounts to check rather than one. Neither describes an architecture. AMBAK appears seven times in CERT-In’s conference proceedings — a contents line, an inaugural-ceremony sentence, a section heading, two paragraphs of purpose, a photo caption and an abbreviations entry — and blockchain appears in that document only as a technology discussed at the conference and the subject of submitted papers. That proximity is almost certainly how the claim was born. The honest position is that the architecture is not public, and that it probably does not bear on your decision anyway: what a verification capability is worth depends on its coverage and its accessibility, not on its data structure.

“Does this mean our existing audit certificates are no longer valid?”

No, and validity is governed by the instruments that already govern it. As worded on published specimen certificates, and consistent with §13.1.2 of the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) — audit at least once a year, and a cyber security audit before implementation of any major change — a certificate holds until a major change is made to server-side application code, or one year, whichever is earlier. It is your release cadence rather than any announcement that determines where you stand. If your certificate is out of date, it was out of date before April 2026. If it is current, an announcement does not retire it. Where the answer matters commercially, confirm it with the body that issued the certificate.

“We are not a Government department. Does AMBAK apply to us?”

Nothing in the release states that it does, and nothing states that it does not — the release announces a launch without defining scope. What is clear is the direction of travel, and it is worth taking seriously even in the absence of detail: a national body that monitors, benchmarks and analyses audits is describing an ecosystem in which the quality of an audit is visible rather than assumed. Commercial buyers can act on that today by asking the three questions that separate an engagement from a certificate purchase: who signs, what is in scope, and may we see the report.

“Can we say we are AMBAK-verified?”

No, and the instinct is worth examining. There is no published verification mark, no criteria and no published grant process — so the claim would be unfounded on its face. More generally, CERT-In constrains claims about its name tightly: an empanelled auditor may not use the CERT-In logo or refer to its association with CERT-In on publicity or promotional material without prior written permission, and the guidelines permit exactly one sentence of description. An organisation inventing a badge in that environment is signalling something about how it treats every other claim it makes.

“If benchmarking is coming, should we change auditors?”

Change auditors for reasons you can evidence today. The useful test has nothing to do with the platform: does the organisation appear on the empanelment list, does it deploy a verification team over its own audit team, does it test beyond tool output, does it state the environment it tested, does it give you closure timelines by severity, and does it keep your data in India and wipe it afterwards. An auditor who does all of that will benchmark well under any measure anyone eventually publishes, and is producing better work for you in the meantime. An auditor who does none of it is a problem now, not in a future quarter.

Who does what

The roles, stated plainly

Here is who is responsible for each part of a CERT-In audit engagement under CERT-In’s own rules.

Activity	Who owns it	What everyone else does
Being empanelled by CERT-In	The empanelled auditing organisation	Empanelment is a standing held by a named legal entity and published by CERT-In.
Performing the audit or penetration test	The empanelled auditing organisation, on engagements where empanelment is required	On Government and critical-sector work, §10.2(vi) of the 2025 guidelines requires the auditing organisation to deploy only manpower declared to CERT-In in its snapshot information form.
Signing the audit report	The empanelled auditing organisation	Under §9.5(iii) of the 2025 guidelines, reports are signed only by manpower declared to CERT-In, and the audit certificate is signed by both the lead auditor and the head of the auditing organisation.
Issuing the security audit or safe-to-host certificate	The empanelled auditing organisation, where a certificate is applicable	For Government sites and applications the certificate may only be issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory — GIGW’s phrase for what CERT-In’s own instruments call an empanelled information security auditing organisation. It is the same body, under two names, which is worth knowing before you search the empanelment list for the word “laboratory” and fail to find it.
Submitting audit reports and metadata to CERT-In	The empanelled auditing organisation	The five-day submission duty and the quarterly return sit with the empanelled entity under its empanelment terms. An auditee neither files nor controls those submissions, and should not be told otherwise.
Reporting a cyber incident within six hours	The affected organisation itself	This duty is the auditee’s, under the Directions of 28 April 2022, and it is not discharged by anyone else. TCSA helps build the detection, triage and reporting path in advance. The report is filed by the organisation.
Closing the findings	The audited organisation	Verification of closure is performed by the auditor as part of the follow-up audit.

Where we fit

We deliver CERT-In audits

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. If AMBAK has you thinking about your next audit, we would be glad to talk it through.

See how a CERT-In audit runs with us

References

The primary sources, named and linked

A page that tells you eight times to find the source should hand you the sources. These are the documents every statement on this page traces to, each named with its issuing body, its version and its date. All were read directly. Where a later version exists, it supersedes what is written here.

Press Information Bureau, Government of India, Ministry of Electronics & IT, release ID 2256581, “CERT-In SAMVAAD 2026”, 29 April 2026. The announcement of the AMBAK launch, and the source of the conference figures. pib.gov.in
Indian Computer Emergency Response Team, CERT-In Samvaad 2026 — Conference Proceedings, 2nd Edition, 666 pages. CERT-In’s own account of the event. Section 7.1 is the fullest published description of AMBAK that exists. cert-in.org.in
CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. Binding on empanelled auditing organisations and covered auditees. Source for the five-day duty (§10.6), the signature rule (§9.5(iii)), maker-checker (§15.2.5(iii)), scope (§13.1.1), and the annual and major-change rules (§13.1.2). cert-in.org.in
CERT-In, Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment, version 7.2, April 2024. Source for clause 2.1 (CERT-In is not a party to your contract), clause 3.2.2 (the five-day submission) and clause 4.2 (the one permitted sentence about the relationship). cert-in.org.in
CERT-In, Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018. Source for the red-team/white-team verification expectation, the methodology-over-tooling rule, the prohibited test classes and the data-residency duties. cert-in.org.in
CERT-In, published list of empanelled information security auditing organisations, with snapshot information per organisation. The document against which every empanelment check on this page is performed. cert-in.org.in
Directions under sub-section (6) of section 70B of the Information Technology Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022, including Annexure I. Source for the six-hour reporting duty, the twenty reportable incident types, the 180-day log retention and the five-year subscriber records. cert-in.org.in
Guidelines for Indian Government Websites and Apps (GIGW 3.0), guideline 5.3.1, National Informatics Centre with STQC and CERT-In. Source for the four bodies permitted to issue an audit clearance certificate before production hosting. guidelines.india.gov.in

Sources last checked 18 September 2026. This page states a number of negative findings — that a claim appears in no official source, that no verification service has been published — and a negative finding is only as good as the date attached to it. If you are reading this well after that date, check the two CERT-In sources above before relying on the negatives. If the position has changed, we would rather be told and correct the page than be quoted accurately on something that has moved.

Frequently Asked Questions

What is AMBAK?

AMBAK is a platform launched by CERT-In, the Indian Computer Emergency Response Team, at CERT-In SAMVAAD 2026, the conference held from 27 to 29 April 2026. Its name stands for Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. CERT-In’s own conference proceedings describe it as launched “to support audit monitoring, benchmarking, analysis and targeted interventions”, reflecting “the need for structured mechanisms to strengthen audit effectiveness, improve visibility into audit outcomes and support continuous improvement in cybersecurity assurance”, and frame it around “data-driven approaches in assessing audit maturity, identifying gaps, enabling benchmarking and supporting informed decision-making across the cybersecurity audit ecosystem”. That is the fullest published description that exists. Nothing operational — architecture, scope, access, coverage or commencement — has been published.

What does AMBAK stand for?

Audit Monitoring, Benchmarking, Analysis and Kinetic Interventions. The expansion appears in the Government of India press release of 29 April 2026 and three times in CERT-In’s conference proceedings, including the Abbreviations annexure. Read as a description of purpose it covers four things: central visibility over information security audits, comparison of audits or auditing organisations against one another, aggregate analysis of what audits collectively show, and action taken on the basis of that analysis. CERT-In’s own paraphrase of the fourth component is “targeted interventions”.

Is there an AMBAK portal or login?

No AMBAK portal, web address or login has been published. Neither official account of the launch gives a URL, and no such portal appears on cert-in.org.in as indexed as at 18 September 2026. If you have been sent a link described as the AMBAK portal, treat it the way you would treat any unverified link that arrived attached to a compliance claim, and ask the sender for the official page it came from.

How do I register for AMBAK?

There is nothing published to register for. No enrolment, onboarding or application process has been announced for auditees or for auditing organisations, and no criteria or forms have been published. An invitation to register your organisation for AMBAK is not something CERT-In has published a process for, and should be traced back to its source before anyone acts on it.

Is AMBAK mandatory for my organisation?

Nothing published imposes any obligation on any organisation in connection with AMBAK. The launch announcements create no duty, no filing, no registration and no deadline. The CERT-In obligations that do apply to an audited organisation today are the ones already in force under the Directions of 28 April 2022 — reporting the twenty categories of incident in Annexure I within six hours, maintaining logs for a rolling 180 days within Indian jurisdiction, synchronising clocks to NIC or NPL time sources, and the five-year subscriber-record retention that applies to data centres, virtual private server providers, cloud service providers and VPN service providers. A new obligation would arrive as a direction, a rule or a published guideline, not as a paragraph in a proposal.

Who built AMBAK?

Not stated in either official account. The press release and CERT-In’s conference proceedings both record that AMBAK was launched at CERT-In SAMVAAD 2026 and that the conference was conceived and executed under Dr. Sanjay Bahl, Director General of CERT-In. Neither names a developer, a technology partner, a vendor or an implementing agency for the platform itself. Any attribution you encounter is therefore unsourced unless it cites something neither of those documents contains.

What is the difference between AMBAK and CERT-In empanelment?

They are different kinds of thing. Empanelment is a standing held by a named legal entity: CERT-In empanels information security auditing organisations to undertake audits, including vulnerability assessments and penetration testing, of government and other organisations, and publishes the list along with snapshot information about each. It is governed by the Terms and Conditions for Empanelment (v7.2, April 2024) and the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025), and it is what determines who may sign an audit report and issue a certificate. AMBAK is a platform announced as supporting audit monitoring, benchmarking, analysis and targeted interventions. Nothing published suggests it replaces, alters or supplements empanelment, and there is no AMBAK equivalent of being on the list.

Is AMBAK blockchain-based?

That claim appears in vendor blogs and professional-network commentary, and in neither official account. There are two to check: the press release, and CERT-In’s 666-page conference proceedings. AMBAK appears seven times across the proceedings — a contents line, an inaugural-ceremony sentence, a section heading, two paragraphs of purpose, a photo caption and an abbreviations entry — and blockchain is not connected to it in any of them. Blockchain does appear in both documents, as one of the technologies discussed at the conference and the subject of submitted papers, which is almost certainly how the claim was born. The architecture is simply not public.

Did AMBAK verification go live on 15 July 2026?

No verification service for audit reports or certificates has been published by CERT-In as indexed, and as at 18 September 2026 the 15 July 2026 date has still not appeared in any official source. The date circulated widely in vendor and professional-network commentary and is absent from the press release, from CERT-In’s conference proceedings for the event, and from cert-in.org.in. It is worth noting that the proceedings are the later document of the two. If you wrote that date into a compliance calendar, a contract clause or a customer commitment, it is worth reconciling now. A certificate can meanwhile be verified without any platform: check the signing legal entity against CERT-In’s published empanelment list for the dates of the audit, read the certificate’s fields against what you are deploying, and confirm the reference number, build and test window with the issuer using contact details you obtain independently.

What was CERT-In SAMVAAD 2026?

The second edition of CERT-In’s national annual conference on cybersecurity auditing: three days, 27 to 29 April 2026, at the BITS Pilani K. K. Birla Goa Campus in association with BITS Pilani, Goa, with over 500 delegates and the theme “Securing Digital Bharat through Future-Ready Audits: Adapting, Assuring, Advancing”. AMBAK was launched there alongside Working Group progress reports on emerging domains and, with BIRD and NABARD, an advanced cybersecurity certification course for Rural Financial Institutions. The programme, the panel, the two working groups and a reading of the full subject list are set out on our page on CERT-In SAMVAAD 2026.

How do I verify a CERT-In audit certificate today?

Four steps, none of which require a platform, and about twenty minutes. First, check the signing legal entity against CERT-In’s published list of empanelled information security auditing organisations — searching the registered name rather than the brand, and comparing the empanelment validity period against the test window on the certificate rather than against today’s date, because an empanelment that lapsed between the audit and the certificate leaves no mark on the document. A parent or sibling company on the list does not put the signing entity on the list. Second, read the certificate field by field: issuing entity and empanelment reference, certificate and report reference numbers, application name, version or build and hash, environment tested stated explicitly, hostnames and URLs in scope, test window, issue date, the basis of validity, named signatories, and the stated exclusions. Third, write to the issuing organisation at an address you obtained independently, quoting the reference numbers, the build, the test window and the signatories, and ask one question: did your organisation issue this, and does the scope stated here match your record? “Is this yours” is answered yes even when the scope has been edited, while “does this match your record” is what catches an alteration. Fourth, keep the certificate, the report, the dated empanelment check, the request and the reply in a per-certificate verification file.

Does AMBAK apply to private-sector security audits?

Neither account defines the platform’s scope, so any statement about whether private-sector engagements are covered is inference. What does apply to private-sector engagements today is the surrounding framework, and it is more substantial than most auditees realise: an empanelled auditing organisation must share the audit report and audit metadata with CERT-In within five days of completing an audit under clause 3.2.2 of the empanelment terms and §10.6 of the 2025 audit policy guidelines. It must report critical vulnerabilities that were identified but not fixed even during follow-up audits, with auditee details. It files a quarterly return covering audits performed, sectors, high-level findings and new areas. And CERT-In may be part of the audit team to assess the quality and maturity of the audit. Those duties sit on the auditor and exist regardless of who the auditee is. §13.2.1(iii) of the 2025 guidelines also requires the auditor to tell the auditee about the five-day duty before the assignment begins.

What does “kinetic interventions” mean in AMBAK?

CERT-In has supplied its own paraphrase, which is the closest thing to a definition that exists. Section 7.1 of its SAMVAAD 2026 conference proceedings describes AMBAK as launched “to support audit monitoring, benchmarking, analysis and targeted interventions” — so where the acronym says kinetic, the agency’s own prose says targeted. In policy writing “kinetic” ordinarily marks action with an operational effect, as distinct from analysis, reporting or advice, and placed at the end of a sequence running monitoring, benchmarking, analysis, it reads as the step where findings produce action rather than observations. CERT-In already holds the instruments for action: section 70B of the Information Technology Act, 2000 empowers it to call for information and issue directions and attaches punitive consequences to non-compliance, and the 2025 audit policy guidelines publish a graded ladder for empanelled organisations running from a watch list through suspension and debarment to penal and legal action. What an intervention consists of under AMBAK, who receives one and on what trigger has not been published, and nothing published connects that ladder to this platform.

Who can issue a security audit or safe-to-host certificate in India?

For Indian Government websites, web applications, portals and mobile apps, the audit clearance certificate must come from NIC, from STQC, from an STQC-empanelled laboratory, or from a CERT-In empanelled laboratory, before the system is hosted in a production environment. That is the requirement behind the phrase “safe to host”, and an internal security team cannot issue one. Tranquility Cybersecurity delivers CERT-In audits, end to end, with its CERT-In empanelled partners.

What is the difference between the audit report and the certificate?

The certificate carries a conclusion, while the report carries everything that makes the conclusion meaningful. A certificate names an application, a version or build, an environment and a date, and states that the audit concluded satisfactorily. The report contains the methodology, the scope and its exclusions, the findings with the objective evidence supporting them, the severity-wise timelines for closure, the sampling, the exemptions and the limitations. Central verification, if and when it arrives, would confirm properties of the engagement. It would not tell you how good the audit was — only the report does that, which is why an auditee should always receive one and a buyer relying on a certificate should always ask for it.

Can an auditor advertise itself as “CERT-In certified”?

No. CERT-In empanels auditing organisations. It does not certify them, and it does not certify the organisations they audit. The guidelines for empanelled auditing organisations permit exactly one formulation — that the organisation is empanelled by CERT-In for providing information security auditing service — and state that no other words may be used to describe the relationship without CERT-In’s prior written permission. They also prohibit use of the CERT-In logo, or any reference to the auditor’s association with CERT-In, on publicity or promotional material without prior written permission. An organisation advertising with the logo or the phrase “CERT-In certified” is telling you something about how it handles claims generally.

Written By Expert Auditors

Surendra Pal SinghChief Information Security Officer & Data Protection OfficerCISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi ChauhanLead AuditorISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Last reviewed: September 2026 • Content verified by certified lead auditors

Keep Exploring