Data Processing Agreement

When your Bot records a moderation action, tracks levels, stores a ticket or counts an invite, it processes personal data about members of your Discord server. You decide that it should happen and why, which makes you the controller. We only store and process it on your instruction, which makes us your processor.

Art. 28(3) GDPR requires that relationship to be governed by a contract. This is that contract. Without it, processing member data through the Service would not be lawful.

Subject matter and purpose. The provision of Ruination Bots: hosting and operating Discord bots on the Controller's behalf and storing the data those bots generate, as configured by the Controller.

Nature of the processing. Collection, recording, organisation, structuring, storage, retrieval, use, transmission to Discord, restriction and erasure, carried out by automated means.

Duration. For as long as the Controller holds an account. For a Bot, the processing ends when that Bot is deleted, and entirely when the account is deleted or the contract for the Service otherwise ends (section 10).

Special categories of data (Art. 9 GDPR) are not intended to be processed. The Service is not designed for them. If the Controller configures a Bot in a way that causes such data to be submitted - for example a ticket form asking about health - the Controller is responsible for having a legal basis under Art. 9(2) GDPR and for its own assessment. Our obligations under this agreement apply to such data all the same.

We process personal data only on the Controller's documented instructions, including with regard to transfers to a third country or an international organisation, unless required to do so by Union or Member State law to which we are subject. In that case we will inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

The Controller's instructions are given by this agreement, by the Terms of Service, and above all by the configuration made in the dashboard: enabling a module, setting a retention option or deleting a record are instructions in this sense. Further individual instructions may be given in text form to privacy@ruination-bots.com.

The Controller is responsible for the lawfulness of the processing it instructs, in particular for having a legal basis and for informing the members of its server (Arts. 6, 13 and 14 GDPR). It has the rights this agreement gives it: to give instructions, to be informed, to object to sub-processors and to audit.

We will inform the Controller immediately if, in our opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions, and may suspend execution of that instruction until it is confirmed or changed. We are not obliged to carry out an instruction that is obviously unlawful.

Everyone we authorise to process personal data under this agreement has committed themselves to confidentiality or is under an appropriate statutory obligation of confidentiality, and that obligation survives the end of their engagement. Access is granted only to those who need it to provide or maintain the Service, and only to the extent needed.

We implement measures appropriate to the risk, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of the processing. These are set out in Annex II and may be updated as technology develops, provided the level of protection is not reduced.

With this agreement the Controller gives its general written authorisation (Art. 28(2) GDPR) for the engagement of sub-processors. Those currently engaged are listed at Sub-processors and reproduced in Annex III.

We will inform the Controller of any intended addition or replacement at least 30 days in advance, by email to the address on the account. The Controller may object within that period, giving a data protection reason. If we cannot resolve the objection, the Controller may terminate the contract for the Service (the Terms of Service together with this agreement) without notice and at no cost, with effect no later than the date the change would take effect; anything paid for the time after the termination is refunded.

We impose on every sub-processor, by contract, the same data protection obligations as set out in this agreement, in particular sufficient guarantees that appropriate technical and organisational measures are implemented, and remain fully liable to the Controller for the performance of their obligations.

Taking into account the nature of the processing, we assist the Controller by appropriate technical and organisational measures in fulfilling its obligation to respond to requests under Chapter III GDPR.

In practice the dashboard is that assistance, and these are the specific surfaces:

• Access (Art. 15): the member lookup shows a member's moderation history and anti-spam escalation level, and each feature shows its own records (the level leaderboard, invite statistics, tickets, giveaways). Everything else stored about a member we provide on request to the data protection contact in Annex I, as a machine-readable file and without undue delay, in time for the Controller to answer within the period of Art. 12(3) GDPR.
• Correction (Art. 16): a member's stored level and experience can be set directly; a moderation record carrying a wrong reason can be removed.
• Erasure (Art. 17): one control erases everything a bot has stored about a Discord member, across every feature at once, and deletes the suggestion messages the bot posted in that member's name. It is available to the bot owner only and cannot be handed to moderators.

