You are a six-person startup in Bengaluru or Mumbai. You sell an API, an analytics dashboard, or a KYC workflow to a stock broker, an AMC, an RTA, or a portfolio manager. You are not regulated by SEBI. Nobody at SEBI has your company name on file. And yet a 40-page security questionnaire just landed in your inbox with "CSCRF alignment" in the subject line, and your deal is frozen until you answer it.
This post is for that startup. Not for the Regulated Entity, which has consultants and a compliance head and a board that signs things, but for the vendor, who has none of those and has just discovered that a framework they are not subject to is standing between them and revenue.
What generic CSCRF articles get wrong is the audience. Almost every guide online is written for the Regulated Entity: your categories, your audit cadence, your Cyber Capability Index. Useful if you are a depository. Useless if you are the SaaS company the depository is buying from. The obligations that reach you are a much smaller subset, and they arrive through a contract rather than a circular. Knowing which subset saves you from building compliance theatre for controls that were never yours.
Quick context: what CSCRF is, and why it reaches you
The Cybersecurity and Cyber Resilience Framework was issued by SEBI on 20 August 2024 under circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113. It replaced SEBI's older broad cyber security guidelines for individual market participants with one graded framework covering the full spread of Regulated Entities, from Market Infrastructure Institutions down to single-office intermediaries.
Two follow-ups matter for anyone reading the framework in 2026: clarifications issued on 31 December 2024 (circular 2024/184) and technical clarifications on 28 August 2025 (circular 2025/119). The implementation timeline was extended more than once, landing at 31 August 2025 for most Regulated Entities, with Market Infrastructure Institutions, KYC Registration Agencies and Qualified RTAs on their own earlier dates. The build phase is behind us. Your customers are now in the recurring cycle of cyber audits, capability reporting and evidence collection, and evidence collection is where you appear.
The framework organises itself around five cyber resilience goals, usually rendered as Anticipate, Withstand, Contain, Recover and Evolve. You do not need to memorise that structure. You need three facts: CSCRF binds only Regulated Entities, a Regulated Entity stays accountable to SEBI for functions it has outsourced, and the only mechanism it has for pushing that accountability onto you is your contract.
1. Find out which category your customer sits in
CSCRF is deliberately graded. Regulated Entities are sorted into categories, commonly described as Market Infrastructure Institutions, Qualified REs, Mid-size REs, Small-size REs and Self-certification REs, with the depth of obligation, the audit method and the reporting burden scaling up the ladder. A national stock exchange and a small portfolio manager do not carry the same load.
This matters more than any single control, because your obligations mirror your customer's. A vendor to a Market Infrastructure Institution gets asked for continuous log feeds, formal audit rights and an ISO 27001 certificate. A vendor to a Self-certification RE may get a questionnaire and nothing more. Same product, same company, two wildly different amounts of work.
Practitioner opinion: ask the category question in the first sales call. "Which CSCRF category are you classified under, and is the system we are supplying in scope for your core and critical systems?" Two minutes, and it tells you whether this deal costs a week of evidence work or a quarter of engineering. Teams that skip it find out after signing, which is the expensive order.
Takeaway: scope your compliance effort from your customer's category and their classification of your system, not from the framework read cover to cover.
2. The SBOM your customer wants is not your lockfile
CSCRF carries an explicit Software Bill of Materials mandate, and it is the single requirement most likely to arrive at your door. Regulated Entities are expected to obtain an SBOM for new software at procurement and to maintain one for existing core and critical systems. If you are the supplier, you are the only party who can produce it.
The field expectations go well beyond a dependency list. Published summaries of the framework consistently describe supplier name, component name and version, license information, dependency relationships including transitive dependencies, cryptographic hashes, encryption details, update frequency, and the handling of known unknowns. Set that against the NTIA minimum elements for an SBOM and CSCRF is asking for a superset.
The practical build is smaller than it sounds. Generate machine-readable SBOMs in CycloneDX or SPDX as a CI step, attach them as build artifacts, and version them with the release they describe. The failure mode is not generating one, it is hand-building one in a spreadsheet the week a customer asks and never updating it. Your customer's obligation is continuous, so the artifact they need is continuous too: a fresh SBOM per release, retrievable on demand.
Takeaway: wire SBOM generation into your pipeline now, in a standard format, and treat the SBOM as a release artifact rather than a document. If you have already hardened your build pipeline, this is a small addition to work you have done, and it pairs naturally with the supply-chain controls around CI/CD.
3. VAPT, and the word "empanelled"
CSCRF requires Regulated Entities to carry out Vulnerability Assessment and Penetration Testing, and it is specific about who does it: auditors empanelled by CERT-In, the Indian Computer Emergency Response Team. CERT-In maintains a published list of empanelled information-security auditing organisations, and that list is the gate.
This catches startups out in a specific way. You may already hold a penetration test report from a perfectly competent firm, engaged for a SOC 2 audit or an enterprise deal in another market. If that firm is not on the CERT-In empanelment list, the report may not carry the weight your customer needs when their auditor asks where the testing evidence came from. The technical quality of the test is not the issue. The provenance is.
Where your system sits inside your customer's scope, expect the testing expectation to follow the release cycle rather than the calendar, and remediation timelines to be tied to severity. Budget for it: an empanelled VAPT engagement is often the largest single cost in the whole CSCRF conversation for a seed-stage company.
Takeaway: before you commission a penetration test that a SEBI-regulated customer will rely on, check the vendor against CERT-In's empanelment list. Retrofitting provenance is not possible.
4. Your logs have to go somewhere, and it may not be your dashboard
One of the more distinctive parts of CSCRF is the Security Operations Center architecture. Larger Regulated Entities are expected to run or contract a SOC; smaller ones can onboard to a Market SOC operated at the market infrastructure level, which exists precisely so that a ten-person intermediary is not forced to staff a 24x7 monitoring function.
The consequence is concrete: if your system is in scope, your telemetry is part of your customer's detection surface. They will ask you to export authentication events, administrative actions, configuration changes and API access records in a format their SOC can ingest, at a latency they can defend to an auditor. "You can log into our admin panel and look" does not survive that conversation.
Build this as a feature, not a support ticket: a documented audit-log schema, stable event names, an export or streaming path, and retention you can state in writing. The engineering is not exotic. The discipline is deciding what counts as a security-relevant event before a customer defines it for you, the same discipline behind reading audit logs for compromise patterns in your own infrastructure.
Takeaway: ship a documented, exportable security audit log with stated retention. It converts a recurring bespoke request into a standard answer.
5. RTO two hours, RPO fifteen minutes, and what that does to your SLA
The August 2025 technical clarifications set recovery expectations explicitly: a Recovery Time Objective of two hours for resumption of critical operations, aligned with IOSCO guidance, and a Recovery Point Objective of fifteen minutes. Those are the numbers your customer is now measured against.
If your service sits inside a critical operation, those numbers propagate into your contract. Not as an aspiration in a marketing page, but as a term with consequences. Two hours to restore service, fifteen minutes of maximum acceptable data loss. For a startup running a single-region deployment with nightly backups, that gap is not a paperwork problem. It is an architecture problem, and it will cost real money to close.
Three honest options: close the gap, scope your way out of it, or decline. Closing it means point-in-time recovery with a fifteen-minute or better window, a restore path you have actually executed under timing, and a documented runbook. Scoping out means demonstrating in writing that your system does not sit in a critical operation. Practitioner opinion: the second route is legitimate and underused. Plenty of vendor tools genuinely are not on the critical path, and saying so early is cheaper than signing a two-hour RTO you cannot meet.
Takeaway: test a restore against a stopwatch before you agree to any recovery term. An untested restore is a number you are guessing at.
6. The incident clock starts before you know what happened
India's baseline incident-reporting obligation comes from the CERT-In directions issued on 28 April 2022 under section 70B(6) of the Information Technology Act, which require specified cyber incidents to be reported within six hours of noticing them. CSCRF sits on top of that, and Regulated Entities carry reporting duties to SEBI as well.
Six hours is the customer's clock, not yours. If your breach is the source, their six hours cannot start until you tell them, so your contractual notification window will be tighter. Expect a demand measured in hours, and expect the clause to be non-negotiable, because your customer cannot negotiate their own deadline.
What makes this survivable is deciding the mechanics in advance: who can declare an incident at 03:00, which named contact at the customer gets called, and what the first notification says when you still know almost nothing. Teams that fail this rarely fail on detection. They fail because nobody knew they were allowed to send the first message before the investigation was finished.
Takeaway: write the notification runbook, name the humans on both sides, and rehearse the first thirty minutes. The first message is a heads-up, not a root-cause analysis.
7. Audit rights are a real operational cost
Because the Regulated Entity stays accountable for outsourced functions, its contracts must preserve the ability to inspect. Expect clauses granting your customer, their auditors, and in some formulations the regulator, the right to examine records and systems relevant to your service.
Founders sign these fast because they read as boilerplate. They are not free. Each audit right is a future interruption: evidence packs, screen-share walkthroughs, access reviews, questions from someone who has never seen your architecture. With one customer that is an annoyance. With eight, spread randomly through the year, it becomes a part-time job landing on the founding engineer.
Practitioner opinion: negotiate the shape of the right, not its existence. Reasonable notice, business hours, a cap on routine audits per year with an exception for post-incident review, and a standing evidence pack that answers the common questions without a live session. Offering the pack proactively reads as maturity and protects your calendar. The same accountability logic drives the same clause set in RBI's IT outsourcing direction.
Takeaway: assume every audit right will be exercised, and build one evidence pack that serves all of them.
8. Where your data physically sits
Data residency runs through Indian financial-sector regulation consistently, and CSCRF conversations reliably surface the question of whether regulated data leaves the country. Your customer will ask where their data is stored, where it is processed, where backups live, and whether any sub-processor moves it offshore.
The trap is not primary storage. Most startups can answer for their main database. The trap is everything around it: log aggregation in a US region, error tracking that captures request payloads, an analytics pipeline, backups replicated to a cheaper region, and the AI API added last quarter that now sees customer content. Each is a data-flow question you will be asked to answer precisely.
Build the answer once, as a data-flow inventory: every system that touches customer data, its region, its provider and the contractual basis. Keep it current. It is the same artifact DPDP Act readiness demands, so the work serves two regimes at once.
Takeaway: inventory every sub-processor and its region before a customer asks. Discovering an offshore log pipeline during due diligence is how deals stall.
9. ISO 27001, and when it stops being optional for you
Under the framework as clarified, ISO 27001 certification is mandatory for Market Infrastructure Institutions, and encouraged and recommended rather than mandatory for Qualified REs, with lower categories treating it as voluntary. That is the position for the Regulated Entity itself.
The flow-down is what affects you. Where a Regulated Entity outsources a function inside its certified scope, the expectation of equivalent assurance travels to whoever provides that function. If you run a component inside a Market Infrastructure Institution's ISO 27001 boundary, you will be asked either to be certified or to show equivalent controls in a form their auditor accepts.
Practitioner opinion: do not start an ISO 27001 programme speculatively at pre-seed. Start it when a specific deal requires it and funds it, and meanwhile keep the underlying controls real so certification is a documentation exercise rather than a rebuild. The trade-offs mirror those in choosing SOC 2 Type 1 against Type 2.
Takeaway: let the deal pull the certificate. Keep the controls real in the meantime so the certificate is achievable in months, not years.
10. The questionnaire is not the control
The most common failure here is not a missing control. It is a startup that answers the questionnaire well and builds nothing behind it. The questions are answerable in an afternoon by someone with a good vocabulary. The evidence is not.
It breaks at the second interaction. The first questionnaire passes. Then an incident happens, or the customer's auditor asks for the artifact behind answer 34, and the gap between claim and reality becomes visible to an institution that is accountable for having verified you. Practitioner opinion: that is far worse than saying "not yet, here is our timeline" up front. Regulated customers deal with imperfect vendors constantly. They have little tolerance for being told something untrue.
Takeaway: answer honestly with dates attached. A dated roadmap beats an unsupported yes with any customer whose own accountability depends on your answer.
Summary: the vendor's short list
| Obligation | Reaches you via | What you actually build |
|---|
| SBOM | Procurement, then every release | CycloneDX or SPDX generated in CI, versioned per release |
| VAPT | Contract plus audit evidence | Testing by a CERT-In empanelled auditor, severity-tiered fixes |
| SOC telemetry | Integration requirement | Documented audit-log schema with an export or streaming path |
| RTO 2h / RPO 15m | SLA terms | Point-in-time recovery, a timed restore drill, a written runbook |
| Incident notification | Contract clause, hours not days | Named contacts, declaration authority, rehearsed first message |
| Audit rights | Contract clause | One standing evidence pack, negotiated notice and frequency |
| Data residency | Due-diligence questionnaire | Sub-processor and data-flow inventory, kept current |
| ISO 27001 | Flow-down from certified scope | Real controls now, certification when a deal funds it |
What to do at your stage
Pre-seed, first regulated pilot. Do the cheap, high-leverage three: SBOM generation in CI, a documented exportable audit log, and a sub-processor inventory. Answer questionnaires honestly, with dates. Do not buy a certification, hire a compliance consultant, or sign a two-hour RTO. If your system genuinely sits outside critical operations, say so in writing.
Seed, two or three regulated customers. The evidence pack is the unlock: one maintained set covering architecture, data flows, access control, logging, backup and recovery, incident process, and your current SBOM. Commission your first CERT-In empanelled VAPT and run a timed restore drill. This is where the work stops fitting between features.
Series A, regulated customers as a segment. Certification now pays for itself, because you answer the same questions repeatedly and each cycle costs deal velocity. Formalise the audit-response process, treat recovery objectives as tested SLOs rather than contract language, and put a name against it. Practitioner opinion: the trigger is not headcount or revenue, it is the fourth customer sending the same evidence request.
If you want a second opinion on your setup
MatrixGard runs a free 20-minute review for founders and CTOs selling into SEBI-regulated customers. Which parts of CSCRF actually reach you through your contracts, which are your customer's problem and not yours, and the cheapest honest path to a signed deal from where you are. My straight read, no NDA needed for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure on AWS, GCP, and Azure.
Methodology note. Framework structure, circular numbers and dates are taken from SEBI's own circulars: the CSCRF circular of 20 August 2024, the clarifications of 31 December 2024, and the technical clarifications of 28 August 2025. The six-hour incident-reporting baseline is from the CERT-In directions of 28 April 2022 under section 70B(6) of the IT Act. Category names, SBOM field expectations, SOC and Market SOC arrangements and the recovery objectives are described as they appear in the published circulars and in consistent independent analysis of them; where a specific number or cadence matters to a decision, read it in the current circular text on the SEBI website rather than in any summary, including this one. How a vendor should sequence the work, what to negotiate and what to decline is practitioner opinion, labelled inline. This post is engineering guidance for vendors, not legal advice or a compliance assessment of your environment.
