Introduction to the SEBI System Audit
The Securities and Exchange Board of India (SEBI) mandates a periodic, independent System Audit of its regulated entities to obtain assurance that the technology infrastructure supporting India's securities markets is secure, resilient, and compliant with the SEBI Cyber Security and Cyber Resilience Framework (CSCRF). The System Audit is not a single monolithic exercise; it is a family of audit obligations that apply to Stock Brokers, Depository Participants, Market Infrastructure Institutions (Stock Exchanges, Clearing Corporations and Depositories), Registrars and Transfer Agents (RTAs / QRTAs), Mutual Funds / Asset Management Companies, KYC Registration Agencies (KRAs), Portfolio Managers and other intermediaries that operate market-facing IT systems.
The audit combines an information-security and cyber-resilience review with a functional / operational review of trading, risk, surveillance, settlement and investor-servicing systems. For an auditor it is an evidence-driven engagement that must be conducted by a CERT-In empanelled auditor (for the cyber-security portions) and, for certain entities, by auditors holding recognised certifications (CISA, CISM, DISA, ISO 27001 LA). For an implementing entity it is a build-and-remediate exercise: designating a Chief Information Security Officer (CISO), operating a Security Operations Centre (SOC), maintaining a Cyber Crisis Management Plan (CCMP), and reporting incidents to CERT-In and SEBI within prescribed timelines. This guide serves both audiences.
The regulatory context matters because the Indian securities market is a nationally critical financial system. A prolonged trading outage, a compromised settlement instruction, a leaked KYC database, or a rogue algorithm firing thousands of orders per second can each cause systemic harm — to price discovery, to investor confidence and to the crores of retail investors who transact through brokers and depositories. SEBI's System Audit therefore functions as a recurring assurance loop: it forces entities to demonstrate, with evidence and to an independent examiner, that the systems underpinning market access are engineered and operated to defined standards, and that the entity can detect, respond to and recover from disruption. The CSCRF explicitly frames this around cyber resilience — the ability to anticipate, withstand, contain, recover from and evolve against adverse cyber events — rather than security controls in isolation.
Because the ecosystem spans several regulators and utilities, an auditor must also be conversant with adjacent regimes. Relevant references include SEBI's CSCRF and its predecessor Cyber Security and Cyber Resilience Framework circulars (first issued for MIIs in 2015 and progressively extended to brokers, DPs, RTAs, AMCs, KRAs and Portfolio Managers), the CERT-In Directions of 28 April 2022 governing incident reporting timelines (typically within six hours of noticing) and log-retention, UIDAI's Aadhaar (Authentication) Regulations and data-security norms for entities using Aadhaar-based e-KYC, NPCI operating rules where UPI or other payment rails touch the broker's collections, RBI expectations that flow through banking partners and the account-aggregator framework, IFSCA norms where the entity operates in GIFT City / IFSC, PFRDA requirements where the entity services NPS, and the Digital Personal Data Protection Act, 2023 as it commences. The System Audit does not assess each regulator's obligations in full, but a competent auditor flags material intersections.
Copyright and source note
SEBI circulars, the CSCRF, the System Audit Framework, and exchange/depository operating instructions are the intellectual property of SEBI and the respective Market Infrastructure Institutions. This CyberSigma guide is an original, plain-language interpretation written for readiness and audit-preparation purposes. It paraphrases requirements and does not reproduce SEBI's copyrighted text. Always verify against the current SEBI master circulars, the CSCRF (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated 20 August 2024 and subsequent amendments), and your exchange/depository's operative circulars, as thresholds, formats and timelines are revised periodically.
What is the SEBI System Audit
The SEBI System Audit is a mandatory, independent examination of the IT systems, cyber-security posture and operational processes of a SEBI-regulated entity, carried out at a frequency prescribed for that entity class (annually, half-yearly or event-driven). It verifies that systems are designed, configured and operated in line with SEBI's regulatory framework and that risks to market integrity and investor protection are adequately managed.
Historically the requirement evolved from separate strands: (a) the System Audit of Stock Brokers offering Internet-Based Trading (IBT), Securities Trading through Wireless (STWT) and Algorithmic Trading; (b) the System Audit of Market Infrastructure Institutions (MIIs); and (c) the Cyber Security and Cyber Resilience Framework circulars issued from 2015 onwards. In August 2024 SEBI consolidated the cyber-security expectations into a single Cyber Security and Cyber Resilience Framework (CSCRF) applying a graded, size-based approach across all Regulated Entities (REs). The System Audit now typically encompasses the CSCRF controls plus the functional audit of the entity's core market systems.
The System Audit is distinct from, but complementary to, other assurance activities an entity may undertake — such as an ISO 27001 certification audit, a SOC 2 attestation for a cloud service, an internal audit, or a statutory financial audit. Where those provide broad or financial assurance, the SEBI System Audit is narrowly targeted at the market-facing IT estate and is benchmarked against SEBI's own prescriptive checklist. Findings from the System Audit feed directly into the entity's regulatory standing: unresolved high-severity observations, repeat findings, or a failure to submit the report within the stipulated timeline can attract regulatory action, monetary penalties or restrictions on onboarding new clients.
Key characteristics of the engagement:
- Independence: the auditor must be independent of the systems being audited; the same firm cannot both implement and audit the same controls in the same cycle.
- Empanelment: cyber-security testing (VAPT) must be performed by a CERT-In empanelled auditor; IS auditors should hold CISA / CISM / DISA / ISO 27001 LA credentials.
- Prescribed scope: SEBI / the exchange issues a Terms of Reference (ToR) and standardised checklist that the audit must cover in full.
- Reporting: findings are classified by severity, an action-taken report (ATR) is produced, and the report is submitted to the exchange/depository and placed before the entity's Board / IT Committee.
- Follow-up: closure of high and medium findings is tracked and re-verified; repeat observations attract regulatory attention.
Who must comply
The System Audit obligation and its frequency depend on the entity category and, under the CSCRF, on a size-based classification. SEBI's CSCRF groups Regulated Entities into five bands: Market Infrastructure Institutions (MIIs), Qualified REs, Mid-size REs, Small-size REs and Self-certification REs. Higher bands carry more prescriptive controls, mandatory SOC, and more frequent audit and reporting.
| Entity category | Typical audit obligation | Indicative frequency |
|---|
| Stock Exchanges / Clearing Corporations / Depositories (MIIs) | Full System Audit + Cyber Audit + BCP-DR drills under CSCRF (highest band) | Annual System Audit; half-yearly VAPT; periodic DR drills |
| Stock Brokers / Trading Members (IBT, STWT, Algo, Co-location) | System Audit covering trading systems, cyber controls, algo & API controls | Annual (half-yearly cyber audit for larger / Qualified REs) |
| Depository Participants (DPs) | System Audit per depository (NSDL/CDSL) circular + CSCRF cyber controls | Annual (or as per depository byelaws) |
| Registrars & Transfer Agents / QRTAs | System & Cyber Audit; QRTAs held to MII-like standards | Annual System Audit; half-yearly VAPT for QRTAs |
| Mutual Funds / AMCs | Systems Audit of RTA-facing and fund-accounting systems + CSCRF | Annual |
| KYC Registration Agencies (KRAs) | System Audit + cyber controls for KYC data protection | Annual |
| Portfolio Managers, Investment Advisers, Research Analysts (mid/small) | CSCRF graded controls; self-certification for smallest band | Annual audit or annual self-certification per band |
| Sponsors / Investors in market entities using APIs | Scoped to interfaces and data they operate | As applicable to the connected system |
Determining the correct band is the first scoping decision. The CSCRF thresholds are based on parameters such as number of clients/investors, trade volume, assets under custody/management and fund size, and the specific numeric cut-offs are set out (and periodically revised) in the CSCRF and exchange circulars. Entities near a threshold should classify conservatively.
The graded nature of the framework is deliberate: SEBI recognises that a large depository and a boutique research analyst cannot reasonably carry identical control obligations. The CSCRF therefore concentrates the most demanding requirements — mandatory 24x7 SOC (own or a Market-SOC subscription), red-teaming, near-site DR, half-yearly VAPT and stringent RTO/RPO — on MIIs and Qualified REs, while permitting Small-size REs and the Self-certification band to meet a proportionate subset and, for the smallest, to submit an annual self-certification rather than a full third-party audit. A practical consequence is that band mis-classification is one of the most common and most serious findings: understating size to reduce the control burden exposes the entity to regulatory action, while overstating it wastes scarce security budget. Auditors should independently recompute the band from source data (client masters, exchange volume statements, AUM/AUC reports) rather than accept management's assertion.
| CSCRF band | Typical control posture | SOC / VAPT expectation |
|---|
| Market Infrastructure Institutions | Most prescriptive full control set; near-site DR; red-teaming | Dedicated 24x7 SOC; half-yearly (or more frequent) VAPT |
| Qualified REs | Near-MII controls; mandatory SOC; strict RTO/RPO | SOC (own or Market-SOC); half-yearly VAPT |
| Mid-size REs | Comprehensive controls with some proportionality | SOC access; at least annual, often half-yearly VAPT |
| Small-size REs | Proportionate essential controls | Baseline monitoring; annual VAPT |
| Self-certification REs | Minimum essential controls; annual self-attestation | Annual VAPT where applicable; self-certification of compliance |
Timelines that catch entities out
Two timelines cause most avoidable non-compliance. First, cyber incidents must be reported to CERT-In within the window set by the CERT-In Directions (typically within six hours of noticing the incident) and separately notified to SEBI and the relevant exchange/depository — a delay is itself a reportable failure. Second, the completed System Audit report and Action-Taken Report must reach the exchange/depository within the stipulated period after the audit period ends (commonly within a few months, as specified in the operative circular). Build a compliance calendar that anchors both, and rehearse the CERT-In reporting path before you need it.
Structure of the SEBI System Audit
The audit is organised into control domains. The cyber-resilience portion of the CSCRF is structured around the widely used cyber-resilience goals — Anticipate, Withstand, Contain, Recover and Evolve — operationalised through the NIST-style functions: Governance, Identify, Protect, Detect, Respond and Recover. Overlaid on this are SEBI-specific functional domains for the trading, settlement and investor-servicing systems. The table below summarises the principal domains an auditor must cover.
| Domain / control family | Scope covered | Illustrative requirement identifiers |
|---|
| Governance & Cyber Resilience | CISO, IT Committee, policies, board oversight, CSCRF compliance | CSCRF GV / Governance standard |
| Identify | Asset inventory, data classification, risk assessment, third-party risk | CSCRF ID / IDENTIFY |
| Protect | Access control, network segmentation, hardening, encryption, endpoint | CSCRF PR / PROTECT |
| Detect | SOC, SIEM, log management, monitoring, threat intelligence | CSCRF DE / DETECT |
| Respond | Incident response, CERT-In reporting, CCMP, communication | CSCRF RS / RESPOND |
| Recover | BCP-DR, RTO/RPO, backups, restoration testing | CSCRF RC / RECOVER |
| VAPT & Security Testing | Vulnerability assessment, penetration testing, closure | CSCRF VAPT standard |
| Data Protection & Localisation | Data storage in India, retention, DLP, PII/UIDAI handling | CSCRF DP + SEBI data-storage circulars |
| Application / Trading System controls | OMS/RMS, order routing, price/quantity limits, kill-switch | SEBI IBT/STWT/Algo circulars |
| Algorithmic Trading & API controls | Algo approval, tagging, throttling, unique algo IDs, order-per-second limits | SEBI Algo Trading framework |
| Co-location / Tick-by-tick Data | Fair access, latency parity, audit of co-lo racks | SEBI co-location circulars |
| Business Continuity & DR | DR site, drills, near-site, wide-area disaster scenarios | SEBI BCP-DR circular for MIIs |
| Investor Protection & Grievance | SCORES integration, complaint SLAs, fund segregation reporting | SEBI investor-grievance circulars |
| Software Change & SDLC | Change management, UAT, version control, secure coding | CSCRF PR change-management controls |
| Cloud & Third-Party / Outsourcing | Cloud framework, MSP oversight, exit strategy | SEBI Cloud Framework + Outsourcing norms |
Master assessment checklist
This is the core working section. Each control family below carries a h3 heading and a table of what the auditor must verify against the typical evidence the entity should be able to produce. Implementers should treat the left column as a build backlog and the right column as the artefacts to maintain. No control area is omitted.
1. Governance and Cyber Resilience (GV)
| What to verify | Typical evidence |
|---|
| A Board-approved Cyber Security & Cyber Resilience Policy exists and is reviewed at least annually | Signed policy, board/IT-committee minutes approving and reviewing it |
| A designated CISO is appointed with defined responsibilities and reporting line to the board/MD | CISO appointment letter, JD, org chart, reporting evidence |
| A Technology / IT Committee (and Standing Committee on Technology for MIIs) meets at prescribed frequency | Committee ToR, meeting minutes, attendance |
| CSCRF band classification is documented and correct for the entity's size parameters | Band-classification workpaper with client/volume/AUM figures |
| Cyber-risk is reported to the board with metrics and open actions | Board cyber dashboards, risk register extracts |
| Roles, responsibilities and accountability (RACI) for cyber and IT are defined | RACI matrix, delegation of authority |
2. Identify — Asset, Risk and Third-Party Management (ID)
| What to verify | Typical evidence |
|---|
| A complete, current inventory of hardware, software, data and services (including Critical Systems) is maintained | Asset register with owners, criticality, CIA ratings |
| Data classification scheme is defined and applied (public/internal/confidential/regulated) | Data classification policy, sample tagged datasets |
| Formal risk assessment covering threats, vulnerabilities and business impact is performed periodically | Risk assessment report, risk register, treatment plan |
| Critical Systems are identified and subject to enhanced controls and SLA/RTO/RPO | Critical-systems list, dependency mapping |
| Third-party / vendor / outsourcing risk is assessed and contractually governed | Vendor risk assessments, contracts with security clauses, SLAs |
| Software Bill of Materials / dependency inventory for critical applications | SBOM, license/version register |
3. Protect — Access Control and Identity (PR-AC)
| What to verify | Typical evidence |
|---|
| Role-based access control with least privilege across systems | Access matrix, role definitions, sample entitlement review |
| Multi-factor authentication enforced for privileged, remote and internet-facing access | MFA policy, config screenshots, auth logs |
| Privileged Access Management (PAM) with session recording and just-in-time access | PAM tool config, privileged session logs, vault records |
| Periodic user access recertification and prompt deprovisioning of leavers | Access review sign-offs, HR-IT offboarding tickets |
| Password policy (length, complexity, rotation, lockout) enforced technically | GPO/IAM policy export, config evidence |
| Segregation of duties in maker-checker workflows for critical actions | Workflow config, SoD conflict analysis |
4. Protect — Network, Hardening and Encryption (PR-NW)
| What to verify | Typical evidence |
|---|
| Network segmentation isolating trading, DMZ, internal and management zones | Network diagram, firewall zone config, VLAN plan |
| Firewall, IPS/IDS and WAF deployed with reviewed rulebases | Rulebase export, review logs, tuning records |
| System hardening to CIS / vendor benchmarks with documented baselines | Hardening standards, benchmark scan reports |
| Data-in-transit and data-at-rest encryption using strong algorithms and key management | TLS config, encryption inventory, KMS/HSM records |
| Anti-malware / EDR deployed and current on all endpoints and servers | EDR console coverage report, signature/agent status |
| Secure configuration of DNS, email (SPF/DKIM/DMARC) and web services | DNS/email auth records, config evidence |
| Removable-media and DLP controls to prevent data exfiltration | DLP policy, blocked-transfer logs, USB control config |
5. Detect — SOC, Logging and Monitoring (DE)
| What to verify | Typical evidence |
|---|
| A Security Operations Centre (own or Market-SOC/managed) monitors 24x7 for qualifying entities | SOC operating model, staffing roster, SLA |
| SIEM aggregates logs from critical systems, security devices and applications | SIEM source list, log-source coverage report |
| Log retention meets SEBI/CERT-In minimums with integrity protection and time-sync (NTP) | Retention policy, WORM/immutable-log evidence, NTP config |
| Use cases / correlation rules exist for key threats (privilege abuse, exfiltration, brute force) | SIEM rule catalogue, alert samples |
| Threat intelligence is consumed and actioned; participation in sectoral sharing | TI feed subscriptions, IOC-action tickets |
| Continuous monitoring of unauthorised changes to Critical Systems (FIM) | FIM configuration, change-alert logs |
6. Respond — Incident Management and CERT-In Reporting (RS)
| What to verify | Typical evidence |
|---|
| Documented Incident Response Plan and Cyber Crisis Management Plan (CCMP) aligned to NCIIPC/CERT-In | IRP, CCMP, approval records |
| Cyber incidents reported to CERT-In within the mandated timeline and to SEBI/exchange | Incident register, CERT-In submission acknowledgements |
| Severity classification, escalation matrix and communication (including investor) procedures | Escalation matrix, comms templates, drill records |
| Root Cause Analysis and corrective/preventive actions tracked to closure | RCA reports, CAPA tracker |
| Incident-response tabletop exercises conducted periodically | TTX reports, lessons-learned logs |
| Forensic-readiness and evidence-preservation procedures | Forensic playbook, chain-of-custody templates |
7. Recover — Business Continuity and Disaster Recovery (RC)
| What to verify | Typical evidence |
|---|
| Board-approved BCP-DR policy with defined RTO and RPO for Critical Systems | BCP-DR policy, RTO/RPO matrix |
| DR site (and near-site for MIIs) at adequate geographic separation with independent seismic zone | DR architecture, site details, distance/zone evidence |
| DR drills including live/unannounced switchover conducted at prescribed frequency | Drill plans, switchover logs, drill result reports |
| Backups performed, encrypted, offsite/immutable, and restoration tested | Backup schedule, restore-test evidence, backup catalogue |
| Recovery meets RTO/RPO objectives in tested scenarios (including intra-day) | Drill timing evidence vs targets |
| Wide-area / regional disaster scenario addressed for MIIs | Scenario documentation, alternate-region plans |
8. VAPT and Security Testing
| What to verify | Typical evidence |
|---|
| VAPT conducted by a CERT-In empanelled auditor at prescribed frequency on all internet-facing and critical systems | Empanelment proof, VAPT scope and reports |
| Comprehensive scope including web, API, mobile app, network and configuration review | Scope document, asset list tested |
| Findings closed within SEBI-mandated timelines with revalidation of criticals | Closure tracker, revalidation reports |
| VAPT results and closure status reported to SEBI/exchange and IT committee | Submission acknowledgements, committee minutes |
| Secure code review for critical/in-house applications | SAST/DAST reports, code-review sign-offs |
| Red-team / scenario-based testing for MIIs and Qualified REs where required | Red-team report, remediation plan |
9. Data Protection, Localisation and Privacy
| What to verify | Typical evidence |
|---|
| Regulatory data stored within India as required by SEBI and RBI-adjacent norms | Data-residency attestation, hosting location evidence |
| PII and UIDAI/Aadhaar data handled per UIDAI regulations and masking requirements | Aadhaar-masking config, UIDAI compliance records |
| Data retention and secure disposal meet SEBI record-keeping requirements | Retention schedule, disposal logs |
| Data Loss Prevention across endpoints, email and cloud egress | DLP coverage report, incident logs |
| Alignment with the Digital Personal Data Protection Act (DPDP) obligations where applicable | DPDP gap assessment, consent/notice records |
| Encryption and tokenisation of sensitive fields (KYC, bank, PAN) | Field-level encryption/tokenisation evidence |
10. Application and Trading System Controls (OMS/RMS)
| What to verify | Typical evidence |
|---|
| Order Management System enforces validation, price bands and quantity limits | OMS config, limit parameters, test evidence |
| Risk Management System applies pre-trade risk checks and margin/exposure limits | RMS rules, pre-trade check logs |
| Kill-switch / order cancellation capability tested and available | Kill-switch procedure, drill evidence |
| Audit trail of orders, modifications and cancellations is complete and tamper-evident | Order log samples, integrity controls |
| Client-level and terminal-level access controls in the trading application | User-terminal mapping, access logs |
| System capacity and performance monitored against peak load thresholds | Capacity reports, load-test results |
11. Algorithmic Trading and API Controls
| What to verify | Typical evidence |
|---|
| Every algo strategy is approved/registered by the exchange with a unique algo ID and tagging | Exchange approval letters, algo-ID register |
| Order-per-second (OPS) throttling and message-to-trade ratio controls enforced | Throttle config, exchange rejection logs |
| Static and dynamic price bands / self-trade prevention are enforced | STPO config, price-band evidence |
| Third-party/vendor API access is authenticated, rate-limited and logged (including retail algo/API framework) | API gateway config, key management, access logs |
| Changes to algo logic follow change control with exchange re-approval where required | Change tickets, re-approval evidence |
| Segregation and audit of co-location / proximity hosting for fair access | Co-lo rack audit, latency parity evidence |
12. Software Change Management and SDLC
| What to verify | Typical evidence |
|---|
| Formal change-management process with approval, testing and rollback | Change policy, sample CAB-approved changes |
| Segregation of development, test/UAT and production environments | Environment inventory, access separation evidence |
| Version control and release management for critical applications | Repo/branching evidence, release notes |
| User Acceptance Testing sign-off before production deployment | UAT test cases, sign-off records |
| Emergency change process with post-implementation review | Emergency-change log, PIR records |
| Secure SDLC practices including security testing in the pipeline | CI/CD security-gate evidence, secure-coding standards |
13. Cloud, Outsourcing and Third-Party Governance
| What to verify | Typical evidence |
|---|
| Cloud adoption complies with the SEBI Framework for Adoption of Cloud Services | Cloud governance policy, MeitY-empanelled/CERT-In-audited CSP evidence |
| Shared-responsibility model documented and monitored | Responsibility matrix, CSP compliance reports (SOC 2 / ISO 27001) |
| Outsourcing of critical activities governed with right-to-audit and exit plans | Outsourcing agreements, exit/BCP clauses |
| MSP / vendor access is controlled, monitored and periodically reviewed | Vendor access logs, review records |
| Concentration risk and CSP/vendor lock-in assessed | Concentration-risk assessment, multi-region/portability plan |
| Sub-contractor (4th-party) risk visibility maintained | 4th-party disclosure, flow-down clauses |
14. Investor Protection, Grievance and Operational Reporting
| What to verify | Typical evidence |
|---|
| Integration with SEBI SCORES for complaint intake and SLA-based resolution | SCORES logs, resolution-TAT reports |
| Client funds and securities segregation and daily/weekly reporting to exchange | Segregation reports, upstreaming evidence |
| Investor communication for outages, incidents and corporate actions | Communication logs, disclosure records |
| Accuracy of regulatory filings and system-generated reports | Filing evidence, reconciliation records |
| Handling of investor PII and consent in servicing systems | Consent records, access controls on investor data |
| Business-hours and after-hours support / escalation for investor issues | Support SLA, escalation logs |
15. Depository Participant and Back-Office Controls
| What to verify | Typical evidence |
|---|
| Demat account opening, modification and closure follow depository (NSDL/CDSL) byelaws with maker-checker | DPM system logs, maker-checker config, sample account trail |
| e-DIS / delivery instruction slip processing is authenticated (OTP/2FA) and reconciled | e-DIS logs, OTP-authentication evidence, reconciliation reports |
| Reconciliation of holdings between DPM, back-office and depository at prescribed frequency | Daily reconciliation statements, break-resolution logs |
| Pledge, unpledge, margin-pledge and corporate-action processing controls | Pledge instruction logs, corporate-action processing records |
| Segregation and monitoring of client securities; no unauthorised transfers | Client-securities segregation reports, alert configuration |
| Access controls and audit trail on the DPM / back-office application | User-role matrix, DPM audit-trail samples |
16. KYC, e-KYC and Aadhaar / UIDAI Controls
| What to verify | Typical evidence |
|---|
| Aadhaar-based authentication uses UIDAI-licensed AUA/KUA channels with valid agreements | AUA/KUA licence, UIDAI agreements, sub-AUA records |
| Aadhaar numbers are masked/redacted and never stored in prohibited forms | Masking configuration, database field review, sample records |
| Biometric and demographic data are encrypted in transit and at rest per UIDAI standards | Encryption evidence, HSM/key-management records |
| KYC data shared with KRAs is accurate, consented and access-controlled | KRA upload logs, consent artefacts, access controls |
| e-sign and OTP-based KYC flows are logged and tamper-evident | e-sign audit trail, OTP logs |
| Video-KYC (where used) meets SEBI process, geo-tagging and recording norms | VCIP recordings, geo-tag evidence, process checklist |
17. Surveillance, Fraud Monitoring and Alert Generation
| What to verify | Typical evidence |
|---|
| Trade and transaction surveillance alerts for manipulation, wash trades and unusual activity are configured | Alert-rule catalogue, sample generated alerts |
| Suspicious Transaction Reports (STRs) under PMLA are generated and filed to FIU-IND | STR register, FIU-IND submission acknowledgements |
| Escalation and disposition workflow for alerts with audit trail | Alert-disposition logs, escalation matrix |
| Enhanced surveillance for client-code modifications and off-market transfers | Client-code modification logs, exception reports |
| Integration with exchange surveillance advisories and action on them | Advisory action-taken records |
| Periodic tuning and back-testing of surveillance parameters | Tuning logs, back-test reports |
18. Physical, Environmental and Data-Centre Controls
| What to verify | Typical evidence |
|---|
| Data centre / server room access is restricted, logged and periodically reviewed | Access logs, biometric records, access-review sign-offs |
| Environmental controls (power/UPS/DG, cooling, fire suppression) are in place and tested | Maintenance records, DG/UPS test logs, fire-drill records |
| CCTV coverage of critical areas with adequate retention | CCTV configuration, retention evidence |
| Co-location and third-party data-centre controls are covered by the provider's certifications | DC provider certifications (ISO 27001/PCI/Uptime), audit reports |
| Media handling, secure storage and disposal of decommissioned assets | Media-disposal certificates, asset-decommissioning logs |
| Cabling, rack security and separation of production/DR environments | Data-centre layout, rack-access records |
19. Human Resources and Security Awareness
| What to verify | Typical evidence |
|---|
| Background verification of employees and contractors handling critical/sensitive systems | BGV records, contractor vetting evidence |
| Role-based security-awareness training with completion tracking | Training records, completion dashboard, content |
| Phishing simulation exercises with remediation for repeat failers | Phishing-campaign reports, remediation logs |
| Acceptable-use, confidentiality and NDA agreements in force | Signed AUP/NDA records |
| Joiner-mover-leaver process synchronises HR events with access changes | JML tickets, timely-deprovisioning evidence |
| Specialised training for CISO, SOC and developers on SEBI/CERT-In requirements | Certification/training evidence for key roles |
Scoping the engagement
Accurate scoping prevents both under-coverage (regulatory non-compliance) and over-testing (wasted effort). The scope is derived from the entity's registrations, its CSCRF band, and the specific systems it operates. Scoping is also where the auditor establishes the boundary of the 'Critical Systems' — the subset of applications and infrastructure whose failure would materially disrupt trading, settlement, risk management or investor servicing. Critical Systems attract the strongest controls (enhanced monitoring, stricter RTO/RPO, more frequent testing), so mis-scoping this boundary either weakens protection or inflates cost. A defensible scope note records the entity's registrations, the computed band, the full asset universe, the Critical-Systems subset with justification, in-scope third parties and cloud services, and any exclusions with rationale.
- Confirm the entity's registration categories (broker, DP, RTA, AMC, KRA, MII, etc.) and each associated audit obligation.
- Establish the CSCRF band from size parameters (clients, volumes, AUM/AUC, funds) and lock the applicable control set.
- Enumerate in-scope systems: trading (OMS/RMS), settlement, KYC/back-office, investor-facing web/mobile, APIs, algo engines, co-location, DR site and supporting infrastructure.
- Include internet-facing assets, third-party/cloud-hosted components and integrations with exchanges/depositories/RTAs.
- Reference the exchange/depository Terms of Reference and standardised checklist that must be fully covered.
- Define the audit period, sampling approach for logs/tickets, and cut-off dates for evidence.
- Identify exclusions explicitly (e.g., non-market corporate IT) and record the rationale.
Scoping tip
Where an entity holds multiple registrations, do not assume a single audit satisfies all obligations. A broker that is also a Depository Participant typically faces both the exchange's broker System Audit and the depository's DP audit, with overlapping but non-identical checklists. Map obligations to a single control library to test once and report to many.
Implementation approach
For entities preparing to be audited, the following phased approach builds and evidences the required controls. Each phase lists key activities and the deliverables an auditor will later expect.
Phase 1 — Discovery and Classification (Weeks 1-3)
- Activities: determine CSCRF band; inventory assets, data and critical systems; map regulatory obligations to control library; identify data flows and third parties.
- Deliverables: band-classification workpaper, asset and critical-systems register, data-flow diagrams, obligations-to-controls matrix.
Phase 2 — Gap Assessment (Weeks 3-6)
- Activities: assess current state against CSCRF and functional requirements; run configuration and access reviews; perform baseline VAPT to find technical gaps.
- Deliverables: gap-assessment report with prioritised findings, risk register, baseline VAPT report.
Phase 3 — Governance and Policy Build (Weeks 5-9)
- Activities: appoint/confirm CISO; stand up IT/Technology Committee; author and board-approve cyber, BCP-DR, incident, access and data-protection policies; define RTO/RPO.
- Deliverables: approved policy suite, committee ToR and minutes, RACI matrix, RTO/RPO matrix.
Phase 4 — Technical Remediation (Weeks 8-16)
- Activities: implement MFA/PAM, segmentation, hardening, EDR, DLP, encryption; deploy/onboard SIEM and SOC; configure OMS/RMS limits, kill-switch and algo controls; remediate VAPT findings.
- Deliverables: hardened baselines, SIEM/SOC onboarding evidence, trading-control configurations, VAPT closure tracker.
Phase 5 — Resilience and Testing (Weeks 14-20)
- Activities: implement/validate DR site and backups; conduct DR drill and live switchover; run incident-response tabletop; complete comprehensive VAPT and revalidation.
- Deliverables: DR drill report, backup restore-test evidence, TTX report, final VAPT and revalidation reports.
Phase 6 — Audit, Reporting and Continuous Compliance (Weeks 18-24+)
- Activities: engage independent CERT-In empanelled / certified auditor; support fieldwork; produce Action-Taken Report; submit to exchange/depository and board; establish ongoing monitoring and periodic re-audit cadence.
- Deliverables: signed System Audit report, ATR, regulatory submission acknowledgements, continuous-compliance calendar.
Maturity and capability model
While SEBI does not mandate a single numeric maturity score for all entities, a capability-maturity view helps both auditor and entity communicate posture and track improvement. The following five-level model can be applied per control family.
| Level | Descriptor | Characteristics |
|---|
| 1 | Initial / Ad hoc | Controls absent or informal; reliance on individuals; no documented policy; reactive to incidents. |
| 2 | Developing | Basic policies exist; some controls implemented but inconsistently; limited evidence and monitoring. |
| 3 | Defined | Controls documented, standardised and consistently applied; roles defined; regular reporting to committee. |
| 4 | Managed | Controls measured with KPIs/metrics; SOC/SIEM operational; drills and VAPT closure tracked; risk-based tuning. |
| 5 | Optimised | Continuous improvement; threat-intelligence-driven; automated detection/response; resilience validated under live scenarios. |
A minimum target for Qualified REs and MIIs is Level 4 across governance, protect, detect, respond and recover families, with critical trading controls at Level 4-5. Smaller REs should evidence at least Level 3 with a documented roadmap to Level 4.
Assessment and audit approach
- Confirm auditor eligibility: CERT-In empanelment for VAPT and appropriate IS-audit certifications; confirm independence from the audited systems.
- Agree the Terms of Reference against the exchange/depository standard checklist and lock the audit period.
- Conduct entry meeting; collect governance artefacts, policies, asset registers and prior-audit ATRs.
- Perform design assessment: review policies, standards and configurations against CSCRF and functional requirements.
- Perform operating-effectiveness testing: sample logs, access reviews, change tickets, incident records and drill evidence.
- Execute or review VAPT scope and results; verify closure and revalidation of critical/high findings.
- Test trading/settlement controls (OMS/RMS limits, kill-switch, algo tagging, audit trails) via configuration review and walkthroughs.
- Validate resilience: examine DR drill, backup restore tests and RTO/RPO achievement.
- Classify findings by severity (Critical/High/Medium/Low), quantify risk and agree management responses.
- Obtain the Action-Taken Report and re-verify remediation of prior and current high-severity observations.
- Issue the signed audit report; support board/IT-committee presentation and submission to the exchange/depository/SEBI.
- Establish follow-up cadence for open findings and the next audit cycle.
Finding severity should be assigned consistently, because closure timelines and regulatory visibility depend on it. The table below sets out a workable classification an auditor can apply and an entity can plan remediation against.
| Severity | Definition | Expected remediation window |
|---|
| Critical | Exploitable weakness in a Critical System or a control failure with market-wide or investor-fund impact | Immediate / within days; interim compensating controls at once |
| High | Significant control gap materially increasing risk to trading, data or resilience | Within the SEBI/exchange-mandated period; tracked to closure and revalidated |
| Medium | Control weakness with moderate risk, contained by other controls | Within the agreed remediation plan, typically the current cycle |
| Low / Observation | Minor deviation or improvement opportunity with limited risk | Best-effort; monitored, no regulatory escalation |
Evidence request list
The auditor should request, and the entity should maintain, the following categorised evidence. As a working principle, every control assertion in the checklist should be supported by at least one artefact that is dated within the audit period, attributable to a named owner, and verifiable independently of management's narrative. Screenshots alone are weak evidence; prefer exported configurations, system-generated logs, signed approvals and tool reports. Maintain evidence in a structured repository indexed to the checklist so that re-audit and regulatory queries can be answered quickly.
- Governance: board-approved policies, CISO appointment, IT/Technology Committee ToR and minutes, band-classification workpaper, RACI, risk register.
- Identify: asset and critical-systems inventory, data classification, risk-assessment reports, vendor/third-party risk assessments, SBOM.
- Protect: access matrices and recertification records, MFA/PAM configs, hardening baselines and scans, encryption/KMS inventory, EDR/DLP coverage, firewall rulebase and network diagrams.
- Detect: SOC operating model and roster, SIEM source coverage, log-retention and NTP evidence, correlation-rule catalogue, threat-intel and FIM records.
- Respond: IRP and CCMP, incident register, CERT-In/SEBI submission acknowledgements, RCA/CAPA tracker, tabletop reports.
- Recover: BCP-DR policy, RTO/RPO matrix, DR architecture, drill and switchover reports, backup schedule and restore-test evidence.
- Testing: CERT-In empanelment proof, VAPT scope and reports, closure/revalidation trackers, secure code-review results.
- Data protection: data-residency attestations, Aadhaar-masking config, retention/disposal logs, DPDP gap assessment.
- Trading/functional: OMS/RMS configurations, kill-switch procedures, algo-ID register and exchange approvals, order audit-trail samples, capacity reports.
- Cloud/outsourcing: cloud governance policy, CSP compliance reports, outsourcing agreements with right-to-audit and exit clauses.
- Investor protection: SCORES logs, segregation/upstreaming reports, complaint TAT records, investor-communication logs.
- Prior cycle: previous System Audit report, ATR, and evidence of closure of prior observations.
Roles and responsibilities
| Role | Responsibility |
|---|
| Board / Governing Council | Approve cyber and BCP-DR policies; oversee cyber risk; review audit outcomes and ATR. |
| Managing Director / CEO | Accountable for overall compliance; ensures resourcing; signs regulatory submissions. |
| Chief Information Security Officer (CISO) | Owns the cyber-security programme, CSCRF compliance, incident reporting to CERT-In/SEBI, and audit closure. |
| IT / Technology Committee | Reviews technology risk, audit findings, VAPT closure and DR-drill outcomes at prescribed frequency. |
| IT / Infrastructure Head | Implements and operates technical controls, segmentation, hardening and DR infrastructure. |
| SOC / Security Operations | 24x7 monitoring, detection, triage and escalation of incidents. |
| Application / Trading System Owner | Maintains OMS/RMS, algo, kill-switch and audit-trail controls. |
| Compliance Officer | Tracks regulatory obligations, filings, SCORES and submission timelines. |
| Internal Audit | Independent internal assurance and coordination with the external System Auditor. |
| External System Auditor (CERT-In empanelled / certified) | Conducts the independent System and Cyber Audit and issues the report. |
KPIs to track
- Percentage of critical/high VAPT findings closed within the SEBI-mandated timeline.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.
- Number of incidents reported to CERT-In within the mandated reporting window (target: 100%).
- DR drill success rate and achievement of RTO/RPO against targets.
- Backup restore-test success rate.
- User access recertification completion rate and orphaned-account count.
- SIEM log-source coverage of critical systems (percentage).
- Patch/remediation SLA adherence for critical vulnerabilities.
- SCORES complaint resolution turnaround time and pendency.
- Repeat audit observations (target: zero recurrence of prior high findings).
- MFA/PAM coverage of privileged and internet-facing access.
- Percentage of Critical Systems with current, correct asset-register and criticality mapping.
Readiness checklist
- CSCRF band correctly determined and documented.
- Board-approved cyber-security and BCP-DR policies current and reviewed within 12 months.
- CISO appointed and IT/Technology Committee operating at prescribed frequency.
- Complete asset and critical-systems inventory with data classification.
- MFA and PAM enforced for privileged, remote and internet-facing access.
- Network segmentation, hardening baselines, EDR and DLP implemented.
- SOC/SIEM operational with adequate log-source coverage and retention.
- Incident Response Plan and CCMP approved; CERT-In reporting process tested.
- VAPT completed by CERT-In empanelled auditor with critical/high findings closed.
- DR site validated; DR drill and live switchover completed within cycle.
- Backups encrypted, offsite/immutable and restore-tested.
- OMS/RMS limits, kill-switch and algo-ID controls configured and tested.
- Data-residency, Aadhaar-masking and retention requirements met.
- Cloud/outsourcing governance with right-to-audit and exit plans in place.
- SCORES integration and fund-segregation reporting operational.
- Prior audit observations closed with evidence retained.
- Independent System Auditor engaged and ToR agreed against the exchange checklist.
Common gaps
- Incorrect or absent CSCRF band classification, leading to under-scoped controls.
- Policies exist on paper but are not board-approved, not reviewed, or not operationally enforced.
- CISO role vacant, part-time, or without genuine authority and reporting line to the board.
- Incomplete asset inventory — shadow systems, forgotten internet-facing hosts and untracked APIs.
- VAPT scope too narrow (missing mobile apps, APIs, DR site) or critical findings not closed within timeline.
- MFA/PAM not covering all privileged and remote access; stale accounts of leavers.
- SIEM ingesting device logs but missing application/trading-system logs; short retention or unsynchronised clocks.
- No genuine DR drill / live switchover; RTO/RPO untested or unmet; backups never restore-tested.
- Incidents not reported to CERT-In within the mandated window; weak RCA and no closure tracking.
- Algo controls weak: missing unique algo IDs, unthrottled APIs, or changes deployed without exchange re-approval.
- Data localisation and Aadhaar-masking gaps; cloud usage without SEBI cloud-framework governance.
- Repeat observations from prior audits left unremediated.
SEBI System Audit mapped to other frameworks
| SEBI CSCRF domain | ISO/IEC 27001:2022 | NIST CSF 2.0 | PCI DSS v4.0 |
|---|
| Governance & Cyber Resilience | A.5 Organisational controls, Clause 5 Leadership | GOVERN (GV) | Req 12 Security policy & programme |
| Identify (assets, risk, 3rd party) | A.5.9 Asset inventory, A.5.19-5.23 Supplier | IDENTIFY (ID) | Req 12.5, 12.8 Scope & third parties |
| Protect (access, network, crypto) | A.8 Technological, A.5.15 Access control | PROTECT (PR) | Req 1-8 Network, access, crypto |
| Detect (SOC, logging) | A.8.15-8.16 Logging & monitoring | DETECT (DE) | Req 10 Logging & monitoring, Req 11.5 |
| Respond (incident, CERT-In) | A.5.24-5.28 Incident management | RESPOND (RS) | Req 12.10 Incident response |
| Recover (BCP-DR) | A.5.29-5.30 Continuity, A.8.13 Backup | RECOVER (RC) | Req 12.10.1 Recovery, Req 3.4 Backup |
| VAPT & security testing | A.8.8, A.8.29 Vulnerability & testing | ID.RA, PR.PS | Req 11.3-11.4 VAPT |
| Data protection & localisation | A.5.34, A.8.10-8.12 Privacy & data | PR.DS | Req 3 Protect stored data |
| Change management & SDLC | A.8.25-8.32 Secure development & change | PR.PS-01 | Req 6 Secure systems & software |
| Cloud & outsourcing | A.5.19-5.23 Supplier, A.5.23 Cloud | GV.SC Supply chain | Req 12.8-12.9 Service providers |
How CyberSigma helps
CyberSigma is a CERT-In empanelled cyber-security auditor with QSA-grade compliance expertise and deep experience across SEBI-regulated entities — stock brokers, depository participants, RTAs, AMCs, KRAs and MIIs. We run your SEBI System Audit end to end: correct CSCRF band classification, gap assessment against the current CSCRF and exchange/depository checklists, CERT-In empanelled VAPT, remediation advisory covering SOC/SIEM, PAM/MFA, DR and trading-system controls, DR-drill and incident-response readiness, and the final independent System Audit report with an Action-Taken Report ready for board and regulatory submission. We map SEBI controls to ISO 27001, NIST CSF and PCI DSS so a single control library satisfies multiple obligations — reducing audit fatigue while keeping you continuously compliant. Talk to CyberSigma to scope your next SEBI System Audit with confidence.
