CERT-In's 12-Hour Patch Window: Building a Remediation SLA Your Auditor Can Verify

India's cyber agency has put a number on how long exposure is allowed to persist, and most Indian SOCs cannot currently prove they meet it.

---

Executive Summary

On 25 May 2026, CERT-In issued Version 1.0 of a 38-page document titled "Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure", catalogued on the CERT-In site under reference code CISG-2026-02. The headline that travelled was the 12-hour patch window. That headline is roughly right and precisely wrong, and the difference matters if you are the person who has to operate the resulting SLA.

What the blueprint actually contains is a table headed "Indicative Risk-Based Remediation Timelines" with six rows: five finding types with expected windows ranging from 12 hours to five days, plus a sixth row governing what to do when no patch exists. The 12-hour row applies only to a known exploited vulnerability affecting internet-facing and crown-jewel systems, and the expectation is "immediate containment; patch, mitigate, or remove exposure within 12 hours where feasible." That is an exposure clock, not a patch clock. Read as a patching mandate it is unachievable in most enterprises. Read as a containment mandate it is demanding but tractable — and it is what the document says.

Around that table sit twelve core defensive principles, twelve governance areas, fourteen technical control areas, thirteen security-operations areas, nine validation areas, and a three-phase implementation roadmap that ends at day 60. The blueprint also restates, in its incident response section, that entities should report cyber incidents to CERT-In "in accordance with the directions issued by CERT-In from time to time, including reporting of cyber incidents within 6 hours."

This post does three things: reads the timeline table precisely, works out what has to be true in your environment before any of those windows are measurable, and translates the roadmap into the detection, telemetry and staffing decisions that actually determine whether you hit them.

---

1. What the Blueprint Is, and What It Is Not

Two distinctions decide how much weight to give this document.

It is guidance, not a direction. CERT-In's binding instrument is the set of Directions under Section 70B(6) of the IT Act issued on 28 April 2022, which carry the six-hour incident reporting obligation and the log retention requirement. CISG-2026-02 is framed differently throughout. Its closing paragraph asks organisations to implement the recommendations "in a risk-informed manner based on operational criticality, threat exposure, and organisational maturity," and the timeline table is headed indicative. Nobody is going to prosecute you for a 14-hour containment.

That is not the same as it being optional. Guidance from the national CERT is exactly the material an auditor reaches for when a framework says "reasonable security practices" without defining them. Once a national agency has published a number, "we patch monthly" stops being a defensible baseline in a post-incident review — regardless of whether the number was mandatory. If you operate under RBI's Cybersecurity Directions 2026 or under SEBI's CSCRF, assume your next assessor has read CISG-2026-02 and will ask how your remediation SLA compares.

The stated threat model

The blueprint's argument for compressed windows is explicit: "AI-assisted cyber exploitation reduces the time required for adversaries to identify, weaponize, and exploit vulnerabilities, exposed services, weak identities, insecure APIs, and misconfigured systems." It names agentic AI as a specific concern, warning of "automated multi-stage cyber operations involving reconnaissance, exploitation, persistence, lateral movement, and data exfiltration" executed within highly compressed timeframes.

Independent analysis reaches similar conclusions. The Cloud Security Alliance's research note on the blueprint, published 27 May 2026, cites CrowdStrike's 2026 Global Threat Report for an average eCrime breakout time of 29 minutes with a fastest observed instance of 27 seconds, and the 2026 Verizon DBIR for the finding that organisations patched only 26% of CISA's Known Exploited Vulnerabilities catalogue, down from 38% the prior year. Those are CSA's citations rather than CERT-In's, and they are secondary here — but they describe the same asymmetry the blueprint is responding to.

Practitioners quoted by The Register on 27 May 2026 made the operative point plainly: the guidance is workable because it explicitly permits temporary mitigation instead of a full patch. Dray Agha of Huntress described the "patch, mitigate, or remove exposure" phrasing as turning the deadline into "a highly feasible and necessary containment strategy."

---

2. The Six Rows, Read Precisely

