The CERT-In Directions of April 2022, Explained.

Six directions, issued on 28 April 2022 under sub-section (6) of section 70B of the Information Technology Act, 2000, and effective sixty days later. Between them they fix your system clocks, start a six-hour clock on incidents, put a named person between you and CERT-In, require 180 days of logs, and place five years of subscriber records on four classes of provider.

The sentence most summaries get wrong: the six-hour clock runs from noticing the incident or being brought to notice about it — not from confirmation, not from root cause, and not from the moment the incident commander accepts the page.

The CERT-In Directions of April 2022 are a single instrument — No. 20(3)/2022-CERT-In, issued by the Indian Computer Emergency Response Team on 28 April 2022 under sub-section (6) of section 70B of the Information Technology Act, 2000 — containing six numbered directions that bind service providers, intermediaries, data centres, body corporate and Government organisations. They require ICT system clocks to be synchronised to NIC or NPL time, the twenty incident types at Annexure I to be reported to CERT-In within six hours of noticing them, a point of contact to be designated in the Annexure II format, logs of all ICT systems to be enabled and maintained securely for a rolling period of 180 days, five years of subscriber registration data to be kept by data centres and VPS, cloud and VPN service providers, and five years of KYC and financial transaction records to be kept by virtual asset, exchange and custodian wallet providers. The instrument closes by stating that failure to furnish information or non-compliance may invite punitive action under sub-section (7) of section 70B of the IT Act, 2000 and other laws as applicable, and that the direction becomes effective 60 days after the date on which it is issued.

That paragraph is the whole of it, and almost everything written about these Directions since is a paraphrase of it. This page works from the instrument itself and from CERT-In’s own published explanatory material, because the paraphrases have drifted in ways that matter operationally: the six hours are widely reported as running from confirmation rather than from noticing, the 180 days are read as a retention ceiling rather than a rolling floor, and the five-year registration rule is repeated as though it applied to every business rather than to four named classes of provider. Where the text and the common summary diverge, this page shows both. For CERT-In itself — what it is, what it does and where its authority comes from — start with what CERT-In is.

The Directions are issued by CERT-In, the Indian Computer Emergency Response Team, which the Central Government appointed as the national agency for cyber security functions by notification dated 27 October 2009 under sub-section (1) of section 70B of the IT Act, 2000. The manner in which CERT-In performs its functions is prescribed by the Information Technology (The Indian Computer Emergency Response Team and Manner of performing functions and duties) Rules, 2013, notified by notification dated 16 January 2014. Sub-section (4) of section 70B sets out the functions: collection, analysis and dissemination of information on cyber incidents, forecast and alerts, emergency measures, coordination of incident response activities, issuing guidelines, advisories, vulnerability notes and whitepapers, and such other functions as may be prescribed.

Sub-section (6) is the enabling power, and its wording is broader than the Directions themselves. It empowers CERT-In to call for information and give directions to the service providers, intermediaries, data centres, body corporate and any other person for carrying out the activities in sub-section (4). The Directions then address themselves to a specific list of classes. That gap between the width of the power and the list in the instrument is worth noticing: the classes named in the Directions are who the Directions speak to, and the power under which they were issued reaches further than that list.

The recitals name the reason. CERT-In records that where cyber incidents are reported, the requisite information is sometimes not available, or not readily available, with service providers, data centres and body corporate — and that this primary information is essential to carry out analysis, investigation and coordination as per the process of law. Read against that recital the six directions stop looking like six unrelated compliance items and start looking like one design: synchronised clocks so that events from different systems can be sequenced, prompt notification so that CERT-In learns of an event while it can still be acted on, a named human to route the conversation through, logs that still exist when the question is asked, and subscriber records that survive the end of the relationship they describe.

One more textual point, because it recurs throughout this page. The Directions state that the meaning of terms such as cyber incident, cyber security incident and computer resource may be ascribed as defined in the IT Act, 2000 or in the CERT-In Rules, 2013. The instrument therefore does not define its own vocabulary. It borrows it. When a question turns on what a word means — and several do — the Act and the Rules are where the answer lives, not the Directions.

