MGA System Audit Requirements: What Your Tech Stack Must Document

What the MGA Compliance Audit Actually Covers

If you hold an MGA licence, the document that defines what your auditor is going to do is the Compliance Audit Manual (MGA/G/001, August 2018, v1). It tells appointed auditors which procedures are mandatory and which they have to design themselves based on your particular setup. The manual is clear that the listed procedures aren’t optional, and auditors are expected to go beyond them where the risk picture demands it.

What’s easy to miss is how much ground a single audit covers. The manual pulls together obligations from the Gaming Act, the Authorisations Regulations, the Compliance and Enforcement Regulations, the Player Protection Regulations, the Authorisations and Compliance Directive, the Player Protection Directive, and the Prevention of Money Laundering Act. So a single review touches corporate governance, AML, player protection, and your tech stack at the same time. Operators who treat these as separate workstreams tend to find audit prep more painful than it needs to be, because the auditor doesn’t see them as separate either.

There’s also been movement since 2018 that the manual itself doesn’t reflect. In 2025 the MGA issued a clarification on how System Audits, System Reviews, and Compliance Audits are run in practice, taking on board feedback from the External Audit Service Providers and pushing the process toward something more risk-aligned and less mechanical. The 2026 Regulatory Oversight: Supervisory Engagement Efforts publication points the same way: continuous engagement, targeted testing, and supervision calibrated to your actual risk profile rather than a uniform checklist run once a year.

Practically, that means a control matrix or audit-readiness plan built only off the 2018 manual will be technically defensible but operationally behind. You want to read the manual alongside the 2025 clarification and the 2026 supervisory document, not in isolation.

The Four Things the MGA Wants From Your Tech Stack

The technical side is governed by a separate document: the MGA’s Technical Infrastructure guidelines for Remote Gaming (December 2015, v1), which still sits on the MGA’s Guidance Notes page. It’s older than the current Gaming Act regime, but it’s still live, and auditors still test against it.

It boils down to four regulatory objectives:

Integrity and security means your regulatory data, transaction logs, and gaming functionality have to stay intact. Always. Availability, traceability and accessibility means your gaming and financial logs have to be reachable at all times, including by the MGA. Privacy and confidentiality covers personal, gaming, and financial data under the usual data protection rules. And accountability is the one a lot of operators underestimate: the MGA puts the responsibility for hitting all of the above squarely on the licensee, full stop.

“The responsibility for the attainment of the established and desired standards on these regulatory principles will remain that of the licensee at all times.”

That last principle does a lot of work. If you’re on a white-label B2C platform, integrated with a B2B gaming supplier, or running through a managed SOC, none of that transfers your regulatory accountability to anyone else. The auditor is going to look at your controls and your documentation, not your supplier’s brochure.

Hosting: Where Your Kit Actually Lives

You’re required to give the MGA a network schematic showing every piece of hardware and every virtual machine in play, with internal IPs, plus the geographic locations and addresses of everywhere your gaming systems, control systems, and regulatory data are hosted. If you’re on cloud, you owe them a complete list of every region the infrastructure could deploy into, not just where it currently is.

On location: the architecture has to sit in Malta, an EEA member state, or a third-country jurisdiction the MGA is satisfied meets the same principles. Third-country approvals happen case by case, not by category. So if you’ve quietly migrated to a multi-region cloud setup since your original licensing, and you haven’t formally cleared each new region, that’s an open compliance gap waiting for an auditor to find it.

This is one of the more reliable findings in MGA audits, by the way. The auditor pulls up the network schematic on file with the MGA, then walks through what’s actually in production, and the two don’t match. Usually because the operator scaled, switched a region, or added a CDN edge without telling anyone.

Critical Components

The MGA singles out a specific set of components as “critical,” meaning they carry heightened regulatory or integrity risk. They are: random number generators, jackpot servers, player database servers, financial database servers, gaming database servers, and anything else the MGA decides is critical for your particular setup. Hosting expectations land hardest on these. The auditor will trace each one through your network schematic to confirm where it actually runs.

ISO 27001, and the Slightly Awkward Version Question