This is the table that matters, reproduced from Section 9 of the blueprint.

#	Finding type	Indicative remediation expectation
1	Known exploited vulnerability affecting internet-facing and crown-jewel systems	Immediate containment; patch, mitigate, or remove exposure within 12 hours where feasible
2	Critical externally exposed vulnerability	Patch, mitigate, or remove exposure within 1 day
3	Known exploited vulnerability affecting internal systems	Patch or mitigate within 1 day unless compensating controls are implemented and documented
4	Critical internal vulnerability affecting high-value systems	Patch or mitigate within 3 days
5	High-severity vulnerability	Patch or mitigate within 5 days based on risk prioritisation
6	No patch available	Temporary mitigation — isolation, access restriction, WAF/API protection, enhanced monitoring, or feature disablement — until remediation becomes available

Four things follow from reading it closely rather than from the headline.

"Known exploited" is a routing key, not a severity label. Rows 1 and 3 turn on exploitation status; rows 2, 4 and 5 turn on severity and exposure. That means your triage logic needs a live exploitation feed — the CISA KEV catalogue at minimum — joined to your asset data before severity is even consulted. The blueprint's own control table for risk-based prioritisation names KEV prioritisation and EPSS-based exploit likelihood assessment as indicative measures, alongside exploitability analysis, business criticality assessment and threat intelligence integration.

"Crown-jewel" is your definition, and it will be audited. Nothing in the document defines it. That is a governance artefact you own, and if it does not exist in writing before an incident, it will be written afterwards by someone less sympathetic. Tie it to the same critical-asset register your business continuity and RBI/SEBI reporting already depend on rather than maintaining a second list.

Row 3 is the only row that names documentation as the escape hatch. A known exploited vulnerability on an internal system may exceed one day if compensating controls are implemented and documented. The word "documented" is doing real work: the exception is legitimate, the undocumented exception is not.

Row 6 removes the most common excuse. "No vendor fix yet" is not a holding position. It routes you to isolation, access restriction, WAF or API protection, enhanced monitoring or feature disablement — every one of which is a change your SOC and network team can make without waiting on a vendor.

---

3. The Prerequisite Nobody Budgets For

You cannot meet a 12-hour window with a scanner. You meet it with an inventory.

When a CVE lands, the clock that actually runs is: which assets run this component, which of those are internet-facing, which are crown jewels, and who owns each one. In most Indian enterprises that question takes days, not hours, and no amount of patching automation compresses it. This is why the blueprint's technical controls table opens with Asset Visibility and Attack Surface Management — asset inventory, attack surface monitoring, shadow IT and shadow AI detection, cloud exposure monitoring, dependency tracking — before it reaches identity, endpoint or network controls.

It also, in the same row, points at CERT-In's separate Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, and Section 7 asks organisations to improve visibility through adoption of Software Bill of Materials, AI Bill of Materials, Quantum Bill of Materials, Cryptographic Bill of Materials and related xBOM mechanisms. The reasoning is stated directly: xBOM supports "dependency tracking, provenance validation, vulnerability impact assessment, rapid exposure identification, and coordinated remediation."

The practical translation for a security lead scoping this work:

Prerequisite	What "done" looks like	What gates it
Internet-facing asset register	Continuously discovered, not annually declared; reconciled against DNS, cloud provider inventory and the external scanner	Tooling plus the reconciliation effort; the delta between discovery and the CMDB is the real work
Crown-jewel definition	Written, approved, mapped to systems, versioned	Governance, not engineering — it moves at the speed of the approving forum
Ownership map	Every asset resolves to a named remediation owner and an escalation path outside business hours	Organisational, and usually the longest pole; orphaned assets surface here
SBOM coverage for critical apps	Generated in CI, stored, queryable by component and version	Release cadence — coverage arrives one pipeline at a time
Exploitation feed integration	KEV and EPSS joined to asset data in the vulnerability platform or SIEM	Integration work; the shortest item on this list and the one that unlocks tiering
Out-of-hours containment authority	Named roles with pre-approved authority to isolate or disable, with an audit trail	Governance and legal sign-off; no procurement required

