Data Processing Addendum

This Data Processing Addendum (“DPA”) is part of the Terms of Service. It applies when MonoAdmin handles personal data about players, and about other people on a customer’s game server, on the customer’s behalf. It is written for the Data Privacy Act of 2012 (Republic Act No. 10173) of the Philippines and its implementing rules, and it is meant to meet Article 28 of the GDPR as well, so it can be used by customers in the EU, the EEA and the UK. By accepting the Terms, the customer accepts this DPA. No signature is needed. If you need a signed copy, write to hello@monoadmin.net.

1. Roles and Words

• The customer is the owner of the MonoAdmin project. The customer is the personal information controller (the “controller” in EU and UK law) for the personal data of its players and other people in its project.
• MonoAdmin is the personal information processor (the “processor”) for that data.
• Player data is the personal data that MonoAdmin handles for a project, as described in section 4.
• Data protection law means the Data Privacy Act of 2012 and its implementing rules and, where they apply, the GDPR and the UK GDPR.
• A sub-processor is another party that MonoAdmin uses to handle player data.

For the account data of the customer and its staff, which MonoAdmin handles for its own purposes, MonoAdmin is the controller. The Privacy Policy covers that.

2. Subject Matter and Duration

The subject matter is running the customer’s project: storing and handling player data so the customer’s staff can moderate and manage their game server. This DPA lasts for as long as the project exists and MonoAdmin holds player data for it. It ends when that data has been deleted, including from backups (section 11).

3. Nature and Purpose of the Processing

MonoAdmin receives player data from the MonoAdmin resource on the customer’s game server and from players’ own games, from the customer’s staff using the panel and the in-game menu, and from Discord and Steam when the customer uses features that depend on them. It stores the data, shows it to the customer’s staff according to the roles the customer has set, passes some of it to the customer’s own Discord server for tickets, and deletes it on the schedule below. The purpose is to give the customer the service it has set up, and nothing else.

4. Data and People Concerned

The people are the players on the customer’s game server, people who apply to its whitelist, people who take part in its Discord tickets, and the customer’s staff members, as far as their actions in the project are recorded.

The data, depending on which features the customer switches on:

• identifiers: the name a player uses, Rockstar license, Steam, Discord, Cfx.re and Xbox or Microsoft identifiers, and hardware tokens;
• IP addresses on visits, and the places looked up from them (counts only);
• visits, positions, routes, and live details from a player’s game (health, armour, vehicle, activity);
• pictures of a player’s character’s face, and Discord and Steam profile pictures fetched by ID;
• screenshots, and report attachments;
• live views of a player’s game in the Player Monitor, which pass through a relay and are not recorded;
• Server Logs lines: connections, kicks, staff actions, chat messages, commands, item and money events, public phone posts and ended calls, and webhook lines;
• notes, warnings, bans, kicks, mutes, community service and reports;
• Discord ticket messages, files and transcripts, which can also be posted to a channel in the customer’s Discord server and sent by Discord message to the person who opened the ticket;
• whitelist applications and the answers to the customer’s questions, and whitelist requests, which hold the player’s name, Discord ID if reported and the account identifiers shown at the last attempt;
• analytics (jobs, money, activity) and server numbers;
• data the customer imports from txAdmin.

Character, inventory and owned-vehicle data stays in the customer’s own game database and is not copied, except for a backup of a deleted vehicle, kept for 60 days.

MonoAdmin does not set out to handle special or sensitive categories of personal data. The customer should not enter any in notes, reports, whitelist questions or tickets, and should remember that free text its players write may contain some.

5. Instructions

MonoAdmin handles player data only on the customer’s documented instructions. The customer’s instructions are what it does in the panel and the in-game menu, and its settings: which features are on, which Server Logs types are recorded, the roles it gives, the limits it sets and what it asks on its whitelist. The Terms and this DPA are also instructions.

MonoAdmin does not use player data for its own purposes. The one exception is what is needed to run, secure and protect the service and to follow the law. If MonoAdmin believes an instruction breaks data protection law, it tells the customer.

6. Confidentiality

At MonoAdmin, only the people who run the service can reach player data, and they must keep it confidential and use it only as this DPA allows. Staff work in a back office that needs two-factor sign-in, and the changes they make there are recorded with a reason. Staff can open a session as a customer’s account for at most 30 minutes, only to answer a support request or to look into abuse or a security problem, and only with a recorded reason. Every sign-in as an account, every back-office change and every address lookup is recorded, and changes made in such a session appear in the project’s Audit Logs under the customer’s account name.

7. Security

MonoAdmin takes technical and organisational measures to protect player data. In summary:

• long-lived credentials (sessions, tickets, server credentials) are random tokens kept only as hashes, and there are no signed tokens that stay valid on their own; short-lived links and codes in outgoing emails are kept in the mail queue for 30 days, and each of them stops working long before that;
• every route of the service has a declared access policy, and roles are checked on every request;
• a project’s data is kept apart from every other project’s: every query is limited to the project, and the database’s own keys enforce it;
• the game server and the player’s game never name a project or a user in what they send; players connect with single-use tickets, and the game accepts only a fixed list of messages;
• connections to the panel, the game gateway and the website use HTTPS, and live views of a player’s game go through a relay so the viewer and the player never see each other’s address;
• two-factor secrets and customers’ own Discord bot tokens are encrypted, and passwords are salted hashes;
• player IP addresses are masked for everyone but the owner and the roles that may see them, and are cleared from visits after 90 days at the latest;
• stored files are kept under long random addresses that cannot be guessed, and MonoAdmin gives an address only to the customer’s staff allowed to see that file; anyone who holds an address can open the file until it is deleted or expires, so the customer’s staff must treat file links as confidential; files that are not images are served so that a browser downloads them and cannot run them;
• requests are rate limited, and sign-in and sign-up have a bot check;
• every change by a customer’s staff and by MonoAdmin staff is recorded.