Almost every summary of these Directions gives a single effective date. There are three, and the second and third come from a separate instrument that most summaries never mention. On 27 June 2022, under the same reference number, CERT-In issued an order titled Extension of timelines for enforcement of Cyber Security Directions of 28th April, 2022 ... for MSMEs and also for implementation of mechanism for validation of subscribers/customers details by Data Centres, VPS providers, Cloud Service providers and VPN Service providers. It is published on CERT-In’s own Directions page alongside the Directions themselves and the questions and answers.

All three dates are now in the past, so nothing here changes what is owed today. It matters for two narrower purposes, and both come up. A statement about when an obligation attached — in a contract, a diligence response or a regulatory filing — is wrong if it uses the wrong date for the entity it describes. And the existence of the extension order is itself a useful test of a summary: a page that tells you these Directions have one effective date has not read CERT-In’s own publication list.

The applicability questions CERT-In has been asked most often are about reach rather than category. Asked whether the Directions apply only to Indian companies or also to foreign firms serving Indian customers, CERT-In pointed to sections 1 and 75 of the IT Act and said the Directions are applicable to any entity whatsoever, in the matter of cyber incidents and cyber security incidents. The two adjacent answers are close to that but not identical, and the difference is worth noticing rather than smoothing over. Asked about virtual asset providers not located in India but catering to Indian users, CERT-In said the Directions are applicable to any entity only in the matter of cyber incidents and cyber security incidents. Asked about online gaming companies, it said they are applicable to all entities in so far as reporting of a cyber incident is concerned. Read together, the three answers say the same thing about reach and are careful about subject matter: wide as to who, bounded to the incident subject. Asked separately whether providers without a physical presence in India must designate a point of contact, CERT-In said that service providers, intermediaries, data centres and body corporate offering services to the users in the country shall designate one to liaise with CERT-In — a list that, unlike direction (iii) itself, does not name Government organisations.

CERT-In published a set of frequently asked questions on these Directions in May 2022, and much of what follows on this page draws on it, because it is CERT-In’s own statement of how it reads its own instrument. That document says of itself that it is not a legal document and in no way whatsoever replaces, amends or alters any part of the IT Act, 2000 or the CERT-In Rules, 2013, and that it is an evolving document whose version may change. The correct weight to give it is therefore: strong evidence of the regulator’s position, not a substitute for the direction it explains. Where this page says CERT-In has said, that is the source. Where it quotes the obligation itself, the source is the instrument.

The obligation is to connect to the Network Time Protocol server of the National Informatics Centre or the National Physical Laboratory, or to NTP servers traceable to these, for synchronisation of all ICT system clocks. Entities whose ICT infrastructure spans multiple geographies may also use an accurate and standard time source other than NPL and NIC — with the qualification that their time source shall not deviate from NPL and NIC.

CERT-In has explained the reasoning plainly: a typical cyber incident involves multiple computer systems within and across entities, and without an accurate timestamp it is extremely challenging to re-create an accurate sequence of events. It adds a second reason that security teams recognise immediately — correlation rules in security technologies lean heavily on time, so unsynchronised clocks can cause security systems to fail outright, and can defeat an organisation’s ability to act on proactive alerting from CERT-In and others.

Two clarifications from CERT-In remove most of the confusion this direction generates. First, there is no requirement to set system clocks to Indian Standard Time: NTP provides a timestamp in UTC, conversion to local time happens at the host, and what the direction requires is uniform synchronisation across all ICT systems irrespective of time zone — with the time zone recorded alongside the time so that accurate conversion is possible later. Second, on cloud: where infrastructure spans multiple geographies, organisations typically run their own NTP servers to keep time uniform and to handle situations such as leap smearing consistently, and CERT-In accepts an accurate and standard source for that case provided it does not deviate from NPL and NIC. Customers in a cloud environment may use the native time service the cloud offers, or run their own — and where they run their own against sources other than the native cloud service, NIC, NPL or another accurate and standard source may be used as long as accuracy is maintained.

The reason to take this direction seriously is not the direction. It is that every other obligation in the instrument produces evidence stamped with a time, and an incident report whose timestamps cannot be reconciled with the logs behind it is an incident report that invites questions you cannot answer. Clock discipline is the cheapest control on this page and the one that makes the rest of your evidence worth reading.

