Data Processing Agreement

1. Parties and defined terms

1.1 This Data Processing Agreement (the DPA) is between Clouds On Mars Sp. z o.o. (Guardioz, we, us) and the Customer (you). Our registration details are in clause 1.2 of the Terms.

1.2 The Customer is the business that holds the Account. The person who creates the Account states in the Terms (clause 5.2) that they have the authority to accept the Terms for the Customer. The Service is for business use.

1.3 These terms have the same meaning in the Terms, this DPA, the Privacy Policy, the Service Provider List and the Agent Licence:

Term	Meaning
Service	The Guardioz service as a whole.
Application	The web application at app.guardioz.com, including its programming interface (REST API).
Agent	The Guardioz monitoring agent software installed on the Customer's server.
Account	The user account in the Application. One person uses it, for the Customer.
Organization	The unit in the Application that Servers belong to. It has a name and a plan, and no other details.
Server	A PostgreSQL instance registered in the Application. Written with a small letter, "server" means the machine.
Snapshot	One set of data the Agent sends.
Customer Data	Everything the Agent sends from the Customer's server.
Account Data	Data about the person who uses the Account.
finding	The result of a check on your Snapshots.
Website	guardioz.com.
Documentation	docs.guardioz.com.
Terms	The Terms of Service, https://guardioz.com/terms.
DPA	This Data Processing Agreement, https://guardioz.com/dpa.
Privacy Policy	https://guardioz.com/privacy.
Service Provider List	https://guardioz.com/service-providers.
Agent Licence	https://guardioz.com/agent-licence.
GDPR	Regulation (EU) 2016/679, the General Data Protection Regulation.

1.4 The words personal data, controller, processor, data subject, processing and personal data breach have the meaning that the GDPR gives them. In this DPA:

(a) a sub-processor is another processor that we use for the personal data that this DPA covers;
(b) the monitoring role is the PostgreSQL role that the Agent uses.

2. What this DPA covers

2.1 This DPA covers the personal data that we process for you in the Service: the personal data inside Customer Data, inside what the Service makes from Customer Data (including findings, settings history, analysis records and notification e-mails), and inside the names and descriptions of Servers that you type in the Application. In the rest of this DPA, "the personal data" means all of this. Data that has been anonymised so that it no longer relates to an identified or identifiable person is not personal data.

2.2 This DPA does not cover Account Data. We are the controller of Account Data. The Privacy Policy describes that processing.

2.3 This DPA covers the Service at app.guardioz.com, including the personal data that the Agent sends to the Service.

2.4 Material that you send us by e-mail, for example the output of the installer or lines from the Agent's log, is not Customer Data. You should not include personal data from your databases in it. If it contains such data, we process it only to handle your request, under this DPA, and delete it when it is no longer needed for that purpose. The Privacy Policy describes how we handle the rest of the message.

3. How this DPA applies

3.1 This DPA is part of the Terms. It applies from the moment the Terms apply to you. It is in electronic form.

3.2 We publish each version of this DPA with its date at https://guardioz.com/dpa. You can save and print it. We keep each earlier version and send it to you on request.

3.3 If your own rules require a copy signed by both parties, write to contact@guardioz.com. The signed copy has the same content as the published version and does not change it.

4. Roles

4.1 You act either as the controller of the personal data or as a processor on behalf of your own clients. In this DPA, "Controller" means you in the first case and your client in the second. We process the personal data as your processor or, where you act as a processor, as your sub-processor.

4.2 Where you act as a processor, you confirm that:

(a) you have obtained your Controller's authorisation to engage us and our sub-processors, including for transfers under clause 15; and
(b) your instructions to us are consistent with your Controller's instructions.

You remain our only point of contact, and we have no direct obligations towards your Controller unless the law requires them.

4.3 You determine the scope of the processing by choosing which PostgreSQL instances you register as Servers. The Agent collects data from each registered Server as a whole, and its configuration cannot exclude individual databases, datasets, columns or settings. You are responsible for registering only Servers whose data you may lawfully make available to us. Clause 16.4 sets out the controls that you have.

5. Subject matter, nature, purpose and duration

5.1 Annex I, which forms part of this DPA, sets out the subject matter, nature, purpose and frequency of the processing, the categories of data subjects and of personal data, and its duration. We process the personal data only to provide the Service and on your documented instructions (clause 6), which include the instruction in clause 7.2.

