Privacy policy

1.1 This instrument is issued by CLOUDRIDGE TECHNOLOGIES PTY LTD, ACN 696 705 478, ABN 69 696 705 478, a proprietary company limited by shares whose operations are conducted from the Gold Coast, Queensland. It is the policy required by Australian Privacy Principle 1.3 and is supplied at no charge in a form that can be read, printed or saved without an account.

1.2 The clauses set the rules. The schedules carry the particulars. Where a clause and a schedule conflict, the schedule prevails for the record type it names.

2.1 The Company handles personal information in two capacities. Which capacity applies determines who is entitled to decide what happens to a record, and therefore where a request has to be sent. Every later clause is drafted against this split.

2.2 In the first capacity the Company is an APP entity handling its own business records. It settles the purpose of collection, it bears the obligations, and an individual may enforce them against it.

2.3 In the second capacity the Company stores and returns records on a Customer's documented instruction. The Customer settles what is collected, from whom, and for what. The Company has no purpose of its own for those records. It builds no product on them, derives no statistics from them, sells nothing computed from them, and does not use them to train a model. That restriction is written into every Customer agreement and is not waivable by the Company alone.

2.4 A Player who wants a save deleted, a score removed or a copy of what is held must ask the studio whose game produced the record. The Company will not act on such a request unaided, because doing so would mean overriding the instruction of the entity that is accountable to that Player. Clause 16.4 explains what happens when a Player writes to the Company by mistake.

3.1 The Act governs this instrument, together with the thirteen Australian Privacy Principles set out in Schedule 1 to it. Queensland law governs any dispute about the instrument itself.

3.2 APP 1.2 obliges an APP entity to put in place practices, procedures and systems that make compliance possible and that allow enquiries and complaints to be dealt with. APP 1.3 obliges it to keep a clearly expressed and current policy. APP 1.4 lists what that policy has to contain. The mapping below exists so that the list can be audited against this document rather than taken on trust.

4.1 Section 6D of the Act puts a business with annual turnover of three million dollars or less outside the definition of an organisation, so that the APPs do not bind it, unless one of the carve-outs in that section applies.

4.2 The Company's turnover sits below that figure. It does not run the argument. This instrument is written on the footing that the APPs bind the Company in full, and each Customer agreement repeats the obligations as contractual terms, so that a Customer's remedy does not depend on how the statutory question is resolved.

4.3 Two carve-outs are worth naming because a backend supplier sits close to them. Section 6D(4)(c) removes the exclusion from an operator that discloses personal information about an individual to someone else for a benefit, service or advantage. Section 6D(4)(d) removes it from an operator that provides a benefit, service or advantage in order to collect personal information about an individual from someone else. Whether a paid data-holding service falls within either paragraph is arguable in both directions, and the Company treats the question as settled against itself.

5.1 The Company collects only the categories listed in Schedule A and only by the means that schedule records against each category. APP 3.2 permits collection that is reasonably necessary for an entity's functions or activities; every row in Schedule A is justified on that basis and nothing is collected because it might one day be useful.

5.2 Collection is from the individual concerned wherever that is reasonable and practicable, as APP 3.6 requires. Where a Customer supplies a colleague's work contact details, the Company treats the individual named as entitled to everything in clause 14 notwithstanding that the details arrived through an employer.

5.3 The Company does not collect sensitive information as section 6(1) defines it. That excludes health information, racial or ethnic origin, political opinions or associations, religious beliefs, philosophical beliefs, trade union membership, sexual orientation or practices, criminal record, genetic information and biometric templates. None of it is needed to run a save store or a scoreboard. Please do not put any of it in an email to the Company; if it arrives, clause 5.5 applies.

5.4 Contact lists are not bought. Websites are not scraped for addresses. Third-party enrichment services are not used to add attributes to a record the Company holds.

5.5 APP 4 governs personal information the Company receives without having solicited it. On receipt, the Company decides whether the information could lawfully have been collected under APP 3. If it could not, and neither a law nor a court order requires the Company to keep it, the information is destroyed or de-identified as soon as that is lawful and reasonable. Where an unsolicited item arrives inside correspondence that must be retained for another reason, the item is severed rather than the whole message retained.

6.1 APP 5 requires notification of specified matters at or before collection, or as soon as practicable afterwards. For information collected through this website or by email to the published address, this instrument is that notification, and the matters APP 5.2 lists are covered by clauses 1, 8, 10, 14 and 16 together with Schedules A and B.

