SEBI cyber audit findings cost firms time, money, and regulatory credibility. The frustrating part is that most failures are preventable. Industry experience consistently shows the same five gaps appearing again and again. Here is what they are — and what to do about them before your next audit.
Why auditors flag it: SEBI mandates half-yearly Vulnerability Assessment & Penetration Testing (VAPT) covering all internet-facing applications, internal network segments, and trading infrastructure. Auditors routinely find that firms have conducted VAPT only on their primary website — leaving trading platforms, back-office portals, mobile apps, and APIs completely untested. Partial VAPT is treated as non-compliance, not partial compliance.
What proper evidence looks like: A VAPT report from a CERT-In empanelled auditor covering all in-scope assets, a remediation tracker showing critical and high findings closed, and a re-test report confirming closure. The scope document must match the actual asset inventory.
How to avoid it: Maintain a living asset inventory and ensure your VAPT scope is derived from it. Every internet-facing system, including APIs consumed by third-party apps, should be in scope. Review our SEBI CSCRF Compliance Checklist for the full VAPT requirements.
Why auditors flag it: SEBI requires board-approved IS policies covering access control, patch management, incident response, data classification, and vendor management. Auditors find two common failure modes: either the policies do not exist at all, or they exist as outdated templates that reference obsolete software, decommissioned systems, or out-of-date regulatory references. A policy dated 2019 with no revision history will attract major findings.
What proper evidence looks like: IS Policy with a current board resolution approving it; a policy revision log showing at least annual review; policies that reference current SEBI circulars (particularly CSCRF 2024); a policy communication record showing staff awareness.
How to avoid it: Set a calendar reminder to review and refresh all IS policies at least annually. The revision does not need to be a complete rewrite — but it must be documented, re-approved by the board, and reflect current operational reality.
Why auditors flag it: Almost every firm will claim they patch their systems. But when auditors ask for evidence — change management records, patch logs, exception approvals — many firms cannot produce it. SEBI does not accept verbal assurances. Auditors also look for systems with known critical vulnerabilities that should have been patched months ago.
What proper evidence looks like: A patch management policy with defined SLAs; monthly patch cycle records with approval trails; an exceptions log where patches could not be applied, with documented compensating controls and senior management sign-off; vulnerability scanner reports showing a declining critical findings trend.
How to avoid it: Implement a simple patch management workflow even if you are a smaller firm. A spreadsheet with patch dates and approvals is better than nothing, but a proper change management system provides far stronger evidence.
Why auditors flag it: Privileged access — admin accounts, database access, system administrator rights — is one of the highest-risk areas in any firm. Auditors regularly find: shared admin passwords, admin accounts with no MFA, former employees whose access was never revoked, developers with production database access, and no quarterly review of privileged account holders.
What proper evidence looks like: A Privileged Access Management (PAM) policy; a privileged user register reviewed quarterly with sign-off; MFA enforced on all privileged and remote access accounts; an account termination checklist with dates showing immediate revocation on employee departure; no shared admin credentials.
How to avoid it: Conduct a privileged account audit immediately. List every account with elevated rights. Verify each account is assigned to a named individual currently employed. Enable MFA. Schedule quarterly reviews and document them.
Why auditors flag it: SEBI requires a documented, tested Incident Response Plan (IRP). Many firms have a plan on paper but have never run a tabletop exercise or simulation. Worse, some firms have never formally documented their incident response process at all — relying on informal knowledge of "what we'd do if something happened." This is not acceptable to auditors.
What proper evidence looks like: An IRP document with clear roles, escalation paths, reporting timelines (6-hour CERT-In notification, SEBI notification), and a post-incident review process; a tabletop exercise report from within the last 12 months; documented lessons learned from any real incidents.
How to avoid it: Run a tabletop exercise at least annually. It does not need to be elaborate — a 2-hour workshop walking through a ransomware or data breach scenario with your IT, compliance, and senior management teams, documented properly, is sufficient evidence for most auditors.
The best preparation for a SEBI cyber audit is not a document sprint two weeks before the audit date. It is a year-round evidence collection programme that makes audit evidence a byproduct of how you already operate.
Infosek Team
All five failure reasons share a common root: treating the audit as the event, rather than the outcome. Firms that pass SEBI cyber audits consistently are those that maintain evidence of ongoing security operations throughout the year. The audit simply captures that evidence. To understand the full control framework you need to maintain, see our SEBI CSCRF Compliance Checklist and our breakdown of requirements by RE category.
Our 48-hour gap analysis identifies exactly where your evidence trail is weak before auditors find it. Book a free call to get started.
Book Free 30-Min Assessment