IFSCA Cyber Resilience Audit

Introduction to the IFSCA Cyber Resilience Audit

The International Financial Services Centres Authority (IFSCA) is the unified regulator for financial services in India's International Financial Services Centres (IFSCs), the flagship of which is the Gujarat International Finance Tec-City (GIFT City) IFSC in Gandhinagar, Gujarat. IFSCA was constituted under the International Financial Services Centres Authority Act, 2019 and consolidated the powers previously exercised in the IFSC by the Reserve Bank of India (RBI), the Securities and Exchange Board of India (SEBI), the Insurance Regulatory and Development Authority of India (IRDAI) and the Pension Fund Regulatory and Development Authority (PFRDA). Because IFSCA regulates a diverse population of Regulated Entities (REs) - banking units, capital-market intermediaries, insurers and reinsurers, fund managers, aircraft and ship leasing entities, bullion market participants and FinTech firms - it has issued a horizontal, technology-neutral cyber resilience framework that applies across all of them.

The principal instrument is the IFSCA Circular on 'Cyber Security and Cyber Resilience Framework' (the CSCRF for IFSC), read together with the IFSCA (Information Technology and Cyber Security) directions and the outsourcing and business continuity requirements embedded in the various entity-specific IFSCA regulations. The framework deliberately harmonises with domestic Indian mandates - the RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023), the SEBI Cyber Security and Cyber Resilience Framework (SEBI/HO/MIRSD/CSFT/CIR dated 20 August 2024, the consolidated CSCRF), the CERT-In Directions dated 28 April 2022 (six-hour incident reporting) and the CERT-In empanelment regime - so that entities operating both onshore and in the IFSC face a consistent control baseline. This guide is written for two audiences simultaneously: the auditor who must assess conformance and produce assurance, and the implementer (CISO, IT head, DPO) who must build and remediate the controls.

What is the IFSCA Cyber Resilience Audit

The IFSCA Cyber Resilience Audit is an independent, evidence-based assessment of a Regulated Entity's ability to anticipate, withstand, contain, recover from and adapt to cyber incidents affecting its critical systems and data, measured against the IFSCA Cyber Security and Cyber Resilience Framework and allied IT-governance directions. 'Cyber resilience' extends beyond preventive cyber security: it demands that an RE continue to deliver its critical financial services during and after a disruptive cyber event, with defined recovery time and recovery point objectives, tested continuity arrangements and board-level accountability.

IFSCA structures its expectations around the internationally recognised NIST Cybersecurity Framework functions - Identify, Protect, Detect, Respond and Recover - augmented by governance, third-party/outsourcing risk, data protection (including alignment to the Digital Personal Data Protection Act, 2023), and mandatory incident-reporting obligations to IFSCA and CERT-In. The audit tests both design effectiveness (are the right policies, standards and controls defined and approved) and operating effectiveness (are they consistently performed, monitored and evidenced over the review period). Depending on the RE category, the audit may be conducted as a self-assessment attested by the board, an independent audit by a CERT-In empanelled auditor, or a Vulnerability Assessment and Penetration Testing (VAPT) exercise, with periodic submission of findings and closure status to IFSCA.

Typical deliverables of the engagement are: a scoping and asset-criticality document; a control-by-control conformance assessment mapped to the NIST functions and IFSCA domains; a VAPT report for internet-facing and critical internal systems; a maturity rating; a prioritised remediation roadmap; and the regulatory submission pack (compliance certificate, cyber audit report, and where required a board-approved cyber crisis management plan).

A crucial distinction for the IFSC context is proportionality. Unlike a one-size-fits-all rulebook, IFSCA applies a risk-based, graded approach: the depth of controls, the frequency of testing, and the intensity of independent assurance scale with an entity's systemic importance, transaction volumes, customer footprint and data sensitivity. A Market Infrastructure Institution such as an IFSC stock exchange or clearing corporation must operate a dedicated or managed Security Operations Centre, undertake red-team exercises, compute a cyber-capability/resilience index and perform continuous monitoring, whereas a small Fund Management Entity may satisfy the baseline through a proportionate control set, an annual VAPT and a self-assessment attested by its governing body. The auditor's first task is therefore to correctly place the entity in its category and calibrate expectations accordingly, because assessing a small RE against MII-grade controls produces false negatives, while under-assessing a systemically important RE creates unacceptable residual risk to the IFSC ecosystem.

