Introduction:
On April 26, 2026, the Indian Computer Emergency Response Team issued an advisory that most Indian CISOs could not ignore. Rated high severity, CERT-In's CIAD-2026-0020 did not arrive with the calm tone of a routine compliance update. It named frontier AI models. It described capabilities that previously required teams of skilled human experts. And it told every Indian organisation to stop assuming that a newly disclosed vulnerability would take weeks to be weaponised.
The advisory's core message is blunt: attackers powered by frontier AI move faster than your current security calendar was built to handle. Quarterly patch cycles, annual penetration tests, and periodic monitoring are no longer adequate. The operating model of Indian cybersecurity has changed, and this advisory is the regulator's formal acknowledgement of that change.
This blog breaks down what the advisory demands, how to operationalise it in 30 days, and how to build the 24-hour patch loop that keeps you compliant and defended beyond that.
What the Advisory Actually Says
Strip away the formal language and CERT-In's advisory makes seven demands.
Every newly disclosed critical vulnerability must be triaged and patched, or compensated with a control, inside 24 hours. Every Indian organisation must move toward Zero Trust Network Architecture. Internet-facing attack surfaces must be reviewed and reduced. Unnecessary ports and protocols must be disabled. Continuous threat-intelligence-driven monitoring must replace periodic checks. Multi-stage attack simulation must become a regular part of your security calendar. And incident-reporting workflows must connect directly to CERT-In.
The phrase that carries the most weight is this: treat every newly disclosed critical vulnerability as exploitable within hours, not weeks.
That single sentence retires the 30-day patch cycle for critical findings. It invalidates the annual VAPT as a standalone defence. And it puts the burden on every Indian enterprise to build a security operation that runs at a speed the old calendar was never designed for.
The 30-Day Action Plan
The advisory sets the direction. This plan sets the pace. The goal at the end of 30 days is a documented, evidence-backed posture that maps to each of the seven pillars in the advisory.
Week 1 - Inventory and Exposure (Days 1 to 7)
You cannot defend what you cannot see. The first week is entirely about visibility. Pull every asset register your organisation has. Reconcile cloud infrastructure with data centre records and shadow IT. Run an external attack-surface discovery, not just an internal scan. Every internet-facing host, every forgotten subdomain, and every stale API must be logged and owned.
This is not a six-month project. With the right partner and the right methodology, it is a two-week sprint. Starting it in week one means you have a defensible baseline before the month is out.
Week 2 - Vulnerability Discipline (Days 8 to 14)
With your asset inventory in hand, establish or refresh your VAPT cadence. Wrap it in a service-level commitment: critical findings retested within seven days, not next quarter. Tie remediation owners to specific assets so that accountability is clear when a finding needs to be closed.
Build a CISO dashboard that shows mean-time-to-remediate by severity and by business unit. The number you are working toward on critical findings is single-digit hours, not days.
Week 3 - Detection and Response (Days 15 to 21)
Stand up or upgrade your security operations centre with AI-augmented detection. The point is not to replace human analysts. The point is to compress the time an attacker can move through your environment before someone notices. An attacker operating with frontier AI assistance moves faster than humans reading a queue of alerts. Your detection capability must close that gap.
Test your incident-response runbook with a tabletop exercise that explicitly includes the CERT-In notification flow. The first time you run that flow should not be during a real incident.
Week 4 - Zero Trust Pilot and Board Readout (Days 22 to 30)
Pick the most exposed business unit in your organisation and start your Zero Trust pilot there. Document segmentation decisions, identity-verification posture, and east-west traffic controls. This is not a full Zero Trust rollout. It is a documented, evidence-backed pilot that demonstrates directional compliance with the advisory's ZTNA mandate.
Prepare a board readout that maps your four weeks of work to each of the seven pillars. The board does not need every metric. It needs to see a clear line from each regulatory demand to an action owner and a piece of evidence.
The 24-Hour Patch Window
For most Indian enterprises, the 24-hour patch mandate reads as impossible. It is not. It becomes achievable the moment you stop thinking about patching as a monthly batch operation and start thinking about it as a continuously running loop with six clearly owned stations.
Station 1 - Disclosure Intake (Hour 0 to 1:30)
The clock starts the moment a critical CVE is publicly disclosed, a vendor advisory drops, or a threat-intelligence feed flags a relevant zero-day. Most teams find out eight to 48 hours late because no one is specifically paid to watch. Fix this first.
A live feed from NIST NVD, CERT-In, relevant vendor portals, and a commercial threat-intelligence source must land in a monitored channel around the clock. For most mid-size Indian enterprises, this means a managed SOC partner with the feed already wired in.
Station 2 - Asset and Exposure Check (Hour 1:30 to 4)
Within 90 minutes of disclosure, you need to know whether the vulnerability affects your environment. This is where most organisations fail, not because of slow people but because of wrong data. Most CMDBs are out of date. A maintained external attack-surface map that goes beyond your internal inventory is not optional. Neither is a tagged asset register that ties software components to named business owners. Without owners, no patch happens at speed.
Station 3 - Patch or Compensating Control Decision (Hour 4 to 12)
By hour eight, a decision must be on the table. Patch now, or implement a compensating control while a maintenance window is arranged. Compensating controls include WAF rules, network ACLs, service-account isolation, or temporary feature flagging. This decision is not a technical one. It is a risk and business continuity call. A V-CISO or a named risk-committee delegate must own it.
Station 4 - Deploy and Retest (Hour 12 to 20)
By hour 18, the patch or control should be deployed in production. By hour 20, it should have been independently retested. Retest is not a formality. Misconfigurations under time pressure are common. An independent retest by a CERT-In empanelled auditor produces a signed report that is admissible as evidence in subsequent audits, which is a material advantage the next time a regulator asks for proof.
Station 5 - Evidence and Audit Trail (Hour 20 to 22)
By hour 22, every step above must be in your audit log: who detected, who triaged, who decided, who patched, who retested. Build the log so the artefact is generated automatically as the work happens, not reconstructed from memory afterwards. Auditors, boards, and regulators all want this log. Build it once and it serves all three.
Station 6 - Regulator Reporting (Hour 22 to 24)
By hour 24, if the vulnerability touched sensitive personal data or critical infrastructure, the CERT-In incident report must be filed or queued. If your organisation is a data fiduciary under the DPDPA, you are simultaneously running the 72-hour clock for the Data Protection Board. A single reporting orchestration that satisfies both regulators from the same evidence set is far more efficient than two separate workflows built in a hurry.
| Hour | Station | Owner | What Good Looks Like |
|---|---|---|---|
| 00:00 – 01:30 | Disclosure intake | SOC / Threat-Intel | Critical CVE acknowledged, severity confirmed |
| 01:30 – 04:00 | Asset and exposure check | Asset Mgmt + SOC | Affected hosts identified, owners tagged |
| 04:00 – 12:00 | Patch or control decision | V-CISO / Risk | Decision logged with rationale |
| 12:00 – 18:00 | Deploy patch or control | Platform / DevOps | Change deployed via CAB-light process |
| 18:00 – 20:00 | Retest | CERT-In empanelled auditor | Independent verification, signed report |
| 20:00 – 24:00 | Evidence and report | Compliance / V-CISO | Audit trail closed, regulator filing queued |
Conclusion
CERT-In's advisory is not the heaviest regulation Indian cybersecurity has seen, and it will not be the last. What makes it different is the operating tempo it demands. The 30-day plan above is not a one-time project. It is a new baseline, one that every Indian enterprise now needs to maintain continuously, not revisit annually.
The 24-hour patch loop is not a sprint. It is a loop that never stops running. Once the six stations are staffed, tooled, and rehearsed, the loop becomes the normal pace of your vulnerability management programme, not an emergency response.
The advisory's core message is straightforward: the attacker's clock has accelerated. Your defence must accelerate with it. The 30 days gives you the foundation. The 24-hour loop keeps it standing.
FAQ:
Is CERT-In's advisory mandatory or just advisory?
CERT-In advisories are technically advisory in name. In practice they carry binding weight in audit. Downstream regulators including the RBI and SEBI expect alignment with CERT-In guidance. Treat this advisory as mandatory.
Does my existing annual VAPT contract still meet the spirit of this advisory?
No. The advisory's hours-not-weeks language directly invalidates the annual-test posture as a standalone defence. You need continuous coverage with rapid retest capability. An annual VAPT that sits alone is now a compliance artefact, not a defence.
What if my change-management process takes longer than 24 hours?
Then you need a fast-lane process specifically for security-critical patches. Most boards approve this once the regulatory language is shown to them. Document the fast-lane, brief the change-management committee, and test it before you need it.
What if I cannot confirm within 90 minutes whether a vulnerability affects my environment?
That gap points to an asset inventory problem, not a speed problem. The fix is a maintained external attack-surface map paired with a tagged internal inventory. Without those two things, every future patch decision will start late.
Is 24-hour patching realistic for every type of organisation?
For critical vulnerabilities on internet-facing systems, yes, with the right architecture and the right partner. For internal-only or lower-severity findings, the window can extend to 48 or 72 hours with documented justification. The 24-hour mandate applies specifically to critical findings on exposed surfaces.