The last row is the one that most often silently breaks the SLA. A 12-hour window that starts at 22:00 on a Friday is not a tooling problem.

---

4. Instrumenting the Clock in Your SIEM

A remediation SLA that lives in a spreadsheet cannot be evidenced. The blueprint's validation section names "remediation verification" and "detection testing, SIEM validation, alert quality review, telemetry assessment" as assurance activities, which means the artefact your auditor wants is a timestamped record, not an assertion.

Four events define each finding's lifecycle, and each needs a reliable timestamp source:

1. Discovery — scanner finding, threat intel match, CERT-In advisory, vendor disclosure or penetration test. This is when the clock starts, and it is the timestamp most often lost, because the CVE's publication date and the date you learned of it are different and only one of them is yours to defend.
2. Tiering — the row assigned, and the asset attributes that justified it. Store the inputs, not just the output; an auditor's next question is always why row 4 and not row 1.
3. Action — patch deployed, exposure removed, or compensating control activated, with the change ticket reference.
4. Validation — rescan or configuration check confirming the exposure is gone. The blueprint lists rescanning, penetration testing and configuration validation as the indicative measures under "Validation of Remediation Effectiveness."

If your SIEM is already the system of record for security events, extending it to carry vulnerability lifecycle state avoids maintaining a second timeline that will disagree with the first. QRadar and Splunk both support this pattern through reference data — a reference table keyed on asset plus CVE, updated by the vulnerability platform, joined at search time to produce breach-of-SLA reporting. The mechanics are the same enrichment problem covered in our SIEM and IAM integration playbook: the value comes from the join, not from either dataset alone.

Three dashboards are worth building before any others:

• Open findings by tier against remaining time, so breaches are visible before they occur rather than after.
• Exceptions currently relied upon, with expiry dates. Row 3's documented compensating control is only valid while someone is watching it.
• Time-to-containment distribution, split by internet-facing versus internal. This is the number a board can act on, and it is the number that tells you whether the constraint is tooling, ownership or authority.

The blueprint's security operations table also asks for behavioural analytics, detection rule tuning, threat hunting and monitoring of privilege escalation — capabilities that pair naturally with this data, because a known exploited vulnerability on a crown-jewel asset should simultaneously raise detection coverage on that asset, not merely enter a remediation queue.

---

5. The 60-Day Roadmap, Translated Into People

Section 13 sets out three phases. Read as a technology plan it looks ambitious; read as a staffing plan it is more honest about what each phase actually consumes.

Phase	Window	CERT-In's focus areas	What it actually demands from your team
I — Immediate Risk Reduction	0–7 days	Governance and accountability structures; identify critical assets and internet-facing systems; MFA for critical access; vulnerability assessments; patch critical and known exploited vulnerabilities; reduce unnecessary exposure; incident reporting and escalation procedures; security logging and baseline monitoring; workforce awareness for AI-assisted phishing and deepfakes	Concentrated senior time, not headcount. Asset discovery and a written crown-jewel definition are decisions, and decisions bottleneck on availability of the CISO and application owners
II — Operational Strengthening	8–30 days	Strengthen SOC and monitoring; integrate endpoint, cloud, identity and network telemetry; continuous vulnerability and attack surface management; behaviour-based detection and threat hunting; AI governance and AI system inventory; cloud and API security assessments; third-party and supply-chain assurance; tabletop exercises, ransomware simulations, backup restoration testing	The heaviest phase, and the one that fails on capacity. Telemetry onboarding and detection engineering are sustained engineering work, not a project spike — they need named engineers with protected time
III — Advanced Resilience	31–60 days	Red team exercises and adversarial simulations; continuous control validation; security automation and orchestration; AI-assisted defensive operations where appropriate; resilience and continuity planning; adversarial AI testing; model integrity and AI orchestration security	Specialist skills that most in-house teams do not carry permanently — red teaming, SOAR engineering, adversarial ML testing. This is the phase most sensibly bought rather than hired