Four things in that sentence do the work. Mandatorily — there is no discretion and no materiality threshold written into the direction. As mentioned in Annexure I — the trigger is membership of a list of twenty types, not a severity rating. Within 6 hours — a wall-clock window, not six working hours and not the next business day. Of noticing such incidents or being brought to notice about such incidents — two separate starting events, and the second is the one that catches organisations out, because it puts the start of the clock in a support queue rather than in a security tool.

The channel sentence is part of the direction, not a footnote to it, and the standing instruction inside it matters: the details regarding methods and formats of reporting are published on the CERT-In website and will be updated from time to time. That is an instruction to check the current channels and format rather than to rely on a copy in a runbook, however carefully that runbook was written — including this copy. Note also that the fax number on the direction and the fax number printed on CERT-In’s incident reporting form are not the same number. Each is correct for the document it appears in.

Annexure I itself carries a reference worth following. Its heading reads Types of cyber security incidents mandatorily to be reported by service providers, intermediaries, data centres, body corporate and Government organisations to CERT-In, immediately followed by a bracketed note: Refer Rule 12(1)(a) of the Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013. The list did not appear from nowhere in 2022. What the Directions added was the six-hour window and the explicit, consolidated statement of the obligation.

The single most useful change most teams can make is to split the two decisions apart. Severity governs who is woken up, what is escalated and how the response is resourced, and it should keep doing so. Type governs whether the six-hour obligation is engaged, and it is answered by reading the event against twenty listed categories. An event can be low severity and squarely reportable — unauthorised access to a corporate social media account is the standing example. Run the classification as its own step, early, with its own owner.

The list as the Directions set it out, with the explanation CERT-In itself published for each type, and a note on what the category tends to look like in a real estate. Read the middle column when you are deciding whether an event is in the class. Read the right-hand column when you are deciding what to instrument.

Two observations about the list as a whole. It is written in the language of types rather than of impact, so an event qualifies by being what it is, not by how much it cost. And several entries are drafted to include suspicion — attacks or malicious or suspicious activities affecting cloud systems, the emerging-technology entry, and the artificial intelligence and machine learning entry all use that formulation. Where a type is written around suspicion, an organisation that waits for proof before classifying has inverted the drafting.

CERT-In has also addressed the list’s edges for intermediaries specifically, saying that it is imperative that intermediaries also report those types of cyber security incident which are mentioned in neither the CERT-In Rules, 2013 nor the 2022 Directions, considering the nature, severity and impact of the incident. On vulnerabilities it draws the opposite line: at present, reporting a vulnerability as a standalone, in isolation and unconnected with a cyber security incident, is not mandatory.

Item (xx) of Annexure I reads: attacks or malicious and suspicious activities affecting systems, servers, software and applications related to artificial intelligence and machine learning. It sits in a list of mandatorily reportable types in an instrument issued in April 2022, and it carries the same six-hour clock as ransomware. There is no threshold of harm in it, no carve-out for research or evaluation environments, and no commencement date later than the rest of the instrument. An organisation running models in production in India has been inside a mandatory incident-reporting regime for AI since before most of the current tooling existed.

CERT-In’s own explanation of the type is narrower than the type itself, and worth reading carefully for that reason: attacks that target machine learning models with the intention to cause a malfunction, employing techniques such as deceptive data and environment manipulation to corrupt the model and cause it to behave erroneously, with possible impact on confidentiality, integrity and availability. That description is squarely about model integrity. The words of the type in the annexure are wider — systems, servers, software and applications related to artificial intelligence and machine learning — and the annexure, not the explanation, is what the direction points at. Where an event fits the type but not the explanation, classify on the type and say so in the description.

The six hours run from noticing, or from being brought to notice. In a conventional estate the noticing moment is an alert or a ticket, and it has a machine-written time on it. In an AI stack the detector is frequently neither: it is an offline evaluation run against a checkpoint, a red-team exercise conducted over days, or a researcher noticing a pattern in outputs. Three rules keep that honest.

