It is clear to see that India’s BFSI sector is undergoing digital evolution. Financial institutions are now utilizing Gen AI, cloud and other digital platforms for achieving operational efficiency at scale.
But as the sector sustains its tech-driven growth, a decisive reset in how it approaches software risk is important. “Why software?” you may ask. Because software is the foundation on which the hyper-connected BFSI ecosystem is providing real-time data and exceptional experiences to customers. This is why software supply chain security is a priority now.
Against this backdrop, the RBI and SEBI SBOM mandate for BFSI marks a shift from intent based security to evidence-based governance. Software Bill of Materials is no longer a document you generate once. It is becoming a living control tied directly to resilience, audits, and board oversight.
This guide explains what the mandates really mean, how they differ, and how BFSI organisations can meet them without slowing innovation.
Why SBOM has become non-negotiable for BFSI
Before diving into individual mandates, it helps to understand why regulators are focused on SBOM now.
2024 was the year SBOM gained prominence in India. SEBI mandated SBOM requirements through the Cybersecurity and Cyber Resilience Framework (CSCRF). CERT-In released initial Technical Guidelines on SBOM and RBI formally mandated SBOM adoption via CSITE Advisory – all of them in the same year.
So, what happened in 2024?
To understand it, we need to go back a little to the year 2020, December month to be precise. SolarWinds, a major software company based in the US was breached and malicious code was inserted into its Orion software. The result? Approximately 18,000 organisations were impacted.
This shook the entire world, and the importance of cybersecurity came into spotlight. The regulatory bodies understood that SBOM needs to become the staple of software, security and compliance teams.
SBOM: Non-negotiable for Banks
BFSI systems sit at the centre of national economic stability. A single vulnerable library can cascade across payment systems, trading platforms, or customer channels. Yet most institutions cannot confidently answer basic questions such as which applications use a vulnerable component or whether an exposed flaw is exploitable in their environment.
SBOM closes this gap. It creates an authoritative inventory of software ingredients, including direct and transitive dependencies. More importantly, it enables faster and more accurate risk decisions during incidents.
Our experience shows that organisations that treat SBOM as a governance control, not a compliance artefact, respond to vulnerabilities days faster than their peers.
The RBI SBOM mandate explained
The RBI has taken a firm but structured approach to SBOM adoption. While there is no single standalone circular dedicated only to SBOM, the expectations are unambiguous. RBI SBOM requirements instruct all regulated entities to adopt the SBOM technical guidelines released by CERT In. This directive applies to banks, NBFCs, and other supervised entities.
1. Scope and timelines under RBI
The mandate applies to all critical applications. In practice, this means any application whose compromise could impact confidentiality, integrity, availability, or systemic stability. RBI has made it clear that SBOM coverage is not limited to in house code. It includes third party software, COTS products, and outsourced development.
2. Accountability and governance
One of the strongest elements of the RBI SBOM mandate for BFSI is accountability.
Banks must obtain formal assurance on the accuracy, completeness, and timeliness of SBOMs from internal teams as well as vendors. This shifts responsibility from procurement paperwork to operational validation.
Regulated entities must submit quarterly updates to the board and the RBI outlining SBOM status, vulnerability exposure, and remediation progress. From 2024 onwards, these controls are subject to audit verification.
Non-compliance is not theoretical. RBI has signalled penalties that can go up to one crore rupees, along with business restrictions and public disclosure.
CERT-In baseline requirements
For RBI supervised entities, the 21 data fields defined by CERT-In form the minimum baseline. These include component identifiers, dependency relationships, versioning, integrity hashes, and known vulnerabilities. Institutions cannot selectively adopt these fields. Partial SBOMs will not meet expectations.
The SEBI SBOM mandate and CSCRF
In parallel, SEBI has embedded SBOM into its broader cyber resilience expectations for capital market participants. Under the Cybersecurity and Cyber Resilience Framework, SEBI made SBOM inventories mandatory for all core and critical business applications. This applies whether software is developed internally, procured as COTS, or consumed as SaaS.
1. Compliance timelines under SEBI
After industry feedback, SEBI extended the deadline for most regulated entities to 31 August 2025. This gives organisations more time but also removes any ambiguity about enforcement. Boards are expected to track progress and approve exceptions explicitly.
2. SEBI’s minimum data expectations
Unlike RBI, SEBI does not mandate a specific SBOM format. However, it defines nine minimum data fields focused on governance and integrity.
These include licence information, supplier details, transitive dependency mapping, encryption status, integrity hashes such as SHA 256 or 512, update frequency, declarations of known unknowns, access controls, and error handling processes. This approach reflects SEBI’s focus on operational risk and investor protection rather than purely technical depth.
3. Handling legacy systems
SEBI recognises the reality of legacy platforms. If SBOMs cannot be obtained for proprietary or ageing systems, the board must formally approve the exception. This approval must be backed by documented risk mitigation measures. Silence or informal acceptance will not suffice.
CERT-In guidelines as the common foundation
Both regulators rely heavily on the technical blueprint issued by CERT-In. The CERT In SBOM guidelines aim to standardise how SBOMs are generated, shared, and consumed across critical sectors.
1. Phased maturity model
CERT In recommends a phased approach.
The START phase focuses on identifying critical assets, defining SBOM formats, and updating procurement contracts to mandate vendor SBOMs.
The PROGRESS phase integrates SBOM generation into CI CD pipelines, assigns unique identifiers, and maps supplier data to internal inventories.
The ADVANCE phase moves towards runtime monitoring, automated advisory ingestion, and embedding SBOM into incident response workflows.
This model is especially relevant for BFSI organisations with complex estates.
2. Accepted formats and classifications
To support automation, CERT In recognises SPDX and CycloneDX as acceptable formats. It also defines six SBOM types aligned to the software lifecycle, from design and source to deployed and runtime. This reinforces the idea that SBOMs are living artefacts, not static PDFs.
Operationalising compliance in BFSI environments
Meeting the RBI and SEBI SBOM mandate for BFSI requires more than policy updates.
1. Vendor and third-party management
Contracts must clearly require complete SBOMs covering all dependencies to the last level. Verification replaces trust. Secure sharing mechanisms help address vendor concerns around intellectual property.
2. Vulnerability context with VEX and CSAF
Regulators encourage pairing SBOM with VEX and CSAF. These artefacts clarify whether a vulnerability is actually exploitable in a given environment. This prevents security teams from chasing noise and helps leadership prioritise real risk.
3. Automation over manual effort
Manual inventories do not scale. Software Composition Analysis tools that scan source, binaries, and build pipelines are essential. Without automation, SBOMs become outdated the moment code changes.
4. Internal governance model
Effective SBOM programmes cut across security, engineering, procurement, legal, and risk teams. Clear ownership, SLAs, and audit processes are critical for sustainability.
Common challenges across Indian BFSI
Despite regulatory clarity, execution remains difficult.
Legacy core banking platforms often lack metadata needed for SBOM generation. Technology fragmentation adds complexity, especially where monolithic and microservices architectures coexist.
Vendor reluctance to disclose detailed component data is still common. This must be addressed contractually and through secure disclosure models.
Another challenge is the implementation gap. In many organisations, a large share of scripts and notebooks never enter repositories. These blind spots undermine SBOM completeness.
Conclusion
For BFSI organisations, the RBI and SEBI SBOM mandate for BFSI is not just another regulatory checkbox. It is a structural change in how software risk is understood and governed.
Institutions that invest early in automation, governance, and cross functional ownership turn compliance into a strategic advantage. Faster incident response, clearer vendor accountability, and stronger regulator confidence follow naturally.
We work alongside security teams to make SBOM practical, scalable, and audit ready. If you are assessing your current posture or planning your roadmap, a focused consultation can save months of rework later. Our in-house tool NXRadar is an SBOM management tool powered by AI and aligned to RBI, SEBI and CERT-In guidelines and mapped to fields. Request a demo to know more.
RBI and SEBI SBOM mandate for BFSI FAQs
How often should SBOMs be updated in BFSI environments?
SBOMs should be updated with every release, patch, or configuration change affecting software components. Static annual updates are not sufficient.
Are SaaS providers fully covered under the mandates?
Yes. Both RBI and SEBI expect SBOM visibility for SaaS used in critical or core business processes, subject to contractual feasibility.
Can SBOM data be shared securely with regulators?
Yes. Regulators encourage secure portals and controlled access rather than ad hoc document sharing.
Does SBOM replace vulnerability scanning?
No. SBOM complements vulnerability scanning by providing context and dependency mapping. Both are needed for effective risk management.