The pattern here is familiar to anyone who has run a compliance-driven programme: Phase I is a governance sprint, Phase II is where the programme either gets resourced or quietly stalls, and Phase III needs skills you use in bursts. Teams that treat all three as the same kind of work tend to complete Phase I on time, run Phase II at half speed for a quarter, and never start Phase III.

If Phase II is the constraint, the two workable answers are a managed SOC that already runs 24/7 monitoring and detection engineering or contract security engineers embedded alongside your team for the onboarding period. Which one fits depends on whether you are missing capacity or capability — a distinction we work through in more detail in our SOC-as-a-Service guide.

---

6. Where This Meets Your Existing Obligations

CISG-2026-02 does not arrive on a clean desk. Most Indian regulated entities are already carrying three or four overlapping cyber programmes, and the useful question is what this blueprint changes rather than what it adds.

It gives your existing VAPT cadence a remediation half. Periodic assessment plus indefinite remediation has been the default failure mode of Indian vulnerability programmes for a decade. The blueprint's framing — "organisations can no longer rely solely on periodic assessments or reactive security approaches" — attaches a clock to the back half of that cycle. If your CSCRF or RBI-driven VAPT programme produces findings that sit open for a quarter, the assessment cadence was never the weak part.

It sharpens the "reasonable security safeguards" question under DPDP. Rule 6 of the DPDP Rules 2025 requires security safeguards and log retention, and those obligations commence on 13 May 2027 alongside the rest of the substantive block — the sequencing we set out in our DPDP Rule 4 analysis. "Reasonable" is undefined in the Rules. A national CERT publication stating expected remediation windows is precisely the kind of external benchmark a Data Protection Board inquiry, or an opposing counsel, would reach for. Organisations scoping DPDP readiness work should treat remediation SLA evidence as part of that file, not a separate exercise.

It reinforces, rather than replaces, the six-hour reporting clock. The blueprint's incident response section restates the obligation to report cyber incidents to CERT-In within six hours. Keep the two separate in your runbooks: the reporting clock starts when an incident is noticed; the remediation clock starts when a finding is identified. They meet only when a finding becomes an incident, and at that point both are running from different timestamps.

It aligns with the detection-side gaps CERT-In has already flagged. The blueprint's emphasis on behavioural detection over signature matching continues a line the agency set out in its Digital Threat Report, which we analysed in our detection engineering breakdown. Same agency, same direction of travel: continuous over periodic, behavioural over static.

---

7. What to Do in the First Two Weeks

If you do nothing else, do these in order. Each is scoped to be finishable, and each unblocks the next.

1. Count your internet-facing assets, from outside. Not from the CMDB. External discovery against your own domains and cloud accounts, reconciled with what the CMDB claims. The delta is your actual starting position and is usually uncomfortable.
2. Write the crown-jewel definition down and get it approved. One page. Criteria plus the resulting system list. Version it.
3. Join KEV to your asset inventory. Until exploitation status is a queryable attribute of an asset, rows 1 and 3 of the timeline table cannot be operated at all.
4. Establish out-of-hours containment authority. Name the roles, pre-approve the actions — isolate, restrict, disable — and log the exercise of that authority. This is a governance change, not a purchase.
5. Pick the four events and start timestamping them. Discovery, tiering, action, validation. Even in a spreadsheet, start now; you cannot backfill a baseline.
6. Run one deliberate exercise against row 6. Take a real internet-facing system, assume no patch exists, and walk the mitigation path end to end. The gaps you find will be organisational, and finding them on a Tuesday afternoon is considerably cheaper than finding them during an incident.

---

Talk to a Team That Has Operated These Clocks

Cyberaube runs 24/7 managed detection and response, builds and tunes detection content on QRadar and Splunk, and places SOC, vulnerability management and IAM engineers into Indian enterprise teams on contract and permanent terms. If you are scoping a remediation SLA against CISG-2026-02 — or you have the SLA and cannot yet evidence it — we can help you close the gap between the policy and the timestamps.