This is the part nobody has written down, and this page is not going to pretend to have settled it. Direction (iv) requires logs of all ICT systems, enabled and maintained securely for a rolling 180 days. An LLM application produces a category of record that did not exist when the direction was drafted: the prompt, the tool calls the model made and their arguments, the documents a retrieval step returned, and the completion. Are those logs of an ICT system?

The argument that they are is straightforward. They are the application’s record of what it was asked to do and what it did, which is exactly what an application log is, and without them no incident in this class can be reconstructed at all. You cannot investigate a prompt injection that reached a tool with write scope from infrastructure metrics. The evidence is the tool-call trace. The argument that a blanket reading overreaches is equally straightforward: prompts routinely contain the most sensitive content a user will ever hand a system, and retaining every one of them for 180 days by default creates a concentration of personal data that a data-minimisation obligation points the other way on.

Neither the instrument nor CERT-In’s published questions and answers addresses it. What can be said without inventing a position is that the two obligations pull in opposite directions and the design has to hold both, which in practice means separating the layers rather than choosing between them. A defensible pattern looks like this: retain the metadata of every call — principal, timestamp and time zone, model and version, tools invoked, scopes exercised, outcome, and a content hash — on the full retention, because that layer is what reconstructs a sequence and carries almost no personal data. Retain the content itself on a shorter, deliberate, documented window with access control over it. Where content is needed for an investigation, preserve the slice under hold rather than keeping everything for ever in case.

Treat that as engineering judgement, not as a reading of the direction, and take the position with counsel on your own facts. The direction of travel in the national audit ecosystem is visible enough: AI-driven red teaming methodologies were among the topics presented at CERT-In’s own national audit conference in April 2026, alongside the launch of AMBAK. An organisation that can answer what its agents did last March is in a materially better position than one that cannot, whatever view is eventually taken of the clause.

There is a control hiding in all four: the organisation needs one recorded, immutable moment that everyone agrees is T+0. Not an inference drawn afterwards from mailbox timestamps and Slack scrollback, but a field in a record, written at the time, by whoever first held the information. Instrumenting that field is a day of work and it is the difference between demonstrating compliance and arguing for it.

The fourth case deserves its own treatment, because it is the one where two instruments apply to the same fact at the same moment and neither discharges the other. A penetration test or a VAPT engagement finds something that is not a weakness but a live, pre-existing compromise. Here is who owes what.

None of that is negotiable, which is precisely why the engagement letter should deal with it in advance rather than leaving three parties to discover it during an incident. The clause worth carrying has five parts, and it is short.

One further point for anyone scoping a test. Because critical vulnerabilities the auditee did not fix even during follow-up audits go to CERT-In on the auditor’s five-day clock, the cheapest moment to close a critical finding is inside the remediation window, before the follow-up audit concludes. That is a scheduling decision, made when the statement of work is written, not a technical one. See the rules of engagement for empanelled auditors for what else those instruments put on the testing organisation.

Three things about that first report are worth naming, because they are the three decisions most organisations get wrong under pressure.

What it asserts. That an event of Annexure I type (iii) has been detected, when it was detected, what system it affects, and what has been done so far. Every one of those is a fact the organisation actually held at 11:40. The report is short because the facts were few, not because anything was withheld.

What it deliberately does not assert. Root cause. Scope. Attribution. Whether a data breach occurred. Each of those appears as not yet established rather than as a blank or an estimate, and marking them is doing real work: a blank field reads as an oversight and an estimate becomes a statement you will have to withdraw. The second candidate type is named and expressly not asserted, which is both honest and protective — it shows the classification question was considered at the time rather than reconstructed later.

Why the timestamp in the incident record is 09:12. Not 09:41, when security first saw it, and not 10:20, when the classification decision was made. The direction starts the clock at noticing or at being brought to notice, and a customer describing unauthorised access in a support ticket is the organisation being brought to notice. Recording 10:20 would have bought an extra sixty-eight minutes of apparent headroom and created a discrepancy between the incident record and the helpdesk’s own machine-written receipt time — which is the first place an auditor looks and the one record the organisation does not control the wording of. The deadline here was 15:12, and it was met by three and a half hours. Teams that shave the start time are usually the ones with no margin to spare, which is exactly when the discrepancy is most visible.