5.2 The processing lasts for the term of the Terms and, after they end, until we return or delete the personal data in accordance with clause 13 or as you instruct.

5.3 You choose the Servers from which the Agent collects data (clause 4.3). Annex I describes the categories of personal data that the Agent can collect from them, and clause 16.5 says how you decide about a server whose data can contain special categories of personal data or secrets.

6. Your instructions

6.1 We process the personal data only on your documented instructions. This includes transfers of personal data to a country outside the European Economic Area or to an international organisation.

6.2 Your documented instructions are:

(a) the Terms and this DPA, including the review of the operation of the Service in clause 8.11 of the Terms;
(b) the settings that you choose in the Application;
(c) installing, configuring, updating and removing the Agent;
(d) registering a Server and deleting a Server in the Application;
(e) a request to contact@guardioz.com that you confirm from the Account's e-mail address, provided that it is consistent with the Terms and within the scope of the Service;
(f) the transfers that the Service Provider List describes.

6.3 The law of the European Union or of a Member State can require us to process the data in another way. If it does, we tell you about that requirement before the processing. The only exception is a law that forbids us to tell you, on important grounds of public interest (Article 28(3)(a) GDPR).

6.4 We tell you immediately by e-mail if, in our opinion, an instruction infringes the GDPR or other data protection law of the European Union or of a Member State. We may suspend carrying out that instruction until you confirm or amend it. This clause does not oblige us to provide legal advice or to check every instruction for compliance.

6.5 If you give an instruction that the Service cannot carry out, we tell you so by e-mail. This is not a breach of this DPA or the Terms. You can then end the contract (clause 16 of the Terms) and the processing (clause 13).

7. Anonymised data, and no other use of the personal data

7.1 We process the personal data only to provide the Service to you, on your documented instructions. We do not use it for any purpose of our own, except as described in clause 7.2.

7.2 You instruct us to anonymise the personal data and to use the resulting anonymised data to maintain and improve the Service. We anonymise the data so that neither a data subject nor you can be identified from it, directly or indirectly, and we do not attempt to re-identify it. Anonymised data is not personal data (clause 2.1).

7.3 For example, we combine data from the Service across all customers into statistics: counts, shares and other totals over many Servers. We use them to decide which checks to build or change first, and to find which collections of the Agent and which analyses fail most often. The statistics contain no personal data, and they name no customer, no Server and no object on a Server, such as a database or a table.

7.4 We do not use the personal data, or anonymised data made from it, to train AI models.

8. People who have access

8.1 The Application has no function that allows our personnel to sign in as a customer. Only our personnel who need access to provide, maintain or secure the Service can access the personal data, and only to the extent needed for that purpose. This access takes place through administrative access to our production environment, through our accounts with the e-mail and error-monitoring sub-processors (Annex I, A2.3 and A2.4), through our mailboxes for material under clause 2.4, and, with the encryption key, to our encrypted backups in Microsoft Azure.

8.2 Our people read the production database remotely, from their work computers. A review of the state of the Service, which shows for each Organization its Servers, whether their Agents deliver Snapshots, whether analyses succeed and which findings the Application shows, without the names of objects on a Server, is prepared on such a computer and kept there only in memory, never written to disk. Each new review replaces the previous one.

8.3 We give administrative access only to people who need it for their tasks, and we make sure that each of them has committed to confidentiality or is under a duty of confidentiality that the law sets.

9. Security

9.1 We take the technical and organisational security measures that Article 32 GDPR requires of a processor. Annex II lists the measures that we apply, each with its scope.

9.2 We can change a measure. A change does not lower the level of protection that Annex II describes. When a measure changes, we update Annex II.

10. Sub-processors

10.1 You give us a general written authorisation to use sub-processors. The sub-processors are named in the Service Provider List. Annex III says which part of that list belongs to this DPA.

10.2 Before a change to Table A of the Service Provider List, as clause 2.1 of that list defines a change, we tell you by e-mail at least 30 days before the change takes effect. Where a change does not depend on us, or where we must replace a sub-processor urgently to protect the security or continuity of the Service, we tell you as soon as reasonably possible.

10.3 You can object within that period by e-mail to contact@guardioz.com, on reasonable grounds relating to data protection. If you do not object, the change is deemed accepted. If you object and we still make the change, you can end the processing (clause 13) and the contract (clause 16 of the Terms) before the change takes effect. We do not promise a version of the Service without the new sub-processor.