Two limits on the erasure, stated because they are real rather than because they are convenient. Anything still in progress is refused rather than deleted, and named in the response so it can be resolved: an open ticket, a timed role that has not come off, a temporary voice channel still in use. Deleting those records would break the feature rather than expire it. And records belonging to other members are kept, with the reference to the erased member removed instead, because those records are a third party's data and answering one erasure request by destroying somebody else's is not erasure.

What a Bot has already posted on the Controller's Discord server (ticket messages and transcripts, the answers to a ticket form, announcements) is stored by Discord, not by us, and stays there until the Controller deletes it in Discord.

Where a request reaches us instead of the Controller, we will not answer it ourselves - we will forward it without undue delay and support the Controller in answering.

We notify the Controller without undue delay after becoming aware of a personal data breach affecting data processed under this agreement, with the information available to us, so that the Controller can meet its own obligations under Arts. 33 and 34 GDPR.

We also assist the Controller, taking into account the nature of processing and the information available to us, in complying with Arts. 32 to 36 GDPR, including data protection impact assessments and prior consultation.

At the Controller's choice, we delete or return all personal data after the end of the provision of services, and delete existing copies, unless Union or Member State law requires storage.

The Controller makes that choice itself. Deleting a Bot or the account is the choice to delete, carried out automatically and irreversibly (immediately, with backups overwritten within 30 days). Before deleting, the Controller can ask for a copy of the data at privacy@ruination-bots.com; we provide it as a machine-readable file. If the contract ends in any other way, the periods in the Terms of Service for switching providers apply: the data stays available for retrieval and is deleted afterwards.

Our backups are not used to restore deleted data; they are overwritten on their own cycle within 30 days. That is a technical period, not storage for any purpose of ours. Apart from them, we keep no copy.

We make available to the Controller all information necessary to demonstrate compliance with Art. 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates.

Audits are to be announced with reasonable notice, are limited to normal business hours, must not disproportionately disrupt operations, and are subject to confidentiality. In the first instance we may answer an audit request with documentation of our measures, or with current certifications and audit reports from our sub-processors. Where that is not sufficient, the Controller's right to inspections remains. Inspections at our providers' data centres are carried out through the audit rights we hold under our agreements with them and the reports they publish, since we do not operate those centres ourselves.

Where processing takes place outside the EU or EEA, it is covered by an adequacy decision under Art. 45 GDPR or by appropriate safeguards under Art. 46 GDPR, as a rule the European Commission's Standard Contractual Clauses, supplemented by technical measures. Annex III states the transfer basis for each sub-processor. Any transfer beyond those described there requires the Controller's instruction.

The following measures are implemented in accordance with Art. 32 GDPR. They are stated honestly rather than aspirationally: what is listed is what is in place.

• Pseudonymisation and encryption. TLS for all data in transit. Encryption at rest by our database provider. Bot tokens additionally encrypted at the application layer (AES-256-GCM) with a separate key, never returned to a client and never logged. IP addresses in audit records stored only as keyed hashes. Our own backups encrypted as they are made, with a key that is not on the server.
• Confidentiality - access control. Authentication via Discord OAuth with no passwords held by us. Row-level security in the database restricting each account to its own rows. Administrative credentials held server-side only. A granular permission model for moderators, with the delegation of access itself reserved to the owner.
• Integrity. A log of every change made through the dashboard, including attempts refused for lack of permission, that the Controller can read but not edit, retained 90 days. Server-side validation of input before it is stored. Rate limiting against abuse and enumeration.
• Availability and resilience. A managed database at our database provider, and in addition encrypted daily backups that we make ourselves and keep apart from the database, on our server at our hosting provider, for less than 30 days. Health monitoring of running bots with automatic restarts. Job queues that retry failed jobs with increasing delays.
• Regular review. Dependency updates, review of access rights, and verification that documented retention periods match what the software actually does.
• Separation. Data is separated per account and per bot at the row level, and access is always scoped by the acting account.
• Instruction control. Processing is driven by the Controller's configuration; no member data is used for our own purposes, and none is used to train models or for analytics beyond the Controller's own dashboard.