6.2 Where a Service is running, the APP 5 notification owed to a Player is owed by the Customer, not by the Company. The Company has no channel to a Player, no screen inside the game, and no address to write to. A Customer agreement obliges the Customer to give that notification and to have a lawful basis for the collection before any record reaches the Company.

6.3 The Company will supply, at no charge and in writing, whatever technical particulars a Customer needs in order to make its own notification accurate. Schedule C is drafted so that most of those particulars can simply be quoted.

7.1 APP 2 gives an individual the option of not identifying themselves, or of using a pseudonym, unless that is impracticable or a law requires identification. This website asks nobody who they are. There is no account, no sign-in, no form and no identifier assigned to a reader.

7.2 Correspondence by email necessarily carries the address it was sent from. A pseudonymous address is accepted for a technical question and will be answered. An address that cannot be tied to a legal entity is not enough to issue a quotation or sign an agreement, because the Company has to know who it is contracting with.

7.3 Player records are keyed by an identifier the Customer allocates and which is meaningless outside the Customer's own systems. The following never reach the Company through a Service integration: a Player's name, email address, postal address, telephone number, date of birth, payment details, precise location, and the advertising identifiers issued by mobile platforms, being Apple's identifier for advertisers and the Android advertising ID. The integration provides no field for any of them.

7.4 A pseudonymous identifier is still personal information under the Act when it can be linked back to an individual by the entity holding the link. The Customer holds that link. The Company does not, and does not want it, but the Company does not claim on that basis that the records fall outside the Act.

8.1 APP 6.1 permits use or disclosure for the primary purpose of collection. The primary purpose for each category is stated in Schedule A and is not restated in general terms here, so that there is only one place to check.

8.2 A secondary use occurs only where APP 6.2 allows it. In practice the Company relies on two of those paragraphs and no others: a use the individual would reasonably expect and that is related to the primary purpose, and a use required or authorised by an Australian law or a court or tribunal order.

8.3 Personal information is not sold, rented, bartered or licensed. It is not disclosed to any other entity for that entity's marketing. It is not contributed to an advertising exchange, a data cooperative, an identity graph or an industry benchmark.

8.4 Where a subpoena, notice to produce or statutory demand seeks records the Company holds for a Customer, the Company will tell that Customer before producing anything, unless the instrument or a law forbids the disclosure. Where the Customer decides to resist, the Company will not obstruct it and will not produce the records earlier than the law requires.

8.5 A change of control of the Company does not by itself authorise a new use. If the business or its assets change hands, records pass under the same restrictions, and each Customer is told before its records move.

9.1 APP 7 restricts direct marketing by an organisation. The Company keeps no marketing list, runs no campaign tooling, publishes no newsletter and operates no tracking pixel in any message it sends.

9.2 A commercial electronic message goes only to a person who asked for one. Under the Spam Act 2003 (Cth) such a message must identify its sender and carry a working unsubscribe facility, and a withdrawal of consent must be given effect within five working days. The Company will act on a withdrawal on the day it is read.

9.3 An answer to an enquiry is not a marketing message and is not treated as consent to receive one later.

9.4 No telemarketing is conducted, so the Do Not Call Register Act 2006 (Cth) has nothing to bite on. The Company publishes no telephone number and makes no unsolicited calls.

9.5 Player records are never used for marketing by the Company in any circumstances. That is a structural restriction rather than a policy setting: Schedule C leaves the Company with no field it could market to.

10.1 Schedule B names, by function and by country, every recipient outside Australia that receives personal information in the course of the Company's activities. It is kept current and is the operative answer to the question APP 1.4 asks about overseas recipients.

10.2 APP 8.1 requires reasonable steps, before an overseas disclosure, to ensure that the recipient does not breach the APPs in relation to the information. Where the Company selects a supplier, those steps are contractual: the supplier's terms must bind it to handle the information consistently with the APPs and must permit deletion on the Company's instruction.

10.3 Section 16C is the reason this clause is short and the schedule is specific. Where an APP entity discloses personal information to an overseas recipient under APP 8.1, an act of that recipient which would breach the APPs is deemed an act of the disclosing entity. Accountability does not travel with the data. It stays here.

10.4 The design consequence is that the primary copy of Customer and Player records is to sit in an Australian region of the infrastructure provider selected for production, so that the accountability in section 16C attaches to the smallest possible surface. Where a component genuinely cannot be run onshore, Schedule B names the country before the component is used, not afterwards.

10.5 The Company does not use the informed-consent route in APP 8.2(b) as a general mechanism for moving records offshore. Consent obtained by a checkbox at sign-up is a poor substitute for a contract with the recipient, and it shifts a risk onto the individual who has the least ability to price it.