IFSCA also expects cyber resilience to be evidenced through the accountability chain. The board (or equivalent governing body) owns the cyber-risk appetite and must be demonstrably engaged: approving the policy suite and the Cyber Crisis Management Plan, receiving periodic posture reports, and being briefed on material incidents. A designated senior officer - typically the CISO - is accountable for the operating programme, while the audit provides independent challenge. Assessors should look for a golden thread running from board minutes, through the risk register and control catalogue, down to operational logs and test evidence. Where that thread is broken - for example, a well-written policy that no operational team follows, or a SOC generating alerts that no one triages - the control is judged ineffective regardless of its documented design.

Who must comply

The framework applies to entities registered with or licensed by IFSCA to operate in an IFSC. Applicability and audit intensity scale with the entity's systemic importance, client-facing footprint and data sensitivity. The table below summarises the principal categories.

• Systemically important REs and MIIs attract the most prescriptive controls (dedicated/managed SOC, red-teaming, cyber resilience testing).
• Smaller REs may follow a proportionality principle but must still meet the core Identify-Protect-Detect-Respond-Recover baseline and mandatory reporting.
• Group entities relying on head-office or parent infrastructure must still demonstrate IFSC-specific governance, data localisation/segregation and independent assurance.

A recurring theme across all categories is the treatment of inter-connectivity. IFSC entities rarely operate in isolation: broker-dealers connect to IFSC exchanges and clearing corporations; banking units interface with correspondent banks, SWIFT and domestic payment rails; and almost every RE depends on cloud service providers and parent-group infrastructure. Because a compromise can propagate across these links, IFSCA holds each RE responsible for the security of its own connectivity endpoints, APIs and shared services, and for ensuring that reliance on a parent or vendor does not dilute independent assurance. Auditors must therefore trace every trust relationship - human, machine and third-party - and confirm that controls hold at each boundary, not merely at the perimeter.

Structure of the IFSCA Cyber Resilience framework

The framework is organised around the five NIST CSF functions - Identify, Protect, Detect, Respond and Recover - with an over-arching Govern function and cross-cutting domains for third-party/outsourcing risk, data protection and regulatory reporting. This structure is deliberate: it lets an RE that already reports under RBI, SEBI or IRDAI regimes reuse the same control language and evidence, and it lets a single audit produce findings that map cleanly onto ISO/IEC 27001, the NIST CSF and CERT-In expectations. The table below maps the domains, their constituent control families and the anchor regulatory references an auditor should cite.

Master assessment checklist

This is the operative section of the audit. It enumerates each domain and its control families with a h3 heading and a two-column table (What to verify / Typical evidence). No control area is omitted. Auditors should sample across the full review period; implementers should treat every 'What to verify' row as a build/remediation requirement.

How to use this checklist: for each row, the auditor should (a) confirm the control is defined and approved (design), (b) obtain and inspect the stated evidence, (c) sample instances across the review period to confirm consistent operation, and (d) record a conclusion - conformant, partially conformant with a finding, or non-conformant - with a severity rating. Sample sizes should be risk-based: a small population of critical assets may be tested in full, whereas high-volume events such as access changes or patch cycles warrant statistical sampling. Where a control is inherited from a parent or cloud provider, the RE must evidence the shared-responsibility split and its own monitoring of the provider's control. Implementers, conversely, should read each row as an acceptance criterion: the artefacts in the 'Typical evidence' column are precisely what a remediation project must produce and retain to withstand the next audit.

GV - Governance and board oversight

ID - Asset, data and risk identification

PR.AC - Identity and access management

PR.DS - Data security and cryptography

PR.IP - Secure configuration, patch and vulnerability management

PR.PT - Network and infrastructure protection

PR.AT - Security awareness and training

DE - Security monitoring and detection

Detection capability is the difference between a contained incident and a headline breach. IFSCA and CERT-In expectations converge here on three non-negotiables: comprehensive log capture from critical systems, retention of logs for a rolling 180 days within Indian jurisdiction, and accurate time synchronisation so that events across systems can be correlated into a coherent timeline. For systemically important REs the audit tests whether the SOC is genuinely operational - staffed, alerting on tuned use-cases and demonstrably triaging - rather than a dormant tool licence. Detection coverage should be mapped against a recognised threat model such as MITRE ATT&CK so that gaps are visible and defensible.

RS - Incident response and reporting

Incident response is where cyber resilience is most visibly tested, and where regulatory exposure is highest. IFSC REs face concurrent reporting obligations: to CERT-In within six hours of noticing a reportable incident under the 28 April 2022 Direction, to IFSCA within its prescribed timelines, and - for personal-data breaches - under the DPDP Act to the Data Protection Board and affected data principals. The audit must confirm not only that plans exist but that reporting clocks, contacts and escalation paths are pre-wired so that the six-hour window is achievable in practice, including out of hours.