Hosting locations have to operate under an Information Security Management System throughout the licence term, conforming to ISO/IEC 27001:2013. Cloud service providers should additionally be guided by ISO/IEC 27002:2013, the code of practice for information security management. Worth knowing that ISO has since published 2022 editions of both standards, but the MGA’s guidance hasn’t been updated to reflect the new editions. In practice, talk to your audit service provider about which edition they’re testing against. You don’t want to find out at the audit that your fresh 27001:2022 certificate isn’t what they wanted to see, or vice versa.

If you process credit card or other payment data, the MGA wants PCI DSS Level 1 across your data environment. That doesn’t change because you outsourced payments to a PSP. The licensee still has to demonstrate the standard is met end to end.

Practical note: hosting locations need an ISMS conforming to ISO/IEC 27001:2013 (or, where your auditor accepts it, the 2022 edition) for the full term of the licence. Keep current certification evidence for every data centre and cloud location, and make sure it’s actually accessible on the day of the audit. Lapsed certs and gaps for secondary hosting locations are common findings, and they’re entirely avoidable.

The trick is not waiting until audit time to spot ISO gaps. Certificates expire, cloud regions change, third-party data centres occasionally lose certification themselves. A standing process that tracks renewal dates against your licence obligations is the version of this that doesn’t bite you.

Critical Components in the Cloud

If you want to put critical components on cloud, the MGA wants more from you. You need to run a risk assessment using the framework in ISO 31000:2009 and submit it, along with how you’re going to manage and mitigate the cloud-specific risks listed in the guidelines (loss of governance, data leakage, isolation failure, multi-tenancy issues, and so on).

The default expectation is that critical components live on a private cloud, not shared with other tenants. Virtual private cloud (logical segregation inside a shared environment) can be allowed, but only when the MGA is satisfied the integrity and security of the critical components isn’t at risk. Standard public cloud or shared-tenant configurations for critical components will get scrutiny, and you’ll typically need extra technical and contractual evidence to make the case.

Logs: Available Doesn’t Mean “Stored Somewhere”

The accessibility principle means gaming and financial transaction logs have to be reachable at all times. This isn’t a retention question. The auditor will test whether you can actually pull the logs at the moment of the review, not whether they exist on a backup tape in a colo somewhere.

Logging gaps come up a lot. The usual culprits: log rotation policies that prune records before the retention window closes, centralised logging that quietly excludes certain game server instances, or log formats that exist but aren’t queryable in a way that satisfies a regulatory data request.

Auditors don’t look at logs in isolation either. They cross-reference log data against player accounts, bonus award histories, and financial reporting. When the logs say one thing and the financial statements say another, that gets treated as an integrity failure, not a paperwork issue.

“Gaming and financial transaction logs must be accessible at all times. In this area, and with data being hosted on servers and in data centres outside Malta, including cloud environments, there may be an issue of jurisdiction of same data that may affect accessibility by the MGA for regulatory purposes.”

If your infrastructure sits offshore, the MGA does offer a mitigation route: real-time replication of regulatory data to a live replication server in Malta. To use it, your application needs to spell out the replication server’s physical location, rack number, and IP addresses; the connectivity and security protocols for moving data; what data is replicated and any time lag between live and replication; and a documented procedure that lets MGA officials walk in (or log in) and inspect the replication server on demand. The MGA can also adjust what has to be replicated based on your risk profile.

Practical test: can you respond to a simulated regulatory data request inside a defined SLA, and can you document that you did? If yes, you’re in decent shape. If you’ve never tried, that’s the next thing to fix.

Change Control

The other reliable technical finding is change-control weakness. The Technical Infrastructure principles, combined with the accountability principle, mean every material change to your gaming systems, infrastructure, or regulatory data flows has to be documented, authorised, and traceable. The auditor wants to see that the change was approved before it went live, that someone assessed the impact on regulatory data integrity, and that the post-change state was verified.

The patterns that fail an audit: no formal change advisory process for cloud infrastructure updates, emergency changes that never got documented after the fact, B2B supplier version changes the licensee can’t show were assessed for regulatory impact, and configuration drift where the live environment no longer matches the approved schematic.

