SEBI's MII subsidiary proposal: three tests, one narrow exemption

SEBI has put out a consultation paper proposing that an MII's IT and cyber security framework follow the work into its subsidiaries. The paper is dated 11 September 2026 and comments close on 2 October 2026. It runs to five pages: three short tests, two provisions on what falls outside them, and a table of ten worked examples.

This is a proposal, not a circular. Nothing below binds anyone today.

The gap SEBI says it is closing

MIIs are governed by SEBI's IT and cyber framework, but the applicability and regulatory jurisdiction of that framework are, in the paper's words, "not explicitly defined over their subsidiaries."

The subsidiaries it has in mind are the ones that grew out of the parent's own operations. Such subsidiaries, the paper says, "may be required to operate in close coordination with the parent MII and may utilize shared technology infrastructure, applications, market data or other critical IT resources." Subsidiary takes its meaning from section 2(87) of the Companies Act, 2013. The concern was deliberated in SEBI's Technical Advisory Committee on 9 December 2025.

Three tests, and any one of them is enough

Under proposed paragraph 9.1.1, the parent's framework would also apply to a subsidiary that:

• 9.1.1.1: is carrying out "an activity which the MII is supposed to do"
• 9.1.1.2: "is handling the data which the MII is supposed to handle"
• 9.1.1.3: "is sharing the infrastructure with MII"

The tests are joined by "or". Meeting one would be enough. Proposed paragraph 9.1.2.1 addresses the subsidiary that meets none of the three.

What would follow for a subsidiary that meets one is stated in a single sentence. Such subsidiaries would comply with all applicable requirements relating to "cyber security, system audits, incident reporting, BCP-DR and technology governance, etc."

That list ends in "etc.", so it is a floor rather than a boundary. Four of the five named obligations are recurring rather than one-off: a system audit has a cycle, incident reporting has clocks, BCP-DR has tests, and technology governance has committees and minutes.

SEBI's illustrations point at shared services

Annexure-A carries ten worked examples, which SEBI marks as "Not Exhaustive". Six are marked Applicable and four Not Applicable. Four of the six are shared-services subsidiaries rather than product ones, and every one of the six is tied to the parent by the example's own wording.

Annexure-A	The example SEBI gives
Row 1	Develops, operates and maintains "the trading engine used by the parent Stock Exchange"
Row 2	Operates "the SOC, SIEM, vulnerability management and incident response for the parent MII"
Row 3	Hosts "production servers, databases or disaster recovery infrastructure used by the parent MII"
Row 4	Provides "analytics, surveillance or AI services using trading, settlement or investor data of the parent MII"
Row 5	Manages "Active Directory, Identity & Access Management, email or network services for the parent MII"
Row 6	Administers "production servers, databases or storage used by the parent MII"

That nexus is doing the work. In every row the service is rendered to the parent, which is what engages one of the three tests. A subsidiary running Active Directory for itself is not the example SEBI gives; a subsidiary running it for the parent is.

Row 2 repays attention: a subsidiary that runs the parent's security operations would itself come inside the framework it operates. SEBI's stated reason is that it manages critical cyber security functions affecting the MII. Row 6's reason is blunter: "It has privileged access to critical systems and infrastructure."

The four SEBI marks Not Applicable are an investor-education or certification subsidiary with no access to MII systems or data, facility management, an independent financial services business under its own regulator with its own infrastructure, and HR or payroll without access to trading, clearing, settlement or depository systems.

The proportionality route is narrower than the headline suggests

Paragraph 9.1.3 offers a proportionality route, and it is easy to over-read. It would be available to a subsidiary "meeting only condition (9.1.1.3) i.e. sharing of IT infrastructure with MII", and to nothing else. A subsidiary that also handles MII data, or performs an activity the MII is supposed to do, would fall outside it.

Where it would apply, the MII "may seek exemption from SEBI", and the proposal is that the request include "details of compensatory controls put in place / proposed to be put in place" together with the views of SCOT and of the Board of the MII.

That is a filing with three separate contents. The compensatory controls have to exist, or be committed to, before the request is credible, which in practice means the assessment that identifies them comes first.

Our reading, for a shared-services subsidiary

The hard case here is not the trading-engine subsidiary in row 1. It is the shared-services company in rows 5 and 6: Active Directory, IAM, email, network, storage administration, run as internal IT, on an internal IT budget, with internal IT assurance.

Two things would change for that entity if the proposal were adopted as drafted, and neither is a control.

Scope becomes a documented artefact. The phrase "all the applicable requirements" has to be resolved against a named systems boundary. A subsidiary administering production databases for the parent has to be able to say which systems it touches, at what privilege, and which of those the parent classifies as critical. That mapping is the input to every other line, and it is usually the thing that does not exist yet.

Incident reporting acquires a recipient outside the group. Reporting to a regulator is a different artefact from escalating to the parent's IT director: it carries a clock, a defined content and an evidence trail. Clocks that run outside the group change what has to be detected, logged and timestamped at the subsidiary rather than at the parent.

The cheapest time to establish which of the three tests an entity meets is while the proposal is still a proposal.

Where to start

List the subsidiaries and run each against the three tests in 9.1.1. The second-order question is the harder one: which of the parent's systems each subsidiary actually touches, and at what privilege.

For any subsidiary that meets only 9.1.1.3, decide early whether you intend to seek the 9.1.3 route. It would need compensatory controls, a SCOT view and a Board view, and Board cycles are slower than assessment cycles.

For everything else, treat system audit scope as the first deliverable rather than the last. The obligations in 9.1.1 all resolve against a boundary.

Comments go to SEBI through its public comments form and close on 2 October 2026. The paper names two officers for technical difficulties with the form, and asks that email submissions carry the subject "Applicability of IT and Cyber Security Framework of MIIs to their Subsidiaries".

Security Brigade has been CERT-In empanelled since 2008 and works with MIIs and their subsidiaries on system audit scoping, VAPT and CSCRF readiness. If you are working out which of your subsidiaries the three tests reach, that is a conversation worth having before the consultation closes.