What does SEBI's June 2026 consultation paper actually change?
On June 22, SEBI published the fourth consultation paper in its ease of doing business series for market infrastructure institutions. This one covers trading software and technology for exchanges and proposes a single consolidated circular for MIIs on common IT provisions: annual system audit, business continuity and disaster recovery, cyber security and cyber resilience, and capacity planning. Comments are open until July 13, 2026.
Read quickly, it looks like a compliance cleanup exercise, and much of it is. Duplicated provisions get deleted, obsolete references like WAP-based trading get removed, several reports that used to land at SEBI now go to the MII's own Standing Committee on Technology, and a long list of older cyber provisions gets folded into the Cybersecurity and Cyber Resilience Framework (CSCRF). The interesting part sits underneath the cleanup. SEBI is stripping out repeated language so that the remaining obligations converge on one question: can the institution show that its controls, recovery plans, and response processes actually work? Security teams did not need another binder of overlapping clauses. They needed a regulator that asks for proof, and this paper, read carefully, is that regulator asking.
Simplification is not relaxation
Here is the trap in reading this paper: treating every deleted provision as a lowered expectation. Look at what is being deleted and why. Quarterly cyber preparedness reviews, threat scenario reviews before the board, tabletop exercises and mock drills, VAPT, SOC operations, encryption of data at rest and in motion, backup management, change management, zero trust. Every one of these is proposed for removal from the master circular for a single stated reason: CSCRF already mandates it, often in more detail and on a tighter cycle. The paper cites the exact controls, from GV.PO on board-approved policy to RC.RP on response and recovery. The obligations survive. The duplication does not.
That trade is worth making. Duplicated regulation produces a specific kind of waste where teams spend audit season mapping one clause to another clause instead of asking whether a control held up when tested. Consolidation clears the noise, and what remains is harder to satisfy, not easier.
Now look at what SEBI keeps and strengthens. Adequate backup and restore systems at brokers move from advisable to mandatory. Live trading must run from the disaster recovery site for two consecutive days every six months, alternating quarters with DR drills. Primary and DR infrastructure must maintain one-to-one correspondence in hardware, system software, and network and security devices, and any exception now needs SEBI approval on the recommendation of its Technology Advisory Committee. If actual capacity utilization of any component crosses 75% of installed capacity, immediate action is expected, and for depositories that threshold is measured over a 15-day rolling window. None of this is paperwork. Running your market from the DR site for two full trading days is about as operational as evidence gets. The provisions that survived this cleanup are the ones that force an institution to demonstrate performance rather than attest to it.
Scenario-based resilience testing is the strongest idea in the paper
The most important cyber language the paper leans on comes from CSCRF guideline RC.RP.S2: comprehensive scenario-based cyber resilience testing at least twice per financial year, built around "extreme plausible cyber-attack scenarios" and informed by past incidents, near-miss analysis, SOC data, and honeypot logs. Results go before the IT committee, lessons learned go to SEBI within three months, and observations get tracked to closure.
That clause deserves more attention than it gets. Generic exercises no longer produce enough learning. A tabletop that walks a familiar incident script is useful for coordination, but it cannot tell you whether telemetry is present, whether detections fire, whether escalation works, or whether the same gap quietly reappears next quarter. The better question is whether you can safely emulate the attacker behaviors that matter and watch what actually happens. If an attacker gains execution on an endpoint, does the endpoint control stop it, and does the SOC see it? If a detection rule gets tuned after a miss, can the team re-run the same behavior and prove the outcome improved? Resilience becomes real when the institution has tested the whole chain, from control to telemetry to detection to response to remediation to retest, not when a document says the chain exists.
This is not only an Indian story. DORA in the EU mandates threat-led penetration testing for financial entities, the Bank of England runs CBEST, the ECB framework is TIBER, and Hong Kong has iCAST. Financial regulators are converging on the same position from different directions: documented controls are the floor, demonstrated resilience is the expectation. SEBI's consolidation fits that pattern cleanly.
Why periodic VAPT and red teaming are no longer enough
VAPT is necessary. Red teaming is necessary. Skilled human operators thinking creatively against a specific environment will keep finding things no automated system finds. Their limitation is time. These engagements are point in time, the report describes the environment as it was during the test window, and the environment changes the following week.
That limitation gets worse as attacker capability gets cheaper. Frontier-class reasoning is no longer confined to a handful of closed labs. The strongest open weight models now trade blows with the best proprietary systems, and once weights are public, every guardrail becomes optional. Advanced offensive iteration, where an agent inspects a target, forms a hypothesis, tests a payload, debugs the failure, mutates the technique, and tries again, stops being the preserve of state actors and reaches financially motivated groups who never had that depth of expertise before. If attackers are running agents to accelerate offensive work, a defense built on two human-led test windows a year is structurally behind. We have to beat their agents with our own.
Autonomous cyber resilience systems close the capacity gap
Collecting operational evidence should be the goal, and the way to sustain it is to run autonomous systems for cyber resilience alongside the humans. Most security teams are stretched thin on exactly the skills this requires: offensive depth, detection engineering, threat hunting, investigation bandwidth. That gap does not close by hiring, because the expertise is scarce everywhere, and it is scarcest at the mid-size institutions this circular covers.
Autonomous systems close it differently. An autonomous offensive validation system continuously tests relevant attacker behaviors in safe ways. Autonomous detection engineering identifies where detection logic is weak and proposes improvements. Autonomous threat hunting looks for related signals across telemetry, and autonomous investigation assembles context the moment something fires instead of an hour into triage. None of this removes the humans. People still set priorities, approve changes, own risk decisions, and handle judgment-heavy response. The system keeps the resilience loop moving between those decisions, and it keeps producing evidence even where in-house expertise is thin.
Operational evidence should become a leadership metric
Most security metrics still describe inventory or activity: open vulnerabilities, alerts generated, incidents closed, policies reviewed. Those numbers have their place, but none of them answers the resilience question. The metrics a technology committee should be asking for look different. Which attack behaviors did we validate this month? Which controls prevented them, which only detected them, and which missed entirely? Which fixes were retested, and did the retest pass?
That is operational evidence, and it strengthens compliance evidence rather than replacing it. A board makes better decisions when it can see what failed during realistic validation, what changed, and whether the change held up on the retest. A committee reviewing whether a policy exists is governance on paper. A committee reviewing misses and retest results is governance in practice.
Where adversarial exposure validation fits
The SEBI paper is not about any product category and should not be read as one. But the direction it points toward maps closely to adversarial exposure validation: safely emulating attacker behavior to measure whether security controls perform as expected.
This is the problem FourCore ATTACK was built for. The platform emulates real adversary behavior across endpoint, email, network, WAF, and DLP attack surfaces, mapped to MITRE ATT&CK, and measures what each control prevented, detected, or missed. It does not replace vulnerability management, VAPT, red teaming, EDR, SIEM, or the SOC. It makes those investments measurable, because a control being deployed is not the same as a control working. The part that matters most is what happens after a miss. In FourCore ATTACK, a failed validation becomes a remediation path: tune the rule, add the log source, adjust the policy, assign the owner, and re-run the same behavior to prove the fix worked. Sigma rules, detection guidance, and configuration recommendations come attached to the simulated behavior, so the loop from evidence to improvement to re-tested evidence stays intact. That loop is the operating model this regulatory direction is asking institutions to build.
The practical takeaway
The consultation paper cleans up the regulatory structure without letting institutions off the harder work, which is proving resilience continuously rather than once a year during an audit. A direct question worth asking your team this week: if a realistic attack scenario played out right now, what evidence do we have that our controls would hold, our SOC would see it, and our fixes would improve the next outcome? If the honest answer is a policy document and last year's VAPT report, that is the gap.
Attackers are getting faster, and AI-assisted offensive capability is spreading well beyond the actors who used to monopolize it. The institutions that do well from here will treat resilience as an operating system: validate continuously, engineer detections faster, remediate what actually failed, and retest until the improvement is real, with autonomous agents running that loop alongside their people. The goal is evidence that the institution can take a hit, learn from it, and come back stronger before the attacker gets the next iteration.
If you operate in this market, the consultation window is open until July 13, 2026. Read the draft circulars and respond. Regulators write better rules when practitioners tell them what evidence is actually feasible to produce.