The first limb: when required by order or direction of CERT-In, for the purposes of cyber incident response and protective and preventive actions related to cyber incidents, the service provider, intermediary, data centre or body corporate is mandated to take action, or provide information, or any such assistance to CERT-In which may contribute towards mitigation actions and enhanced situational awareness. The order or direction may include the format of the information required — up to and including near real-time — and a specified timeframe in which it is required, which should be adhered to. Otherwise it would be treated as non-compliance of the direction.

The phrase near real-time did most of the work in the commentary this direction attracted, and it is worth being precise about what it attaches to. It qualifies the format an order may specify. CERT-In has addressed the standing-feed reading directly, saying that the Directions do not envisage seeking information from service providers on a continuing basis as a standing arrangement, and that it may seek information in the case of cyber security incidents and cyber incidents on a case-to-case basis for the discharge of its statutory obligations. On logs specifically, CERT-In has said that a requisition for information in respect of logs may be given by an officer of CERT-In not below the rank of Deputy Secretary to the Government of India, for carrying out the functions in sub-section (4) of section 70B.

The second limb is the point of contact, and it is the one that quietly fails. Service providers, intermediaries, data centres, body corporate and Government organisations shall designate a Point of Contact to interface with CERT-In. The information relating to that Point of Contact shall be sent to CERT-In in the format specified at Annexure II and shall be updated from time to time. All communications from CERT-In seeking information and providing directions for compliance shall be sent to the said Point of Contact.

Three operational consequences follow from that last sentence about all communications being sent to the Point of Contact. The address has to be monitored, including out of hours. It has to survive the person — a named individual with a personal mailbox is a single point of failure with a notice period attached, and the most robust pattern is a named individual whose contact details route to a monitored role mailbox. And the update obligation needs an owner and a trigger: put the Annexure II record on the joiner-mover-leaver checklist, so that a role change produces a refresh rather than a gap nobody notices until CERT-In writes to someone who left in 2024.

One textual detail worth knowing, because diligence questionnaires sometimes turn on it. The sentence mandating action, information or assistance names the service provider, intermediary, data centre and body corporate. The sentence requiring a Point of Contact to be designated names those four and Government organisations. The instrument is not uniform across its own limbs, and reading it as though every direction applies identically to every class will occasionally produce the wrong answer.

Two features of that sentence do most of the work. The clock starts at cancellation or withdrawal of the registration, not at the start of the relationship — so a five-year obligation on a customer who leaves in 2026 runs to 2031, and a deletion process that cascades records away at account closure defeats it. And the direction says register, and calls the information accurate, and calls two of the seven fields validated. Those are three different standards, and a signup form that accepts whatever is typed into it meets none of them.

The scoping question this direction raises most often is about VPNs, and CERT-In has answered it. Asked whether the direction applies to enterprise and corporate VPNs, CERT-In answered No, and explained that for the purpose of this direction a VPN Service provider means an entity that provides Internet proxy like services through the use of VPN technologies, standard or proprietary, to general Internet subscribers or users. An organisation running a VPN so that its own staff can reach its own systems is not in this class. It is still a body corporate, still inside directions (i) to (iv), and its VPN logs are still ICT system logs.

Cloud providers should read the class boundary the same way, from the service they actually sell rather than from the word cloud. And every provider in this direction should check one specific engineering behaviour: whether a subscriber deleting their account, or a retention job enforcing a privacy commitment, removes records this direction requires to be kept for five years after the relationship ends. That collision between a deletion promise and a retention obligation is a design problem to settle deliberately, with counsel, rather than to discover from a support ticket.

The KYC baseline is imported rather than invented. The direction points to the Reserve Bank of India Directions 2016, a Securities and Exchange Board of India circular dated 24 April 2020, and a Department of Telecom notice dated 21 September 2021, as amended from time to time, with the detail set out at Annexure III. That annexure lists the officially valid documents to be used and maintained — passport, driving licence, proof of possession of Aadhaar number, voter’s identity card, NREGA job card signed by a State Government officer, and a letter issued by the National Population Register containing name and address — together with a validated phone number and trading and bank account details. For business customers it points at the customer due diligence process prescribed in the RBI Master Direction on KYC, 2016, as updated.

