A plain-language guide to the June 2026 IFSCA cyber advisory — and exactly what your organisation needs to do (and document) before an inspection.
I’ve been tracking IFSCA’s regulatory output closely, and one thing I’ve learned is that when IFSCA issues something titled “advisory,” the word doesn’t mean optional. The June 4, 2026 circular on heightened cyber security risks from Frontier AI models is effective immediately, sits on top of the existing March 2025 Cyber Security Guidelines, and introduces obligations that need to be operationalised — not filed and forgotten.
Before we go further, here’s the circular: IFSCA Advisory on Heightened Cyber Security Risks from Frontier AI Models
Read it in full. Then use this note as your practical implementation guide — what needs to happen, who needs to own it, what policies need revision, what Board approvals are needed, and what documentation must exist when IFSCA comes calling.
Why This Circular Exists — And Why It Matters More Than Most
To understand what IFSCA is asking for, you need to understand what changed in the threat environment that prompted this circular.
For years, when a software vulnerability was publicly disclosed, financial institutions had a reasonable window — days, sometimes weeks — to assess exposure and deploy patches before attackers could build working exploits. That window shaped how patch management policies were written, how vendor SLAs were structured, and how incident response plans were calibrated.
Frontier AI models have eliminated that window.
These models can now scan complex codebases, identify known and previously unknown vulnerabilities, reason about how to exploit them, and generate working attack code — in hours, not weeks. The expertise and resources previously required to mount a sophisticated cyberattack have been compressed and democratised by AI. What used to require a nation-state-level team can now be initiated by a moderately capable attacker with access to the right model.
IFSCA’s position is that even though the most capable models aren’t freely available today, that restriction will not last. The circular is a forward-looking signal: restructure your security posture now, before AI-assisted attacks become routine, not after your entity is on the wrong end of one.
This context is important because it shapes how you should approach the compliance response. This isn’t about ticking eleven boxes in Annexure A. It’s about fundamentally recalibrating your organisation’s operating tempo around cyber risk — and ensuring that recalibration is documented, approved, and evidenced at every level.
Who Needs to Drive This — And It’s Not Just the CISO
Let me address something upfront that often causes compliance gaps in cyber security circulars. The instinct in most entities is to route these to the IT or information security team and consider the compliance obligation discharged. That approach will not hold up with IFSCA.
This circular explicitly requires Board-level governance of AI cyber risk. It requires policies to be updated. It requires risk assessments to be placed before the Board. It requires vendor obligations to be contractually embedded. These are governance and compliance functions, not just technical ones.
The Compliance Officer and Principle Officer need to own the governance trail. The CISO owns technical implementation. The Compliance Officer owns the evidence that the entity has met its regulatory obligations. Both roles need to be actively engaged — and the documentation needs to reflect that.
With that framing, let’s walk through what needs to happen, in the sequence that makes organisational sense.
First: Review and Revise Your Policies
This is where most compliance teams should begin, because the policies are the foundation on which everything else rests. An IFSCA inspector examining your compliance with this circular will start by looking at your governing documents — and if those documents predate the circular and make no reference to AI-driven threats, everything else you show them carries less weight.
The Cyber Security Policy is the primary document that needs revision. Your current policy was almost certainly written against a threat landscape that didn’t account for AI-assisted attacks. It needs to be updated to explicitly recognise Frontier AI models as a defined threat category, to reflect the hours-level response expectation for critical vulnerabilities, and to set out the governance framework for AI tool usage within the entity. This isn’t cosmetic editing — it’s a substantive policy revision.
The Patch Management Policy needs to be reviewed separately. If it currently prescribes response timelines of 72 hours or longer for critical vulnerabilities, those timelines need to be compressed. The circular’s expectation is that critical CVEs are treated as exploitable within hours of disclosure. Your policy needs to say that, and your procedures need to operationalise it.
The Third Party Risk Management Policy needs an AI-specific module. Currently, most TPRM frameworks assess vendors against standard security questionnaires. This circular introduces a specific additional obligation — critical vendors must demonstrate preparedness for AI-driven threats and accelerated exploit timelines. Your TPRM policy needs to reflect this as a formal requirement, not an ad hoc check.
The Incident Response Policy needs updating to include AI-attack scenarios specifically — automated credential attacks, rapid reconnaissance, AI-speed exploit attempts — and must set response SLAs calibrated to minutes for credential compromise scenarios, not hours.
The Software Development Lifecycle Policy needs a new mandatory control: AI-generated or AI-remediated code must undergo rigorous security testing and human review before production deployment. If your SDLC policy doesn’t currently address AI-generated code at all, this is a gap that needs closing now.
The AI Tools Usage Policy — if one doesn’t exist, it needs to be created. This circular effectively mandates that entities have a governance framework for their internal use of AI tools. The policy should cover: what constitutes an AI tool for these purposes, the authorisation process for adopting new AI tools, data classification requirements governing what information can be processed by which tools, and the review requirements for AI vendor data handling terms.
Every one of these policy revisions needs to go through your normal policy approval process — which, for an IFSCA-regulated entity, means Board approval or approval by a Board-delegated committee, depending on your governance framework. The revised policies need to be dated after June 4, 2026, and the approval needs to be documented in Board or committee minutes.
What must be documented: Version-controlled copies of each revised policy showing tracked changes from the previous version. Board or committee meeting minutes approving each revised policy, with the date of approval. A policy register showing the current effective version and approval date of each policy. Distribution records confirming that updated policies were communicated to relevant staff.
Second: Update Your Risk Assessment and Take It to the Board
Once your policies are being revised, the next step is the Cyber Security Risk Assessment — and this one has a specific Board approval requirement embedded in the circular.
The CSRA must be updated to include Frontier AI Model Risk as a formally assessed, named threat scenario. This means more than adding a paragraph. It means working through the standard risk assessment methodology — what is the threat, what is the likelihood for your specific entity, what is the potential impact given your technology environment and business model, what controls are currently in place, and what residual risk remains after those controls.
The depth of this assessment will depend on your entity’s nature and scale, but it needs to be genuine. Generic boilerplate about “AI presenting emerging risks to the financial sector” will not satisfy an inspector who asks you to walk them through your assessment methodology.
What the Compliance Officer needs to do here: Don’t leave the CSRA revision entirely with the IT team. Sit with the CISO and understand the AI threat in the context of your specific entity. If your entity runs a fund management operation with limited direct technology exposure, that shapes the risk assessment differently than if you’re running a trading platform or a banking unit with complex API-driven infrastructure. The assessment needs to reflect your reality.
Once updated, the CSRA must be presented to and approved by the Board. For MIIs, it additionally goes before the Standing Committee on Technology. The Principle Officer needs to own the scheduling of this — it should be a substantive agenda item at the next Board meeting, with adequate pre-reading circulated in advance so the Board can engage meaningfully rather than rubber-stamp.
The Board presentation itself should cover: the nature of the AI threat and why it represents a step-change from previous cyber risk, your entity’s specific exposure, the controls proposed or already implemented, identified gaps and remediation timelines, and the updated risk rating after controls.
After the presentation, the minutes need to reflect a real discussion. Inspectors can tell the difference between minutes that record genuine Board engagement and minutes that record a formality. The Board should ask questions, the minutes should capture them, and any actions arising should be recorded with owners and timelines.
What must be documented: The updated CSRA, dated after June 4, 2026, with Frontier AI Model Risk as a named scenario including full risk assessment methodology, likelihood and impact ratings, control mapping, and residual risk. Board meeting agenda showing the CSRA as a substantive item. Board presentation deck or paper circulated as pre-reading. Board meeting minutes recording the discussion, questions raised, Board acknowledgment, and any actions arising with owners and timelines. For MIIs, equivalent Standing Committee on Technology minutes. Evidence of the periodic review cycle — the circular requires this to be done regularly, so you need a documented schedule for future reviews.
Third: Build and Maintain the Operational Documentation
With governance in place — policies revised, Board informed and on record — the next layer is the operational documentation that proves your controls are actually working, not just written into policies.
Software Bill of Materials: The SBOM is a complete inventory of every software component in your production environment — proprietary code, open-source libraries, third-party dependencies. It needs to exist, be version-controlled, be updated on every deployment, and be connected to your vulnerability management process so that when a CVE is published, you can immediately check your exposure. The compliance team doesn’t build the SBOM — but the Compliance Officer needs to confirm it exists and understand how it feeds into the patch process.
Documents needed: The SBOM itself in version-controlled form, the SOP describing how it’s maintained and updated, and evidence of the link to your CVE monitoring process.
Patch Management Log: Your revised Patch Management Policy says critical CVEs are treated as exploitable within hours. This log is the evidence that your operations match your policy. For every critical vulnerability, the log should record: date and time of public disclosure, date and time of internal impact assessment completion, date and time of patch deployment, and SLA compliance status. Gaps between policy and log are exactly what inspectors look for.
Documents needed: The Patch Management Log, maintained contemporaneously, with all fields completed for every critical CVE from the date the policy came into effect.
MFA Coverage Register: A structured record of every internet-facing system and every privileged account, showing the MFA type currently deployed and any gaps with documented remediation timelines. Also needed alongside this: the MFA Enrolment and Device Change SOP, showing the identity verification steps required to register a new MFA device or modify an existing one.
Documents needed: The MFA Coverage Register with current status and gap remediation plan. The MFA Enrolment SOP. Evidence of periodic review.
API Inventory: A comprehensive register of every API your entity exposes or consumes, the applications that use each, access control settings, rate-limiting configurations, and the whitelist of authorised entities. Evidence of quarterly review and decommissioning of unused APIs.
Documents needed: The API Inventory Register with all fields completed. Review records showing quarterly verification and any APIs decommissioned.
SOC Detection Rules Documentation: Written confirmation that your SOC detection capabilities have been tuned to identify AI-speed attack patterns — automated reconnaissance, abnormally rapid scanning, access sequences exceeding human-plausible timelines. The CISO should be able to produce a document summarising these rules and their last review date.
Documents needed: SOC detection configuration summary or rules document, with last review date. Evidence of periodic review.
Tabletop Exercise and Drill Reports: IFSCA will want to see that you’ve tested your incident response capabilities, not just documented them. At minimum, conduct one tabletop exercise simulating an AI-driven attack scenario — including credential compromise with automated response — and document the outcome, gaps identified, and improvement actions taken.
Documents needed: Tabletop exercise or simulation reports, including scenario description, participants, findings, and action items with owners and timelines. Evidence of follow-up on action items.
Incident Response Records: For any actual security events, maintain records showing the timeline from detection to containment. For credential compromise specifically, the record must demonstrate minutes-level response. These records are both an operational tool and an inspection exhibit.
Documents needed: Incident response records for all events, with timestamps at each stage of the response.
Fourth: Extend Your Compliance Obligations to Your Vendors
The vendor requirement in this circular is, in my view, the most practically challenging — and the one where documentation gaps are most common. The circular makes clear that your critical service providers’ preparedness for AI-driven threats is your regulatory responsibility, not just their commercial obligation.
What the Compliance Officer needs to do: Begin by formally identifying your critical service providers under your TPRM framework, with documented criteria for that classification. Then issue a formal AI Cyber Risk Questionnaire to each — not a casual email, a structured questionnaire that asks specifically about their SBOM practices, patch timelines for critical vulnerabilities, AI threat assessment processes, and incident response capabilities. Get written responses. File them.
Then review your vendor contracts. If they don’t currently include obligations around AI cyber risk assessment and vulnerability remediation timelines, they need to. For new contracts, incorporate this as standard language. For existing critical vendor contracts, negotiate an addendum. The obligation being in writing matters — a verbal assurance from a vendor’s account manager has no inspection value.
Where vendor vulnerabilities are identified, your remediation tracker needs to show that you’re actively managing closure — with owner, timeline, and evidence of completion.
What must be documented: Critical Service Provider Register with classification criteria. AI Cyber Risk Questionnaires issued — keep copies of what you sent, not just responses received. Written vendor responses, dated and filed. For inadequate responses, evidence of follow-up or escalation. Vendor contract addenda incorporating AI risk obligations. Vendor Remediation Tracker with open items, timelines, and closure evidence.
Fifth: Govern Your Own Use of AI Tools — And Get Board Sign-Off
This is the dimension of the circular that most entities haven’t yet thought through systematically. The focus tends to be on defending against AI. But the circular equally addresses your own use of AI tools — and creates specific governance obligations around it.
Many teams across IFSC entities are already using AI tools without a formal governance framework: developer code assistants, AI-powered security scanners, cloud-based vulnerability analysis platforms, AI-assisted SIEM tools. The circular requires that every such tool be formally authorised, that you know what data it processes and where that data goes, and that you’ve reviewed the vendor’s data handling terms and concluded they’re adequate.
What the Compliance Officer needs to do: Commission an internal survey of every AI tool in use across the entity. The results will almost always be broader than leadership expects — tools adopted at team level without central IT approval are common. Once the inventory is complete, work with legal and the DPO to review vendor terms for every tool that processes sensitive or regulated data. Then take a consolidated AI Tool Governance framework — covering authorisation process, data classification requirements, vendor review criteria, and DLP controls — to the Board for approval as a policy matter.
This Board approval is important. The circular creates a specific obligation around AI tool governance that goes beyond routine IT procurement. Bringing it to the Board signals that the entity has understood the obligation and taken it seriously at the governance level.
What must be documented: An AI Tool Register listing every tool in use, the data types it processes, approval status, and authorisation date. Legal or DPO review records for each tool processing sensitive data, with a conclusion on adequacy of vendor terms. The Board-approved AI Tools Usage Policy, with minutes of approval. DLP configuration records. Where tools are found to be unapproved or inadequately governed, evidence of remediation — either formal authorisation obtained or tool decommissioned.
Also under this heading: the AI-Generated Code Review Log. Every instance of AI-generated or AI-remediated code going to production must have a record of the security testing conducted and the human sign-off obtained. The updated SDLC Policy, Board-approved, provides the framework. The log provides the evidence of compliance.
Pulling It Together: What the Inspection File Looks Like
An IFSCA inspection examining compliance with this circular will essentially be looking for a connected chain of evidence — not a pile of individual documents, but a coherent narrative that runs from Board-level governance through to operational execution.
The chain looks like this: the Board knew about the risk (CSRA presentation and minutes), the Board approved the response framework (revised policies and minutes of approval), management implemented the controls (SBOM, patch log, MFA register, API inventory, vendor questionnaires, AI tool register), the controls were tested (tabletop reports, drill records), and incidents were responded to as prescribed (incident response records with timestamps).
If any link in this chain is missing or undated, the inspection finding will reflect it. If the CSRA was updated but never taken to the Board, that’s a governance gap. If the policies were revised but the Board approval isn’t minuted, the revision carries less weight. If the patch log shows deployment timelines that don’t match the policy SLA, that’s an operational gap. If vendor questionnaires were issued but responses were never received or followed up, that’s a third-party risk gap.
The documentation needs to tell a consistent story. Build it that way — not as a retrospective exercise before an inspection, but as the natural output of running the compliance programme properly.
A Realistic Timeline
Week one: Initiate CSRA update, schedule Board meeting agenda item, conduct internal AI tool survey, identify critical vendors. These are governance and coordination actions that don’t require technical implementation.
Weeks two and three: Issue vendor AI risk questionnaires, begin contract review for critical vendors, circulate draft revised policies for internal review, confirm SBOM status with IT head, revise patch management SOP.
Thirty days: Board meeting to present updated CSRA and approve revised policies — Cyber Security Policy, Patch Management Policy, TPRM Policy, Incident Response Policy, SDLC Policy, AI Tools Usage Policy. All approvals minuted.
Thirty to sixty days: Technical controls implementation — MFA gap remediation, API inventory completion, SOC detection rule updates, DLP configurations, AI tool formal authorisations. All documented as implementation progresses.
Sixty days: Tabletop exercise on AI-attack scenario. Report produced and acted upon.
Ongoing: Patch log maintenance, vendor tracker updates, periodic CSRA review cycle, annual policy review cycle — all on documented schedules.
One Final Thought
The circular uses “shall” for hard obligations and “encouraged” for softer expectations. In IFSCA’s regulatory practice, “encouraged” calibrated against your entity’s size and risk profile is the operative standard — if you don’t implement something marked “encouraged,” you should have a documented, proportionality-based reason why not, and that reasoning should sit in your CSRA.
Effective immediately means effective immediately. The compliance standard exists from June 4, 2026, regardless of where your implementation currently stands. What matters is that you can show genuine, good-faith progress — documented, sequenced, and Board-owned.
The entities that handle IFSCA inspections well are not the ones with the thickest files. They’re the ones where the files tell a coherent, honest story of an organisation that understood the obligation, took it to the right level of governance, implemented it seriously, and documented it as they went.
Full circular here for reference: IFSCA-CSD/MSC/3/2026-DCS dated June 4, 2026
This guidance note is prepared for compliance, legal, and technology professionals at IFSCA-regulated entities in GIFT City. It is a practical reading companion to the circular and does not constitute legal advice. Implementation should be calibrated to your entity’s specific size, nature, scale, and risk profile.
