ISO 27001 for CySEC-regulated FX brokers: what the auditor checks first
A CySEC-regulated FX broker is not a standard SaaS company. Here is what an ISO 27001 auditor looks for first - and where most brokers fail Stage 1.
By Kellwick Team · July 13, 2026 · 6 min read
A CySEC-regulated FX broker faces an audit environment that most generic ISO 27001 guides simply do not address. You have trading infrastructure running 24 hours a day, institutional counterparties who demand evidence of your controls before onboarding, and a regulator that expects you to map your information security programme onto CIF authorisation obligations. When an auditor walks into Stage 1, they are not looking for a beautifully formatted policy folder. They are looking for a management system that is visibly alive and anchored to the actual risks of running a retail and institutional brokerage.
This post covers what a CySEC-licensed broker should expect from an ISO 27001 Stage 1 audit, and where the gaps tend to show up before anyone has sat down with the external auditor.
Why a broker is not a standard SaaS company
Most ISO 27001 implementation guides are written with a software-as-a-service company in mind: a SaaS product, a cloud environment, a small engineering team, and a handful of B2B customers asking for a compliance certificate.
An FX broker's information assets are structurally different. Client money is held in segregated accounts governed by CIF rules. Trade execution data flows across MT4 or MT5 infrastructure that was not designed with ISO 27001 evidence in mind. KYC documentation is processed under AML/CFT obligations that create their own data handling rules. Introducing broker (IB) agreements mean that a third party has contractual access to client information and lead data. PSP connections - card processors, e-wallets, crypto rails - multiply your third-party risk surface considerably.
When an auditor scopes the ISMS, every one of those asset classes must appear somewhere in the risk register and in the Statement of Applicability. If the scope document says "our internal IT systems" and makes no reference to the trading platform, the PSP integrations, or the IB network, Stage 1 will not proceed smoothly.
The scope document: where most brokers stall
Scope is the single most common early failure point. A broker's ISMS scope needs to draw a defensible boundary around:
- Client-facing systems (web trading platform, mobile apps, client portal)
- Back-office infrastructure (MT4/MT5 manager, bridge software, liquidity provider connections)
- Client data stores (CRM, KYC repository, AML screening logs)
- Key third parties in scope (PSPs, technology providers, IB portal access)
- Physical locations and any relevant outsourced functions
A scope that simply says "Head office IT systems in Limassol" without naming the trading infrastructure will raise an immediate observation. Auditors trained in financial services environments know that the highest-risk data - real-time P&L, withdrawal requests, client identity documents - does not live inside generic "IT systems." It lives in purpose-built broker infrastructure.
The scope document also needs to reference any cloud hosting. If MT5 server instances run on a third-party hosted environment, that provider needs to appear in Annex A controls around supplier relationships (A.5.19 to A.5.23 under ISO 27001:2022).
Management-system evidence: what the auditor reads first
At Stage 1, the auditor is checking whether the management system exists as a real operating entity, not just a set of documents. The first things they typically read:
Information security policy - signed by a named director, not a compliance officer acting as a proxy. The policy should reference the CIF's specific risk context, not generic corporate language copied from a template.
Risk register - an active document with a treatment plan, owners, and evidence of review. A risk register that was created at implementation and never touched since is a Stage 1 finding. For a broker, risks around system availability during high-volatility trading periods, PSP credential exposure, and IB data access should be visible and treated.
Management review minutes - covering information security performance, incidents, audit findings, and changes in risk context. If the last management review happened 14 months ago, that is a nonconformity against clause 9.3.
Internal audit records - completed internal audits with findings, not just a schedule. Brokers in their first certification cycle often have the schedule but nothing to show that the audits actually ran.
Trading platform controls: MT4/MT5 and the bridge
The trading platform is where the most technically specific audit questions arise. An auditor familiar with financial services environments will ask:
- Who holds MT4/MT5 Manager credentials? How are those accounts provisioned, and is there a joiners/movers/leavers process for platform admin access?
- Are MT5 admin password changes logged? Is there a record of when credentials were last rotated?
- Is the bridge (the software connecting the platform to liquidity providers) covered by the change management process?
- What monitoring is in place for abnormal position activity or access to reporting functions outside trading hours?
The common pattern in practice is that trading platform administration is treated as a purely operational matter, owned by the dealing desk or a technical operations team, and entirely outside the information security management system. The ISO 27001 auditor will not accept that separation. Platform admin access is a privileged access control question and must be evidenced accordingly.
PSP and KYC integrations: third-party risk in practice
A retail FX broker typically connects to multiple PSPs across different geographies, each with its own API credentials, webhook endpoints, and reconciliation data flows. Under ISO 27001:2022 Annex A.5.19 and A.5.20, supplier information security must be governed by written agreements and subject to periodic review.
In practice, the audit gaps here are:
- No written information security terms in PSP contracts (reliance on the PSP's standard T&Cs)
- Shared API credentials across multiple internal users with no individual accountability
- No record of having reviewed PSP security posture since onboarding
- KYC document stores with access lists that have never been formally reviewed
The CySEC regulatory expectation around client data protection reinforces ISO 27001 here. If you have already carried out a data protection impact assessment under GDPR, that work can be referenced, but it does not replace the supplier review obligation under the standard.
Withdrawal and client-money controls
Auditors occasionally probe withdrawal processing because it is a high-value, high-risk data flow. The question is not whether your withdrawal process is compliant with CySEC rules - that is a regulatory matter - but whether the information security controls around that process are documented and evidenced.
That means: who has access to initiate and approve withdrawals in the back office, is that access periodically reviewed, are there logs of withdrawal instruction changes, and is there a record of what happens when a withdrawal request is flagged as anomalous. A four-eyes approval process that everyone follows in practice but that exists nowhere in writing is an uncontrolled control.
Introducing broker access: the overlooked scope item
IB partners often have access to a client portal, a CRM section, or a custom reporting environment. That access represents a third-party connection to client data and must appear in the ISMS scope. The relevant questions are:
- What data can an IB access, and is that access limited to their own clients?
- How is IB portal access provisioned and deprovisioned when an IB relationship ends?
- Is there a written agreement with information security obligations?
Brokers regularly omit IB portal access from their third-party supplier inventory. This is a consistent audit observation when it comes to light.
Where Kellwick fits
Kellwick works with CySEC-regulated brokers to find the gaps that block Stage 1 before an external auditor does. That means scoping the ISMS around the real asset landscape - trading infrastructure, PSP connections, IB access, and KYC flows - not a generic IT boundary. If you are preparing for certification or want an independent view of where you stand, see what the FX broker readiness review covers.
Need a second pair of eyes before the auditor does?
A readiness review shows exactly where your ISMS stands - and what to fix first - while there is still time to act on it.