The transaction half of the direction sets a standard rather than a field list, and the standard is the interesting part: accurate information shall be maintained in such a way that an individual transaction can be reconstructed, along with the relevant elements — comprising, but not limited to, the following.

Two phrases are worth holding onto. But not limited to means the list is a floor: if reconstructing a transaction on your platform needs an element that is not named, that element is inside the obligation. And reconstructed is a functional test, which means the only honest way to evidence compliance is to perform one — take a historical transaction, rebuild it end to end from the retained records, and keep the output as the evidence. An assertion that records are retained for five years does not answer the question the direction actually asks.

Note also the timestamps and time zones in the first element. That is direction (i) doing its work three directions later: a reconstruction is a sequence, and a sequence built from unsynchronised clocks across exchange, wallet and settlement systems is not a reconstruction at all.

The Directions themselves create no penalty. They point at one. The operative sentence reads that in case of any incident the above-referred entities must furnish the details as called for by CERT-In, and that the failure to furnish the information or non-compliance with the directions may invite punitive action under sub-section (7) of section 70B of the IT Act, 2000 and other laws as applicable — a clause summaries almost always drop, and the one that carries the sectoral and data-protection exposure.

CERT-In has reproduced the sub-section it points to: any service provider, intermediaries, data centres, body corporate or person who fails to provide the information called for or comply with the direction under sub-section (6) shall be punishable with imprisonment for a term which may extend to one year, or with fine which may extend to one lakh rupees, or with both. Asked directly about the implications of non-compliance, CERT-In added a sentence that deserves to be quoted alongside the penalty rather than instead of it: this power will be exercised reasonably and on occasions when the non-compliance is deliberate.

Two further points of law sit behind this and change how contracts should be drafted. Section 81 of the IT Act provides that the Act has effect notwithstanding anything inconsistent contained in any other law for the time being in force, and CERT-In has relied on it to answer the question organisations ask most often about reporting: the obligation to report is statutory and overrides a confidentiality clause in a contract. And on allocation, CERT-In has said that any entity which notices a cyber security incident shall report it, and that the obligation of reporting is neither transferrable nor indemnified nor dispensed with.

A note on the incident register, because it is the artefact people are most tempted to curate. A register with honest entries — including one that shows a report went out late, with the reason and the change that followed — reads as a functioning control. A register with no entries at all across a long period reads as a detection question, not as a clean record. Whoever reviews it will have seen both.

Steps one to seven are policy, ownership and rehearsal, and a competent team can complete them inside a month. Steps eight to eleven are engineering, they cost real money, and they are where the programme either finishes or quietly stalls. Steps twelve and thirteen apply only if their opening condition describes you, and step fourteen applies to everyone. Budget the log work explicitly rather than folding it into a security line item, and put the retrieval drill on a recurring calendar before the first one is run, because the drill is the control and the configuration is only its evidence.

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

Against these Directions specifically, the work that actually moves the needle is preparation: settling applicability in writing, instrumenting the noticing timestamp, building the log inventory and running the retrieval drill, getting the Annexure II point of contact submitted and owned, and rehearsing the six hours before an incident requires it. That is readiness and engineering work, and it is what our testing and remediation practice is built around.

Two documents are named on this page and are not listed above, for the same reason in each case: they are cited by an official instrument but were not retrievable from CERT-In’s site when this page was last reviewed. Those are the CERT-In Rules, 2013 — which the Directions point to for the meaning of their own terms, and which Annexure I cites at Rule 12(1)(a) — and the method-of-verification document named by the audit policy guidelines. Where this page relies on either, it relies on the official document that quotes it, and says so rather than pretending to a reading it has not made.

Related reading: what CERT-In is, CERT-In empanelment explained, AMBAK, how to verify a CERT-In audit certificate, the safe-to-host certificate, safe-to-host versus a security audit certificate, GIGW compliance before go-live, and the wider Indian data-protection picture.