SEBI CSCRF Compliance Checklist: VAPT and SBOM Requirements

SEBI issued its Cybersecurity and Cyber Resilience Framework (CSCRF) for Regulated Entities (REs) on 20 August 2024, under circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113. The circular replaced SEBI's earlier, entity-specific cybersecurity circulars with a single framework, and it names nineteen categories of REs it applies to, from stock exchanges and depositories to investment advisers, portfolio managers and mutual funds.

CSCRF is not a one-time audit. It sets recurring obligations for vulnerability assessment and penetration testing (VAPT), a software bill of materials (SBOM) for critical systems, application security testing built into the development lifecycle, log collection and retention, and a security operations centre (SOC), each graded by how SEBI categorises the RE. SEBI has also revised the framework since the original circular: a clarifications circular changed some entity thresholds, and two further circulars extended the compliance deadline.

This checklist works through what the circular and its clarifications require, clause by clause, for applicability, VAPT, SBOM, application security testing, log retention, SOC and the compliance timeline. It is not a substitute for reading the circular itself.

Who CSCRF Applies To and How REs Are Categorised

CSCRF applies to nineteen categories of SEBI regulated entities named in clause 16 of the circular: Alternative Investment Funds, Bankers to an Issue and Self-Certified Syndicate Banks, Clearing Corporations, Collective Investment Schemes, Credit Rating Agencies, Custodians, Debenture Trustees, Depositories, Designated Depository Participants, Depository Participants, Investment Advisers and Research Analysts, KYC Registration Agencies, Merchant Bankers, Mutual Funds and Asset Management Companies, Portfolio Managers, Registrars to an Issue and Share Transfer Agents, Stock Brokers, Stock Exchanges and Venture Capital Funds.

Section 2 of CSCRF, "Thresholds for REs' categorization," sets out a graded approach with five categories: Market Infrastructure Institutions (MIIs), Qualified REs, Mid-size REs, Small-size REs and Self-certification REs. Which standards apply, and how often, depends on the category. The category is fixed for the whole financial year: "The category of REs shall be decided at the beginning of the financial year based on the data of the previous financial year," and it does not change even if the RE's underlying numbers move during the year.

Exact thresholds are set per entity type (AUM for Alternative Investment Funds, active client counts for stockbrokers, and so on), and SEBI revised several of them in its April 2025 clarifications circular, which also re-categorised KYC Registration Agencies from MIIs to Qualified REs and moved Alternative Investment Fund and Venture Capital Fund categorisation to the fund manager level.

VAPT Frequency and Scope

Clause 4.3 of CSCRF sets out VAPT requirements, cross-referenced to standard DE.CM.S5. REs must plan VAPT activity at the start of the financial year, and periodicity depends on category:

• REs identified as "Protected systems" and/or Critical Information Infrastructure by the National Critical Information Infrastructure Protection Centre must complete a full VAPT cycle, including report submission, closure and revalidation, in each half of the financial year (April to September and October to March).
• The rest of REs must complete VAPT at least once a year, commencing in the first quarter of the financial year.

Once a VAPT activity is complete, CSCRF sets fixed timelines: the report must be submitted, after IT Committee approval, within one month; findings must be closed within three months of report submission, using a graded approach based on criticality; and revalidation must be completed within five months of completing the original VAPT. Any vulnerability still open after three months has to be approved by the IT Committee for REs and closed before the next VAPT cycle starts.

Annexure-L sets the VAPT scope, which CSCRF says must be "made transparent to SEBI" and cover internal and external infrastructure, internal and external applications, external penetration testing, WiFi testing, API security testing, network segmentation, mobile applications, OS and database assessment, cloud implementations and configuration audit. The methodology should draw on CSCRF itself, NCIIPC and CERT-In guidelines, NIST SP 800-115, ISO 27001, PCI DSS, the OSSTMM and the OWASP Testing Guide.

REs running this cycle themselves can use SecOpsTool's VAPT Services, which combine automated scanning with manual testing led by OSCP, CEH and CREST-certified testers, and deliver a report with CVSS scores, proof-of-concept evidence and remediation guidance, followed by a re-test of the fixes. For the scanning layer feeding a VAPT programme, Nessus is built to find flaws, missing patches and misconfigurations across operating systems, devices and applications, with compliance audit templates included.

SBOM Requirements

CSCRF's supply-chain risk management standard, GV.SC, makes an SBOM mandatory for all REs. Existing critical systems needed an SBOM "within 6 months (starting from the date of issuance of CSCRF)" of the circular. New critical systems and Software-as-a-Service applications need an SBOM "at the time of procurement," and MIIs must include SBOM as part of their empanelment criteria for application software vendors.

CSCRF specifies what an SBOM has to contain: licence information; the name of the supplier; all primary, top-level components together with their transitive dependencies, whether in-house or open-source; the encryption used; cryptographic hashes of components; frequency of updates; an account of "known unknowns" where the dependency graph is incomplete; access control; and a method for handling occasional incidental errors. For legacy or proprietary systems where an SBOM genuinely cannot be obtained, the Board, Partners or Proprietor of the RE has to approve the exception with a documented rationale and risk-management approach, rather than the item simply being skipped.

For building this into a pipeline, O3 Security's SEBI CSCRF page maps its SBOM output onto the framework's required fields, licence, supplier, transitive dependencies, encryption, hashes and update frequency, generated in CycloneDX format. Mend.io generates SBOMs in both SPDX and CycloneDX formats, keeps them updated as dependencies change, and can incorporate VEX data and third-party SBOMs alongside its own.

Application Security Testing and Secure SDLC