10.6 At the effective date the only routine overseas element is the delivery of this website, described in rows 1 and 2 of Schedule B. No Player record has left Australia because no Player record exists.

11.1 APP 9 restricts an organisation from adopting a government related identifier as its own identifier for an individual, and from using or disclosing one except in narrow circumstances.

11.2 The Company adopts none. Tax file numbers, Medicare numbers, driver licence numbers, passport numbers and Centrelink reference numbers are not collected, not requested and not accepted. No Company record is keyed to any of them.

11.3 A Customer's Australian Business Number is recorded for invoicing and tax purposes. An ABN held by a company is not personal information about an individual; an ABN held by a sole trader can be. Where the second case applies the ABN is treated as personal information, appears in Schedule A, and is used for invoicing and nothing else.

12.1 APP 10 requires reasonable steps to ensure that personal information collected is accurate, current and complete, and that information used or disclosed is accurate, current, complete and relevant. The Company's controller-side records are almost entirely things a person typed and sent, so the effective step is a short retention period and a correction route, both of which appear in Schedule A and clause 14.

12.2 APP 11.1 requires reasonable steps to protect information from misuse, interference, loss, unauthorised access, modification and disclosure. What that means at this size, stated without decoration:

• This site is static. It runs no server-side application, holds no database, accepts no submitted input and executes no third-party script, so the common injection and takeover routes have nothing to attack.
• Response headers deny framing, forbid content-type sniffing, restrict script and style sources to this origin, block plugin content, and prevent the full URL from travelling to another origin as a referrer.
• Transport is encrypted for every page and every asset.
• Correspondence sits in one mailbox. Credentials for it are held by officers of the Company and by nobody else. There is no shared login, no support desk seat, and no contractor with standing access.
• Player records held on a Customer's instruction are kept in the environment recorded for that Service in Schedule C, separated by Customer, and reached only through the access route named in that Customer's agreement.

12.3 APP 11.2 requires destruction or de-identification once information is no longer needed for any purpose for which it may be used or disclosed and no law requires it to be kept. Clause 13 and the retention column of Schedule A give effect to that.

13.1 Each row of Schedule A carries its own retention period. Where a period is expressed as a number of years it is driven by a statutory record-keeping obligation or by a limitation period, and the row says which.

13.2 Records the Company holds on instruction are retained for as long as the Customer instructs and no longer. On a written instruction the Company will effect deletion of data within the period stated for that Service in Schedule C.

13.3 On termination of a Customer agreement, the Customer has thirty days to run the export described in Schedule C. At the end of that window the Company destroys the records unless the Customer has instructed otherwise in writing or a law requires retention.

13.4 Deletion propagates to backups on the backup rotation rather than instantly. Schedule C states the maximum lag for each Service. A restored backup is filtered against the deletion log before it is brought into service, so a restore cannot resurrect a deleted record.

13.5 An individual may ask the Company to delete your data held about them under Schedule A Part 1. The Company will do so unless a tax, corporate or limitation obligation requires the record to be kept, in which case it will say which obligation applies, for how long, and will restrict the record to that purpose in the meantime.

13.6 Destruction means the record is removed from live systems and from the backup set on the rotation in 13.4. Where a record cannot be destroyed because it is embedded in an accounting ledger, it is de-identified to the extent the ledger permits.

14.1 APP 12 entitles an individual to access personal information the Company holds about them as an APP entity. Send the request to the address in clause 21 from the address the Company already holds, or give some other way of confirming identity that does not require sending a document more sensitive than the record being sought.

14.2 The Company responds within thirty days. Nothing is charged for making a request, and at present nothing is charged for giving access either; the volume does not justify a fee and one will not be introduced without amending this instrument first.

14.3 Access may be refused only on a ground in APP 12.3. If it is refused, the Company gives written reasons, identifies the ground, and sets out the complaint route in clause 16, as APP 12.9 requires.

14.4 APP 13 requires correction where information is inaccurate, out of date, incomplete, irrelevant or misleading, whether the Company notices it or an individual asks. Say what is wrong and what the record should say instead. If the Company declines to correct, APP 13.4 entitles the individual to have a statement of the disputed point associated with the record, and the Company will attach it so that anyone reading the record reads the objection with it.

14.5 Access and correction requests about Schedule A Part 2 records are directed to the Customer. The Company acts on the Customer's instruction within the period stated for that Service in Schedule C, and gives the Customer whatever technical assistance the request needs.

15.1 Part IIIC of the Act contains the Notifiable Data Breaches scheme. It applies to the Company and its operation is not qualified by anything in a Customer agreement.

