| TL;DR A service level agreement (SLA) clause for emergency patches should name who patches, how fast, and what proof you receive. Tie urgency to exposure and active exploitation, not to a severity score alone. A critical advisory from the Indian Computer Emergency Response Team (CERT-In) is the usual trigger in India; mitigation can start before the patch lands. Ask for patch logs, a compromise check and a written exception for anything left unpatched. |
When a critical security vulnerability affects a managed server, the provider and customer need to know who is responsible, what action must be taken, and how quickly the risk must be addressed. A contract that promises only that security patches will be applied regularly may not define an emergency response deadline, interim mitigation requirements, or proof of remediation.
For CIOs, IT heads, and procurement teams evaluating managed server services in India, an emergency patching SLA should define responsibility for each software and infrastructure layer, risk-based response timelines, customer approval requirements, and evidence of completed work.
This guide explains the clauses buyers should review before signing or renewing a managed server contract, including what happens when a patch is unavailable, a production reboot requires approval, or a security investigation reveals a possible compromise.
Who Owns an Emergency Patch on a Managed Server?
Responsibility for emergency patching depends on the services covered by the managed server contract. The provider may manage the operating system, kernel, hypervisor, firmware, and monitoring agents, while the customer retains responsibility for application code and certain software components. The exact division must be documented in the agreement.
Gaps often occur in the software layer between the operating system and the application. A web server, PHP runtime, database engine, or control panel may be installed during server provisioning but excluded from the ongoing maintenance scope. When a vulnerability affects one of these components, unclear ownership can delay remediation.
Before signing the contract, create a layer-by-layer responsibility matrix. For each component, identify who monitors security advisories, assesses exposure, approves emergency changes, applies patches, verifies the outcome, and communicates any delay.
Typical areas to define include:
-
Infrastructure and operating system: Operating system packages, kernel updates, hypervisor, firmware, and infrastructure management agents.
-
Middleware and platform software: Web servers, language runtimes, database engines, and control panels. Specify whether the provider manages each component or whether it remains the customer’s responsibility.
-
Application components: Application code, plugins, dependencies, and third-party libraries, with ownership assigned according to the agreed service scope.
The same matrix should identify dependencies between the provider’s responsibilities and the customer’s responsibilities. If a patch requires application testing, a maintenance window, or customer approval, the contract should define how those dependencies are handled during an emergency.
For a comparison of the wider responsibilities involved, see our guide to choosing between managed and unmanaged dedicated servers.
Figure 1. The infrastructure, operating system, middleware, and application layers that should be covered by a managed server patching responsibility matrix.
Why a CERT-In Critical Advisory Changes the Patch Clock
Last updated: 27 Oct 2026
A critical security advisory can require action outside the routine maintenance cycle, particularly when the affected service is exposed to the internet or the vulnerability is being actively exploited. The contract should therefore define an emergency response process that does not depend on the next scheduled patch window.
Two October 2026 notices show why. In advisory CIAD-2026-0049, CERT-In reports that in a financially motivated campaign against Indian entities, agentic tooling compressed the time from initial access to final impact from days to a few hours. The same advisory says victims that remediated incompletely were attacked again within days, at greater scale. A half-finished patch, in other words, is not a safe resting point.
Six days later, CERT-In issued vulnerability note CIVN-2026-0510 on remote code execution flaws in PHP 8.2 to 8.5, rated critical, with a risk assessment of complete system compromise. PHP sits exactly in the middle layer described above, which is why the owner list matters.
The wider data points the same way. The US Cybersecurity and Infrastructure Security Agency (CISA), citing Verizon’s 2026 Data Breach Investigations Report, says only 26% of vulnerabilities in CISA’s Known Exploited Vulnerabilities (KEV) catalogue were fully remediated in 2025, down from 38%, with a median of 43 days to full resolution. A contract that only promises the monthly cycle leaves that gap open.
The National Institute of Standards and Technology (NIST) treats this as a planning problem. Its Special Publication (SP) 800-40 Revision 4 guide to enterprise patch management (April 2022) recommends defining maintenance plans in advance, including an emergency path for vulnerabilities that cannot wait for routine maintenance, and using mitigations when a patch cannot yet be applied.
Urgency Tiers for an Emergency Patching SLA on Managed Servers
A tiered emergency patching SLA helps buyers and providers prioritize remediation according to the risk posed by a vulnerability. Instead of using a severity score alone, the contract should consider internet exposure, evidence of exploitation, potential system impact, available mitigations, and the availability of a tested fix.
The following framework is a starting point for contract negotiations, not a prescribed regulatory standard. Buyers should agree on the applicable deadlines with their provider and adjust them to the workload’s risk profile, business requirements, and operational constraints.
The contract should distinguish four separate milestones: acknowledgement and assessment, interim mitigation, patch deployment, and verification. A deadline for one milestone should not be treated as completion of the entire remediation process.
| Tier | Trigger | Interim mitigation | Patch and verification |
|---|---|---|---|
| Tier 1, emergency | Actively exploited or highly exposed vulnerability with potential for major compromise | Apply effective mitigation within the agreed emergency window; isolate or restrict the service if necessary | Use a specifically agreed emergency deadline after a compatible fix becomes available; verify remediation and assess possible compromise |
| Tier 2, urgent | High-risk vulnerability without confirmed exploitation, or a critical issue with limited exposure | Apply appropriate controls according to risk and document any residual exposure | Patch within the shorter, contractually defined urgent window and verify the result |
| Tier 3, routine | Lower-risk vulnerability without indicators requiring emergency handling | Apply controls where warranted by the risk assessment | Address within the normal maintenance cycle defined in the contract |
These tiers are proposed contract terms, not universal patching deadlines. If a buyer uses an external framework as a benchmark, the article should identify its scope and limitations. For example, requirements issued by CISA for US federal agencies do not automatically apply to Indian managed server contracts. The final SLA should specify actual time limits, clock-start conditions, escalation procedures, and how exceptions are approved.
For example, an internet-facing eCommerce application running an affected PHP release may require emergency mitigation and expedited patching. An internal reporting database with restricted network access may follow a different timeline, provided the exposure assessment supports that decision. In both cases, the provider and customer should document the rationale, applicable controls, and deadline for reassessment.
Figure 2. How internet exposure and evidence of exploitation can inform emergency patch prioritization.
Evidence to Request and What CERT-In Reporting Covers
A patch clause is only as good as the proof behind it. Ask for records that show the patch was applied, that the server was checked for compromise before and after, and that anything left unpatched has a named owner and an expiry date.
The CERT-In Directions of 28 April 2022 under section 70B shape what that evidence should include. They require service providers, data centres and body corporates to report listed cyber incidents within 6 hours of noticing them, to keep information and communication technology (ICT) system logs for a rolling 180 days within Indian jurisdiction, and to synchronise system clocks to an approved time source. Patch records with accurate timestamps fit naturally into that log set.
A missed emergency patch is not itself a reportable incident; an intrusion through that unpatched service can be. Annexure I of the Directions lists the reportable types, including unauthorised access of IT systems or data and compromise of critical systems or information. An unpatched system on its own is not a listed category, which is why the compromise check matters: it tells you whether the 6-hour clock has started.
Rollback matters too. A patch that breaks a service needs a restore point taken just before it, and the difference between that and a full recovery plan is covered in our explainer on backup versus disaster recovery.
Figure 3. An emergency patch workflow covering alert assessment, mitigation, patch deployment, verification, and rollback where required.
EVIDENCE TO REQUEST
|
What Happens When an Emergency Patch Cannot Be Applied?
A security patch may be unavailable, incompatible with the production environment, or require testing before deployment. In such cases, the provider should not treat the issue as resolved simply because the patch cannot be installed immediately.
The emergency patching SLA should define an alternative process:
-
Document the blocker: Identify the affected server, vulnerability, reason for delay, and expected availability of a fix.
-
Apply interim controls: Restrict network access, disable the affected feature, deploy a suitable security rule, or isolate the service where appropriate.
-
Obtain approval: Record the customer’s acknowledgement of any residual risk and the approval required for downtime or service isolation.
-
Set a review deadline: Assign an accountable owner and a date for reassessing the exception.
-
Escalate overdue exceptions: Specify who must be notified if the agreed remediation deadline cannot be met.
-
Close the exception: Record the final patch deployment, verification results, and removal of temporary controls where appropriate.
If no effective mitigation is available, the provider and customer should assess whether continued operation is acceptable or whether the affected service needs to be isolated or temporarily disabled. The decision and its rationale should be documented.
A patching exception should be a controlled, time-bound risk decision, not an indefinite substitute for remediation.
An emergency patching SLA cannot cover components outside the agreed service scope, make unsupported software compatible with new fixes, or eliminate the operational risks associated with production changes. Some patches require a reboot, application testing, or a planned maintenance window. The contract should define the approval process, interim safeguards, escalation route, and responsibility for any delay. Where immediate action is necessary to reduce a serious security risk, it should also specify who can authorize isolation or service shutdown.
Emergency Patching SLA: Contract Review Checklist
| Contract criterion | Why it matters | What to verify |
|---|---|---|
| Patch ownership | Prevents gaps between infrastructure and application responsibilities | Named owner for each software and infrastructure layer |
| Emergency response clock | Prevents delays while teams determine who should act | Defined acknowledgement, assessment, mitigation, and patch deadlines |
| Risk-based prioritisation | Ensures urgent vulnerabilities receive appropriate attention | Triggers based on exposure, exploitation evidence, and potential impact |
| Interim mitigation | Reduces exposure while a patch is unavailable or being tested | Approved mitigation options and verification requirements |
| Patch verification | Confirms that remediation was completed successfully | Software version, vulnerability status, and service-health results |
| Exception management | Prevents unresolved vulnerabilities from being overlooked | Documented reason, compensating control, accountable owner, and review date |
| Change and rollback | Reduces the risk of service disruption during emergency updates | Approval process, restore point, rollback criteria, and recovery responsibilities |
| Incident escalation | Supports timely investigation and required notifications | Named contacts, escalation route, evidence preservation, and reporting responsibilities |
Use this checklist during contract negotiations and periodic service reviews. The specific deadlines and responsibilities should be written into the agreement rather than left to informal operating practices.
Frequently Asked Questions
Does a CERT-In advisory legally require my provider to patch within a set time?
Not automatically. A vulnerability advisory and a binding direction are different. The emergency patching deadline generally needs to be established in the managed server contract unless a separately applicable law, regulatory requirement, or specific direction imposes an obligation. Buyers should verify the requirements that apply to their organization and industry.
Can my provider reboot a production server without asking?
That depends on the contract and the agreed change-management process. The agreement can authorize emergency reboots for predefined server groups while requiring approval for systems where downtime could affect critical workloads. Specify the authorized approvers, notification process, rollback procedure, and escalation path for urgent situations.
Do we have to report an incident to CERT-In within 6 hours if we are still investigating?
No. A missed patch does not automatically mean a reportable cyber incident has occurred. The six-hour requirement under the CERT-In Directions applies to listed cyber incidents noticed by covered entities. If exploitation or another reportable incident is suspected or detected, the organization should promptly assess its reporting obligations and follow the applicable incident response procedure.
What if the vendor has not released a patch yet?
The provider should follow the agreed mitigation process rather than waiting without taking action. Depending on the vulnerability, this may involve restricting access, disabling an affected feature, applying a suitable security control, or isolating the service. The provider should document the residual risk, identify the accountable owner, set a review deadline, and deploy and verify the fix when it becomes available.
When Should You Negotiate a Tiered Emergency Patching SLA?
A tiered emergency patching SLA is particularly valuable when managed servers support internet-facing applications, business-critical databases, customer data, or workloads subject to specific security and compliance requirements. It helps organizations define what the provider must do when a vulnerability cannot wait for the next routine maintenance window.
Before signing or renewing a managed server contract, confirm that it identifies patch owners for every relevant software layer, defines response and remediation deadlines, provides for interim mitigation, and requires evidence of successful remediation. It should also specify how patch failures, production downtime, unresolved vulnerabilities, and suspected compromises will be handled.
The objective is not simply to demand faster patching. It is to establish a clear, auditable process that reduces exposure while protecting service availability. Buyers should review the proposed timelines against their workloads, risk tolerance, and applicable obligations before agreeing to the final SLA.
|
NEXT STEP Review your managed server requirements with RackBank’s team to define patch ownership, emergency response timelines, verification procedures, and escalation responsibilities. |