Under standard PR.IP.S16, all software solutions, applications and products used for critical systems must mandatorily pass through a defined set of tests: Dynamic Application Security Testing (DAST), described in CSCRF as scanning applications in real time against sources such as the OWASP Top 10 and SANS Top 25 CWE; Static Application Security Testing (SAST), for analysing source code for issues such as SQL injection, buffer overflows and XML external entity attacks; a functional audit; VAPT after every major release; an SBOM; a Requirement Traceability Matrix; and an audit of firewall, WAF and token configuration. CSCRF also requires that all critical systems logs be integrated with the RE's SOC, and that application security testing include API security and API discovery.

CSCRF's Secure Software Development Life Cycle guidelines also require regression testing, covering business logic, security controls, performance under stress and recovery conditions, before any new or modified system goes live, plus vulnerability assessment for every production release. CSCRF states that threat modelling and application security testing shall be conducted during development, and that REs shall refer to application security standards published by OWASP, giving OWASP-ASVS as an example.

For the SAST and API security layer, Checkmarx One is described by its vendor as an application security platform built to secure every stage of the SDLC, combining source-code scanning, open-source dependency scanning, API security testing, infrastructure-as-code scanning and secrets detection.

Log Management and Retention

CSCRF's PR.AA guidelines require REs to identify every log source and collect from it. The indicative list given is system logs, application logs, network logs, database logs, security logs, performance logs, audit trail logs and event logs. On retention, CSCRF does not set one fixed number of years across the board; instead it requires that a strong log retention policy be implemented as per government guidelines, policies, laws, circulars and regulations issued by SEBI or the Government of India, naming the IT Act 2000, the Digital Personal Data Protection Act 2023, and requirements from CERT-In and NCIIPC as the governing references. REs also have to monitor all logs to identify unusual patterns and behaviours in events and incidents, not just archive them.

This sits alongside the earlier requirement that all critical systems logs be integrated with the RE's SOC, so log collection, retention and SOC integration tend to be one design decision, not three.

SOC Requirements

CSCRF states that it has mandated a SOC for all REs, except client-based stockbrokers with fewer than 100 clients, and allows three models: an RE's own or group SOC; the Market SOC, which NSE and BSE must set up and NSDL and CDSL may optionally set up; or a third-party managed SOC. Small-size and Self-certification REs are mandated to be on-boarded onto the Market SOC, though SEBI's August 2025 clarifications allow REs in those categories that already have their own SOC, by virtue of a different regulated activity, to leverage it instead, while still submitting the periodic SOC efficacy report CSCRF requires.

For MIIs and Qualified REs, CSCRF adds further obligations: they must measure the functional efficacy of their SOC on a half-yearly basis, using the reporting format in Annexure-N; they must conduct a goal-based adversarial simulation red-teaming exercise on a periodic basis to identify weaknesses in their defences; and they must run threat hunting and compromise assessment on a regular basis.

Testing whether a SOC catches what it is meant to catch is a different exercise from building it. Cymulate's Exposure Validation product runs continuous testing of current threats and MITRE ATT&CK techniques against the controls a SOC depends on, including EDR, SIEM, web and email gateways, WAF and DLP, which maps onto the red-teaming and threat-hunting obligations above.

Compliance Timelines and Extensions

The original circular set a two-track glide path in clause 17: REs already covered by an earlier SEBI cybersecurity circular had until 1 January 2025 to comply, while REs for whom CSCRF was being issued for the first time had until 1 April 2025. SEBI then extended these dates twice. Its March 2025 circular extended the compliance timeline by three months, to 30 June 2025, for all REs except Market Infrastructure Institutions, KYC Registration Agencies and Qualified Registrars to an Issue and Share Transfer Agents. Its June 2025 circular extended it again, by two further months, to 31 August 2025, with the same three exclusions. MIIs, KRAs and QRTAs therefore stayed on the original timeline throughout both extensions.

SEBI's August 2025 technical clarifications also softened two specific requirements after the deadline had passed. ISO 27001 certification, originally mandatory for MIIs and Qualified REs, is now only encouraged and recommended, not mandatory, for Qualified REs; it remains mandatory for MIIs. The mobile application security guidelines under standard PR.AA.S16 were also reclassified as recommendatory rather than mandatory. Anyone building a CSCRF checklist from the original August 2024 text alone should check the later clarification circulars before treating either of these as a hard requirement.

Turning This Into a Working Compliance Programme

Treat CSCRF as a set of recurring obligations tied to an RE's category, not a document to file away after one audit. A working checklist assigns an owner, an evidence artefact and a cadence to each item covered above: VAPT plan and periodicity, VAPT report/closure/revalidation timelines, SBOM currency for every critical system, application security testing evidence for each release, a log retention policy mapped to the IT Act 2000 and the DPDP Act 2023, the SOC model and its efficacy reporting, and the ISO 27001 and mobile-app-security clarifications where they apply.

If you are scoping this work, from a VAPT ahead of your next compliance window to SBOM automation or SAST coverage for a secure SDLC, evaluate any tool against the specific CSCRF clause it needs to satisfy, and confirm the evidence it produces is in a format your IT Committee for REs and auditor can sign off. SecOpsTool can scope a VAPT engagement against your CSCRF category and deadline on a free call, with no obligation afterwards.

Questions Buyers Ask

Sources

Primary documents this article is based on. Regulatory clauses and product statements above are taken from these pages.

• SEBI CSCRF circular (Aug 2024)
• SEBI CSCRF extension circular (Mar 2025)
• SEBI CSCRF clarifications circular (Apr 2025)
• SEBI CSCRF extension circular (Jun 2025)
• SEBI CSCRF technical clarifications circular (Aug 2025)
• SecOpsTool VAPT Services
• Tenable Nessus
• Cymulate Exposure Validation
• Checkmarx One
• O3 Security - SEBI CSCRF compliance
• Mend.io SBOM