RC - Business continuity, disaster recovery and backup

Third-party and outsourcing risk

Data protection and privacy (DPDP alignment)

Cyber resilience testing (VAPT, red-team, drills)

Regulatory reporting and assurance

The reporting and assurance domain closes the loop between operational controls and the regulator. IFSCA relies on periodic attestations, cyber audit reports and incident filings to supervise the ecosystem, so accuracy and timeliness here are non-negotiable. The audit should confirm that submissions are complete, board-reviewed, filed on schedule and reconciled against the underlying evidence - a compliance certificate that overstates the control environment is a serious governance failure. Where the RE's systems qualify as Critical Information Infrastructure, coordination with NCIIPC is an additional obligation the assessor must confirm.

Scoping the assessment

Accurate scoping determines audit validity. The scope must reflect the RE's IFSC-licensed activities and every system that stores, processes or transmits critical or customer data, including those hosted by the parent group or third parties.

• Define the legal entity and IFSC registration(s) in scope and the regulatory category driving control intensity.
• Enumerate critical business services and their supporting applications, infrastructure, cloud tenants and data flows.
• Include internet-facing assets, remote-access paths, APIs and integrations with exchanges/depositories/payment rails.
• Cover outsourced and group-shared infrastructure, clarifying the shared-responsibility boundary and right-to-audit reach.
• State the review period (typically 12 months for operating-effectiveness testing) and any carve-outs with justification.
• Identify data-protection scope: personal data categories, cross-border flows and DPDP applicability.
• Confirm testing scope: which systems undergo VAPT, red-teaming and DR/BCP drills.

Data-flow mapping deserves particular attention during scoping. The auditor should trace how customer, transaction and personal data enters, moves through and leaves the RE's environment, including flows to the parent group, exchanges, clearing corporations, payment networks and cloud services. Each flow reveals a control boundary that must be tested - encryption in transit, authentication of the interface, logging of the exchange and retention of the data at rest. Data-flow diagrams also underpin the DPDP assessment, since cross-border transfers and processing by parent entities located outside India trigger specific safeguard obligations. An RE that cannot produce accurate, current data-flow diagrams almost always has blind spots in its control coverage, and this alone frequently warrants a finding.

Finally, scoping must fix the assurance model. IFSCA accepts different levels of independent assurance depending on category: a board-attested self-assessment for smaller REs, an independent audit by a CERT-In empanelled organisation for most REs, and the most intensive combination of continuous monitoring, red-teaming and third-party audit for MIIs and banking units. The engagement letter should record which model applies, who signs the attestation, and the reporting timeline to IFSCA, so that the deliverables produced actually satisfy the regulatory obligation rather than merely informing management.

Implementation approach

A phased programme lets an RE reach conformance methodically without stalling the business. The sequencing below front-loads discovery and governance (which unblock every downstream control), overlaps technical remediation with policy work, and reserves resilience testing and independent assurance for the end when controls are stable enough to test meaningfully. Timelines are indicative for a mid-size RE; MIIs and banking units typically run longer, phased over two to three quarters with parallel workstreams, while small FMEs may compress to eight to twelve weeks. The phases deliberately overlap - for example, technical remediation begins before every policy is finalised - so that momentum is maintained and quick wins (MFA, EDR, patch SLAs) reduce risk early.

Phase 1 - Discovery and gap assessment (weeks 1-4)

• Activities: build asset and data inventory; classify data; map critical services and third parties; run a control-gap assessment against the CSCRF and NIST functions; baseline current maturity.
• Deliverables: asset/data inventory, criticality register, gap-assessment report, prioritised risk-ranked findings, indicative maturity rating.

Phase 2 - Governance and policy foundation (weeks 3-8)

• Activities: draft/refresh board-approved cyber policy, CCMP, IRP, outsourcing and data-protection policies; appoint/confirm CISO and DPO; constitute IT/cyber committee; define risk appetite and RACI.
• Deliverables: approved policy suite, committee charter, risk register, obligations and compliance calendar.

Phase 3 - Technical remediation (weeks 6-16)

• Activities: deploy/tune MFA, PAM, EDR, DLP; harden configurations; implement segmentation; stand up SIEM/SOC and 180-day logging with NTP sync; establish patch and vulnerability SLAs; embed secure SDLC.
• Deliverables: hardened baselines, IAM/PAM rollout, SOC use-case catalogue, VM programme, backup/immutability configuration.