10.4 We use a sub-processor only under a written contract that imposes on it data protection obligations providing at least the same level of protection as this DPA (Article 28(4) GDPR). For each sub-processor, the Service Provider List names the contract.

10.5 If a sub-processor does not meet its data protection obligations, we remain liable to you for its performance as required by Article 28(4) GDPR, subject to the limitations of liability in the Terms.

11. Help with requests from data subjects and with your own duties

11.1 In the Application you can read the findings and the Server page, edit the fields of the Server record and delete a whole Server. The Application has no function to search Customer Data for one person, or to correct or delete a single record of it; we do that for you on request (clause 11.2). Most personal data inside Customer Data is not shown in the Application at all, for example the text of SQL statements and client addresses (Annex I, A6).

11.2 For any request of a data subject, write to contact@guardioz.com from the Account's e-mail address. We search the data that we hold for your Servers and, on your instruction, correct or delete the records that concern that person. We do this without undue delay, so that you can answer the data subject within the time that Article 12(3) GDPR sets, and we send you what we found and, where you ask for it, a copy in a structured, commonly used and machine-readable format. Copies in backups and logs expire as clauses 13.6 and 13.7 describe. New Snapshots can carry the same data again; clause 16.4 lists the controls that stop it.

11.3 If a person writes to us about personal data inside Customer Data, and we can tell which Customer it concerns, we forward the request to you by e-mail without undue delay. We do not answer the request or verify the person's identity ourselves, unless the law requires us to.

11.4 We help you with your duties under Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to us, by providing this DPA, the Documentation, the Service Provider List and answers to your questions by e-mail. Further assistance, such as participation in a data protection impact assessment or a consultation with a supervisory authority, is subject to a reasonable fee agreed in advance.

12. Personal data breach

12.1 We notify you without undue delay after we become aware of a personal data breach that affects the personal data (Article 33(2) GDPR). We take reasonable steps to contain the breach and mitigate its effects.

12.2 We send the notice to the Account's e-mail address. You are responsible for keeping that address up to date; a notice sent to it is deemed received. If you have deleted the Account (clause 13.4) and we still hold the personal data, we send the notice to the last e-mail address we have for the Account.

12.3 The notice contains, as far as known to us at that time:

(a) what happened and when;
(b) the categories and approximate number of data subjects and of personal data records affected;
(c) the likely consequences;
(d) the measures we have taken or plan to take;
(e) a contact point for further information.

If we do not have all of this information at once, we provide it in phases without undue further delay. A notice is not an acknowledgment of fault or liability.

12.4 If you learn of a personal data breach that affects the personal data, or suspect one, tell us at contact@guardioz.com. We record every personal data breach, its effects and what we did about it.

13. Deletion and return

13.1 During the term of the Terms, the Service does not delete the personal data by age. You decide how long it is kept by deleting Servers (clause 13.2) or the Account (clause 13.4). Backups expire as clause 13.6 describes.

13.2 You end the processing for a Server by deleting that Server in the Application. This removes from the production database the Server record with its free-text fields, its Snapshots, the findings and check results computed from them, its settings history, its machine profiles, its notification state, the technical records of its analysis runs and its collector key (the secret of its Agent).

13.3 After a deletion under clause 13.2 or 13.4, copies stay outside the production database for a time, as clauses 13.6 and 13.7 describe.

13.4 You end the processing for the whole Organization by deleting the Account in the Application. Because no second person can be added to an Organization (Terms 6.4), the deletion removes from the production database every Server of the Organization as clause 13.2 describes, the Account, and the Organization with its name. It is immediate and cannot be undone. If you cannot delete the Account yourself, for example because it is disabled, write to contact@guardioz.com and we delete it in the same way within 30 days of receiving your request (clause 16.8 of the Terms).

13.5 Deleting a Server, or the Account, does not stop the Agent. It keeps collecting and sending, and the Service refuses its requests, until you remove it from your server (section 8 of the Agent Licence). Each refused request is still recorded in the logs of the production machine with the network address of your server. Not every change that the installer made can be reversed (Annex II, B11).

13.6 The encrypted backups of the production database have a retention of 14 days. A backup made before your deletion is removed after about 14 to 21 days. After that, the backup storage keeps the deleted files for 14 more days. In total, deleted data stays in the backups for up to about 36 days. The weekly restore test makes a temporary copy from the backups on the production machine and deletes it after the test. A full copy of the production database that we make before we roll back a software update is deleted once the rollback is finished, and automatically at the latest 15 days after it was last read or changed.

