Legal Information
Data Processing Addendum for the gro.now Platform (B2B)
Version v.1.1 as of 28.11.2025
1. Introduction
1.1.
This Data Processing Addendum for the gro.now platform (hereinafter – the “Addendum” or “DPA”) is concluded between:
(i) “Pwron” LLP, BIN 241040012133, address: Republic of Kazakhstan, Almaty, Bostandyk district, Satpayev St., 90/54, apt. 5, index 050000; website: https://gro.now/ (hereinafter – the “Processor”),
AND
(ii) the Client, who has concluded the Customer Agreement for the gro.now Platform with the Processor, see https://www.gro.now/legal/terms (hereinafter – the “Customer Agreement” or “CA”), who is the Operator (Controller) of personal data within the meaning of applicable legislation (hereinafter collectively referred to as the “Parties”).
(i) “Pwron” LLP, BIN 241040012133, address: Republic of Kazakhstan, Almaty, Bostandyk district, Satpayev St., 90/54, apt. 5, index 050000; website: https://gro.now/ (hereinafter – the “Processor”),
AND
(ii) the Client, who has concluded the Customer Agreement for the gro.now Platform with the Processor, see https://www.gro.now/legal/terms (hereinafter – the “Customer Agreement” or “CA”), who is the Operator (Controller) of personal data within the meaning of applicable legislation (hereinafter collectively referred to as the “Parties”).
1.2.
This Addendum regulates the relations between the Parties arising during the processing by the Processor of personal data transmitted to it by the Client or obtained from data subjects on behalf of the Client, within the framework of the execution of the Principal Agreement.
1.3.
This Addendum is an integral part of the Customer Agreement and shall be interpreted jointly with it, as well as with other internal documents of the Processor regulating the use of the gro.now platform, including:
- General Personal Data Processing Policy https://www.gro.now/legal/general-privacy-policy;
- Personal Data Processing Policy for Respondents (https://www.gro.now/legal/privacy-policy) – an independent document regulating the processing of personal data of individuals participating in surveys, tests, research, and other activities organized by Clients on the platform;
- Cookie Processing Policy https://gro.now/legal/cookie-policy.
- Service Level Agreement (SLA) https://www.gro.now/legal/sla;
- Rules for Conducting Surveys and Activities for B2B Clients of the Platform (https://gro.now/legal/activity-rules) – a document regulating the procedure for conducting Surveys and other Activities by Clients on the Platform;
- Acceptable Use Policy (AUP) https://www.gro.now/legal/acceptable-use-policy.
1.4.
In case of a contradiction between the terms of this Addendum and the terms of other documents, in the part concerning the processing of personal data, **this Addendum shall prevail**.
1.5.
The applicable legislation for the purposes of this Addendum is the legislation of the Republic of Kazakhstan, unless explicitly provided otherwise by the Principal Agreement.
2. Terms and Roles
2.1. Platform
Platform – the gro.now hardware and software complex, including web interfaces, mobile applications (app), backend services, AI-based analytics modules, data connectors, SDK, and (if any) API, as well as related documentation.
2.2. Operator / Controller
Operator / Controller – the Client who independently determines the purposes and (or) content of personal data processing and provides the Processor with instructions for their processing within the framework of the Principal Agreement.
2.3. Processor
Processor – “Pwron” LLP, the Platform owner, processing personal data according to the instructions of the Operator (Controller) and in its interests.
2.4. Subprocessor
Subprocessor – a third party engaged by the Processor to perform individual personal data processing operations on behalf of the Processor and on terms ensuring a level of protection no lower than that established by this Addendum.
2.5. Personal Data (PD)
Personal Data (PD) – any information relating to an identified or identifiable natural person (Data Subject), including, but not limited to: identification data, contact data, service usage data, technical identifiers, respondent answers, and other categories described in Appendix 1.
2.6. Processing
Processing – any action (operation) or set of actions with PD, including collection, recording, systematization, storage, clarification (updating, modification), extraction, use, transfer (distribution, provision, access), anonymization, blocking, deletion, destruction.
2.7. Data Subject
Data Subject – a natural person to whom the PD relates (including Client employees and representatives, respondents, integration users, and other persons, as specified in Appendix 1).
2.8. Activity
Activity – any participation scenario for Respondents on the gro.now Platform, conducted at the instruction of the Operator or by the Processor independently, including, but not limited to: electronic Surveys, other research, tests, contests, sweepstakes, games, referral mechanisms, and other forms of interaction.
2.9. Respondent
Respondent – a natural person participating in the Activity and providing their personal data during participation.
2.10. Operator Instructions
Operator Instructions – documented (including electronic) instructions from the Operator to the Processor regarding the purposes, categories of PD, processing operations, retention periods, transfer, deletion, and other parameters. Instructions may be contained in the Principal Agreement, account/project settings in gro.now, support requests, integration specifications, and other written communications.
2.11. Security Incident (PD Security Breach)
Security Incident (PD Security Breach) – an event that resulted in or may result in accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access to PD processed by the Processor.
2.12. Technical and Organizational Measures (TOMs)
Technical and Organizational Measures (TOMs) — a set of measures for PD protection applied by the Processor and listed in Appendix 2 or a separate agreement with the Operator.
2.13. Cross-Border Transfer
Cross-Border Transfer — the transfer of PD to the territory of a foreign state, to servers or third parties located outside the jurisdiction defined by the Principal Agreement, as well as remote access to PD from such a jurisdiction.
2.14. Applicable Law
Applicable Law – the legislation subject to application to the relations between the Parties under this Addendum, as defined in Section 1 and the Customer Agreement, including local RK requirements and other mandatory norms for cross-border processing.
2.15. Confidential Information
Confidential Information – any information of a Party, explicitly designated as confidential or considered such by its nature (including PD), disclosed to the other Party in connection with this Addendum.
2.16. Aggregated/Anonymized Data
Aggregated/Anonymized Data – data processed in such a way that the Data Subject is not identified and is not identifiable, subject to compliance with anonymization procedures; such data are not considered PD.
2.17. Roles and Their Segregation.
a) **Processor** acts solely as a **processor** in relation to PD processed according to Operator Instructions;
b) In terms of PD that the Processor processes for its own purposes (e.g., accounting, infrastructure security, anti-fraud), the Processor acts as an **independent operator/controller** – such processing is governed by the Privacy Policy and is not covered by this Addendum.
c) In terms of data obtained from external sources and integrations (e.g., SSO accounts, calendar slots, trackers), the Processor's role is determined by the Operator's Instructions and the description in Appendix 1; if integration providers have their own purposes, they act as independent operators.
b) In terms of PD that the Processor processes for its own purposes (e.g., accounting, infrastructure security, anti-fraud), the Processor acts as an **independent operator/controller** – such processing is governed by the Privacy Policy and is not covered by this Addendum.
c) In terms of data obtained from external sources and integrations (e.g., SSO accounts, calendar slots, trackers), the Processor's role is determined by the Operator's Instructions and the description in Appendix 1; if integration providers have their own purposes, they act as independent operators.
3. Subject Matter of DPA and Client's Instructions
3.1.
This Addendum defines the terms and procedure for the Processor's processing of personal data transmitted to it by the Operator or collected by the Processor on behalf of the Operator during the provision of Platform services, including the conduct and support of Activities.
3.2.
Processing is carried out solely in the scope and for the purposes determined by the Operator and documented in:
- (i) the Customer Agreement and its appendices;
- (ii) account/project settings, configurations of Activities and forms on the gro.now platform;
- (iii) technical specifications of integrations and API;
- (iv) written/electronic Operator Instructions transmitted through the platform interface or official communication channels.
3.3. The Processor undertakes to:
- (i) process PD **only according to Operator Instructions**, except for cases of mandatory processing by law;
- (ii) **not use PD for its own purposes** unrelated to the fulfillment of the Operator's instructions;
- (iii) **not disclose/transfer PD to third parties**, except in cases explicitly provided for by the DPA, the Principal Agreement, or the law;
- (iv) apply the appropriate TOMs (see Appendix 2 or a separate agreement with the Operator).
3.4.
If the Operator's Instruction, in the Processor's reasonable opinion, contradicts the applicable PD law, the Processor **immediately notifies** the Operator and **suspends** the execution of such Instruction until clarification.
3.5.
When the Operator instructs the Processor to **collect PD directly from Respondents** (through forms and other Activity mechanisms), the Processor acts as a **technical intermediary**, ensuring the infrastructure for data collection, storage, routing, and visualization on behalf of the Operator. In this case, the Operator must:
(i) define the purposes and legal bases for Respondent processing;
(ii) ensure proper informing of Respondents and the content of notifications;
(iii) use consent/notification texts and mechanisms consistent with the **Personal Data Processing Policy for Respondents**.
(i) define the purposes and legal bases for Respondent processing;
(ii) ensure proper informing of Respondents and the content of notifications;
(iii) use consent/notification texts and mechanisms consistent with the **Personal Data Processing Policy for Respondents**.
3.6.
The gro.now Platform may include automated functions (analytics, statistics, visualization, integrity control, etc.), the use of which is entrusted to the Processor solely for fulfilling Operator Instructions and without expanding the processing purposes. Separately from this, the Processor may carry out its own anti-fraud and other infrastructure security functions as an **independent operator/controller** in the scope described in the Privacy Policy, which is not covered by this DPA.
3.7.
The Processor has the right to rely on Instructions recorded in the platform's electronic logs, Activity settings, integration parameters, and correspondence through official channels, as valid written Instructions from the Operator.
3.8.
Processor's Independent Activities. If the Processor conducts an Activity independently (not on the Operator's behalf) for its own purposes, the Processor acts as an **independent operator/controller**; such processing is not covered by this DPA and is governed by the Privacy Policy and the Personal Data Processing Policy for Respondents. Within the framework of this DPA, the Processor **does not pursue its own purposes** when processing Respondent PD on behalf of the Operator.
4. Categories of Data and Data Subjects
4.1.
The Processor processes personal data transmitted by the Operator or collected on its behalf, concerning the following categories of data subjects:
- a) **Respondents** – natural persons participating in Activities conducted on the Platform;
- b) **Operator Employees and Representatives** – persons having access to the platform and participating in Activity management or data processing;
- c) **Integration and External Service Users** (e.g., analytics systems, CRM, mailings), if the data of such users are transferred or synchronized with gro.now;
- d) **Other Persons** whose personal data may be included in Activity results or transferred by the Operator to the Processor (e.g., clients, partners, loyalty program participants).
4.2. Categories of Personal Data,
Categories of personal data processed within the framework of this Addendum may include:
a) **Identification Data** (name, surname, nickname, ID in the system, account, email, phone number, etc.);
b) **Contact Data** (postal address, country, time zone, interface language, etc.);
c) **Respondent Answers and Content**, provided by them within the framework of Activities (e.g., textual, numerical, audio, or visual data, attached files);
d) **Technical Data** (IP addresses, device identifiers, cookie and SDK data, log data, browser data, referral source, date and time of activity);
e) **Metadata on Platform Use**, including login history, actions, and changes in projects;
f) **Data of Operator Employees and Representatives**, transferred for the purposes of account registration, authentication, administration, and support;
g) **Other Categories of Data**, defined in Appendix 1 and Operator Instructions.
a) **Identification Data** (name, surname, nickname, ID in the system, account, email, phone number, etc.);
b) **Contact Data** (postal address, country, time zone, interface language, etc.);
c) **Respondent Answers and Content**, provided by them within the framework of Activities (e.g., textual, numerical, audio, or visual data, attached files);
d) **Technical Data** (IP addresses, device identifiers, cookie and SDK data, log data, browser data, referral source, date and time of activity);
e) **Metadata on Platform Use**, including login history, actions, and changes in projects;
f) **Data of Operator Employees and Representatives**, transferred for the purposes of account registration, authentication, administration, and support;
g) **Other Categories of Data**, defined in Appendix 1 and Operator Instructions.
4.3.
In relation to data **collected directly from Respondents**, the Processor acts as a **technical intermediary** and does not determine the content or legality of the transmitted data. Responsibility for the legality of purposes, completeness, and relevance of such data **rests with the Operator**.
4.4.
The Operator must **not transmit** to the Processor personal data relating to special categories (biometric, genetic, health information, political views, religious beliefs, etc.) if their processing **is not provided for** by the Principal Agreement or a separate written consent of the Processor.
4.5.
The Processor has the right to **anonymize or aggregate** personal data for the purposes of testing, performance analysis, and service quality improvement, provided that such data **do not allow identification** of a specific data subject.
4.6.
The list and description of categories of personal data, as well as the corresponding data subjects and processing purposes, are provided in Appendix 1 to this Addendum.
5. Legal Bases on the Client's Side
5.1. Operator's Responsibility.
The Operator confirms and guarantees that it possesses all necessary legal bases for instructing the processing of personal data to the Processor (contract, law, consent, legitimate interest, etc.), including the processing of Respondent data within the scope of Activities.
5.2. Informing Data Subjects.
The Operator ensures proper and timely **informing** of Respondents and other data subjects about the purposes, scope, timeframes, recipients, cross-border transfer, data subject rights, and the Processor's role as a processor. When using the Processor's materials (templates of banners/notifications), the Operator is responsible for their relevance and compliance with the specific Activity.
5.3. Consents (where applicable).
If the legal basis is consent, the Operator:
a) obtains **free, specific, informed, and unambiguous** consent;
b) documents the fact of obtaining and the possibility of withdrawal;
c) ensures that the consent text is consistent with the **Personal Data Processing Policy for Respondents** and the terms of the specific Activity.
a) obtains **free, specific, informed, and unambiguous** consent;
b) documents the fact of obtaining and the possibility of withdrawal;
c) ensures that the consent text is consistent with the **Personal Data Processing Policy for Respondents** and the terms of the specific Activity.
5.4. Special Categories and “Sensitive” Data.
Transfer of special categories of data (e.g., health information, biometrics) to the Processor is allowed **only with the corresponding basis and prior written agreement** with the Processor. The Operator undertakes **not to transmit** such data by default.
5.5. Minors.
If the Activity involves the participation of minors, the Operator confirms the availability of the necessary legal bases and **additional notifications/consents** of legal representatives, as well as correct **age verification** (age-gating), if required.
5.6. Integrations and Third-Party Sources.
When connecting integrations (e.g., SSO providers, calendar/communication services, CRM, analytics), the Operator ensures the availability of a legal basis for data transfer to gro.now and **proper notification of data subjects** about such transfers and recipients.
5.7. Cross-Border Transfer.
The Operator confirms the **legality of cross-border PD transfer** (including placement/access outside the Operator's jurisdiction) and, if necessary, the application of corresponding legal mechanisms (contractual clauses/standard provisions/other tools), taking into account the requirements of applicable law.
5.8. Minimization and Relevance.
The Operator undertakes to transfer to the Processor only the **minimally necessary volume of PD**, ensure their **accuracy and relevance**, and eliminate excessive or erroneous data.
5.9. Legality of Activity Content.
The Operator is responsible for the legality of the content of Activities, formulas, and questions, as well as for preventing the request of excessive or prohibited categories of data from Respondents.
5.10. Documentation and DPIA.
The Operator **maintains necessary records of processing**, conducts impact assessment (**DPIA**) if necessary, and ensures the fulfillment of other controller obligations under applicable law.
5.11. Data Subject and Authority Requests.
The Operator receives and validates initial requests from data subjects and state bodies and sends the Processor **only valid and relevant instructions** necessary for the execution of such requests in the part related to the Processor.
5.12. No Delegation of Obligations.
Nothing in this Addendum **shall be construed as a delegation to the Processor of the Operator's obligations** for choosing the legal basis, informing, obtaining consents, assessing the lawfulness of Activities, or the content of requests to Respondents.
6. Location and Regime of Processing. Cross-Border Transfer
6.1. Processing Locations.
Processing of PD under this Addendum is carried out by the Processor and/or its Subprocessors in data centers and locations specified in Appendix 1 (description of processing) and Appendix 3 (list of Subprocessors). Actual locations may include the territory of the Republic of Kazakhstan and other jurisdictions, if necessary for the provision of gro.now platform services.
6.2. Remote Access.
The provision of remote access to PD from another jurisdiction is qualified as **cross-border transfer**. Such access is allowed **strictly on a need-to-know basis** and subject to compliance with TOMs (Appendix 2 or a separate agreement with the Operator).
6.3. Triggers for Cross-Border Transfer.
Cross-border transfer (including access) may occur during:
a) hosting and backup;
b) use of cloud Subprocessors (SaaS/PaaS/IaaS);
c) incidents requiring escalation/support;
d) connection of integrations according to Operator Instructions;
e) activation of fault tolerance/DR mechanisms.
a) hosting and backup;
b) use of cloud Subprocessors (SaaS/PaaS/IaaS);
c) incidents requiring escalation/support;
d) connection of integrations according to Operator Instructions;
e) activation of fault tolerance/DR mechanisms.
6.4. Legal Mechanisms.
For each respective transfer, the Processor ensures the availability of **contractual guarantees and other mechanisms** permitted by applicable law (including standard/modular clauses, additional obligations, assessment of law enforcement practice in the receiving country), and the Operator ensures the availability of a **legal basis for transfer** in relation to its data subjects (Section 5).
6.5. Local Law Restrictions.
If mandatory requirements of the Operator's local law provide for special conditions/prohibitions on cross-border transfer, the Operator:
a) notifies the Processor before the start of the relevant processing;
b) specifies the necessary restrictions in the Instructions;
c) if necessary – chooses a processing configuration without cross-border transfer or provides additional guarantees. The Processor assists where possible, taking into account technical feasibility.
a) notifies the Processor before the start of the relevant processing;
b) specifies the necessary restrictions in the Instructions;
c) if necessary – chooses a processing configuration without cross-border transfer or provides additional guarantees. The Processor assists where possible, taking into account technical feasibility.
6.6. Logging and Transparency.
The Processor maintains internal records of processing and, upon the Operator's request, provides **generalized information** about the categories of transfers (type, purpose, recipients/jurisdictions) within reasonable sufficiency and without disclosing confidential security details.
6.7. Failover and Disaster Recovery.
When activating fault tolerance and disaster recovery (DR) procedures, PD may be temporarily processed in an alternative location. The Processor guarantees that such locations and providers are included in Appendix 3 or are provided with an equivalent level of protection and contractual guarantees comparable to the main environments.
6.8. Integrations and External Recipients.
When activating integrations (SSO, calendar, communication, CRM, analytics, etc.), the Operator determines the geography and legal terms of transfer to the respective services. The Processor ensures transfer/access in the scope of the Operator's Instructions and informs the Operator of the role of such providers as **independent operators** where they have their own processing purposes.
6.9. State Authority Requests.
In case of receiving a mandatory request from a competent authority for access to PD, the Processor, **if not prohibited by law, immediately notifies the Operator** and limits the provision of data to the minimally necessary volume, documenting the legal basis for the disclosure.
6.10. Prohibition of Unauthorized Routing.
The Processor **does not carry out cross-border transfer of PD to jurisdictions not specified in Appendices 1, 3, without prior notification to the Operator**, except in cases where such transfer is explicitly required by law or necessary for the immediate prevention/localization of a Security Incident; in such a case, notification is sent without undue delay.
7. Technical and Organizational Measures (TOMs)
7.1. General Principle.
The Processor applies a set of technical and organizational protection measures (hereinafter – **TOMs**) to ensure the confidentiality, integrity, availability, and resilience of personal data processed on the Platform, in accordance with the risks and scale of processing.
7.2. Standards and Security Management.
a) The Processor's PD protection system is built taking into account international and national standards (including ISO/IEC 27001, ISO/IEC 27018, NIST SP 800-53, and recommendations of authorized RK bodies).
b) The Processor implements an information security policy, including role segregation, access control, incident management, backup, and data recovery.
c) TOMs extend to the proprietary infrastructure, as well as to all Subprocessors engaged for performing processing operations.
b) The Processor implements an information security policy, including role segregation, access control, incident management, backup, and data recovery.
c) TOMs extend to the proprietary infrastructure, as well as to all Subprocessors engaged for performing processing operations.
7.3. Access Control.
a) Access for the Processor's employees and contractors is granted **strictly on a "need-to-know" basis**.
b) **Multi-factor authentication (MFA)** is used for all administrative accounts.
c) All accesses are logged, and user actions are recorded in event journals stored in a secure environment.
d) Accesses are reviewed regularly, and upon dismissal or change of role are **immediately revoked**.
b) **Multi-factor authentication (MFA)** is used for all administrative accounts.
c) All accesses are logged, and user actions are recorded in event journals stored in a secure environment.
d) Accesses are reviewed regularly, and upon dismissal or change of role are **immediately revoked**.
7.4. Environment Separation and Change Management.
a) The production environment is physically and logically **isolated** from the test and development environments.
b) All changes in code, infrastructure, and configurations undergo an **internal approval and testing** procedure, including security analysis.
c) Versioning, rollback, and change logging mechanisms are used.
b) All changes in code, infrastructure, and configurations undergo an **internal approval and testing** procedure, including security analysis.
c) Versioning, rollback, and change logging mechanisms are used.
7.5. Monitoring and Incident Detection.
a) The gro.now infrastructure is under **monitoring** for failures, attempts at unauthorized access, and anomalous activity.
b) The automatic notification system sends alerts to responsible specialists upon detection of critical events.
c) All incidents are classified by impact level and documented in accordance with the response procedure (Section 9).
b) The automatic notification system sends alerts to responsible specialists upon detection of critical events.
c) All incidents are classified by impact level and documented in accordance with the response procedure (Section 9).
7.6. Backup and Recovery.
a) **Periodic** backup is performed at a set frequency, ensuring data recovery in case of accidents or loss.
b) Backups are stored in an **encrypted form** on separate media/in cloud environments with an equivalent level of protection.
c) Recovery procedures are checked **at least once a year**.
b) Backups are stored in an **encrypted form** on separate media/in cloud environments with an equivalent level of protection.
c) Recovery procedures are checked **at least once a year**.
7.7. Minimization and Retention Limitation.
a) The Processor ensures **minimization of the volume** of processed data and **retention periods** in accordance with the Operator's Instructions.
b) Upon expiration of the retention period, data are **deleted or anonymized**, including copies in backup storage (where technically feasible), with documentation of the fact of deletion.
b) Upon expiration of the retention period, data are **deleted or anonymized**, including copies in backup storage (where technically feasible), with documentation of the fact of deletion.
7.8. Physical Security.
a) Data centers used by the Processor and Subprocessors are **certified** and equipped with access control systems, video surveillance, fire protection, and backup power.
b) Physical access is allowed only to authorized personnel.
b) Physical access is allowed only to authorized personnel.
7.9. Vulnerability Management and Security Testing.
a) The Processor regularly performs **vulnerability scanning** and conducts **internal penetration tests**.
b) Discovered vulnerabilities are **remedied within a reasonable timeframe** depending on criticality.
c) The Operator may request **generalized information** on the conduct of tests and implemented measures (without disclosing confidential architectural details).
b) Discovered vulnerabilities are **remedied within a reasonable timeframe** depending on criticality.
c) The Operator may request **generalized information** on the conduct of tests and implemented measures (without disclosing confidential architectural details).
7.10. Personnel Training.
Employees allowed to process PD undergo **mandatory training** on information security and confidentiality before commencing their duties, including rules for data handling, incident response, and DPA compliance.
7.11. Certificates and Audit.
a) The Processor has the right to confirm compliance with security measures through internal or external audits.
b) Upon the Operator's request, the Processor provides **current certificates** and/or confirmation of independent checks within reasonable limits.
b) Upon the Operator's request, the Processor provides **current certificates** and/or confirmation of independent checks within reasonable limits.
7.12. Description of Measures.
A detailed list of the applied TOMs is provided in **Appendix 2** to this Addendum or a separate agreement with the Operator.
8. Subprocessors
8.1. General Rule.
The Processor has the right to engage third parties (**Subprocessors**) to perform individual personal data processing operations on behalf of the Operator, provided that such persons ensure a level of personal data protection **no lower** than that established in this Addendum.
8.2. Conditions for Engagement.
Before engaging a Subprocessor, the Processor:
a) conducts an **assessment of its reliability** and compliance with security and confidentiality requirements;
b) concludes an agreement with it containing provisions **equivalent** to the Processor's obligations under this DPA;
c) ensures the inclusion of such persons in the current list of Subprocessors (**Annex III**).
a) conducts an **assessment of its reliability** and compliance with security and confidentiality requirements;
b) concludes an agreement with it containing provisions **equivalent** to the Processor's obligations under this DPA;
c) ensures the inclusion of such persons in the current list of Subprocessors (**Annex III**).
8.3. Categories of Subprocessors.
The Processor may engage Subprocessors for the following categories of services:
a) hosting and cloud infrastructures (data centers, CDN, backup);
b) analytics, monitoring, and event logging;
c) authorization, authentication, and security systems (including SSO and MFA);
d) notification, mailing, and communication services;
e) technical support and disaster recovery (DR);
f) large language models;
g) integrations used on the Operator's instruction (e.g., CRM, analytics, marketing).
a) hosting and cloud infrastructures (data centers, CDN, backup);
b) analytics, monitoring, and event logging;
c) authorization, authentication, and security systems (including SSO and MFA);
d) notification, mailing, and communication services;
e) technical support and disaster recovery (DR);
f) large language models;
g) integrations used on the Operator's instruction (e.g., CRM, analytics, marketing).
8.4. Dynamic List Update.
- 8.4.1. The list of current Subprocessors is published by the Processor on the website or in the gro.now administrative panel and is updated as changes occur. The Processor notifies the Operator **in advance, at least 5 calendar days** before engaging a new Subprocessor, except in the following situations where **immediate** (without prior) or **reduced period** notification is allowed:
a) for the prevention or localization of a Security Incident, elimination of a critical vulnerability;
b) for ensuring service continuity/DR (disaster recovery, fault tolerance) in case of sudden unavailability of the previous provider;
c) equivalent replacement of a Subprocessor with another with comparable functions without expanding the purposes, scope, or territory of processing;
d) fulfillment of mandatory requirements of law/regulator;
e) the Operator's activation of a non-mandatory function/integration in the administrative panel, if such function knowingly requires the engagement of a specific Subprocessor. - 8.4.2. In cases a-d, notification is sent **as soon as possible, but no later than 72 hours** from the moment of actual engagement. In case e, notification is considered given at the moment of activation of the function/integration by the Operator (an indication of the Subprocessor is shown in the interface).
8.5. Right to Object.
- 8.5.1. The Operator has the right to send a **justified objection** against a new Subprocessor:
(i) in the usual procedure – **within 5 calendar days** from the moment of notification;
(ii) in the cases provided for in clause 8.4 (accelerated/immediate engagement) – **within 72 hours** from the moment of notification. - 8.5.2. The Parties **in good faith strive to settle** the objection, including:
a) proposing an alternative Subprocessor;
b) temporarily disabling the affected function/integration for the Operator;
c) restricting/localizing processing by territory or data categories. - 8.5.3. If settlement is impossible, the Operator has the right to **terminate the Principal Agreement** in the part of the relevant processing or choose a plan/configuration without the disputed Subprocessor (if available).
8.6. Processor's Responsibility.
The Processor **bears full responsibility** to the Operator for the actions and omissions of Subprocessors engaged by it for PD processing, as for its own, including compliance with security and confidentiality requirements.
8.7. Operator's Subprocessors.
If the Operator independently connects third-party integrations or services (e.g., CRM, SSO, advertising platforms) through the gro.now interface, such persons **are not considered Subprocessors of the Processor**.
In these cases, the Operator is responsible for compliance with legislative requirements and obtaining data subject consents for data transfer to such services.
In these cases, the Operator is responsible for compliance with legislative requirements and obtaining data subject consents for data transfer to such services.
8.8. Subprocessing Outside the Jurisdiction.
If a Subprocessor is located outside the Republic of Kazakhstan, the Processor guarantees that the transfer of PD to it is carried out with the relevant legal basis and **contractual guarantees** (Section 6).
8.9. Notifications and Transparency.
Upon the Operator's request, the Processor provides **generalized information** about Subprocessors, including name, location country, category of services, and a link to their privacy policy.
8.10. Current List.
The current list of Subprocessors engaged by the Processor and the notification procedure are provided in Appendix 3 to this Addendum.
9. Security Incidents and Notifications
9.1. Definition.
A Security Incident (hereinafter – “Incident”) means any event that resulted in or may result in unauthorized access, destruction, loss, alteration, unauthorized disclosure, or other violations of the security of personal data processed by the Processor or its Subprocessors.
9.2. Notification Obligation.
Upon discovery of an Incident, the Processor must:
(i) **immediately** begin investigation and take measures to limit the consequences;
(ii) **notify the Operator without undue delay, but no later than 72 hours** from the moment the Processor became aware of the Incident, if the Incident affects the Operator's PD;
(iii) send the Operator a **preliminary notification** with a brief description of the nature of the Incident, the affected data categories, the estimated number of data subjects, primary response measures, and a contact person for interaction.
(i) **immediately** begin investigation and take measures to limit the consequences;
(ii) **notify the Operator without undue delay, but no later than 72 hours** from the moment the Processor became aware of the Incident, if the Incident affects the Operator's PD;
(iii) send the Operator a **preliminary notification** with a brief description of the nature of the Incident, the affected data categories, the estimated number of data subjects, primary response measures, and a contact person for interaction.
9.3. Further Information.
After the primary notification, the Processor sends **additional information as it is established**, including:
a) the causes and nature of the Incident;
b) the category and volume of the affected PD;
c) a description of the undertaken and planned measures to remedy the consequences;
d) an assessment of the risk to data subjects;
e) recommendations to the Operator for actions (including informing data subjects or authorities, if required by law).
Notifications are sent through the **official communication channel** established between the Parties (email, ticket system, secure channel). The Processor has the right to use **automated notification** in case of mass or infrastructure incidents, if it ensures reliable delivery of information.
a) the causes and nature of the Incident;
b) the category and volume of the affected PD;
c) a description of the undertaken and planned measures to remedy the consequences;
d) an assessment of the risk to data subjects;
e) recommendations to the Operator for actions (including informing data subjects or authorities, if required by law).
Notifications are sent through the **official communication channel** established between the Parties (email, ticket system, secure channel). The Processor has the right to use **automated notification** in case of mass or infrastructure incidents, if it ensures reliable delivery of information.
9.5. Classification and Priority.
The Processor classifies Incidents by impact level (critical, high, medium, low) in accordance with the methodology agreed in the **SLA**, and ensures **priority response** to Incidents that:
a) are related to the leak or disclosure of Respondent PD;
b) affect the confidentiality of Activity data;
c) may entail violations of data subject rights or the Operator's obligations to supervisory authorities.
a) are related to the leak or disclosure of Respondent PD;
b) affect the confidentiality of Activity data;
c) may entail violations of data subject rights or the Operator's obligations to supervisory authorities.
9.6. Joint Response.
The Operator undertakes to **cooperate with the Processor** during the Incident investigation, including providing information on data specifics and Activity settings, if necessary for analysis and remediation.
9.7. Documentation.
All Incidents are subject to **internal registration and investigation** in accordance with the Processor's security policy. Upon the Operator's request, the Processor provides a **generalized report** on the investigation results (Root Cause Analysis, RCA) with an indication of the undertaken corrective actions.
9.8. Incidents with Subprocessors.
If an Incident occurred with a Subprocessor, the Processor must obtain full information from it and send a notification to the Operator within the timeframes established in clause 9.2, as practically feasible. Furthermore, the Processor **retains general responsibility** for interaction with the Subprocessor and measures to remedy the consequences.
9.9. Operator's Violations.
If an Incident is caused by the Operator's actions or omissions (e.g., incorrect Activity settings, credential leak), the Processor has the right to assist in minimizing the consequences, while all costs and responsibility **rest with the Operator**.
9.10. Disclosure to Third Parties.
The Processor **does not disclose** information about the Incident to third parties, except in cases where:
a) disclosure is required by law or an authorized body;
b) it is necessary for interaction with Subprocessors involved in remediation;
c) disclosure is made **in an aggregated form, without identification** of the Operator or its data (e.g., in vulnerability reports).
a) disclosure is required by law or an authorized body;
b) it is necessary for interaction with Subprocessors involved in remediation;
c) disclosure is made **in an aggregated form, without identification** of the Operator or its data (e.g., in vulnerability reports).
9.11. Incidents Not Affecting PD.
Operational failures, momentary unavailability, or performance problems not affecting the security or confidentiality of PD are governed by the **SLA** and the Customer Agreement, and **not this section**.
10. Interaction on Data Subject Rights
10.1. General Principle.
The Processor provides the Operator with **assistance** in fulfilling obligations to ensure the rights of data subjects, including Respondents, within the technical and organizational capabilities of the Platform, as provided for in the Principal Agreement and this Addendum.
10.2. Data Subject Rights.
In accordance with applicable legislation, data subjects (including Respondents) may possess the following rights:
a) to access their personal data;
b) to rectify, update, or supplement data;
c) to restrict processing or withdraw consent;
d) to erasure (right to be forgotten);
e) to data portability;
f) to object to processing or automated decision-making;
g) to receive information about data recipients and their retention periods.
a) to access their personal data;
b) to rectify, update, or supplement data;
c) to restrict processing or withdraw consent;
d) to erasure (right to be forgotten);
e) to data portability;
f) to object to processing or automated decision-making;
g) to receive information about data recipients and their retention periods.
10.3. Receiving Requests.
a) All data subject appeals are received **primarily by the Operator**, who is the Controller.
b) If the Processor receives a request directly from a data subject, it **notifies the Operator without undue delay and does not respond independently**, except in cases where the obligation to respond is explicitly established by law.
c) The Processor has the right to confirm receipt of the appeal to the data subject and inform that it will be processed by the Operator.
b) If the Processor receives a request directly from a data subject, it **notifies the Operator without undue delay and does not respond independently**, except in cases where the obligation to respond is explicitly established by law.
c) The Processor has the right to confirm receipt of the appeal to the data subject and inform that it will be processed by the Operator.
10.4. Assistance to the Operator.
The Processor provides the Operator with **reasonable assistance** in fulfilling data subject requests, including:
a) searching, extracting, rectifying, blocking, or deleting PD within technical capabilities;
b) providing information about the systems in which the data are stored;
c) ensuring an exportable data format (e.g., CSV, JSON) for portability purposes.
a) searching, extracting, rectifying, blocking, or deleting PD within technical capabilities;
b) providing information about the systems in which the data are stored;
c) ensuring an exportable data format (e.g., CSV, JSON) for portability purposes.
10.5. Execution Timeframes.
The Operator determines the timeframes and format for responding to the data subject in accordance with applicable law. The Processor provides assistance within a **reasonable timeframe, usually no later than 10 business days** from receiving the request from the Operator, unless a different timeframe is agreed upon in writing.
10.6. Technical Restrictions.
a) If the execution of the request is **technically impossible** (e.g., due to anonymization or data deletion), the Processor notifies the Operator with an explanation of the reasons.
b) In cases where the data subject's request affects data in backups, the Processor performs deletion within the framework of **backup storage update procedures**.
b) In cases where the data subject's request affects data in backups, the Processor performs deletion within the framework of **backup storage update procedures**.
10.7. State Authority Requests.
If the Processor receives a request from a supervisory authority, court, or law enforcement agencies concerning PD related to the Operator or its Respondents, the Processor, if not prohibited by law:
a) **immediately notifies the Operator**;
b) consults with it regarding the volume of information to be disclosed;
c) limits disclosure to the **minimally necessary volume of data** and documents the grounds for provision.
a) **immediately notifies the Operator**;
b) consults with it regarding the volume of information to be disclosed;
c) limits disclosure to the **minimally necessary volume of data** and documents the grounds for provision.
10.8. Record Keeping.
The Processor maintains a **log of data subject and authority requests** concerning PD processed on behalf of the Operator. Upon the Operator's request, the Processor provides **generalized statistics** of appeals without disclosing confidential information.
10.9. Respondent Notifications.
When conducting Activities, notifications and messages concerning Respondent rights are formed and placed by the Operator. The Processor provides technical capabilities for their display and the recording of consents, but **is not responsible for their content**.
10.10. Limitations and Responsibility.
The Processor **is not responsible** for the content of answers, the completeness of information, or for untimely or incorrect execution of data subject requests if this is caused by the actions or omissions of the Operator, its employees, or Subprocessors engaged by it independently.
11. Audits and Inspections
11.1. “Information-First” Format.
The Operator agrees that the primary and sufficient means of confirming the Processor's compliance with the requirements are:
a) current **certificates/confirmations** (e.g., ISO/IEC 27001/27018),
b) **reports of independent assessments and tests** (generalized conclusions without disclosing confidential details),
c) **due diligence questionnaires** and responses thereto.
The provision of items a–c satisfies the Operator's right to audit without additional interference.
a) current **certificates/confirmations** (e.g., ISO/IEC 27001/27018),
b) **reports of independent assessments and tests** (generalized conclusions without disclosing confidential details),
c) **due diligence questionnaires** and responses thereto.
The provision of items a–c satisfies the Operator's right to audit without additional interference.
11.2. Remote Document Audit.
If the Operator has justified questions remaining after clause 11.1, it has the right to send a written request for additional information **no more than once every 12 months**. The Processor provides a reasonable package of information (high-level policies, role matrix, description of TOMs in the context of Appendix 2) **without disclosing architectural secrets, source codes, or data of other clients**.
11.3. On-Site Audit – Only on Exceptional Grounds.
On-site inspection at the Processor's premises is allowed **only if the following conditions are simultaneously met**:
a) there is a ** confirmed Incident** affecting the Operator's PD, or documented signs of a material breach of the DPA;
b) measures under clauses 11.1-11.2 are **objectively insufficient** to answer specific questions;
c) the Operator has sent a notification **30 calendar days in advance** with justification of the goals, scope, and list of requested artifacts.
The Processor has the right to propose alternatives (additional documents, managed remote access to logs, interviews with responsible persons). On-site audit is conducted **only when necessary**, in a volume minimally sufficient to confirm the conclusions.
a) there is a ** confirmed Incident** affecting the Operator's PD, or documented signs of a material breach of the DPA;
b) measures under clauses 11.1-11.2 are **objectively insufficient** to answer specific questions;
c) the Operator has sent a notification **30 calendar days in advance** with justification of the goals, scope, and list of requested artifacts.
The Processor has the right to propose alternatives (additional documents, managed remote access to logs, interviews with responsible persons). On-site audit is conducted **only when necessary**, in a volume minimally sufficient to confirm the conclusions.
11.4. Restriction of Scope and Access.
During any audit:
a) **access to the data and systems of other clients and to Respondent data in open form is prohibited**; only masked/demo data or selective fragments of logs, purged of secrets, are allowed;
b) **vulnerability scanning, stress tests, export/copying of artifacts, imaging, photo/video, connection of external media and software are prohibited**;
c) auditors **must not be competitors** of the Processor;
d) the audit is conducted **during business hours, for no more than 1 business day**, in a specially prepared area or virtual session;
e) any information discovered is considered **Confidential Information** of the Processor.
a) **access to the data and systems of other clients and to Respondent data in open form is prohibited**; only masked/demo data or selective fragments of logs, purged of secrets, are allowed;
b) **vulnerability scanning, stress tests, export/copying of artifacts, imaging, photo/video, connection of external media and software are prohibited**;
c) auditors **must not be competitors** of the Processor;
d) the audit is conducted **during business hours, for no more than 1 business day**, in a specially prepared area or virtual session;
e) any information discovered is considered **Confidential Information** of the Processor.
11.5. Approval of Persons and NDA.
The Operator uses only **previously approved auditors**. All auditors sign the **Processor's NDA** in the Processor's version. The Processor has the right to **reject** an auditor if there is a conflict of interest/security risks.
11.6. Payment and Costs.
All costs of the Operator and auditors **are borne by the Operator**. If the audit requires significant resources from the Processor (more than 8 person-hours in total), the Operator reimburses the Processor for **reasonable costs** at the rate specified in the pricing/Terms.
11.7. Results and Corrections.
Following the audit, auditors provide the Operator and the Processor with a **brief report without disclosing secrets**. Discovered non-conformities are classified by criticality. The Processor develops **corrective measures** within a reasonable timeframe, taking into account criticality and technical feasibility.
11.8. Frequency and Combination.
Repeated audits on the same grounds **are not allowed earlier than 12 months** later, except for verification of the remediation of critical non-conformities (a limited volume remote review).
11.9. Refusal if Risk of Harm.
The Processor has the right to **refuse or suspend an audit** if it creates a threat to platform security, violates the rights of third parties, or contradicts law/security obligations; in such a case, the Processor offers **equivalent compensatory procedures** (additional documents, targeted interviews, managed log viewing).
11.10. No Access to Production Data.
Under no circumstances does the audit **grant** the Operator or auditors **direct access to production Respondent PD** or means for their decryption. Verification is confirmed through **control procedures and artifacts** that do not disclose PD.
12. Confidentiality and Processor Personnel
12.1. Confidentiality Obligation.
The Processor undertakes to **keep confidential** all Confidential Information received from the Operator in connection with the execution of this Addendum, including personal data, technical specifications, and information about Activities. Confidentiality is maintained **indefinitely**, including after the termination of the DPA and the Principal Agreement.
12.2. Access to Personal Data.
a) Access to PD is granted **only to authorized employees** of the Processor who need it for the performance of their official duties (the **need-to-know** principle).
b) The Processor **maintains records** of all persons having access to PD and ensures control over their compliance with security procedures.
c) Access to the production environment is carried out through personalized accounts with mandatory use of **multi-factor authentication (MFA) and logging** of actions.
b) The Processor **maintains records** of all persons having access to PD and ensures control over their compliance with security procedures.
c) Access to the production environment is carried out through personalized accounts with mandatory use of **multi-factor authentication (MFA) and logging** of actions.
12.3. Personnel Obligations.
a) All employees and contractors of the Processor allowed to process PD undergo **training on data protection and confidentiality** before commencing their duties.
b) Each employee **signs a non-disclosure obligation** and personal responsibility for breach of confidentiality.
c) Upon termination of employment or change of role, the employee's access to systems containing PD is **immediately blocked**.
b) Each employee **signs a non-disclosure obligation** and personal responsibility for breach of confidentiality.
c) Upon termination of employment or change of role, the employee's access to systems containing PD is **immediately blocked**.
12.4. Information Transfer within the Processor's Group of Persons.
The Processor has the right to transfer PD and other Confidential Information to its affiliates (within the corporate group) provided that:
a) such persons are under **analogous confidentiality obligations**;
b) processing is carried out for the purpose of executing this DPA;
c) the transfer **does not expand the territory or purposes** of processing established in Appendix 1
d) the Processor **retains full responsibility** for the actions of affiliates.
a) such persons are under **analogous confidentiality obligations**;
b) processing is carried out for the purpose of executing this DPA;
c) the transfer **does not expand the territory or purposes** of processing established in Appendix 1
d) the Processor **retains full responsibility** for the actions of affiliates.
12.5. Restriction of Disclosure.
The Processor **does not disclose** Confidential Information to third parties, except in cases where:
a) disclosure is **explicitly permitted** by this DPA or Operator Instructions;
b) disclosure is required by **law, court act, or request** of an authorized body, and the Processor, if not prohibited by law, **notifies the Operator in advance**;
c) disclosure is necessary for a Subprocessor to perform the entrusted operations and is accompanied by equivalent confidentiality obligations;
d) information is disclosed in an **anonymized, aggregated, or statistical form**, excluding the identification of the Operator or data subjects.
a) disclosure is **explicitly permitted** by this DPA or Operator Instructions;
b) disclosure is required by **law, court act, or request** of an authorized body, and the Processor, if not prohibited by law, **notifies the Operator in advance**;
c) disclosure is necessary for a Subprocessor to perform the entrusted operations and is accompanied by equivalent confidentiality obligations;
d) information is disclosed in an **anonymized, aggregated, or statistical form**, excluding the identification of the Operator or data subjects.
12.6. Confidentiality in Activities.
When processing Respondent data within the scope of Activities, the Processor ensures that access to answers and other materials is granted **only to persons specified in the Operator's Instructions**.
Any use or viewing of Activity data by the Processor's employees is allowed **solely for official purposes** related to technical support, debugging, or security.
Any use or viewing of Activity data by the Processor's employees is allowed **solely for official purposes** related to technical support, debugging, or security.
12.7. Operator's Obligations.
The Operator is also obliged to maintain the confidentiality of technical solutions, architecture, logs, documentation, API, and other information received from the Processor, and **not disclose them to third parties without the Processor's written consent**.
12.8. Distinction between Confidentiality and Public Data.
Information is not considered Confidential if:
a) it is publicly available on lawful grounds;
b) it became known to the Party from other sources prior to its disclosure;
c) it was disclosed with the written consent of the other Party;
d) it is required for the fulfillment of legal obligations, provided the other Party is notified.
a) it is publicly available on lawful grounds;
b) it became known to the Party from other sources prior to its disclosure;
c) it was disclosed with the written consent of the other Party;
d) it is required for the fulfillment of legal obligations, provided the other Party is notified.
12.9. Consequences of Violation.
In case of a breach of confidentiality, the **liable Party compensates for proven losses** within the limits of liability established by the Principal Agreement, except in cases of **willful misconduct or gross negligence**, when the limitation of liability **does not apply**.
13. Data from Open Sources and Source Restrictions
13.1. General Position.
The Processor has the right to use data obtained from **open sources** (including publicly available websites, databases, catalogs, social networks, and other resources) when executing this Addendum, provided such data are processed **exclusively in an aggregated, anonymized, or analytical form** and **the rights of data subjects and third parties are not violated**.
13.2. Availability Restrictions.
The Operator acknowledges and agrees that the availability of data from external open sources **is not guaranteed** and may change due to reasons beyond the Processor's control, including:
a) changes in privacy policies or access settings by source owners;
b) technical restrictions, blocking, or cessation of source operation;
c) introduction of restrictions on automated data extraction or API;
d) changes in the legal regime or regulatory requirements.
a) changes in privacy policies or access settings by source owners;
b) technical restrictions, blocking, or cessation of source operation;
c) introduction of restrictions on automated data extraction or API;
d) changes in the legal regime or regulatory requirements.
13.3.
In these cases, the Processor **is not responsible** for the impossibility or cessation of access to such data, and also has the right to replace the source with an analogous one or **suspend** the corresponding functionality **without violating the terms of this DPA or SLA**.
13.4. Source Replacement or Cessation.
If parsing or integration of data from open sources becomes unavailable, the Processor may:
a) replace the source with another one that provides a comparable result;
b) temporarily disable data collection until access is restored;
c) notify the Operator of the cessation of support for a specific source if its restoration is impossible or economically unfeasible.
Such changes **are not considered a deterioration of service quality** and **do not entail penalties** from the Operator.
a) replace the source with another one that provides a comparable result;
b) temporarily disable data collection until access is restored;
c) notify the Operator of the cessation of support for a specific source if its restoration is impossible or economically unfeasible.
Such changes **are not considered a deterioration of service quality** and **do not entail penalties** from the Operator.
13.5. Restrictions on the Operator's Use of Data.
The Operator undertakes to:
a) use data obtained from open sources through the gro.now platform **exclusively within the lawful purposes of its Activities**;
b) **not disseminate or publish** such data in violation of the terms established by the source owners;
c) **comply with all current terms** of use, licenses, and prohibitions applicable to each specific source;
d) **not extract, combine, or export** data from gro.now for the purpose of creating external databases, unless provided for by the Principal Agreement or a separate agreement.
a) use data obtained from open sources through the gro.now platform **exclusively within the lawful purposes of its Activities**;
b) **not disseminate or publish** such data in violation of the terms established by the source owners;
c) **comply with all current terms** of use, licenses, and prohibitions applicable to each specific source;
d) **not extract, combine, or export** data from gro.now for the purpose of creating external databases, unless provided for by the Principal Agreement or a separate agreement.
13.6. Disclaimer.
The Processor does not guarantee:
a) the **accuracy, completeness, relevance, or reliability** of data obtained from open sources;
b) **constant availability or immutability** of functionality related to such sources;
c) the **absence of errors** caused by changes in external APIs, policies, or data formats.
a) the **accuracy, completeness, relevance, or reliability** of data obtained from open sources;
b) **constant availability or immutability** of functionality related to such sources;
c) the **absence of errors** caused by changes in external APIs, policies, or data formats.
13.7.
All such data are provided “**as is**” and do not constitute a separate obligation of the Processor under the SLA.
13.8. Compliance with Third-Party Rights.
When processing data from open sources, the Processor complies with legislation on personal data protection, intellectual rights, and confidentiality. In cases where a source explicitly prohibits automated extraction or use of data, the Processor **ceases such processing**.
13.9. Responsibility.
The Operator is responsible for any consequences of unlawful use of data from open sources if it acted in violation of this DPA, the terms of the sources, or exceeded the scope of the provided Activities.
13.10. Approval of Changes.
The Processor has the right to change the list of used open sources and the procedure for their processing **without the Operator's prior consent**, provided that the level of data protection remains equivalent. In case changes affect the legal status of the data (e.g., the introduction of processing restrictions), the Processor **notifies the Operator within a reasonable timeframe**.
14. Retention Periods, Deletion, and Return of Data
14.1. General Principle.
The Processor retains personal data transferred or collected on behalf of the Operator **only for the period necessary** to execute the Operator's Instructions and the purposes provided for in the Principal Agreement. Upon expiration of the retention period, the data are subject to deletion or return in the manner established by this section.
14.2. Retention Period.
PD retention periods are determined by:
a) the Operator's Instructions or Activity settings (including the duration of the Activity and the retention period for its results);
b) legislative requirements, if they provide for a longer retention period;
c) the Processor's security and backup policy – **exclusively for disaster recovery (DR) purposes**.
a) the Operator's Instructions or Activity settings (including the duration of the Activity and the retention period for its results);
b) legislative requirements, if they provide for a longer retention period;
c) the Processor's security and backup policy – **exclusively for disaster recovery (DR) purposes**.
14.3.
If a specific period is not defined, data are retained for **no more than 180 calendar days** after the end of the Activity or termination of the agreement with the Operator.
14.4. Data Deletion.
Upon expiration of the retention period, the Processor:
a) **deletes or reliably anonymizes** personal data in active systems;
b) ensures their **deletion from backups** within regular update and overwrite cycles (**no later than 90 calendar days** after deletion from active systems);
c) **documents the fact of deletion** (internal data deletion log).
a) **deletes or reliably anonymizes** personal data in active systems;
b) ensures their **deletion from backups** within regular update and overwrite cycles (**no later than 90 calendar days** after deletion from active systems);
c) **documents the fact of deletion** (internal data deletion log).
14.5.
The Processor has the right to use methods of **irreversible deletion** (e.g., cryptographic wiping, destruction of encryption keys), confirming the impossibility of data recovery.
14.6. Data Return.
Upon written request from the Operator, submitted **no later than 30 calendar days** from the termination of the Principal Agreement, the Processor provides a data export in a machine-readable format (CSV, JSON, or other available format). After the return is completed, the data are subject to deletion, unless the Operator specified otherwise.
14.7.
In the absence of a request within the specified period, the data are considered **unnecessary for the Operator** and are deleted **without additional notification**.
14.8. Recovery Restrictions.
After data deletion, the Processor **cannot restore** them at the Operator's request. Responsibility for creating and retaining own copies of data (within the provided export interfaces) **rests with the Operator**.
14.9. Deletion of Respondent Data.
If the Operator receives a request from a Respondent for the deletion of their personal data, the Operator sends the corresponding Instruction to the Processor. Deletion is performed within the timeframe agreed upon with the Operator, but **no later than 10 business days** after receiving the confirmed Instruction, except in cases where retention is required by law.
14.10. Certificate of Deletion.
Upon the Operator's request, the Processor may provide **confirmation of deletion (certificate of deletion)** in the form of an electronic report, containing the date and description of the actions performed. The provision of the certificate **is a paid service**, unless provided otherwise in the Principal Agreement.
14.11. Anonymization and Statistics.
After the deletion or return of personal data, the Processor has the right to retain **anonymized and aggregated data**, used for statistical, analytical, and technical purposes (e.g., performance improvement, functionality optimization), provided that these data **do not allow the identification of data subjects**.
14.12. Termination of Agreement.
Upon termination of the Customer Agreement, the Processor performs the following actions:
a) **ceases processing** the Operator's personal data;
b) at the Operator's choice — **returns or deletes** the data;
c) **revokes accesses** related to the Operator's account;
d) **retains in archives** only the data necessary for compliance with legal requirements (e.g., accounting or tax records).
a) **ceases processing** the Operator's personal data;
b) at the Operator's choice — **returns or deletes** the data;
c) **revokes accesses** related to the Operator's account;
d) **retains in archives** only the data necessary for compliance with legal requirements (e.g., accounting or tax records).
14.13. Legal Priority.
If applicable legislation obliges the Processor to retain certain categories of data (e.g., for investigations, financial accounting, or dispute resolution), the Processor retains such data **only in the volume and for the duration strictly necessary** to fulfill these requirements.
15. Liability and Limits
All issues related to the distribution of responsibility, limits of damages, compensation, exemption from liability, and other consequences of breach of obligations are governed by the **Customer Agreement and apply to this Addendum by analogy**.
16. Term and Termination
16.1. DPA Term.
This Addendum enters into force upon the conclusion of the Customer Agreement and remains in effect during **its entire term**, as well as until the Parties fully fulfill their obligations for data deletion or return.
16.2. Termination.
This Addendum terminates:
a) simultaneously with the termination of the Customer Agreement;
b) upon written agreement of the Parties;
c) upon the Operator's withdrawal of the data processing instruction.
a) simultaneously with the termination of the Customer Agreement;
b) upon written agreement of the Parties;
c) upon the Operator's withdrawal of the data processing instruction.
16.3. Actions upon Termination.
After DPA termination, the Processor:
a) ceases processing the Operator's personal data, except in cases provided for by law;
b) at the Operator's choice — **returns or deletes** the data in the manner established by Section 14;
c) **revokes all accesses** granted for data processing.
a) ceases processing the Operator's personal data, except in cases provided for by law;
b) at the Operator's choice — **returns or deletes** the data in the manner established by Section 14;
c) **revokes all accesses** granted for data processing.
16.4. Survival of Obligations.
The Parties' obligations regarding confidentiality, security, liability, data protection, and interaction with supervisory authorities **remain in effect after DPA termination**.
16.5. Priority of Terms.
In case of discrepancy between the provisions of this DPA and the Principal Agreement regarding **personal data protection** — **this Addendum shall apply**; in all other matters, the Principal Agreement and the Customer Agreement shall prevail.
Previous versions:
Version 1.0
Version 1.0
gro.now Platform Subprocessor Register
Version 1.0 · Published May 27, 2026
This Register is Annex 3 to the Data Processing Agreement (DPA) of the gro.now platform and is published as a section of the DPA page. The Register contains the list of subprocessors engaged by Pwron LLP for the processing of personal data of Clients and Respondents of the gro.now platform in its capacity as a Processor.
1. General Provisions
1.1. This Register constitutes a list of subprocessors engaged by Pwron LLP (hereinafter the "Company") for the processing of personal data of Clients and Respondents of the gro.now platform in its capacity as a Processor, and forms Annex 3 to the Data Processing Agreement (DPA) concluded by the Company with the Clients of the platform.
1.2. The Register shall apply as the current list of subprocessors as of the date of its publication. Changes to the list of subprocessors (engagement of a new one, removal, replacement) shall be carried out in the manner prescribed by the "Subprocessors" section of the DPA, and shall be reflected in the Register by publishing a new version.
1.3. In the event of a discrepancy between this Register and the provisions of the DPA or instructions of the Clients (Controllers), the DPA and the instructions shall prevail to the relevant extent.
2. Principles of Maintaining the Register
2.1. The Company includes in the Register third-party services that:
-
store, transmit, process, or have access to the personal data of Clients or Respondents of the gro.now platform;
-
are engaged by the Company to process data on behalf of Clients in its capacity as a Processor under the DPA.
2.2. The Company does not include in the Register (see also Section 4 "Services Outside the Scope of the Register"):
-
services used by the Company as an independent Controller for its own operational activities (accounting, HR, Company's corporate marketing, hiring)—these are governed by the gro.now General Personal Data Processing Policy and a separate internal register of personal data recipients;
-
services that the Client connects independently through the platform interface ("Subprocessors" section of the DPA);
-
development and operational tools without access to production and to the data of Clients / Respondents;
-
one-time contractors without continuous access to the data of Clients / Respondents.
2.3. The categories of subprocessors correspond to the categories established by the "Subprocessors" section of the DPA:
-
hosting and cloud infrastructures;
-
analytics, monitoring, and event logging;
-
authentication and security systems;
-
notification, mailing, and communication services;
-
technical support and disaster recovery;
-
large language models (LLMs);
-
integrations used on the instruction of the Client (Controller).
Additionally included in the specified categories is a payment processor—applied regarding the billing data of Clients processed by the Company when paying for subscription plans.
3. Register of Subprocessors
3.1. Google Cloud Platform (GCP)
| Field | Value |
|---|---|
| Legal Entity | Google LLC (US) / Google Ireland Limited |
| Category | Hosting and cloud infrastructure |
| Purpose | Compute (hosting the backend part of the application and database), persistent disks, IAM, networking, cloud storage |
| Data Region | Frankfurt, Germany (europe-west3) |
| Categories of processed data | All categories of platform data (identification, contact, Activity responses and content, technical, metadata, data of Client's representatives) |
| Contractual Basis | Google Cloud Terms of Service + Google Cloud Data Processing and Security Terms |
| DPA / Privacy / Certifications | DPA: cloud.google.com/terms/data-processing-addendum · Privacy: cloud.google.com/terms/cloud-privacy-notice · Certifications: ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 1/2/3, PCI DSS, HIPAA-aligned |
3.2. Vercel
| Field | Value |
|---|---|
| Legal Entity | Vercel Inc. (US) |
| Category | Hosting and cloud infrastructure (application hosting, file storage, CDN, deployment) |
| Purpose | Hosting of the gro.now application (frontend / backend functions), edge network, deployment |
| Data Region | Frankfurt, Germany + Washington DC, USA (multi-region edge). The persistent database of Clients is not stored in Vercel |
| Categories of processed data | Technical data, metadata, temporary application data; content passes through edge functions / serverless |
| Contractual Basis | Vercel Terms of Service + Vercel Data Processing Addendum |
| DPA / Privacy / Certifications | DPA: vercel.com/legal/dpa · Privacy: vercel.com/legal/privacy-policy · Certifications: SOC 2 Type II, ISO/IEC 27001 |
3.3. Firebase Authentication
| Field | Value |
|---|---|
| Legal Entity | Google LLC (US) — as part of Google Cloud / Firebase |
| Category | Authentication and security systems |
| Purpose | Platform user authentication (including password hashing by the provider); JWT tokens; support for login via Google OAuth |
| Data Region | Google Cloud global infrastructure (Firebase Auth is not region-bound in the standard configuration) |
| Categories of processed data | Identification data (email, phone, hashed password, account ID), technical session data |
| Contractual Basis | Google Cloud Platform Terms + Firebase Terms of Service + Google Cloud DPA |
| DPA / Privacy / Certifications | Same as Google Cloud Platform |
3.4. Google Gemini API
| Field | Value |
|---|---|
| Legal Entity | Google LLC (US) |
| Category | Large language models (LLMs) |
| Purpose | AI processing for platform features: generation, translations, sentiment analysis, aggregation of insights |
| Usage Channel | Paid Gemini API via a Google Cloud project with an active billing account (not Unpaid Services / not the free Google AI Studio quota) |
| Data Region | Google Gemini Developer API does not guarantee regional data localization. In accordance with the Gemini API (Paid Services) terms, Google may store and cache data transitively or temporarily in any country where Google or its agents maintain facilities. Regional data residency guarantees are available for the separate Google Cloud Vertex AI / Gemini Enterprise lineup, which the Company does not use as of the date of approval of this Register |
| Categories of processed data | Activity content (briefs, questions, responses); limited context for analytics; identification data is transmitted only if it is present in the actual content of the responses |
| Contractual Basis | Gemini API Additional Terms of Service (Paid Services) + Google Cloud Data Processing Addendum (business.safety.google/processorterms) |
| Use of data for model training | Not used. In accordance with the Gemini API terms regarding Paid Services, Google does not use Company prompts and responses to improve its products or train models; processing is governed by the Google Cloud DPA |
| DPA / Privacy / Certifications | DPA: business.safety.google/processorterms · Privacy: cloud.google.com/terms/cloud-privacy-notice · Certifications: Same as Google Cloud Platform (ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 1/2/3) |
3.5. Brevo
| Field | Value |
|---|---|
| Legal Entity | Sendinblue SAS (France) |
| Category | Notification, mailing, and communication services |
| Purpose | Sending transactional emails to Clients and Respondents |
| Data Region | St. Ghislain, Belgium |
| Categories of processed data | Identification and contact data of recipients (email, name), content of transactional notifications |
| Contractual Basis | Brevo Terms of Use |
| DPA / Privacy / Certifications | DPA: brevo.com/legal/termsofuse · Privacy: brevo.com/legal/privacypolicy · Certifications: ISO/IEC 27001:2022 |
3.6. Rollbar
| Field | Value |
|---|---|
| Legal Entity | Rollbar, Inc. (USA) |
| Category | Analytics, monitoring, and event logging |
| Purpose | Collection and monitoring of errors in the backend and frontend of the gro.now application |
| Data Region | USA (primary infrastructure — AWS) |
| Categories of processed data | Technical data (logs, stack traces), limited personal data (if it appears in logs as part of a debugged event) |
| Contractual Basis | Rollbar Terms of Service |
| DPA / Privacy / Certifications | DPA: docs.rollbar.com/docs/data-processing-agreement · Privacy: docs.rollbar.com/docs/privacy-policy |
3.7. Stripe
| Field | Value |
|---|---|
| Legal Entity | Stripe, Inc. (USA) / Stripe Payments Europe, Ltd. (Ireland) |
| Category | Payment processor |
| Purpose | Processing of online payments by Clients, billing, subscriptions |
| Data Region | USA |
| Categories of processed data | Identification and contact data of payers (name, email); payment data (including card details) — processed by Stripe; Pwron does not store, transmit, or process card data directly; transactional links and references |
| Contractual Basis | Stripe Services Agreement |
| DPA / Privacy / Certifications | DPA: stripe.com/legal/dpa · Privacy: stripe.com/privacy · Certifications: PCI DSS Level 1, SOC 1 Type II, SOC 2 Type II, ISO/IEC 27001 |
| Note (PCI DSS) | The processing of payment card data is fully outsourced to Stripe (PCI DSS Level 1). The PCI DSS scope for Pwron is limited to integration controls (transmitting non-sensitive data via a secure channel, storing transaction references without card data). |
3.8. Google Workspace
| Field | Value |
|---|---|
| Legal Entity | Google LLC (US) / Google Ireland Limited |
| Category | Corporate communications of the Company; regarding the processing of personal data of Clients and Respondents — used for receiving inquiries at functional addresses legal@gro.now, privacy@gro.now, security@gro.now, abuse@gro.now |
| Purpose | Corporate email, video conferencing, calendar, documents for internal work; receiving inquiries from external parties via the Company's functional channels |
| Data Region | Google Cloud global infrastructure |
| Categories of processed data | Inquiries from external parties via functional addresses (may contain personal data of the sender and third parties); internal corporate correspondence |
| Contractual Basis | Google Workspace Agreement + Google Cloud DPA |
| DPA / Privacy / Certifications | Same as Google Cloud Platform |
4. Services Outside the Scope of the Register
The following categories of services and contractors are not included in this Register. This does not indicate their absence from the Company's infrastructure, but rather reflects their legal model.
4.1. Development tools without access to data of Clients / Respondents
GitHub (GitHub, Inc., part of Microsoft Corporation) — used by the Company to store the source code of the gro.now platform, dependency scanning, and security advisories. It contains source code, not Client data or the personal data of Respondents. Under the DPA model, it is not classified as a subprocessor of Clients' personal data; it is mentioned in this section for transparency purposes.
4.2. Services used by the Company as an independent Controller
Services engaged by the Company for its own operational activities (and not on the instruction of the Client)—including accounting and HR services, the Company's corporate marketing, and applicant tracking services during hiring—are not subprocessors within the meaning of the DPA. They process the personal data of the Company's employees, contractors, and counterparties, are governed by the gro.now General Personal Data Processing Policy, and are subject to a separate internal register of personal data recipients, which the Company maintains separately from this Register.
4.3. Services connected independently by the Client
Services that the Client connects independently via the platform interface ("Subprocessors" section of the DPA) are not included among the Company's subprocessors; the responsibility for their compliance with applicable requirements is borne by the Client as a Controller.
4.4. One-time contractors without continuous access
One-time contractors and consultants engaged by the Company without continuous access to the data of Clients / Respondents are not included in the Register. Their interaction with data (if necessary as part of a one-time assignment) is formalized through a separate NDA / contractor agreement with applicable processing requirements.
5. Changes to the Subprocessor List
5.1. The engagement of a new subprocessor, the removal of an existing one, or a replacement shall be carried out in the manner prescribed by the "Subprocessors" section of the DPA. Notifications to Clients regarding such changes shall be sent by the Company in the manner and within the timeframes stipulated by the DPA.
5.2. This Register shall be updated upon any change in the list of subprocessors. The version and date of the update are indicated in the header of the document; previous versions are retained in the Company's archive.
5.3. The Director of the Company is responsible for maintaining the Register up to date. The physical inventory of subprocessors is conducted with the assistance of the Company's development team.
6. Validity and Revision
6.1. The Register enters into force on the publication date indicated in the header of this document.
6.2. The Register shall be revised:
-
upon changes to the list of subprocessors;
-
upon material changes to the Company's DPA requiring an update to Annex 3;
-
based on the results of an internal review of the data's relevance.
6.3. The version and publication date of the current edition of the Register are specified in the header of this document. Previous editions are retained in the Company's archive and, if necessary, provided to Clients upon request.