Skip to main content
SEBI CSCRF · Programme context, not legal advice · Reviewed August 2026

A CSCRF file is built from dated evidence, not assertions.

ShadowMap does not tell you which tier you fall into and does not sign your audit. What it produces is the record underneath: continuous external-monitoring evidence, a remediation timeline trail, accepted-risk entries that survive the decision that created them, and an action log per finding.

This is programme context, not legal advice. Nothing on this page interprets the framework for your entity, states which obligations attach to your tier, or asserts that any artefact will satisfy your auditor. That assessment work belongs to your compliance function and to Security Brigade.

Boundary

Classification and applicability are answered on Security Brigade

Which tier you fall into depends on your registration category and on your client count, assets under management or trading volume, and those tables have been rewritten twice since the framework was issued.

Security Brigade publishes the assessment side of this: the classification wizard, the obligation calendar and the per-tier cards. Taking your classification from a monitoring vendor's marketing page is the wrong way round.

What follows covers one narrow thing instead. A CSCRF review asks an organisation to demonstrate that certain things were happening continuously, not that they were true on the day someone looked. Continuous external monitoring leaves artefacts behind that speak to some of those expectations and are silent on most of them. The table below states which are which, and every row carries what it does not cover.

Evidence mapping

What is asked for, and what actually demonstrates it

One row per evidence expectation. The note beneath each row is the limit of that artefact, including the row where the answer is that the framework does not ask for this at all.

CSCRF evidence expectations mapped to external-monitoring artefacts
What a CSCRF review asks you to showThe artefact that shows itProduced by
A current inventory of assets A dated external asset inventory covering domains, subdomains, reachable services and exposed panels, with the attribution evidence that ties each entry to your organisation and not to a similar name. Attack Surface Management
CSCRF asset inventory covers the whole estate, including internal systems. Outside-in discovery covers the internet-facing part of it and nothing else. The internal register stays yours to maintain.
Monitoring that runs continuously, not at a single point in time A change record, not a report: what appeared, what changed, when it was first observed, and when it stopped being observed. The record itself is the evidence. Attack Surface Management
This is a record of external exposure. It is not a SOC, and it does not discharge whatever SOC or M-SOC obligation attaches to your tier. Which one attaches, and on what terms, is a classification question this page does not answer. Security Brigade publishes the tier cards that do.
Closure of findings inside a defined remediation timeline Per-finding timestamps for first observed, acknowledged, owner assigned and closed, measured against the remediation window your own policy sets, so adherence can be queried instead of reconstructed. The platform
The window is yours, not ours. CSCRF does not publish one universal remediation SLA, so the trail records adherence to whatever timeline your policy and IT Committee have defined.
Risks knowingly carried instead of remediated An accepted-risk record holding the finding, the approver, the rationale and the review date. It stays alongside the open queue instead of being deleted out of it, so an accepted risk resurfaces when its review date arrives. The platform
Acceptance is a decision your IT Committee or its delegate makes. The platform records the decision and keeps the finding visible; it does not make the decision, approve it, or judge whether it was reasonable.
Third-party and supply-chain exposure Vendor-side external findings scored with the identical categories, the same maths and the same bands used on your own estate, so an internal target and a vendor threshold are directly comparable. Third-Party Risk Management
The August 2025 clarifications place supply-chain risk assessment in consultation with the IT Committee. Outside-in vendor findings are an input to that assessment. They are not the assessment, and they do not see anything inside a vendor perimeter.
Exposure that has been tested, not only observed (which CSCRF does not ask for) Where it is safe and authorised, a validation record naming what was tested, the scope it was bounded to, the time it ran and the audit identifier for the run. Continuous Automated Red-Teaming
SEBI made BAS and Continuous Automated Red-Teaming recommendatory on 28 August 2025. See the section below before treating it as an obligation. Validation is also never universal: what was not tested says so.
Awareness of directives issued against you A dated log of advisories and directives from the authorities in scope for you, each routed to the part of the platform that holds your evidence for it, so the open question is whether a directive applies to you, not whether it exists. Regulatory Intelligence
Programme context, never legal advice. Tracking covers 31 authorities, which matters because SEBI amends this framework often, but a feed cannot tell you whether an amendment binds you.
An audit trail of who did what An action log per finding: who changed its state, what they changed it to, and when. Nothing is deleted from the queue, so a closed or accepted finding is still there to be produced. The platform
This is the platform’s own log and covers activity inside ShadowMap. It is one source among the several a CSCRF review will ask for, not the whole audit trail.