13.7 Deleting a Server, or the Account, does not remove copies of Customer Data held outside the production database: notification e-mails that were sent, error reports at our error-monitoring sub-processor, and the logs of the production machine. Annex I, A2.3 and A2.4, say what these copies contain. Our e-mail sub-processor is set to keep no copy of the content of an e-mail and to delete its record of each e-mail after 1 month; the e-mails stay in the recipients' mailboxes. On our plan, the data retention period at our error-monitoring sub-processor is 30 days. The logs of the production machine are kept for up to about 5 weeks: the system journal and the request logs for 14 days, and the copies of log entries that the operating system keeps in its own log files at the latest 36 days after an entry was written. The hosting provider's agent on the machine sends those operating-system log files to the hosting provider every hour (Service Provider List, row A1). The log files of the database are overwritten after 7 days, or up to 14 days when the database was restarted during that week, and a copy of them stays in the backups as clause 13.6 describes.

13.8 Return of data: the Service has no export function. If you want the data returned, write to contact@guardioz.com before you delete the Server or the Account. We send you a copy within 30 days, in a structured, commonly used and machine-readable format (clause 16.11 of the Terms).

13.9 When the Terms end because you delete the Account, the deletion in clause 13.4 applies. When they end in another way, we delete the Account and the Organization with its data in the same way: on your request, within 30 days of receiving it, or, when we ended the contract, 30 days after the end date (clause 16.10 of the Terms). We keep the personal data longer only where the law of the European Union or of a Member State requires it.

14. Information and audits

14.1 We give you the information you need to show that Article 28 GDPR is met. What we can give today is:

(a) this DPA with its annexes;
(b) the Service Provider List;
(c) the Documentation;
(d) the source code of the Agent, which is on your own server under /opt/guardioz-agent and which the Agent Licence allows you to read for an audit;
(e) the install manifest on your own server, /etc/guardioz-agent/install-manifest.txt;
(f) written answers to your questions, sent to contact@guardioz.com.