How MonoAdmin Is Secured describes these measures in more detail for customers. The list is not complete, and no system is perfectly secure.

8. Sub-Processors

The customer allows MonoAdmin to use the sub-processors listed on the Sub-processors page. MonoAdmin stays responsible to the customer for them. Tebex, which sells paid plans to the customer as reseller and merchant of record, is an independent provider and not a sub-processor. It is not on that list and receives no player data.

MonoAdmin posts any new sub-processor on that page and emails the project owners at least 14 days before it starts to handle player data. The customer can object by writing to hello@monoadmin.net within that time, giving its reasons. If we cannot find a solution, the customer can stop using MonoAdmin and delete its project before the new sub-processor starts.

9. Requests From People

When a person asks MonoAdmin to see, correct or delete their player data, or objects to its use, MonoAdmin does not decide the request itself. It tells the person to ask the customer, or passes the request to the customer, and helps the customer answer it.

The panel has no screens to export or erase a single player’s record, so MonoAdmin helps the customer by hand. The customer asks at hello@monoadmin.net and MonoAdmin answers within 30 days and says what it did, or what it could not do and why. The customer remains responsible for deciding what to do and for answering the person.

10. Personal Data Breaches

If MonoAdmin finds out about a personal data breach that affects the customer’s player data, it tells the customer without undue delay, by email to the project owner, with what it knows: what happened, which data and roughly how many people, the likely consequences, and what it has done and will do about it. The customer decides whether it must tell the National Privacy Commission, its own supervisory authority or the people affected, and does so. MonoAdmin helps with that. MonoAdmin deals with breaches of the data it controls itself, as the Privacy Policy says.

11. Deleting the Data

When the project is deleted. If the owner deletes the project in Settings > Delete Project, if MonoAdmin deletes a terminated project 14 days after it ended, or if the owner’s account is deleted, MonoAdmin deletes the project’s player data: players, identifiers, punishments, notes, reports, files, settings, the whitelist, tracked positions, Analytics, audit logs, webhook logs and Server Logs. Stored files and Server Logs are deleted along with it.

Time-based data. Positions, Analytics, Server Logs, audit logs, webhook logs and Player Locations are deleted for good about 60 days after they were recorded. They are removed in batches, so a record can outlast that by a few days. Other kinds on the schedules in the Privacy Policy. A plan ending deletes nothing at once. What the plan’s history hides is deleted as it passes 60 days.

Backups. Deleted data can remain in backups for up to 30 days before it is overwritten.

What is not player data. Payment records stay for accounting, and MonoAdmin’s own staff log stays. Neither is player data.

Getting a copy first. The panel can export reports as an HTML page, JSON or a ZIP with the files. For any other copy of player data, the customer asks at hello@monoadmin.net before it deletes the project, and MonoAdmin answers within 30 days and says what it did, or what it could not do and why. Data that lives on the customer’s own game server, such as the local copy of bans that the resource keeps, and the character data in its own database, is the customer’s own.

12. Showing That We Comply

MonoAdmin gives the customer what it needs to check that this DPA is followed: this page, the Sub-processors list, the security documentation, and answers to reasonable written questions sent to hello@monoadmin.net. MonoAdmin does not hold an outside security certification. If data protection law requires an audit by the customer or by a regulator, MonoAdmin will take part, with reasonable notice, during working hours and at the requester’s cost, without exposing other customers’ data.

13. What the Customer Must Do

The customer promises that it:

• has a lawful basis for each kind of player data it collects, and uses the data only for running its game server;
• tells its players what is collected and why, in a privacy notice, because MonoAdmin does not do so in the game: identifiers and hardware tokens, IP addresses, positions and routes, chat and commands, screenshots, live views of the screen and face pictures, as far as the customer uses those features;
• does not use MonoAdmin to monitor people unlawfully or in a way that the law of its players’ countries forbids;
• switches off the features and Server Logs types it does not need, and keeps access to those who do;
• is responsible for the questions on its whitelist form and for any personal data they collect;
• does not enter special or sensitive data in notes, reports or tickets;
• answers its players’ requests about their data, with MonoAdmin’s help under section 9;
• follows the rules for young players’ data where they apply;
• keeps its own and its staff’s accounts secure, and follows the Acceptable Use Policy.

14. Moving Data Across Borders

The customer and its players can be anywhere, and MonoAdmin and its sub-processors may handle player data in other countries, including to deliver traffic worldwide. The customer allows this. Under the Data Privacy Act the customer stays accountable for data it hands over, and MonoAdmin keeps to this DPA in every country. For personal data that comes from the EU, the EEA or the UK, where the law requires a transfer safeguard such as standard contractual clauses, MonoAdmin will put one in place on request.

15. Liability and Order

Liability under this DPA is subject to the limits in the Terms of Service. If the Terms and this DPA disagree about player data, this DPA comes first.

16. Changes

MonoAdmin may update this DPA. For a material change it posts the change on this page and emails the project owners at least 14 days before it takes effect. The date at the top says when this page was last changed.

17. Contact

Write to hello@monoadmin.net for anything about this DPA.