15.2 Where there are reasonable grounds to suspect an eligible data breach, section 26WH requires an assessment to be carried out expeditiously and, in any event, within thirty days. The Company treats thirty days as an outer limit rather than a target.

15.3 A breach is an eligible data breach where there is unauthorised access to, unauthorised disclosure of, or loss of personal information, a reasonable person would conclude that it would be likely to result in serious harm to an affected individual, and remedial action has not removed that likelihood. Where those conditions are met, sections 26WK and 26WL require a statement to the Commissioner and notification of affected individuals as soon as practicable.

15.4 Where the incident touches records held for a Customer, the Company notifies that Customer within one business day of forming a reasonable suspicion, in writing, with what is known at the time and what is still being established. The Company does not wait for the assessment to finish before making that call. There is no paging rotation at this size, so the commitment is expressed in business days rather than in hours, which is the honest form of it.

15.5 For those records the Customer, as the entity that holds the relationship with the Player, makes the assessment and gives any notification to Players. The Company supplies the facts the assessment needs: which records, which Players by identifier, over what window, and what has been done since.

15.6 Where the incident touches Schedule A Part 1 records, the Company runs its own assessment and notifies affected individuals directly.

15.7 An incident affecting no personal information is still reported to any Customer whose Service was degraded, because availability is a contractual matter even where it is not a privacy one.

16.1 Complaints go to [email protected] with the words "Privacy complaint" in the subject line. Set out what occurred and what outcome is sought. The Company acknowledges receipt within 5 business days and gives a reasoned answer within 30 days.

16.2 The answer states what was found, what was done, and what will change. Where the finding goes against the complainant, it says why and identifies the evidence relied on.

16.3 A complainant dissatisfied with that answer, or one who prefers not to deal with the Company at all, may take the matter to the Commissioner.

16.4 A Player who writes to the Company about a game is told, within 5 business days, which studio holds the decision and that the request has been passed to that studio. The Company passes it on and then acts on whatever the studio instructs. It does not act on the Player's request by itself, and clause 2.4 explains why.

16.5 Schedule 2 to the Privacy and Other Legislation Amendment Act 2024 (Cth) created a statutory cause of action for serious invasions of privacy. It is pursued in court, independently of a complaint to the Commissioner. Nothing in this instrument limits it, and nothing in a Customer agreement purports to.

17.1 The Company publishes no mobile app. It holds no App Store listing, no Google Play listing, and no consumer product of any kind. What follows exists because a Customer that embeds a Service in a game does have those obligations, and a supplier that leaves the studio guessing about its own SDK is not much use.

17.2 App Tracking Transparency. Apple requires a permission prompt before an app tracks a user across apps and websites owned by other companies, or accesses the device advertising identifier. A Service integration reads no identifier for advertisers, reads no identifier for vendors, builds no device fingerprint, and transmits nothing that could be joined to another company's dataset. Embedding a Service therefore does not, on its own, require the App Tracking Transparency prompt. If a Customer joins Service data to data from a third party's app or site for advertising or measurement, the prompt obligation is the Customer's and the Company's position does not change it.

17.3 Google Play Data Safety. The Customer completes that form for its own listing. The facts a Customer needs in order to complete it accurately are these. Data types transmitted to the Company: an identifier the Customer allocates, an opaque save payload, a score with its board identifier, and any display name the Customer chooses to pass. Data is encrypted in transit. Data is not sold. Data is not shared with other companies for advertising. Deletion is available, and is requested through the Customer, which is what the Data Safety form's deletion question is asking about.

17.4 The Company will put those facts in a signed written statement for a store review at no charge, and will correct it in writing if the integration ever changes.

17.5 If a future Service makes any of the statements in 17.2 or 17.3 inaccurate, this clause is amended before that Service opens rather than after.

18.1 The Company's own dealings are with businesses. It does not knowingly collect personal information from a child in its capacity as an APP entity, and it operates nothing a child would use directly.

18.2 A Customer's game may well be played by children, and the Company holds the resulting records under Schedule A Part 2 on that Customer's instruction. The Customer decides whether the game is directed to children and what consent, if any, is needed before a record is created.

18.3 The Company's design reduces the problem rather than describing it. Because no email address, no name, no date of birth and no advertising identifier ever reaches a Service, a child's record held by the Company consists of an identifier the studio allocated and the game state that identifier points at. That is a deliberately thin record, and it is thin so that the compliance work sits with the studio that knows its audience rather than with a supplier that cannot see it.