Phase 4 - Resilience and testing (weeks 14-20)

• Activities: conduct VAPT via CERT-In empanelled auditor; run DR/BCP and ransomware-recovery drills; perform cyber tabletop; red-team for systemically important REs; remediate and retest.
• Deliverables: VAPT report and closure, drill after-action reports, RTO/RPO evidence, remediation tracker.

Phase 5 - Assurance, reporting and continual improvement (weeks 18-24)

• Activities: independent cyber audit; compile regulatory submission pack; board review; establish KPIs, dashboards and a continual-improvement cadence.
• Deliverables: cyber audit report, IFSCA compliance certificate/submission, KPI dashboard, continual-improvement plan.

Maturity and capability model

CyberSigma rates each domain on a five-level capability scale (aligned to NIST CSF Tiers and CMMI concepts). The rating drives the remediation roadmap and evidences trajectory to IFSCA over successive audits. Maturity is assessed per domain rather than as a single blended score, because an RE can be optimised in access control yet initial in third-party risk; a per-domain radar exposes exactly where investment is needed. IFSCA does not expect every RE to reach Level 5 - the appropriate target depends on category and risk appetite - but it does expect a realistic target state, a credible plan to reach it, and demonstrable progress between audit cycles. A declining or static maturity trend, especially in the Detect and Recover functions, is itself an audit red flag.

Assessment and audit approach

The audit follows a structured, repeatable methodology that separates design-effectiveness testing (is the control properly defined and approved) from operating-effectiveness testing (did it work consistently across the review period). Evidence is gathered through four complementary techniques - inspection of documents and configurations, observation of processes in action, enquiry through interviews, and re-performance or independent testing such as VAPT. The auditor triangulates across these techniques so that no conclusion rests on a single, potentially self-serving, source. The ten steps below describe the end-to-end flow.

1. Initiation and scoping: confirm entity, IFSC registrations, RE category, critical services, review period and testing scope; agree the engagement plan and RACI.
2. Documentation review: examine policies, standards, procedures, registers, prior audit and VAPT reports, and regulatory correspondence for design adequacy.
3. Control walkthroughs and interviews: with CISO, IT, SOC, DPO, business and vendor-management teams to understand as-implemented processes.
4. Technical validation: configuration reviews, sampling of access, logs, patch and change records; independent VAPT of in-scope systems by a CERT-In empanelled tester.
5. Operating-effectiveness testing: sample transactions/events across the review period to confirm controls operated consistently (e.g., access recertifications, incident handling, backup restores).
6. Resilience testing review: evaluate DR/BCP drills, tabletop outcomes and RTO/RPO attainment against targets.
7. Findings and risk rating: consolidate observations, assign severity and likelihood, and map to domains and NIST functions.
8. Maturity scoring: rate each domain on the five-level scale and compute an overall posture.
9. Reporting: issue the draft report with management responses, agree remediation owners and timelines, then finalise.
10. Regulatory submission and follow-up: assist with IFSCA/CERT-In submissions and track remediation to closure with retesting.

Evidence request list

The following categorised evidence pack accelerates the audit and should be assembled during Phase 1.

• Governance: board-approved cyber policy, committee charter and minutes, CISO/DPO appointments, risk appetite, RACI, obligations register, compliance calendar.
• Asset and risk: CMDB/asset inventory, data classification and inventory/RoPA, critical-asset list, business impact analysis, cyber risk assessment reports.
• Access and identity: RBAC/role matrices, MFA and PAM configurations, JML records, access recertification reports, SoD matrix, dormant-account reports.
• Data security: encryption inventory and key-management policy, TLS scan results, DLP rules and reports, media-disposal certificates, cross-border transfer assessments.
• Configuration and vulnerability: hardening baselines and scan results, patch policy and cycle reports, VM scan reports and remediation trackers, change-management records.
• Network and endpoint: network diagrams, firewall rule-review reports, WAF/DDoS config, EDR coverage, VPN/ZTNA config, email-security (SPF/DKIM/DMARC) evidence.
• Detection and monitoring: SIEM source coverage, log-retention (180-day) and NTP config, SOC SOP/roster or MSSP contract, use-case catalogue, threat-intel evidence.
• Incident and reporting: IRP/CCMP, severity matrix, CERT-In and IFSCA incident filings with timestamps, RCA reports, lessons-learned register.
• Resilience: BCP/DR plans, RTO/RPO register, backup policy and restore-test logs, DR/ransomware drill after-action reports.
• Third party: outsourcing register, due-diligence assessments, executed contracts with security/right-to-audit clauses, CSP certifications, exit plans.
• Privacy: DPDP consent artefacts, DPIAs, retention/purge schedules, data-principal rights logs, breach register.
• Assurance: prior cyber audit and VAPT reports, remediation trackers, IFSCA compliance certificates and acknowledgements.