Talk to a Cyberaube security specialist

---

FAQ

Is CERT-In's 12-hour patch window legally binding?

No. The blueprint presents the timelines under the heading "Indicative Risk-Based Remediation Timelines" and asks organisations to implement its recommendations "in a risk-informed manner based on operational criticality, threat exposure, and organisational maturity." It is guidance, not a direction issued under Section 70B(6) of the IT Act. The separate 2022 Directions on incident reporting are binding, and the blueprint restates the six-hour reporting obligation explicitly.

Does the 12-hour tier apply to every vulnerability?

No. It applies to a known exploited vulnerability affecting internet-facing and crown-jewel systems, and the wording is "immediate containment; patch, mitigate, or remove exposure within 12 hours where feasible." A critical externally exposed vulnerability that is not known to be exploited sits in the one-day tier. A high-severity finding sits at five days.

What if there is no vendor patch available?

The blueprint has a dedicated row for that case. It asks for temporary mitigation — isolation, access restriction, WAF or API protection, enhanced monitoring, or feature disablement — until remediation becomes available. The absence of a patch is not treated as a reason to leave exposure in place.

How does this interact with the six-hour incident reporting rule?

They are different clocks with different triggers. The six-hour rule under the 28 April 2022 Directions starts when a listed incident is noticed. The remediation tiers start when a finding is identified in your environment. A vulnerability sitting unpatched past its tier is not by itself a reportable incident; evidence that it was exploited is.

Do we need to buy a new tool to meet these timelines?

In most environments the binding constraint is inventory and ownership, not scanner or patching capability. You cannot assess exposure to a newly disclosed CVE within 12 hours if you cannot enumerate which assets run the affected component and who is accountable for each. The blueprint reflects this by placing asset visibility, attack surface management and SBOM/xBOM adoption at the top of its technical controls table.

What evidence should we keep for an audit?

Per finding: the discovery timestamp and its source, the tier assigned and the reasoning, the containment or patch action with its timestamp, the rescan or validation result, and — where a tier was missed — the documented compensating control and the approval that accepted the residual risk. The blueprint's validation section names remediation verification and independent audits among its assurance activities.

Does this apply to us if we are not in a regulated sector?

The blueprint is addressed to organisations generally and is not sector-scoped, though it identifies government, finance, telecommunications, Digital Public Infrastructure, healthcare, energy, transportation, manufacturing and digital services as facing elevated exposure. For unregulated organisations the practical relevance is evidentiary rather than regulatory: it is now the published national benchmark against which a remediation posture will be judged after an incident.

---

Conclusion

The 12-hour number is the part of CISG-2026-02 that travelled, and it is the least useful part to argue about. Whether your organisation can patch a production system in half a day is mostly a question about your change process. Whether you can remove exposure in half a day is a question about asset visibility, ownership and out-of-hours authority — and that is the question the blueprint is really asking.

Read that way, the document is less a patching mandate than a specification for a capability most Indian security programmes have been deferring: a continuously accurate picture of what is exposed, who owns it, and what happened to each finding, with timestamps. Everything in the six-row table is measurable once that exists, and nothing in it is measurable until it does.

The organisations that will struggle in the next audit cycle are not the ones missing a 12-hour window. They are the ones who cannot say, with evidence, how long anything took.

---

About the Author

Saurabh Pande is Co-Founder of Cyberaube Technologies with 13+ years of experience across enterprise security platforms including IBM Security, CyberArk, and QRadar. He has interviewed and placed 2,500+ cybersecurity professionals across SIEM, PAM, and IAM disciplines, and advises BFSI organizations on security operations strategy and compliance readiness.

---

About Cyberaube

Cyberaube provides cybersecurity staffing, 24/7 managed security services, and expert consulting for SIEM, IAM, and data protection platforms. Our certified specialists implement and operate QRadar, Splunk, ArcSight, CyberArk, Okta, SailPoint, and integrated security stacks for enterprises across India and globally.

Contact Cyberaube for SOC and vulnerability management support