18.4 Capacity to consent under the Act is assessed individually. The Commissioner's guidance treats an individual aged fifteen or over as ordinarily having capacity unless something indicates otherwise, and treats a younger individual's capacity as a question of understanding and maturity rather than of age alone. That assessment belongs to the Customer, which is the only party with the information to make it.

18.5 A Customer whose game is directed to children in the United States has obligations under the Children's Online Privacy Protection Act that the Company cannot discharge for it. The Company's contribution is to hold nothing that would make an operator's position worse, and to answer a regulator's technical questions in writing if asked.

18.6 The Act as amended in 2024 requires the Commissioner to develop a Children's Online Privacy Code. When that code is registered the Company will review this instrument against it and publish whatever change it requires.

19.1 The Company makes no decision about an individual by automated means that could affect that individual's rights or interests. There is no scoring, no profiling, no eligibility engine and no ranking of people.

19.2 A leaderboard ranks scores. It does not rank Players, and no consequence outside the game follows from where a score lands.

19.3 Amendments to the Act require a privacy policy to describe substantially automated decisions of that kind where an entity makes them. The Company makes none, so the disclosure it would otherwise owe is nil. If that changes, this clause is rewritten before the system is switched on.

20.1 The effective date and version number are printed at the head of this document. A change to either indicates a change to the text.

20.2 A material change is notified to every Customer by email at least fourteen days before it takes effect. A material change is one that widens a purpose, adds a recipient, lengthens a retention period, or reduces a right under clause 14 or 16.

20.3 A superseded version is supplied on request to anyone who asks, so that a statement made in an earlier version can be checked against the version in force at the relevant time.

20.4 A change is never applied retrospectively to records already collected under an earlier version where the effect would be to widen what may be done with them.

21.1 Every privacy matter in this instrument goes to [email protected]. That address is monitored on business days.

21.2 The Company holds no separate privacy officer position. Correspondence to the address in 21.1 reaches an officer of the Company, and there is no intermediate queue it can be lost in.

21.3 Documents requiring formal service go to the registered office shown for ACN 696 705 478 in ASIC's register. That register is the authoritative source for it, and the Company publishes no alternative postal address that would carry no legal effect.

Part 1 lists what the Company holds as an APP entity deciding its own purposes. Part 2 lists what it would hold on a Customer's instruction once a Service opens. Nothing in Part 2 was held at the effective date.

Part 1 — Held by the Company as an APP entity

Part 2 — Held on a Customer's instruction

This schedule answers the overseas-recipient question in APP 1.4 and supports clause 10. It lists recipients by function. Where a provider has been engaged, its country of processing is stated; where the Company has not yet contracted a component, the row says so instead of implying a decision that has not been made.

Two consequences worth stating plainly

Reading this website discloses an IP address to two recipients: the host that serves the page, and Google, which serves the typefaces. That is the whole of the overseas exposure created by the site, and it is why the row for fonts is present rather than folded into a general reference to third-party assets.

The infrastructure row is deliberately unfilled. Naming a provider that has not been contracted would be a claim about a decision nobody has taken, and it would be the kind of claim that is hard to withdraw once a customer has relied on it.

Each Service is contracted separately, so each carries its own processing terms. The table states the operative periods and the status of each Service. The notes below it state what is peculiar to each Service.

Save sync

The record is an identifier and a block of bytes the Company cannot interpret. Conflict resolution uses a version vector the client supplies, which means the Company never has to inspect the payload to decide which copy wins. A per-Player deletion instruction removes the payload, its metadata and its history; the identifier is removed with it rather than left as a tombstone carrying a date.

Leaderboards

A board entry may carry a display name where the Customer chooses to pass one. A display name is chosen by the Player and is the one field in the whole system that a Player may have made identifying. It is retained for the life of the board and is removed by a deletion instruction like any other field. Abuse flags raised by a validation hook are surfaced to the Customer for decision; the Company suspends nobody and bans nobody, because that is a judgement about the Customer's community and not about its infrastructure.

Remote config

This Service normally holds no Player record at all. It holds configuration values and a change history naming the Customer's own staff. Where a Customer stages a rollout by cohort, the cohort definition is supplied by the Customer and evaluated against an identifier the Customer already sends; the Company stores the rule, not a list of who matched it.

Common to all three

Sub-processing requires the Customer's prior written agreement, and the Company will not appoint a sub-processor to a Service by giving notice and treating silence as consent. Export is a documented endpoint the Customer can call without opening a ticket, and the restore test runs on the backup's own schedule with the result visible to the Customer. Audit rights, security obligations and the consequences of breach sit in the Customer agreement and in the terms of service, which this schedule is read alongside.