The Compliance Audit Manual tells auditors to design extra procedures wherever they spot risk. So one undocumented change isn’t just one finding. An auditor who sees one gap will start pulling the thread on the broader change register, and you’ll find the scope of the review expanding in real time.

Evidence Pack: Have These Ready

There’s no official evidence checklist, but the manual’s mandatory procedures map to a fairly predictable set of documents. Roughly:

Network and architecture documentation: current schematic, confirmed hosting locations, and evidence those line up with what the MGA has on file. Anything that’s changed since the last audit should have a paper trail.

Information security certification: current ISO/IEC 27001:2013 certificates (or 27001:2022 where your auditor accepts it) for every hosting location, PCI DSS Level 1 evidence wherever payment data is in scope, ISO/IEC 27002:2013 (or 2022) conformance for cloud providers, and your ISO 31000-based risk assessment for any critical components running on cloud.

Transaction and gaming log access: demonstrable on demand. You should be able to pull a defined set of transaction records for a given player or time window without faffing about. Log retention configs, backup schedules, and retention periods should all be written down. If you’re using replication to Malta to meet the accessibility principle, that documentation needs to be current too.

Change management records: every material change since the previous review, with the authorisation trail, impact assessment, and post-implementation verification.

AML and KYC documentation: covered separately under the AML review, but bear in mind the system-side evidence (automated monitoring alerts, transaction flagging logs, screening records) overlaps with the technical scope. Don’t assume the AML evidence and the technical evidence live in different worlds.

This is general guidance. If your setup involves multi-jurisdictional infrastructure or cross-border data flows, get jurisdiction-specific legal advice on top.

When You Don’t Own the Infrastructure

A lot of MGA licensees aren’t running their own platform. White-label B2C deals and integrated B2B suppliers are everywhere. The MGA’s position on this is short: accountability for hitting the regulatory standards stays with the licensee. The audit doesn’t get redirected to the platform provider.

What that means in practice is your contracts with B2B suppliers need to give you actual access rights. ISO certifications, pen test reports, change logs, infrastructure documentation, all of it. If your contract doesn’t entitle you to these things, you’re going to find yourself unable to hand the auditor evidence you don’t control. And the auditor isn’t going to accept “my supplier has it” as a substitute.

Auditors do adjust their approach for B2B structures, but adjusting isn’t the same as reducing. If anything, a B2B setup adds an extra evidence burden around supplier oversight, because now you need to show you’re managing the supplier as well as the operation.

How the MGA Actually Prioritises Now

The MGA isn’t running compliance as a uniform checklist applied identically to every licensee anymore. The model is risk-based supervision: how much regulatory attention you get is calibrated to your actual risk profile. Player fund exposure, transaction volumes, product mix, geographic reach, outsourcing structure, history with the MGA. All of it feeds into how often and how deeply you get looked at. Two operators holding the same licence type can end up with materially different levels of engagement.

The substantive shift is that compliance isn’t being assessed only on whether you have controls. It’s being assessed on whether your controls are effective for your risk footprint. Higher-risk operators should expect more frequent data requests, deeper dives on transaction monitoring, broader testing of AML and player protection, and more attention on how you govern your third-party providers. Lower-risk operators with clean track records and solid control environments may see a lighter touch, but the readiness expectation doesn’t change. The MGA is effectively asking: can you identify, manage, and evidence your own risks before we have to step in?

That’s the real test now.

Key Resources

MGA Compliance Audit Manual (MGA/G/001, August 2018, v1), Malta Gaming Authority. The primary reference for audit scope and mandatory procedures applicable to all compliance reviews conducted on behalf of the MGA.

MGA Technical Infrastructure Requirements for Remote Gaming (December 2015, v1), Malta Gaming Authority. Sets out the four regulatory principles governing technical infrastructure: integrity and security, availability and traceability, privacy and confidentiality, and accountability. Includes hosting architecture, information security, and data jurisdiction requirements.

Gaming Act (Cap. 583 of the Laws of Malta), Parliament of Malta. Primary legislation underpinning all MGA licensing and compliance obligations.

Gaming Compliance and Enforcement Regulations (S.L. 583.06), Malta. Subsidiary legislation governing enforcement powers and the compliance framework within which audits operate.