Legal
Data processing agreement
The article 28 agreement, published as a standard form so your DPO can read it before the first call.
Provisional: this document is not approved yet
Everything below is a draft. It becomes the studio's approved position only when every administrator has signed this exact version in the client area. Until then, read it as an accurate description of what we do and intend, not as a document anybody has signed off.
Written in-house, not reviewed by a lawyer, and no Maltese entity exists yet to be a party to it. What approval means here
This is the agreement article 28 of the GDPR requires between a controller and its processor, in the form the studio behind Getaway Gaming offers it to every operator. It is published here so that your data protection officer can read it before the first call, not in the third week of an integration.
It is incorporated by the supply agreement between the operator and the studio, which names this form by its version and its date, and it is version 1.0 of the form. A signed counterpart naming your entity is available on request; the text is this text.
This form is complete and it cannot be signed yet
There is no Maltese company to be the processor, so there is nobody to be a party to this agreement and no entity to put in the signature block. Everything below is the form we will offer and the commitments the system already honours. It is a document to review, not one to execute.
The day the entity exists, this page names it, because every document on this shelf reads the party from one file.
1. Who is who
You are the controller. You hold the player's account, you decided to offer the game, you set the purposes, and the privacy notice the player is owed is yours.
We are the processor. We receive an opaque reference your systems generate and we resolve, settle and record the round against it. We cannot identify a player, we have no route to your key, and we use none of it for any purpose of our own.
This is where the line is easy to get wrong, so it is drawn here: an opaque reference you can resolve back to an account is pseudonymised personal data, not anonymous data. We do not claim to be outside the Regulation on the strength of not holding the key, because that is not what the Regulation says.
What this agreement does NOT cover: the accounts your staff hold in our client area. We are the controller of those. We decide who may reach what, why and for how long, and the privacy notice for them is ours. Sweeping them into a processor agreement would be claiming an instruction nobody gave.
2. What we process, and what does not exist
Article 28(3) wants the subject matter, duration, nature, purpose, data types and categories of data subject in the contract. Here they are as a table.
| Article 28(3) asks for | And this is it |
|---|---|
| Subject matter | Operating the games the operator has licensed: resolving each round, settling it against the operator's wallet, and keeping the record a regulator can replay. |
| Nature and purpose | Collection, structuring, storage, retrieval and erasure, entirely automated, for the single purpose of providing the gaming service the operator asked for. No profiling, no automated decision-making about a person, and no use of any of it for our own purposes. |
| Duration | For the term of the supply agreement, plus the period the operator's own licence obliges them to keep gaming records. That period is theirs to set and ours to honour. |
| Categories of data subject | Players holding an account with the operator. Nobody else: we hold nothing about the operator's staff beyond the client-area accounts, for which we are the controller and which this agreement does not cover. |
| What | Why it exists | Who can identify a person from it |
|---|---|---|
| An opaque player reference | It is what joins the rounds of one session together and what a recall or a dispute is answered by. | only the operator can |
| The round: stake, outcome, win, currency, time, game, market, licence | It is the game. It is also the record GLI-19 §4.14 and the Dutch KS.09.15 require to be replayable. | only the operator can |
| The decisions a player made inside a round that waited for them | A cash-out, a card, a pot. An input to the maths, never a cache of its state. | only the operator can |
| The wallet calls that settled the round | Our own transaction id, the amount, the outcome and the idempotency key. A timeout is not a failure and has to be reconcilable. | only the operator can |
| The committed seed, the nonce and the number of draws | What makes a round from two years ago reproducible, and what a provably-fair check is run against. | not personal data |
The strongest measure is the data that was never collected
Adding a column for any of the following is a legal decision with a basis behind it, not a schema change, so none will appear by accident. There is no column anywhere in our systems for any of them:
name · email address · postal address · date of birth · national identifier · payment instrument · IP address · geolocation · device fingerprint · any special category of data under article 9
3. Instructions, and the one exception the law allows
We process only on your documented instructions, including about transfers. The supply agreement, this form and the technical interface you integrate against are those instructions in writing; anything outside them needs a new one from you.
The exception article 28(3)(a) allows: where Union or Member State law requires us to process something, we will. We will tell you which law before we do it, unless that law forbids us to tell you. For a licensed supplier this is not hypothetical. A gaming authority may compel production of a round record, and a laboratory examining a certified build will read the same record.
If we think an instruction of yours breaches the Regulation, we will say so and we will not carry it out silently.
4. Confidentiality
Everybody we let near any of it is under a written duty of confidence that survives their leaving. Access is a named role with an author, a stated reason and an end date rather than a password that circulates, and what a person actually read is written to an append-only log.
This is how the access control in our systems is built. It is queryable, and it exists because GLI-19 §2.8.9 asks a supplier to be able to answer who held which account and when.
5. Security (article 32)
What is actually built. The gaps are in the last row.
| Measure | What it is |
|---|---|
| No player identifiers at all | There is no column anywhere in the schema for a name, an email address, a postal address, a date of birth, a national identifier, a payment instrument, an IP address or a geolocation. The strongest security measure available is the data that was never collected. |
| Deny by default | Row level security is enabled on every table and denies unless a policy allows. A sensitive read goes through a gate that checks the permission FOR THAT OPERATOR and writes one log row per call. |
| Access is a grant, not a property | Seven roles over twenty-six permissions; every grant carries who gave it, why, from when and until when. A grant to an external account cannot outlive its window, and a self-grant is refused. |
| Four eyes on production | A write to a certified object in production needs a second, unexpired approval from somebody other than the author. |
| Encryption | TLS in transit everywhere; encryption at rest by the managed database. The round record is deliberately not encrypted at the application layer, because a regulator has to be able to replay it, and that is why it is kept. |
| Integrity of the build | The running release re-hashes itself against an approved manifest at boot and every twenty-four hours, and appends the result to a table that cannot be edited or deleted. |
| Reconstructibility | Every round can be reproduced from its committed seed and compared against what was recorded: the win, every event, and the number of draws consumed. |
| Separation of environments | Three databases. Production is written only by CI, from a tagged commit, with a second person's sign-off. |
| What is missing | No penetration test has been performed against any of this, by anybody. Backups have never been restored and there is no tested disaster recovery plan. Both are on the security page in the same words. |
6. Sub-processors
Annex III, published rather than sent on request.
You give general authorisation to the sub-processors listed below. We will tell you at least thirty days before adding or replacing one, and you may object on reasonable data protection grounds. If you do, we either find another route or you may terminate the affected service without penalty.
Every sub-processor is bound by written terms no weaker than these, and we remain fully liable to you for what they do. The list is published here rather than sent on request, so the copy you read is the current one.
| Sub-processor | What they do | Where | What they can reach | Since |
|---|---|---|---|---|
| Supabase Inc. | Managed PostgreSQL and authentication: the database our systems run on. | European Union region. The data does not leave the EEA in normal operation. | Yes, it is the database. Access by their staff is for support and is governed by their own data processing addendum. | 2026-08-11 |
7. Helping you answer a player
A request from a player goes to you, because only you can verify who they are. We cannot identify a player from what we hold and acting on a request we cannot verify would be the actual privacy failure.
We will help you answer one, by appropriate technical and organisational measures and taking into account what we actually hold: give us the reference and we can return, correct, restrict or erase what is attached to it, inside the limits in clause 9. For access and portability, the round history we hold is already exportable.
We will also assist with your obligations under articles 32 to 36 (security, breach notification, impact assessments and prior consultation) with the information we have.
8. Breach notification
Twenty-four hours, not seventy-two, and the reason is in the clause.
We notify you without undue delay, and in any case within twenty-four hours, of becoming aware of a personal data breach affecting your data. Twenty-four and not seventy-two, on purpose: seventy-two is YOUR deadline to the supervisory authority, and a processor who uses all of the controller's time leaves them none.
The notification carries what article 33(3) requires, as far as we know it: the nature of the breach, the categories and approximate number of records, the likely consequences and what we are doing about it. We keep sending what we learn rather than waiting until we know everything.
We do not notify a supervisory authority or a player on your behalf and will not do so without your instruction. That is the division article 33 sets, and it is yours to make the call.
9. The end of the service, and what survives it
The clause most supplier templates get wrong by promising more than the law allows.
At the end of the service you choose: we return your data in a machine-readable form, or we delete it. If you choose nothing within thirty days, we delete it.
What survives: where the law requires a record to be kept, it is kept, and in gaming the law does. Your own licence obliges you to retain gaming records, typically for five years; the round record has to stay replayable for a regulator or a laboratory under GLI-19 §4.14 and the equivalent in every market we serve. Promising you a clean deletion would be promising to put you in breach of your own licence.
So what is retained is the minimum that keeps the record whole (the round, its seed, its settlement), for the period your own obligation sets, under restricted access, used for nothing else, and deleted at the end of it. Anything beyond that minimum goes on the thirty-day clock with the rest.
10. Audit
We make available everything you need to demonstrate compliance with article 28, and we submit to audits. In practice that means three things that cost you nothing to use: the certification pack behind every build, the access control matrix as a query rather than as a spreadsheet, and this site, where the storage, the sub-processors and the third parties are published rather than described.
For an audit proper: thirty days' notice, during business hours, once a year unless a breach or a regulator's demand makes a further one necessary, at your cost, by you or by an auditor neither of us has a conflict with. We may require an auditor who is not a competitor of ours to sign a confidentiality undertaking. We will not refuse an audit a supervisory authority has ordered, on any ground, including that one.
11. International transfers
The data stays in the European Union. The database runs in an EU region and nothing in our systems ships it anywhere else.
If a transfer outside the EEA ever becomes necessary it happens only on your instruction and only under a transfer mechanism that is valid at the time: an adequacy decision, or Module Two (controller to processor) of the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914, incorporated into this agreement by reference and completed with the annexes below.
One footnote: our database vendor is a US-incorporated company hosting in the EU, and their support staff can in principle reach the systems they operate. That is covered by the Standard Contractual Clauses in their own data processing addendum, and it is why they are named in the sub-processor list rather than treated as infrastructure.
12. What you undertake
Short, and the second and third are the ones that actually get breached.
You warrant that you have a lawful basis for the processing you instruct, that the privacy notice you give your players covers a supplier operating the game, and that your instructions comply with the Regulation.
You undertake not to send us a player reference that is itself personal data, such as an email address, a username or an account number that appears on a statement. The field is specified as an opaque string for a reason, and a reference that carries meaning outside your own records moves data into our systems that neither of us wants here.
You undertake not to send us any special category data under article 9 or any criminal offence data under article 10, in any field, including free-text ones. There is nowhere for it to go and no basis for us to hold it.
13. Liability, precedence and term
Each of us is liable for its own breach of this agreement and of the Regulation. Nothing here limits a data subject's rights under article 82, and nothing here limits either party's liability in a way the law does not allow.
Between us, the caps and the indemnities in the supply agreement apply to this one, except where that would leave a liability under article 82 or a regulatory fine uncovered. In that case the cap does not reach it.
Where this agreement and the supply agreement disagree about the processing of personal data, this one wins. Where this agreement and the Standard Contractual Clauses disagree, the Clauses win.
This agreement runs for as long as we process personal data for you, and the clauses that are meant to survive it (confidentiality, retention, audit) do. It is governed by the laws of Malta and disputes go to the courts of Malta, except where the Standard Contractual Clauses require otherwise, in which case they do.
Executing it
Ask and you get this text as a signable counterpart with your entity in it, plus the certification pack for the builds you would run and the access matrix behind clause 5. Write to hello@getawaygaming.com.
Provisional until every administrator has approved this version. Written in-house, not reviewed by a lawyer, and no Maltese entity exists yet to be a party to it.