Standardization Testing and Quality Certification Requirements for Software Vendors · 20260903-15

NOTICE

---

To All Vendors,

SEBI has issued a circular with subject “Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (REs)” vide reference no. SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated August 20, 2024, with objective to strengthen the cybersecurity measures in Indian securities market, and to ensure adequate cyber resiliency against evolving cyber threats, cybersecurity incidents/ attacks.

Further, as per CSCRF circular, “all software services in the form of SaaS/ Hosted services, COTS, customized COTS, in-house developed software, etc. shall be certified for application security and functional audit. COTS products empanelled by stock exchanges/ depositories shall be certified for application security testing, and functional audit by STQC at the time of empanelment.”

Commercial Off The Shelf (COTS) being provided by empanelled vendors are covered in the aforesaid framework for Cybersecurity and Cyber Resilience Framework (CSCRF). As per standards PR.IP.S15, mentioned in the CSCRF framework, Empanelled vendors and prospective vendors are required to perform “Application security testing” and “Functional audit” through Standardisation Testing and Quality Certification (STQC) auditor.

Section A: Scope for STQC Certification:

1. Application security testing:

• i. Dynamic Application Security Testing (DAST) for scanning software applications in real-time against leading vulnerability sources, such as OWASP Top 10, SANS Top 25 CWE, etc. to find security flaws or open vulnerabilities.
• ii. Static Application Security Testing (SAST) for analyzing program source code to identify security vulnerabilities such as SQL injection, buffer overflows, XML external entity (XXE) attacks, OWASP Top 10 security risks, etc.

2. Functional audit: brief overview of the areas covered under the STQC Functional Audit:

• i. Login and Authentication
• ii. User Management
• iii. Input Validation
• iv. Navigation
• v. CRUD Operations (Create, Read, Update, and Delete)
• vi. Forms and Business Logic Validation

Notes:

• The above represents a high-level overview of the Application security testing and Functional Audit scope. To define the exact number of test cases and prepare a comprehensive functional test plan, STQC auditor would require the complete Software Requirements Specification (SRS) document, as the scope and coverage are determined based on the application's documented functional requirements.
• Refer – Annexure A “STQC – Terms of Reference”.

Section B: Process for registration of Software of Empanelled vendors:

1. Prospective Vendor:

• i. At the time of empanelment (COTS) vendors are required to provide STQC certification for the software/ products (ETI, IBT, STWT, API & Back Office) solution to be registered with the Exchange as per SEBI circular no. SEBI/HO/ ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated August 20, 2024, on Cybersecurity and Cyber Resilience Framework (CSCRF).
• ii. Provisional empanelment to be granted based on STQC labs’ acknowledgement for completion of testing.
• iii. Post submission of test report by STQC Lab, where the vulnerabilities/ observations are identified by the STQC Centre and closure is pending, the vendor shall submit a “Compensatory Control Letter” duly signed by the CTO, detailing interim controls, risk assessment, mitigation measures and target closure dates. Final empanelment to be granted after receipt of certificate from STQC regional centre.
• iv. In the case of a newly empanelled vendor and product registration during the year, where the STQC certificate has already been submitted to the Exchange, the vendor shall not be required to resubmit the STQC certification at the time of annual STQC certificate submission to Exchange for that initial year.
• v. From the subsequent year onwards, the vendor shall comply with the STQC certification requirements and guidelines applicable to all empanelled vendors.

2. Existing Empanelled Vendor:

• i. STQC certification is required for all the latest versions of ETI, IBT, STWT, API & Back Office Softwares/Applications products which are already registered with the Exchange at the time of issuance of circular. The STQC certificate is required to be submitted by February 28, 2027.
• ii. Subsequently on an annual basis, STQC certification is required to be submitted for period ending 31st March by 30th June every year. The annual submission process would become effective with effect from March 31, 2028.
• iii. For registering new software/products solution/version with the Exchange, STQC certification is mandatory.
• iv. New product may be registered on provisional basis after submission of STQC laboratory acknowledgment along with the other applicable documents.
• v. In case of software changes, only the delta version introduced through the change may be subjected to testing by the STQC Laboratory. However, all impacted modules, interfaces, integrations and dependencies shall also be tested to ensure there is no adverse impact on application security, functionality or performance.
• vi. Based on the provisional registration of the vendor product, Trading member can apply for product registration.
• vii. Post submission of test report by STQC Lab, where the vulnerabilities/ observations are identified by the STQC Centre and closure is pending, the vendor shall submit a “Compensatory Control Letter” duly signed by the CTO, detailing interim controls, risk assessment, mitigation measures and target closure dates.
• viii. Vendors shall submit a declaration covering all currently deployed and supported versions, confirming that such versions are covered under STQC certification. The declaration shall include product name, version number, etc (ETI, IBT, STWT, API & Back Office Softwares/Applications).
• ix. Final product registration to be granted after receipt of certificate from STQC regional centre.

Further, vendors may have developed the software which are applicable for one or more Exchanges. In such cases vendor may get the STQC done for the software used in any of the Exchanges and subsequently share with all the concerned Exchanges.

Section C: Vendors seeking registration for Non-Exchange Frontend software/systems shall continue to provide the following documents to the Exchange at the time of registration:

• i. Application for registration of the software with details of the product / segment / versions / applicable exchanges etc.
• ii. Product write-up including write-up on Risk Management Systems.
• iii. Vendor shall continue to submit a CISA / CISSP / CISM / DISA certified Auditor’s certificate as per existing formats.
• iv. Vendors shall also be required to provide information on the minimum software / hardware requirements for their respective versions at the time of registration. The same can be part of the product / version write-up or can be provided as a separate document to the Exchange.
• v. When registering the software, vendors shall be required to:
  • a. Declare the baseline requirements and security patch levels pertaining to OS, databases, enterprise mobile devices, etc. within the IT environment of member brokers. This baseline is for deployment of registered products and providing maintenance support.
  • b. Ensure compatibility of the software with the specified OS, databases, enterprise mobile devices, etc.
  • c. Provide a declaration that software vendors will cease maintenance support to member brokers for software that does not meet baseline requirements and alert exchange(s) immediately.
• vi. Vendors developing STWT solutions shall be further required to adhere to standards PR.AA.S16 and PR.AA.S17 specified in the framework w.r.t. Mobile Application Security and API’s.
• vii. It may be noted that SEBI under the framework has specified Major change / Major Release and CSCRF has mandated VAPT after every major release. The following changes (including but not limited to) are broadly considered as major release(s) or major change(s):
  • a. Implementation of a new SEBI circular.
  • b. Changes in core versions of software (e.g., .net, SQL, Oracle, Java, etc.)
  • c. Any changes in policy of login and/ or password management.
  • d. Significant system modifications that alter how data is exchanged with stock exchanges (e.g., file format changes, message protocol changes, etc.).
  • e. Introduction of new security protocols (e.g., switching from SSL to TLS 1.3).
  • f. Expansion into new financial markets (e.g., adding currency trading).
  • g. Implementation of new processes/ schema changes.
  • h. Any change in the core RMS/OMS of the trading application.