Cybersecurity audits for fintechs: beyond the ISO 27001 certificate

The first thing a fintech founder shows us when we begin a security audit engagement is the ISO 27001 certificate. The certificate is real, the auditor is reputable, and the controls listed in the Statement of Applicability are in place. The founder's expectation is that the audit will confirm what the certificate already says.

That is not what the audit does. ISO 27001 is a baseline. It demonstrates that the company has an information security management system, that risks are identified, and that controls are documented. It does not, by itself, demonstrate that the controls hold up against the threats the company actually faces. For an Indian fintech today, the threats have moved faster than the certification cycle.

The RBI's Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (issued November 2023, applicable to NBFCs with assets above ₹500 crore and to all banks) has added a layer of regulatory expectation that goes beyond ISO 27001. SEBI's System Audit framework for AIFs, mutual funds, and intermediaries adds another. The gap between the certificate and the regulatory expectation is where real audit work now sits.

What ISO 27001 actually covers

ISO 27001 certifies that an organisation has an ISMS — Information Security Management System — that meets the standard's requirements. The standard requires documented policies, identified risks, treatment plans, and continuous improvement. It is process-oriented. The auditor reviews documentation, samples evidence, and concludes whether the ISMS is operating.

What ISO 27001 does not do, explicitly: it does not pen-test the company's applications, it does not test the application security against OWASP Top 10, it does not verify that secrets are not committed to public repositories, it does not test incident response by running a tabletop exercise, and it does not assess third-party SaaS exposure beyond confirming that suppliers have been risk-assessed on paper.

These omissions are not flaws in the standard. They are out of scope by design. The standard is general-purpose; the specific testing has to be done by additional, focused work.

Where real fintech security audits begin

A fintech security audit, calibrated to today's threat environment, has six workstreams beyond the certificate.

API security and the OWASP Top 10

Fintech products are API-first. Every customer interaction, every partner integration, every internal microservice runs over APIs. The OWASP API Security Top 10 — broken object-level authorisation, broken authentication, broken object property level authorisation, unrestricted resource consumption, broken function-level authorisation, server-side request forgery, security misconfiguration, lack of protection from automated threats, improper inventory management, unsafe consumption of APIs — defines the surface that has to be tested.

