> For the complete documentation index, see [llms.txt](https://docs.appfarm.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appfarm.io/solution-administration/guide-to-gdpr/glossary.md). # Glossary ### **Data breach** A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed. ### **Data controller** An entity (a person, public authority, agency, etc.) that determines the purposes and means of the processing of personal data. For example, when a business uses Google Workspace for internal communication and collaboration, that business will be the data controller, and Google is the data processor. {% hint style="info" %} **Example**: Appfarm would be the data controller if we outsourced payroll to a third party. In this case, they would be the data processor. {% endhint %} ### **Data Processing Agreement (DPA)** A legal contract outlining the responsibilities and obligations of a data controller and a data processor when processing personal data. It establishes the terms and conditions governing the processing of personal data on behalf of the data controller by a third-party data processor. ### **Data processor** An entity that processes personal data on behalf of the controller. It’s the data controller who sets the rules, and the data processor plays by those rules. {% hint style="info" %} **Example**: Appfarm is the data processor for our SaaS customers. In this case, the client is the data collector. {% endhint %} ### **Data Protection Officer (DPO)** An individual designated by an organization to oversee and ensure the organization's compliance with data protection laws and regulations, particularly GDPR. ### **Data subject** An individual who is identifiable based on the personal data that is being processed. ### **Data sub-processor** A third-party entity engaged by a data processor to perform specific data processing activities on behalf of a data controller. A data sub-processor assists the primary data processor in carrying out certain tasks related to personal data. {% hint style="info" %} **Example**: Appfarm is the data sub-processor for our customers who develop web solutions for their own clients. In this case, the customer is the data processor, and the customer’s client is the data collector. {% endhint %} ### **GDPR** European Union regulation on information privacy in the European Union and the European Economic Area. ### **Personal data** Information relating to an identified or identifiable natural person (data subject). This encompasses all information that can be used to identify an individual. For example, first and last name, address, email address, location data, IP address, etc. ### **Processing** Any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means. For example, collection, recording, structuring, storage, alteration, use, etc. ### **Sensitive data** A type of personal information that is more highly protected by laws due to its more vulnerable nature. For example, political affiliation, racial or ethnic origin, religious beliefs, biometric data such as fingerprints, sexual orientation, etc. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.appfarm.io/solution-administration/guide-to-gdpr/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.