CSCRF evidence expectations mapped to external-monitoring artefacts

A current inventory of assets

The artefact that shows it
A dated external asset inventory covering domains, subdomains, reachable services and exposed panels, with the attribution evidence that ties each entry to your organisation and not to a similar name.

CSCRF asset inventory covers the whole estate, including internal systems. Outside-in discovery covers the internet-facing part of it and nothing else. The internal register stays yours to maintain.

Monitoring that runs continuously, not at a single point in time

The artefact that shows it
A change record, not a report: what appeared, what changed, when it was first observed, and when it stopped being observed. The record itself is the evidence.

This is a record of external exposure. It is not a SOC, and it does not discharge whatever SOC or M-SOC obligation attaches to your tier. Which one attaches, and on what terms, is a classification question this page does not answer. Security Brigade publishes the tier cards that do.

Closure of findings inside a defined remediation timeline

The artefact that shows it
Per-finding timestamps for first observed, acknowledged, owner assigned and closed, measured against the remediation window your own policy sets, so adherence can be queried instead of reconstructed.
Produced by
The platform

The window is yours, not ours. CSCRF does not publish one universal remediation SLA, so the trail records adherence to whatever timeline your policy and IT Committee have defined.

Risks knowingly carried instead of remediated

The artefact that shows it
An accepted-risk record holding the finding, the approver, the rationale and the review date. It stays alongside the open queue instead of being deleted out of it, so an accepted risk resurfaces when its review date arrives.
Produced by
The platform

Acceptance is a decision your IT Committee or its delegate makes. The platform records the decision and keeps the finding visible; it does not make the decision, approve it, or judge whether it was reasonable.

Third-party and supply-chain exposure

The artefact that shows it
Vendor-side external findings scored with the identical categories, the same maths and the same bands used on your own estate, so an internal target and a vendor threshold are directly comparable.

The August 2025 clarifications place supply-chain risk assessment in consultation with the IT Committee. Outside-in vendor findings are an input to that assessment. They are not the assessment, and they do not see anything inside a vendor perimeter.

Exposure that has been tested, not only observed (which CSCRF does not ask for)

The artefact that shows it
Where it is safe and authorised, a validation record naming what was tested, the scope it was bounded to, the time it ran and the audit identifier for the run.

SEBI made BAS and Continuous Automated Red-Teaming recommendatory on 28 August 2025. See the section below before treating it as an obligation. Validation is also never universal: what was not tested says so.

Awareness of directives issued against you

The artefact that shows it
A dated log of advisories and directives from the authorities in scope for you, each routed to the part of the platform that holds your evidence for it, so the open question is whether a directive applies to you, not whether it exists.

Programme context, never legal advice. Tracking covers 31 authorities, which matters because SEBI amends this framework often, but a feed cannot tell you whether an amendment binds you.

An audit trail of who did what

The artefact that shows it
An action log per finding: who changed its state, what they changed it to, and when. Nothing is deleted from the queue, so a closed or accepted finding is still there to be produced.
Produced by
The platform

This is the platform’s own log and covers activity inside ShadowMap. It is one source among the several a CSCRF review will ask for, not the whole audit trail.

The one thing to get right

Continuous Automated Red-Teaming was withdrawn in August 2025

It read as a requirement before that, and any vendor page still selling on it is selling on a basis that was withdrawn.

Aug 2024 → Aug 2025

BAS and CART under CSCRF, before and after