Roles and responsibilities

KPIs to track

• Percentage of critical assets inventoried and classified.
• MFA and PAM coverage across privileged and remote access.
• Mean time to patch critical/high vulnerabilities against SLA; open vulnerability ageing.
• VAPT findings closed within SLA; retest closure rate.
• Mean time to detect (MTTD) and mean time to respond (MTTR) for incidents.
• Percentage of incidents reported to CERT-In within 6 hours and to IFSCA within prescribed timelines.
• Backup restoration test success rate; RTO/RPO achieved vs target in drills.
• Security awareness completion rate and phishing-simulation click/report rates.
• Percentage of critical vendors assessed and contracts with right-to-audit/breach clauses.
• Data-principal rights requests fulfilled within SLA.
• Overall and per-domain maturity trend across successive audits.

Readiness checklist

• Board-approved cyber security and cyber resilience policy is current and version-controlled.
• CISO and (where required) DPO are appointed with defined authority and reporting lines.
• Complete asset and data inventory with criticality and classification is maintained.
• MFA, PAM and least-privilege access controls are enforced and recertified.
• Hardening baselines, patch SLAs and a vulnerability-management programme are operational.
• SIEM/SOC with 180-day log retention and NTP time-sync is in place.
• IRP and CCMP are approved, tested and mapped to 6-hour CERT-In and IFSCA reporting.
• BCP/DR with defined RTO/RPO is documented and drills (including cyber/ransomware) are performed.
• Backups follow 3-2-1 with immutable copies and tested restoration.
• VAPT by a CERT-In empanelled auditor is completed and findings closed.
• Third-party/outsourcing register, contracts and cloud governance meet IFSCA requirements.
• DPDP alignment (consent, DPIAs, rights, retention) is implemented.
• Regulatory submissions (compliance certificate, cyber audit report) are prepared and on schedule.

Common gaps observed

Across IFSC engagements the same deficiencies recur, often because entities relocate mature onshore processes into the IFSC without re-establishing independent governance, or because a rapidly scaled FinTech has prioritised product velocity over controls. The list below flags the highest-frequency, highest-impact gaps; each maps directly to a checklist row above and should be treated as a priority remediation candidate.

• Cyber policy exists but is not board-approved or not reviewed within the last 12 months.
• CISO role lacks independence from IT operations or has no direct board reporting line.
• Asset and data inventories are incomplete, so criticality and classification are unreliable.
• MFA not extended to all privileged/remote access; PAM absent or without session recording.
• Log retention below 180 days, no NTP synchronisation, or SOC use-cases untuned and noisy.
• Incident-response plan not tested; teams unaware of the 6-hour CERT-In reporting obligation.
• Backups not immutable/air-gapped and restoration never tested; ransomware recovery unplanned.
• DR/BCP drills either not conducted or not covering cyber scenarios; RTO/RPO unmeasured.
• Outsourcing contracts lack right-to-audit, breach-notification and exit clauses; parent-hosted systems excluded from scope.
• DPDP obligations (consent records, DPIAs, data-principal rights) not operationalised.
• VAPT performed by a non-empanelled provider or findings left open without retesting.
• No tracking of IFSCA-specific reporting timelines and compliance-certificate submissions.

IFSCA Cyber Resilience mapped to other frameworks

The IFSCA CSCRF is designed to interoperate with domestic and international standards, letting an RE reuse evidence across audits and avoid duplicative control programmes. An entity already certified to ISO/IEC 27001 or complying with the RBI IT Governance Master Direction, the SEBI CSCRF or IRDAI cyber guidelines can cross-walk the bulk of its existing evidence into the IFSCA assessment, closing only the IFSC-specific delta (independent assurance over parent-hosted systems, IFSCA reporting timelines, DPDP alignment and cyber-resilience testing intensity). The mapping below is indicative and should be tailored to the entity's category; where a cell shows a dash, the obligation is either not directly addressed by that standard or is covered generically under its management-system clauses.

How CyberSigma helps

Frequently asked questions

Need help with IFSCA Cyber Resilience?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.