What we look for: authorisation bypass in object-level reads (can a user fetch another user's transaction by changing the ID in the URL?), authentication weaknesses (does the API accept a JWT without verifying signature?), rate-limit failures (can the login endpoint be hit a million times per hour from one IP?), and broken function-level authorisation (can a standard user invoke an admin-only endpoint by direct API call?).

The testing is performed against the staging environment, with a copy of production data structures (synthetic data, not customer PII), by people who have done this on dozens of similar applications. The output is a prioritised vulnerability list, with proof-of-concept for each finding.

Secrets management

The single most common audit finding in early-stage fintech engagements is AWS keys, database passwords, or API tokens committed to a Git repository. Sometimes the repository is public. Sometimes it is private but accessible to former employees. Sometimes the secret was rotated after the commit, but the historical commit is still in the history and discoverable.

The audit runs a scan across all the company's repositories — using tools like TruffleHog, Gitleaks, or detect-secrets — and reports every detected secret with its location and commit timestamp. The remediation is two-step: rotate every exposed secret (because assume it is compromised), and implement pre-commit hooks plus a centralised secrets manager (Vault, AWS Secrets Manager, Doppler) so the recurrence is prevented architecturally.

DDoS readiness

RBI's IT Framework explicitly requires capacity to withstand DDoS attacks. The audit tests whether the company has a CDN with DDoS protection (Cloudflare, AWS Shield, Akamai), what the rate-limiting configuration is at the edge and at the application layer, and whether the response runbook is documented and rehearsed.

For payment-flow APIs specifically, the audit tests the failure mode under sustained traffic. What happens if the payment API gets 10x its normal traffic for 30 minutes? Does it degrade gracefully or collapse? Does the alerting catch it within minutes or hours?

Penetration testing

Annual external pen-test is the minimum. The audit confirms that a recent pen-test exists, that the findings were remediated, and that the testing scope was sufficient. Common gaps: the pen-test covered the website but not the mobile app, or the customer-facing API but not the admin panel, or production but not the build pipeline.

For fintechs handling card data, PCI-DSS adds additional pen-test requirements, including segmentation testing.

Incident response tabletop

ISO 27001 requires an incident response procedure. It does not require that the procedure has been tested. The audit runs a tabletop exercise — a scripted simulation of a specific incident (ransomware on internal file servers, customer data leak via API misconfiguration, vendor breach exposing customer credentials, internal admin account compromise) — with the actual incident response team present.

What the tabletop surfaces is not the procedure. It is the gaps between the procedure and operational reality. Who decides to disclose to RBI under the 6-hour breach reporting requirement? Who is on the call at 2am? Who has the legal authority to engage external forensics? Who notifies the audit committee chair? These questions are usually answered first during a real incident, which is too late.

Third-party SaaS exposure

Most fintechs operate on a substantial SaaS stack — Slack, Notion, GitHub, AWS, Google Workspace, Salesforce, customer support tools, observability platforms. Each of these is a data flow and a potential breach vector.

The audit catalogues every SaaS in use, identifies the data that flows to each one, reviews the SaaS provider's security attestations (SOC 2, ISO 27001, audit reports), tests the access controls at the company end (SSO enforced? MFA enforced? deprovisioning timely?), and identifies tools where the company's exposure exceeds what the SaaS provider's controls justify.

RBI's IT Framework specifics

For NBFCs above the ₹500 crore threshold and for banks, RBI's IT Framework adds specific requirements. The IT Strategy Committee (board-level) and the IT Steering Committee (executive-level) have to be in place with documented charters. The CISO function has to be independent of the CIO function — a separation many fintechs have not implemented. Vulnerability assessment and pen-test reports have to be reviewed by the audit committee.

The Master Direction also brings cyber-incident reporting into a 6-hour window for reportable incidents, with specific definitions of what is reportable. The audit confirms that the reporting workflow exists and has been tested.

SEBI System Audit for AIFs and intermediaries

For SEBI-regulated entities, the System Audit is a parallel requirement. It is performed annually, by a CISA or DISA qualified auditor, against a SEBI-defined scope. The scope covers data integrity, business continuity, access control, change management, and physical security. The audit report is filed with SEBI.

For an AIF with significant LP assets, the System Audit is the regulatory equivalent of a SOC 2 Type II. Treating it as a checklist exercise produces a clean report and no operational improvement. Treating it as a real audit, with findings that the system owners actually have to remediate, is what closes real risk.

Employee phishing rate

One number we always benchmark. The company's employee phishing-click rate, measured by a quarterly simulated phishing test. The industry baseline is 15 to 25% click rate on the first test, dropping to 3 to 8% after a year of consistent training and re-testing.

If the company has never run a phishing simulation, the audit recommends running one before the engagement closes, and includes the result in the report. The audit committee's reaction to the first number is almost always informative — either the company has been investing in security culture, or it has been investing in security tooling and skipping the human layer.

What we ship

Three deliverables at the close of a fintech security audit.

First, the prioritised vulnerability register. Every finding, with severity, exploitability, and remediation cost. The board sees the top 10. The CTO sees all of them.

Second, the regulatory gap map. Where the company's controls do or do not meet RBI IT Framework, SEBI System Audit, or PCI-DSS requirements as applicable. This is what the regulator will read against if an incident occurs.

Third, the 24-month roadmap. What to fix in the next 90 days, the next 180 days, and the next 24 months. Sequenced by risk score and dependency. The CFO uses this to plan the security budget.

An ISO 27001 certificate tells you that the company has a security management system. It does not tell you that the system is keeping the company safe against the actual threats. The difference between the certificate and the audit is the difference between documented and tested. Most fintechs we audit have one but not the other.

What good looks like

A fintech with a mature security posture has the certificate, the annual pen-test, the quarterly phishing simulation, the secrets scan in CI, the tabletop exercise on the calendar, and a CISO who reports independently of the CIO. The certificate is the floor. Everything above it is what we audit.