What the master circular said
The Cyber Security and Cyber Resilience Framework issued on 20 August 2024 used mandatory language for Breach and Attack Simulation and for Continuous Automated Red-Teaming: regulated entities shall deploy them.
What the 28 August 2025 technical clarifications changed
SEBI replaced that with a recommendation, to be taken in consultation with the IT Committee. The same circular moved other controls in the same direction: ISO 27001 and the mobile application security guidelines both went from mandatory to recommended for part of the population. Which part, and whether your entity is in it, is a classification question Security Brigade answers.
What is still mandatory, and what that leaves
A half-yearly red teaming exercise remains mandatory under the framework for the top two tiers, and automated testing does not substitute for it: the half-yearly exercise is a scoped manual engagement. Whether your entity sits in one of those tiers is, again, a classification question. Continuous Automated Red-Teaming is worth deploying if your IT Committee decides it is, because it keeps the estate tested between those engagements, not because a circular compels you.

The trail

An evidence file accumulates. It is not assembled the week before the review.

The order is the point: every step is only defensible because the one before it carries a date nobody could have supplied afterwards.

Sourcing

What this page was reviewed against

If you are reading this long after the date below, check it against the current circular before you rely on any line of it.

Circulars this page was read againstCaution As of August 2026
  • Master framework: SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, the Cyber Security and Cyber Resilience Framework, dated 20 August 2024.
  • Read with the clarifications of 30 April 2025 (CIR/2025/60) and the technical clarifications of 28 August 2025 (CIR/2025/119), and alongside SEBI’s AI vulnerability detection advisory of 5 May 2026.
  • SEBI issued six further circulars and clarifications against this framework between December 2024 and August 2025. Several of them changed whether a control is mandatory at all, so this page carries a review date.
  • The compliance dates have passed: the last extension ran to 31 August 2025. This page is written against a framework already in force, not one being prepared for.

Deliberately excluded

  • Tier classification. It turns on your registration category and on your client count, assets under management or trading volume, and Security Brigade publishes the tool for it.
  • Any mapping to control identifiers. A published clause mapping is a claim about what the regulator requires of you, it goes stale on the next amendment, and it is advisory work, not product documentation.
  • Data localisation, in abeyance since December 2024 and therefore not cited here as a current obligation.
  • Everything internal. Every artefact above is produced from outside your perimeter, so no internal control, no SOC obligation and no policy or governance artefact is covered.
  • Legal reading. Nothing here interprets the framework for your entity or asserts that any artefact will satisfy your auditor.

Questions this page gets asked

Before any of this goes into a compliance file

Does CSCRF require Continuous Automated Red-Teaming?

No. SEBI made Breach and Attack Simulation and Continuous Automated Red-Teaming recommendatory on 28 August 2025, to be taken in consultation with the IT Committee. The master circular of August 2024 did read as mandatory, which is where the claim comes from, but any vendor still selling CART as a CSCRF requirement is selling a requirement that no longer exists. It is worth deploying on its own merits, because it keeps the estate tested between the scoped manual engagements, and that is the case we make for it.

Does using ShadowMap make us CSCRF compliant?

No. Compliance is a determination made about your organisation by your auditor and ultimately by SEBI. What ShadowMap produces is evidence that an external monitoring control was operating: dated, scoped and attributable to specific assets. What that evidence is worth against a particular obligation is assessment work, and that is a Security Brigade engagement, not a product feature.

Can you map ShadowMap to specific CSCRF control identifiers?

Not on this page, and the omission is deliberate. A published clause mapping is a claim about what the regulator requires of you. It goes stale the moment SEBI issues another clarification: six have landed since the master circular, several of them changing whether a control is mandatory at all. It is also advisory work, not product documentation. In an engagement an adviser does that mapping against the circulars that actually bind you and against your own control set, which is the only version of it worth having.

Which tier do we fall into?

Tier turns on your registration category and on your client count, assets under management or trading volume, and those tables have been rewritten twice since the framework was issued. Taking that answer from a monitoring vendor is the wrong way round: Security Brigade publishes the classification wizard and the per-tier cards, and they are maintained against the current circulars.

Our auditor wants proof the monitoring ran, not a walkthrough. What do we hand over?

The external inventory as it stood on the dates under review, the change record covering the period, each finding with the state it was given and the timestamps around it, the accepted-risk entries with their approvers and review dates, and the action log showing who did what. It is the ordinary operating record of the platform, exported for the period as it stood. Nothing is assembled specially for the review.

See what your CSCRF evidence file is missing from outside

One apex domain, two business days, a written snapshot of what is already reachable: assets, credentials, leaked code and impersonating domains. No call required.