CSCRF sets precise patching timelines, specific evidence requirements and defined technical controls across access, network, application and endpoint layers. It means even if you have controls in place, you need the discipline to document, test and retain proof that those controls are working every day, not just on audit day.
This blog covers what patch management and technical controls under CSCRF require, where regulated entities most commonly fall short and what audit-ready evidence looks like in practice.
What CSCRF requires on patch management
Patching timelines by severity
Patch management sits inside CSCRF’s Protect function under the Maintenance standard. The framework sets three patching windows based on vulnerability severity:
- Critical vulnerabilities must be patched within 24 hours of identification.
- High-severity findings from VAPT must be closed within one week.
- All other VAPT findings must be remediated within three months of the report date.
For an exchange or clearing corporation processing millions of orders daily, the 24-hour window for critical vulnerabilities is operationally demanding. It does not accommodate standard change management cycles or scheduled downtime windows. The clock starts when the vulnerability is identified.
SEBI’s May 2026 AI advisory reinforced this further. It confirmed that virtual patching is an accepted compensatory control when a full code fix cannot be deployed within the window. It must be documented with a timeline for the permanent fix.
What the evidence chain must show
An auditor reviewing patch management does not accept verbal confirmation. They expect a documented evidence chain for every finding. The chain must show four things: the vulnerability discovery date, the patch applied date, the re-validation date and confirmation from a qualified party that the fix holds.
The re-validation point is where most regulated entities fall short. Applying the patch is not sufficient. The fix must be independently re-scanned or certified, and that evidence must be retained and producible on audit day. Anything still open beyond three months requires formal IT Committee approval with documented justification.
Technical controls CSCRF requires
Access management and identity controls
CSCRF requires enforcement of the principle of least privilege across all systems. For exchanges managing connectivity to thousands of trading members, this means role-based access to trading infrastructure, settlement systems and market data feeds – with access reviews conducted periodically and documented.
Multi-Factor Authentication (MFA) is mandatory for privileged access. Privileged Access Management (PAM) solutions are required for administrative accounts with elevated system access.
The most common audit failure here is not the absence of MFA. It is undocumented access reviews. When an auditor asks when you last reviewed who has access to your settlement system, the answer must be supported by a dated review record with sign-off. A verbal answer is a finding.
Network security and segmentation
CSCRF is specific about network architecture for Market Infrastructure Institutions (MIIs): critical trading systems must be isolated from corporate networks through segmentation. The order matching engine, risk management system and settlement infrastructure must each operate in isolated network zones.
The common failure is segmentation that exists on paper but has not been validated. Auditors expect configuration evidence. The actual firewall rule exports and network diagrams showing isolation and not policy documents. If you cannot produce the export, the control is unverifiable.
SEBI’s May 2026 advisory explicitly recommended Zero Trust architecture as a measure to reduce attack surfaces for entities with large third-party connectivity footprints.
Application security and API controls
CSCRF requires regulated entities to follow Secure Software Development Lifecycle (SSDLC) practices. VAPT must be conducted after every major release or material system change. An exchange that deploys a trading platform update without a post-release VAPT has a gap auditors will flag.
API security controls are explicitly required under CSCRF: rate limiting, throttling and authentication and authorisation mechanisms on every API endpoint. For exchanges whose trading members connect via APIs, an unsecured or under-monitored endpoint is a direct path to market manipulation or data extraction.
Endpoint security and log retention
CSCRF requires Endpoint Detection and Response (EDR) solutions across all endpoints. Audit logs must be maintained with a minimum two-year retention period.
The common failure is EDR deployed in monitor mode rather than active block mode. An auditor checks not just that the tool is installed but whether alerts are being reviewed and acted upon. Log retention must be verified through configuration evidence. Two years must be confirmed, not estimated.
Building the evidence package auditors expect
For MIIs and Qualified Regulated Entities (QREs), the evidence package must be maintained continuously – not assembled in the weeks before an audit. The following must be producible at any point in the compliance year:
- Vulnerability closure tracker showing discovery date, patch date and re-validation date for every finding.
- Firewall configuration exports and network segmentation diagrams.
- Access control lists and periodic access review records with dated sign-off.
- PAM deployment records and MFA enforcement evidence for privileged accounts.
- SSDLC documentation and post-release VAPT reports for every major change.
- API security configuration records covering rate limiting and authentication settings.
- EDR deployment records with evidence of active monitoring and alert review.
- Audit log retention configuration evidence confirming two-year storage.
- IT Committee minutes showing patch status reviewed as a standing agenda item.
Auditors are trained to recognise evidence assembled under pressure. Quarterly IT Committee minutes with identical language, VAPT closure dates that cluster just before submission deadlines, incident logs with no entries throughout the year – all of these are recognised patterns that invite deeper scrutiny.
Conclusion
CSCRF does not reward effort. It rewards evidence. For exchanges and depositories managing India’s critical market infrastructure, the technical controls are not the hard part. The hard part is the continuous discipline of documenting, testing and retaining proof that those controls are working every day.
Patch within the window. Re-validate the fix. Keep the evidence chain intact. Review access quarterly. Test network segmentation. Run your SOC actively.
That is what CSCRF compliance looks like in practice. CyberNX works with MIIs, Qualified REs and other regulated entities to build technically sound, audit-ready CSCRF programmes. Connect with our SEBI CSCRF consulting team to assess where your current controls and patch management processes stand.
FAQs
What are the patch management timelines under SEBI CSCRF?
CSCRF sets three patching windows. Critical vulnerabilities must be patched within 24 hours of identification. High-severity VAPT findings must be closed within one week. All other findings must be remediated within three months of the report date. Findings still open beyond three months require formal IT Committee approval with documented justification. Virtual patching is an accepted compensatory control when a full fix cannot be deployed within the window.
What technical controls do SEBI auditors check most closely?
Auditors focus on four areas: access management, network segmentation, application security and endpoint protection. The common failure across all four is the same. The control exists but the operating evidence does not. Auditors expect configuration exports, access review records, post-release VAPT reports and EDR monitoring logs — not policy documents alone.
What is the difference between a VAPT report and closure evidence under CSCRF?
A VAPT report identifies vulnerabilities and is produced by a CERT-In empanelled auditor. Closure evidence is separate. It is proof that each finding was fixed within the required window, confirmed by a re-scan or third-party certificate dated after the fix. Stating that a patch was applied is not sufficient. SEBI auditors expect the full evidence chain: discovery date, patch date, re-validation date and qualified confirmation.