14.2 We hold an ISO/IEC 27001 certificate for our information security management system and an ISO 22301 certificate for our business continuity management system, both issued by ISOCERT sp. z o.o. (certificates 550191/C/1 and 550191/C/2, valid until 18 December 2028, https://cloudsonmars.com/iso-certifications/). Each certificate states its scope, which does not name the Service. We have no independent audit report of the Service itself to give you today.

14.3 If the information we provide under this DPA is not sufficient to demonstrate compliance with Article 28 GDPR, you can carry out an audit, or have it carried out by an independent auditor that you name, that is not our competitor and that is bound by confidentiality towards us. You notify us in writing at least 30 days before the audit, with its proposed scope and date; after a personal data breach that affects the personal data, at least 10 business days before. We agree the scope, date and duration of the audit with you in advance. The audit takes place during our normal business hours, without unreasonably disrupting our operations, and does not give access to the data of our other customers or to information whose disclosure would compromise our security. Each audit is at your cost and takes place not more than once in 12 months, except after a personal data breach that affects the personal data, in which case the audit is limited to that breach. These limits do not apply to an audit by a supervisory authority.

14.4 An audit does not include direct access to the production machine or its database, because they hold the data of other customers too.

14.5 We contribute to an audit that a supervisory authority requires.

15. Transfers outside the European Economic Area

15.1 The production database with Customer Data, and its encrypted backups, are hosted in Microsoft Azure, in the Poland Central region.

15.2 You instruct and authorise us to transfer the personal data outside the European Economic Area (EEA) to the sub-processors named in the Service Provider List. For each sub-processor, the Service Provider List states the processing location and the transfer mechanism relied on.

15.3 We transfer the personal data outside the EEA only where Chapter V GDPR permits it, such as on the basis of an adequacy decision or the standard contractual clauses (Module 3, processor to processor). On your request, we provide information on the transfer mechanism used for a given sub-processor; commercial terms may be redacted.

16. Your own duties

16.1 You make sure that you have a legal basis for letting the Agent read the data described in Annex I, for sending it to us and for its processing under this DPA, including by our sub-processors (clause 10) and transfers outside the European Economic Area (clause 15). You make sure that the data you let the Agent read has been lawfully collected.

16.2 You inform the data subjects whose personal data appears in Customer Data, as Articles 13 and 14 GDPR require, including about the recipients of the data and transfers outside the European Economic Area. The Service does not inform them or obtain any confirmation from them.

16.3 The Agent removes only the secrets that Annex I, A6.2 names, and nothing in the Service filters the rest of what the Agent reads (Annex I, A7). For this reason, keep other secrets, such as passwords and keys, out of every place that the table in Annex I, A6 lists, for example literal values in SQL statements other than the one after the word PASSWORD, the values of settings that extensions add, index conditions, object and role names, and the host name, paths, mount options and kernel command line of the server. Personal data in these places reaches us as Annex I describes, and you decide under clause 16.5 whether that is acceptable. If you remove a secret from a setting, the earlier value stays in the settings history until you delete the Server.

16.4 The controls that you have are:

(a) the permissions that PostgreSQL gives to the monitoring role;
(b) whether a database allows connections (the datallowconn flag), because the Agent connects only to databases that allow them;
(c) the interval in the Agent's configuration file (A3.1), which sets how often the Agent sends;
(d) the installer option --no-pgdata-access, which affects only the disk measurement of the transaction log directory;
(e) removing the Agent;
(f) deleting the Server, or the Account with every Server of the Organization (clause 13.4).

16.5 You decide whether the Service, with the measures in Annex II, is suitable for a server whose SQL statements or settings may contain special categories of personal data or secrets (Annex I, A7). If you register such a server, you do so on the basis of your own assessment. This does not change our duty under clause 9.1.

16.6 Every notice under this DPA goes to the Account's e-mail address, and a notice sent to it is deemed received. You keep that address working and up to date. To change it, write to contact@guardioz.com from that address (clause 16.8 of the Terms). If you no longer have access to it, write to us from another address; we change the address only when we can verify that the request comes from the person who holds the Account.

16.7 Where you act as a processor (clause 4.2), you make sure that your contract with your Controller allows our engagement as your sub-processor, our use of sub-processors and the transfers under clause 15. You pass on to your Controller our notices under clause 10.2, and any objection of your Controller reaches us only through you.

17. Liability

17.1 Clause 15 of the Terms applies to this DPA.

17.2 Nothing in this DPA or in the Terms limits the rights that the GDPR gives to data subjects, or the liability towards them that the GDPR does not allow to be limited.

18. Changes to this DPA

18.1 We announce a material change to this DPA by e-mail at least 30 days before it takes effect. A change that is required by law, or that does not reduce the protection of the personal data, may take effect sooner, and we announce it as soon as reasonably possible. Changes to the Service Provider List follow clause 10.2.

18.2 If you do not agree with a material change, you can end the contract (clause 16 of the Terms) and the processing (clause 13) before the change takes effect. If you continue to use the Service after that date, the change applies to you.

19. Order of precedence

19.1 If this DPA and the Terms differ about the processing of the personal data, this DPA applies.

19.2 Annex I takes precedence over the Documentation where the two differ, and over the part of the Service Provider List named in Annex III (C2) where they differ about what data a sub-processor receives.

20. Term

20.1 This DPA ends when neither we nor our sub-processors acting on our behalf hold the personal data of your Organization any more, including the copies described in clauses 13.6 and 13.7. Notification e-mails in the recipients' mailboxes are outside our control and do not keep this DPA in force.

20.2 The end of the Terms, or the deletion of the Account, does not end this DPA while such data remains, including data we keep because the law requires it (clause 13.9). For that time, you remain the Customer under this DPA and we process that data only to delete it or as the law requires.

20.3 Clauses that by their nature are intended to continue, in particular those on confidentiality and liability, continue after this DPA ends.

21. Governing law and contact

21.1 Polish law governs this DPA, and the court competent for our registered office decides disputes, as clause 20 of the Terms says.

21.2 Requests, complaints and notices under this DPA go to contact@guardioz.com.

21.3 Our data protection officer is the officer named in clause 1.2 of the Privacy Policy, IOD@cloudsonmars.com.

Annex I - Description of the processing

This Annex names every category of data that the Agent collects.

A1. Subject matter

A1.1 Monitoring and analysis of the configuration and state of your PostgreSQL instances, based on Snapshots from the Agent that you install on the server where PostgreSQL runs.

A1.2 The Agent is the only way Customer Data reaches the Service, and it opens every connection. The Service does not connect to your server or database.

A1.3 The Agent runs fixed statements and system commands written in its code. Each statement is a SELECT or a SHOW on PostgreSQL system catalogs, statistics views, size functions and the function that lists the transaction-log files waiting to be archived (file names only). The database driver also sets each session to read-only. A6.3 lists what it does not read.

A2. Nature and purpose

A2.1 We receive Snapshots, store them, analyse them automatically, show the findings to you in the Application, send notification e-mails, host the data and back it up. We also review the operation of the Service for your Servers (clause 8.2). The table in A6 says how the Service uses each category of data today.

A2.2 Purpose: to tell you which settings and objects of your PostgreSQL instance need attention, and to show the measured data behind each finding. On your instruction, we also anonymise the personal data and use the anonymised data to maintain and improve the Service (clause 7.2).

A2.3 Notification e-mails carry: the name of the Server (by default the host name of your server), the time of the Snapshot, titles of finding groups, counts of objects and a link with the identifier of the Server. For settings and for archiving they also carry, for up to five findings of each group, the explanation that the Application shows, with measured values (for example the current and the recommended value of a setting, free disk space, transaction log volume, the name of a transaction log file, and the number and times of failed archiving attempts). For replication slots they carry the names of up to five affected slots with measured values of each slot (for example the volume of transaction logs that it holds and how long it has been inactive). Today they carry no names of databases, schemas, tables or indexes, and no SQL. Our e-mail sub-processor receives the whole e-mail.

A2.4 Error reports and logs. When an operation of the Service fails, for example receiving or analysing a Snapshot or sending a notification e-mail, an error report can go to our error-monitoring sub-processor. It carries request metadata: the network address of the caller (for a request of the Agent, the address of your server), request headers such as the user agent, and the URL path. Cookies and the Agent's authentication header are removed before a report is sent. It also carries the text of the error and recent lines of the Service's log. That text can contain the name of a Server, e-mail addresses and values from Customer Data, for example database user names, client addresses or statement text in an error of the Service's own database. A report does not carry the body of a request. Clause 3.2 of the Service Provider List gives the detail. The logs of the production machine contain the network address of the Agent's host, the request line, the subject of each notification e-mail with the name of the Server, and the text of errors.

A3. Frequency

A3.1 The installer sets the Agent to send a Snapshot every hour. The interval is a value in the Agent's configuration file, and you can change it there or with the environment variable GUARDIOZ_INTERVAL; the Agent waits for the interval after each collection ends. The 24-hour and 7-day intervals are fixed in the code, and so is the collection, up to once an hour during the first 24 hours after registration, of the data that A6 marks as sent once in 24 hours. The table in A6 says which data each Snapshot carries.

A3.2 The first Snapshot after registration, and a run that you start by hand with the option --once, contain all of the data in A6.

A3.3 The Agent connects to every database of the instance that allows connections, except the template databases.

A4. Data sent at registration

A4.1 At registration the Agent, started by the installer, sends the host name, the port, the PostgreSQL version, the name of the monitoring role, the list of database names, and the credentials that identify the installation. The registration request carries no database password and no dataset.

A4.2 The host name becomes the default name of the Server. The fields that describe a Server in the Application are free text that your user types.

A5. Categories of data subjects

A5.1 The data subjects are:

(a) people and accounts that connect to your databases: administrators, developers and users of your applications;
(b) people whose data appears in literal values of SQL statements, in index definitions or in object names; only you know who they are;
(c) people who can be identified by a host name.

A6. Categories of personal data

A6.1 The Agent sends the data in this table. "Every Snapshot" means every hour with the default settings.

Data	When it is sent	How the Service uses it today
Database sessions. One row for every session in pg_stat_activity: database user name, application name, client address, client host name, client port and the text of the statement, including literal values, except the value that A6.2 says the Agent replaces. For a session that is not active, the text is its last statement.	Every Snapshot	Statement text: read by one automated analysis that classifies database processes; not shown in findings, pages, the API or e-mails. User name and application name of a session that blocks cleanup (vacuum): shown in a finding. Client address, host name and port: stored, not used.
Settings. Name and value of every PostgreSQL setting, except the values that A6.2 says the Agent masks. Other values, for example those of settings that extensions add, can contain connection strings, commands and credentials. The Service keeps a history of earlier values.	Every Snapshot	Values of the settings that the checks tune, and of archive_mode and archive_timeout: shown in findings, some also in e-mails (A2.3). Whether archive_command is set: read by the archiving check. Other values, including primary_conninfo without its password: stored, not shown.
Index definitions. Definitions, expressions and conditions of indexes, including literal values; names of constraints; storage options of tables.	Up to once an hour during the first 24 hours after registration, then once in 24 hours	Definition of an index that a finding is about: copied into that finding.
Object names. Names of databases, schemas, tables, indexes, replication slots and transaction log files; the access privileges text of each database, which contains role names.	Every Snapshot	Names of the objects that a finding is about: shown in that finding, some with generated SQL commands. The names of affected replication slots, and the name of a transaction log file in a finding about archiving, also appear in notification e-mails (A2.3). Access privileges text: stored, not used.
Machine profile. On Linux: the host name (in the output of uname -a); block devices with model and serial number; network interfaces with hardware (MAC) addresses; the whole mount table with device, mount point, file system type and options, which for a network file system can contain the address of a file server; the whole file /proc/meminfo; the kernel command line (/proc/cmdline). Raw values are stored next to parsed values. On FreeBSD the profile is narrower and contains the host name.	First Snapshot, then once in 7 days	Parsed values, such as total memory and the number of processors: used by the checks. Raw fields, including hardware addresses, the mount table and the kernel command line: stored, not used.
Paths of the PostgreSQL data directory and of the transaction log directory.	Every Snapshot	Data directory path: shown on the page of the Server.
Network address of the Agent's host.	Every request of the Agent	Not stored with the Snapshot. It appears in error reports and logs (A2.4).

A6.2 Before it sends a Snapshot, the Agent removes three things: (a) in statement text, a value in quotation marks written right after the word PASSWORD, for example in ALTER ROLE ... PASSWORD; (b) the values of archive_command, archive_cleanup_command, restore_command, recovery_end_command and ssl_passphrase_command, of which it sends only whether each one is set; (c) the password in primary_conninfo. The Service stores the statement text as the Agent sends it. Your PostgreSQL setting track_activity_query_size sets its maximum length.

A6.3 Not collected: the rows of your tables or views, pg_stat_statements, pg_stats, the role catalogs and the PostgreSQL log files. During installation the installer reads the lists of roles and processes on your server, and sends neither. The Agent does not send the monitoring role's password from its configuration file. A password written in a statement in another form than the one A6.2(a) names, for example inside a connection string passed to a function, still reaches the Service if pg_stat_activity shows that statement when the Agent collects. Of the errors that your PostgreSQL returns to the Agent, only the five-character error code is sent.

A7. Special categories of personal data and secrets

A7.1 SQL statements, setting values and index definitions can contain any text. Apart from what A6.2 names, nothing in the Agent or in the Service filters, masks, hashes or shortens it. An index whose definition, expression or condition is longer than 64 KB is left out of the Snapshot, a table whose storage options are that long is left out with its indexes, and the limits on the number of objects in the Documentation can leave objects out; neither is a filter of content. For this reason no category of personal data can be excluded. Special categories of personal data, data about criminal convictions, passwords and other secrets can be present if your SQL statements, settings or object names contain them.

A7.2 The Service has no function that looks for such data, and no function that removes it other than deleting the whole Server.

A8. Duration

A8.1 As long as the Server exists in the Application; you decide how long by deleting the Server or the Account (clause 13.1). After you delete the Server, copies stay as clauses 13.6 and 13.7 describe.

A9. Relation to the Documentation

A9.1 The Documentation lists the sources that the Agent reads at https://docs.guardioz.com/reference/data-collected/. That page is a list of sources; this Annex lists the categories of data (clause 19.2).

Annex II - Technical and organisational measures

This Annex lists the measures that exist in the Service at app.guardioz.com, each with its scope. Row B11 describes protections built into the Agent that you install and update on your server.

Area	Measure	Scope
B1. Encryption in transit	The Service accepts TLS 1.2 and TLS 1.3 and no older protocol. Plain HTTP is redirected to HTTPS, and the web server sends the HSTS header, which tells a browser to use HTTPS only. The Agent and the installers check the server certificate. The install command writes the HTTPS address of the Service, https://app.guardioz.com, into the Agent's configuration file, and the Agent sends Snapshots to that address.	The Service at app.guardioz.com.
B2. Browser protections	The Application sends security headers on every response, including a Content-Security-Policy that runs only scripts that we mark for that response, and headers against framing and content-type sniffing. Automated tests check them.	The Application.
B3. Credentials stored as hashes	Account passwords, web session tokens, API refresh tokens and collector keys are stored as hashes. An API refresh token can be used once. A collector key belongs to one Server and is given once, to the installer. The Application has no field for the password of a monitored database; that password stays on your server.	The credentials named here.
B4. Sign-in and sessions	A wrong e-mail address and a wrong password give the same message. Signing in with a password requires a confirmed e-mail address. A password reset link is valid for 30 minutes; a completed reset ends the Account's sessions and cancels its refresh tokens. Changing the password and deleting the Account require a recent sign-in. Users can see and end their own sessions. Sessions end after a period without activity and after a fixed maximum period. Web routes that change data within a session require a secret token of that session.	The Application.
B5. Separation of customers	On every API request the Application takes the user's Organization from its own database. The functions that read and write Servers filter by the Organization, and a Server of another Organization is "not found". Identifiers in URLs are random values, not counters.	The separation is logical. All customers share one database.
B6. Request limits	The production web server limits the requests that one network address can send to the sign-in, registration and Agent endpoints, and the size of a request.	The endpoints named here.
B7. The production machine	The Application runs under a system account that cannot sign in, in a hardened service definition, and listens only on the local machine behind the web server. A firewall refuses incoming traffic except web traffic and administrative access. The database is on the same machine, on a separate disk. When the environment is set to production, the Application refuses to start in debug mode or with a weak secret key. Delete locks protect the virtual machine, its data disk and its public address.	One virtual machine in Microsoft Azure holds the web server, the Application and the database. Region: clause 15.1.
B8. Deployment and administrative access	A person starts each deployment, from a tagged version, after the automated tests pass. The deployment checks that the database schema matches the code before it restarts the service. Administrative access uses SSH keys; password sign-in is switched off. Reviews of the state of the Service are kept only in the memory of the computer on which they are read (clause 8.2). Clause 8.3 sets the duty of confidentiality.	This access reaches the database and so Customer Data (clause 8).
B9. Backups	Backups are encrypted with AES-256 on the production machine before they go to storage in Microsoft Azure. Retention is 14 days (clause 13.6). A restore test runs automatically every week. A failed backup run or a failed restore test sends an alert to the operator.	The production database. The restore test runs on the production machine.
B10. Monitoring and error reports	An external monitor reads a health address that returns no customer data. A disk space check reports to an external heartbeat service. Error reports are sent without request bodies, local variables, cookies and query strings.	What error reports can contain: Annex I, A2.4.
B11. The Agent on your server	The installer needs administrator rights and acts with the rights of the owner of the PostgreSQL instance. It refuses a standby server before its first change. It gives PostgreSQL only a hash of the monitoring role's password, computed on your server, and it does not pass that password as an argument to the commands that it runs with administrator rights. The Agent then runs under a dedicated system account without administrator rights, and it cannot change its own code or its configuration file, which holds its secrets. Two collections run with administrator rights: the first one, which the installer starts right after registration, and one that you start by hand as root. Its access to the PostgreSQL data directory allows passing through the directory, and nothing more. It uses the monitoring role, which the installer creates with membership in pg_monitor and nothing else. If granting pg_monitor fails, for example because the account the installer acts with may create roles but not grant pg_monitor, the installer continues and the role collects less. A role with that name that already existed keeps its privileges, which can be more than pg_monitor, and gets a new password and the right to log in; the old password cannot be restored. The Agent connects over the local Unix socket and opens every database session as read-only, with limits on time and rows. It has no listening port and accepts no commands. Section 6 of the Agent Licence lists what the installer changes and which changes it records with a command that reverses them. On Linux the service definition adds further limits.	The current version of the Agent; an earlier installation reaches it through the update script. The Linux limits do not apply on FreeBSD, where the supervising process runs as root and runs the Agent without administrator rights.

Annex III - Sub-processors

C1. The Service Provider List, https://guardioz.com/service-providers, gives the details of each sub-processor: its location, its transfer safeguard, its contract and what it receives. This Annex names only the sub-processors and their functions.

C2. The part of the Service Provider List that belongs to this DPA is Table A, with clauses 3.1 to 3.3, and section 7 as far as it concerns the sub-processors in Table A. The version of Table A in force on the day this DPA starts to apply to you forms part of this DPA. Clause 10 governs every later change.

C3. Table A covers four functions: hosting of the production database and its encrypted backups (Microsoft Azure), sending of notification e-mails (Brevo), error reports (Sentry), and the mailboxes that receive the material in clause 2.4 (Microsoft 365).

C4. Sections 4, 5, 6 and 8 of the Service Provider List, including Tables B and C, are not part of this DPA.