DATA PROCESSING AGREEMENT (DPA) — Art. 28 GDPR

1. DEFINITIONS

"personal data", "processing", "controller", "processor", "data subject", "personal data breach" have the meanings in Art. 4 GDPR.

2. ROLES

For salon client and staff data processed via the platform, the Controller (Salon) determines purposes and means and is the CONTROLLER; Primer processes such data SOLELY on the Controller's behalf as PROCESSOR. Primer remains a SEPARATE CONTROLLER only for data processed for its own platform purposes (subscription billing, security, fraud prevention, aggregated service improvement, its own legal obligations). This clause applies subject to the exceptions expressly set out in sections 16 and 17, which describe processing in which Primer acts as a joint controller and as a controller in its own right, respectively.

3. SUBJECT-MATTER & DURATION [Art. 28(3)]

Subject-matter: processing necessary to provide the Primer platform (bookings, communications, salon management, AI assistant, Controller-initiated marketing). Duration = the term of the Main Agreement plus the deletion period in clause 11. The subject-matter and duration set out in this clause concern the processing Primer carries out on the Controller's behalf, as a processor. Sections 16 and 17 describe processing in which Primer does not act in that capacity, and their duration is the one stated in those sections.

4. NATURE & PURPOSE [Art. 28(3)]

Nature: collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, transfer to sub-processors, disclosure by dissemination or otherwise making available, where the Controller directs publication through in-platform configuration — in particular the Controller's public website, the booking pages, the team presentation, the gallery and the service catalogue, as well as the Controller's own content published in the review register, restriction, erasure and destruction. Purpose: managing the salon's bookings and client relationship, sending notifications/SMS/email, processing payments, reporting, AI-assistant features, marketing campaigns instructed by the Controller — strictly per the Controller's instructions.

5. DATA TYPES & DATA-SUBJECT CATEGORIES [Art. 28(3)]

Data subjects: salon clients, website visitors, salon staff/collaborators. Data types: name, phone, email, appointment & service history, preferences, notes (including any allergy/scalp data voluntarily provided — potentially sensitive, processed only at the Controller's initiative), tokenized payment data (via Stripe), usage/analytics data, advertising identifiers where the Controller enables marketing. Primer does not request special-category data; if the Controller inputs it, the Controller is responsible for the legal basis. The following are added to the data types above, as published data: the review's content, its rating, the author-display mode the author chose, the day or the month of the visit according to that mode, the service name and the displayed name of the person who performed it, and the Controller's public reply. Data made available under section 17: the booking's internal identifier, its local calendar day, its class and its status at the moment of the seal, and the five eligibility elements listed in section 17(c); the corresponding data subjects are the Controller's customers who made a booking through the online channel.

6. CONTROLLER INSTRUCTIONS [Art. 28(3)(a)]

Primer processes personal data only on the Controller's documented instructions (including this DPA, the Main Agreement and in-platform configuration), including for international transfers, unless required by EU/Member-State law — in which case Primer informs the Controller beforehand unless that law prohibits it. Primer immediately informs the Controller if, in its opinion, an instruction infringes the GDPR.

7. CONFIDENTIALITY [Art. 28(3)(b)]

Primer ensures persons authorised to process the data have committed to confidentiality or are under an appropriate statutory confidentiality obligation, on a need-to-know basis.

8. SECURITY [Art. 28(3)(c) with Art. 32]

Primer implements appropriate technical and organisational measures, including: encryption in transit (TLS) and at rest for sensitive data; role-based access control and authentication; multi-tenant data isolation per salon; card-data tokenization (delegated to Stripe — Primer stores no PAN); audit logs for money/auth/tenant-data operations; backups and restore capability; periodic testing; dev/prod environment segregation; secret management in Azure Key Vault; rate-limiting on sensitive endpoints.

9. SUB-PROCESSORS [Art. 28(2) & 28(3)(d)]

The Controller grants GENERAL AUTHORISATION for the sub-processors in Annex 1. Primer imposes on each, by contract, data-protection obligations equivalent to those in this DPA and remains fully liable to the Controller. Primer gives at least 30 days' notice before adding/replacing a sub-processor; the Controller may object on reasonable data-protection grounds and, failing a solution, may terminate the affected service.

10. ASSISTANCE [Art. 28(3)(e) & (f)]

(e) Primer assists the Controller in responding to data-subject requests (access, rectification, erasure, restriction, portability, objection). (f) Primer assists the Controller in compliance with Arts. 32-36: security, breach notification, and DPIA/prior consultation. Breach: Primer notifies the Controller WITHOUT UNDUE DELAY (target: within 48 hours of becoming aware), providing the nature of the breach, the categories and approximate number of data subjects/records, likely consequences and measures taken, enabling notification within 72 hours under Art. 33.

11. DELETION/RETURN [Art. 28(3)(g)]

On termination, at the Controller's choice, Primer deletes or returns all personal data and deletes existing copies within 30 days, unless EU/Member-State law requires retention. Backup copies are overwritten on the rotation cycle.

12. AUDIT [Art. 28(3)(h)]

Primer makes available to the Controller all information necessary to demonstrate compliance with Art. 28 and allows for and contributes to audits/inspections by the Controller or a mandated auditor, on reasonable notice (min. 30 days), at most once per year (or on a confirmed breach / authority request), during business hours, without disproportionate disruption and under confidentiality. Primer may also satisfy this by providing relevant certifications/reports.

13. INTERNATIONAL TRANSFERS

For any transfer outside the EEA, the Parties rely on the EU Standard Contractual Clauses (Decision 2021/914), appropriate module, incorporated by reference, plus supplementary measures where needed. Certain sub-processors (e.g. Anthropic, Meta, Google) may process data in the USA under SCCs and/or the EU-US Data Privacy Framework.

14. LIABILITY

Each Party's liability follows Art. 82 GDPR. The Main Agreement's liability limits apply to this DPA on an aggregate basis, without limiting liability that cannot be excluded by law. Each Party bears administrative fines attributable to it.

15. PRECEDENCE

In case of conflict on data protection, this DPA prevails over the Main Agreement.

16. JOINT CONTROLLERSHIP FOR THE REVIEW-INVITATION RULE [Art. 26 GDPR]

By way of exception to section 2, for ONE processing segment — the rule that determines WHO receives the invitation to review a completed visit — the Parties are JOINT CONTROLLERS within the meaning of art. 26 GDPR. The reason is factual, not formal: Primer decides, uniformly across the platform and per country, the legal basis and the invited population (legitimate interest plus the existing-customer exception in the countries whose transposition of art. 13(2) of Directive 2002/58 has been reviewed, consent everywhere else), and the Controller CANNOT derogate — neither to widen nor to narrow it. Whoever determines the purposes and means is a controller, whatever the contract calls them. THE TRANSPARENT ALLOCATION OF RESPONSIBILITIES required by art. 26(1): (a) Primer sets and publishes the invitation rule, the frequency (one invitation per eligible visit, a cooling-off period and a lifetime cap) and the content of the invitation, which carries no advertising; (b) the Controller is the trader for the purposes of the existing-customer exception (art. 13(2) of Directive 2002/58, as transposed in its country) — it performed the service, it obtained the contact directly, and the invitation is sent on its behalf; (c) the Controller displays the collection notice and offers the objection at the moment the contact is obtained, on the doors it operates; (d) Primer guarantees the right to object (art. 21 GDPR) in every message, in one step and free of charge, and honours it permanently, without the Controller being able to lift it; (e) Primer is responsible for informing data subjects about this processing (art. 13-14), through the review-invitation policy Primer publishes and through the register's public document. THE ESSENCE OF THIS ARRANGEMENT IS MADE AVAILABLE TO THE DATA SUBJECT under art. 26(2), through that same published policy. Irrespective of the allocation, the data subject may exercise their rights against either Party (art. 26(3)); the Parties forward requests they receive to each other without delay. For the public review register itself — publication, cryptographic anchoring and the integrity guarantee of the corpus — Primer remains a SEPARATE CONTROLLER, not a joint one.

17. THE DAILY COMMITMENT OVER THE BOOKING POPULATION [Art. 28(10) and Art. 6(1)(f) GDPR]

By way of exception to section 2 and in continuation of the final paragraph of section 16, for the processing referred to below as "the daily commitment" — computing a cryptographic fingerprint for each booking in the population defined below, building and publishing a daily root over those fingerprints, anchoring it in time, including the Controller's chain head as a leaf of the platform's daily network root, retaining the opening material and issuing membership proofs — Primer acts as a CONTROLLER IN ITS OWN RIGHT, and not as the Controller's processor nor as its joint controller. (a) WHY THAT ROLE, AS A MATTER OF FACT AND NOT OF DRAFTING. Primer alone determines, uniformly across the platform and without any right of derogation for the Controller, the purpose of this processing and its essential means: the categories of recipients, the type of derived values computed and published, the eligibility rule and its version, the fixed size of the tree, the hour of the seal and the duration of publication. Under art. 28(10) GDPR, whoever determines the purposes and means of processing is a controller in respect of that processing, whatever the contract calls them. Accordingly, section 6 of this agreement does not apply to this processing; the Controller's activation of the feature, described in point (j), does NOT constitute a documented instruction within the meaning of art. 28(3)(a) GDPR, but a condition on which Primer makes its own processing depend. (b) LEGAL BASIS. Primer processes on the basis of art. 6(1)(f) GDPR. The legitimate interest pursued is that the population of bookings from which review invitations may leave be publicly fixed before any answer exists, so that the statement that nothing was later selected out of it is not merely asserted but checkable; that interest is Primer's, the Controller's and that of the people who read the reviews. Recital 47 GDPR recognises the legitimate interests of a controller as a basis, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller. The legitimate-interest assessment, with the necessity test and the balancing exercise, is drawn up in writing before the first processing and is made available to the Controller and to the data subject on request. Consent is not used: an already anchored value cannot be withdrawn, and a basis whose withdrawal cannot be honoured would be non-compliant by construction. (c) WHAT IS PROCESSED. A day's population consists of the Controller's bookings made by the customer through the online channel, whose local calendar day, determined by the location's time zone, is that day at the latest, and which have not entered any earlier commitment of the Controller. Cancelled bookings, no-shows and bookings the Controller removed from its own calendar are part of the population, with their status recorded, precisely so that the population cannot be narrowed once it has become known what is coming. A day's population does, however, have two calendar edges, stated here so that a booking's absence from a commitment can never be read as a narrowing: it does not include bookings whose day precedes the Controller's first published commitment, because a commitment cannot be made retroactively over a period in which it did not exist; and it does not include bookings whose day is older than the retention window set out in point (h), counted from the day being sealed, because for those days the opening material has already been destroyed, and a booking brought back into today's tree would assert that today's population included a visit from months ago. Both edges are enforced by the mechanism, inside the very query that assembles the population, and neither is within the Controller's reach. For each booking in the population a 32-byte fingerprint is computed from: a domain separator, the rule version, the Controller's identifier, the calendar day, a masked booking identifier obtained through a keyed function, a separate commitment to a fixed-width eligibility vector of eight bytes, and a random 32-byte secret belonging to that fingerprint alone. The eligibility vector records only: whether a telephone number exists, whether a communication basis exists, whether the person appears on the Controller's block list, whether the lifetime invitation cap has been reached, whether the same person already has a review with the Controller, the booking's status at the moment of the seal, and the booking's class. The fingerprints are placed at randomly chosen positions in a tree of fixed size, identical every day, padded with padding fingerprints computed under the same rule and indistinguishable from the real ones. Where a day's bookings exceed the size of the tree, the surplus is not excluded but deferred: those bookings remain outside any commitment and enter the commitment of a following day — which is why the population is defined as "that day at the latest" and not as "that very day". That is the third and last reason a booking may be absent from its own day's commitment; the other two are the two calendar edges above, and all three are stated here precisely so that an absence can never be read as a narrowing. (d) WHAT IS NEVER PROCESSED FOR THIS PURPOSE. The hour of the booking or of the visit, the service performed or its category, the price, the staff member who performed the service, the location, any customer identifier and anything derived from a customer identifier, and anything concerning a review. These categories do not enter the fingerprint, do not enter the vector and are not published. (e) WHAT IS PUBLISHED. For each calendar day: the day, a sequence number that advances by exactly one per day, the rule version, the tree size, the daily root, the previous entry's fingerprint and the current entry's fingerprint; separately, the Controller's chain head as a leaf of the platform's daily network root, and that root's time anchoring. A day with no bookings at all produces an entry indistinguishable from a busy day's. The public document also carries a description of what the commitment proves and of what it does not. (f) WHAT IS NEVER PUBLISHED. No membership proof; no secret; no masked identifier; no fingerprint position in the tree; no booking identifier; no moment finer than the calendar day, neither for the entry nor for any element of it; and no figure from which it could be read how many bookings the Controller had that day — the commitment contains no such figure, by construction, and the tree size is a fixed parameter every day is padded to. (g) THE MEMBERSHIP PROOF. A proof that a given booking was in that day's commitment is issued, on request, to: the data subject who left the review that came out of that booking; a supervisory authority or a court, in the context of a request or proceedings; and a mandated auditor, under an obligation of confidentiality. The proof is never published and appears in no public document, export, agent interface or assistant answer. The eligibility vector is NEVER opened on the path by which a data subject obtains their own proof: there, the proof carries the commitment to the vector, not its content. The vector is opened only on an express and reasoned request made through the administration and audit path, recorded as such together with its reason; by default, opening is closed, and a request that states no reason is refused before the mechanism opens or reads anything of the seal: no leaf, no secret, no vector and no proof is touched before the refusal, and a refused opening produces no proof. The issuing of a proof is bounded by the period in point (h). Once a day's retention collapse has taken place, the only proof that can still be issued is the membership proof of a booking that produced a published review, computed and kept before the collapse. For any other booking of that day there is nothing left to issue — not on a data subject's request, not on the request of a supervisory authority or a court, and not on an auditor's — because the opening material no longer exists at Primer. A review published after that period therefore carries no membership proof at all, and the answer says so in those terms rather than asserting that the booking was never sealed. Primer records every issuance of a proof, at every door through which a proof is issued, together with whether the vector was opened at that issuance and, at the administration and audit path, the reason given; it likewise records an entitled request the mechanism had nothing to open for — because the booking was never sealed, because its material was destroyed at the data subject's request, or because its day had already been forgotten. A record of an issuance names the day it was about only for as long as that day's opening material still exists, and at the retention collapse under point (h) it is destroyed together with that material, in the very operation that destroys it; so no record that names a day outlives what that day could open. Every other record names no day at all — a request nothing was opened for, and an issuance of a proof that has outlived the day it came from — and is deleted 90 days after the date it was written. The record cannot be modified, and its deletion is permitted only on the forgetting path under point (h) and only once that period has run. Recording is not a consequence of an issuance but its condition: where the record cannot be written, the proof is not issued. The request then receives an answer of temporary unavailability, with an invitation to come back, and nothing is handed over. The rule is written that way because otherwise the promise in the first sentence would be true only while the platform is not busy, and a promise that is true only sometimes is not the promise being signed here. A request Primer refuses is recorded nowhere, at either door, and not by oversight. Three reasons, each sufficient on its own: at the path by which a data subject obtains their own proof, any requester without an entitlement receives an identical answer that does not reveal whether the review requested exists, and a row written against a named review would answer precisely the question that answer refuses; the row would store a person who, by the hypothesis of the refusal, is not the author of the review the row names, which would be processing without necessity, contrary to art. 5(1)(c) GDPR; and it would be an unbounded write driven by an unauthenticated requester. (h) RETENTION. The daily root, the entry fingerprints and their chain remain published and anchored for an indefinite period: they are an append-only register whose time anchoring cannot be withdrawn by either Party. The opening material — the fingerprint's secret, the vector's secret, the vector, the masked identifier and the link to the booking — is kept separately from the published artefact and under its own technical and organisational measures, within the meaning of art. 4(5) GDPR, which requires the additional information to be “kept separately and subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”; the separation is measured against the published artefact, in which the opening material appears in no form. The material is kept only for as long as it serves the purpose in point (b), and the periods are as follows. For a booking that produced no published review: at most 90 days from the publication of the commitment of the day it belongs to. On expiry of that period an automatic mechanism, running daily, destroys — for the whole day at once, in a single operation that either succeeds entirely or has no effect at all — the fingerprint row of every such booking with everything it carries: the fingerprint value, its position, the fingerprint's secret, the vector's secret, the vector, the masked identifier and the link to the booking, together with the seed from which that day's padding fingerprints were derived. From that moment that day's population can no longer be recomposed, opened or counted by anyone, Primer included. For a booking that produced a published review: until that review ceases to be published. Before the destruction described above, the chain of fingerprints linking that booking's fingerprint to the day's root is computed and kept, so that the proof under point (g) survives the collapse without anything else from that day being kept for that purpose. The 90-day period is a rule of the mechanism, not a deadline for putting one into service, and it is written as such in the database as well: the database refuses the destruction of a fingerprint whose day is still inside the window, refuses the destruction of a fingerprint that a published review names, and refuses any such destruction outside the operation that performs it. The booking itself, which Primer retains on its own basis and with its own retention period, is not touched by this operation. A fingerprint that remains after a destruction requested by a data subject enters the situation described in point (i). (i) ERASURE (art. 17 GDPR) — PERFORMANCE, NOT DEROGATION. On a data subject's founded request, Primer destroys the fingerprint's secret, the vector's secret, the vector's content, the masked identifier and the link between the fingerprint and the booking, recording the moment of destruction; the destruction is irreversible and is refused by the database unless it is carried out in full and at once. That removes the entire personal content belonging to the fingerprint. A person's fingerprint and its position in the tree have NEVER been published and are not published: under points (e) and (f), what remains published is only what is listed there, namely the anchored daily root, which commits to the fingerprint without disclosing it. What remains on Primer's internal records is the fingerprint's value and its position, and they remain for a reason that concerns other people: without them the day's root can no longer be recomputed, and every other person in that day's population loses their proof. As regards those two elements the ground in art. 17(1)(a) is not met for as long as they remain necessary for the purpose in point (b); and where the request rests on an objection under art. 21(1), the overriding legitimate grounds within the meaning of art. 17(1)(c) are likewise confined to those two elements: the impossibility of withdrawing an already anchored value, and the right of the other people in the same population to keep their proof. That necessity has a short, fixed and written end: for a booking that produced no published review, the fingerprint value and its position do not survive the retention collapse under point (h) — the row is deleted whole, at most 90 days after the sealed day, so the residue disappears for everyone, Primer included, without any request having to be made. What remains is the day's root alone, committing to a set nobody can open any more. For a booking that produced a published review the residue is kept for as long as that review is published, and the reason is the one set out above: without it, the proof of that review and the proofs of the other reviews of the same day can no longer be verified. That limitation is communicated to the person with its reasons, under art. 12(4) GDPR; the rest of the request is performed in full. This is the performance of the right to erasure, not a derogation from it: art. 4(2) GDPR counts destruction among the processing operations, and art. 17 requires that the data no longer be attributable to the person, not that a particular byte disappear from a public artefact. As regards anyone other than Primer, the fingerprint committed in the published root is not attributable: its preimage contains 32 bytes of cryptographically generated entropy which have been destroyed, and reconstructing them is not a means reasonably likely to be used by anyone within the meaning of recital 26. As regards Primer, what remains adds nothing to what the booking Primer retains anyway — on its own basis and with its own retention period — already says: from the rule published in point (c) it follows that any online booking of a day is part of that day's commitment, which is read directly from the booking record without any fingerprint; when the booking's retention period ends, that route ends with it. For as long as the artefact remains published, Primer maintains the measures on which the conclusion above depends: the hash function remains unbroken, and on its degradation a new rule version is issued without rewriting the earlier ones; the secrets never leave the platform except in the proofs under point (g); the secrets are generated by a cryptographic generator and never from any element of the person; and Primer undertakes to keep the overwrite cycle of the secrets' backups shorter than the response period for an erasure request, to measure it before the first seal and to verify it at least annually. The right to object, set out in point (o), remains separately available and operates on the future. (j) ACTIVATION, STOPPING, AND THE CONTROLLER'S LIMITS. The commitment is computed for the Controller only where, cumulatively: the reviews module is switched on by the Controller; the Controller has signed this version of the agreement or a later one; and the platform holds the key with which the seal is made — without it no fingerprint is computed, for any Controller. The Controller may switch the module off at any time, with immediate effect for the following days. The Controller may NOT alter, withdraw or reorder a commitment once published, may not remove a booking from a population already sealed, may not add one, and may not require a root to be recomputed. Those limits are not a promise of conduct but are enforced by the mechanism itself: the database refuses, as against anyone, the modification of any of an entry's published values — the day, the sequence number, the rule version, the tree size, the root, the previous entry's fingerprint and the current entry's fingerprint — refuses the deletion of an entry, refuses the emptying of the register, and refuses any missing day in the chain. The only later writes permitted are Primer's, they are listed exhaustively, and none of them touches any published value: the recording of the time stamping under point (l) together with the link to the daily network root the chain head entered — one operation, once per entry — and the retention collapse under point (h), which destroys the padding seed and records the moment, once. After either of them, the published bytes of the day are identical to what they were. Switching the module off does not withdraw commitments already published. (k) THE CONTROLLER MAKING DATA AVAILABLE. By the activation described in point (j), the Controller makes available to Primer, in Primer's capacity as a controller in its own right, the data listed in section 5 under the heading "data made available under section 17"; the Controller is responsible for having its own basis for making them available, which, absent another choice communicated in writing, is that of art. 6(1)(f) GDPR. Primer publishes, in all the platform's languages, a model paragraph describing the daily commitment and referring to the policy Primer publishes. To the extent that the Controller maintains its own information to its customers under art. 13 GDPR, it includes that paragraph in it, at the first update of that information and at the latest within 90 days of the effective date of this version. Informing data subjects about the processing under this section remains Primer's responsibility, discharged through its published policy and through the register's public document. The Controller forwards to Primer without delay any request it receives from a data subject concerning the daily commitment, and Primer forwards to the Controller, on the same terms, the requests it receives that concern the Controller's data. (l) TIME STAMPING. The platform's daily network root is sent, as a single 32-byte value, to a public time-stamping network, so that it can later be proved that the value existed at that moment. That value is the result of at least thirteen successive levels of hashing above any booking's fingerprint and is accompanied by nothing else; it does not relate to an identified or identifiable natural person as regards the operators of that network, who neither hold nor can obtain the additional information needed for attribution. Accordingly, the time-stamping network is a DECLARED TECHNICAL RECIPIENT of that value and not a sub-processor within the meaning of art. 28(2) and (4) GDPR, and it is not listed in Annex 1. Primer states this in its public documents. (m) RELATIONSHIP WITH SECTION 16. The rule that a review invitation for an online booking is sent only after that booking's daily commitment has been published is an element of the invitation rule, which section 16(a) already assigns to Primer to set and publish and which section 16(e) covers as regards informing data subjects. This section does not widen the scope of section 16 and creates no additional obligations for the Controller as regards invitations. (n) NO EFFECT ON THE OTHER CLAUSES. This section does not alter Primer's obligations as a processor for the remaining processing and does not diminish the Controller's rights under sections 11 and 12, which continue to apply in full to processing carried out by Primer on the Controller's behalf. (o) THE RIGHT TO OBJECT (art. 21(1) GDPR). A data subject may object at any time, on grounds relating to their particular situation, to their bookings being included in the daily commitments. Primer honours the objection without invoking overriding legitimate grounds: from the moment it is registered, no later booking of that person — with the Controller or with any other controller using the platform — enters the population under point (c), and the opening material of that person's bookings already sealed, with any of those controllers, is destroyed under point (i). That scope is not a courtesy but the consequence of the classification in point (a): the objection concerns processing carried out by Primer in its own right, not the commercial relationship with a particular Controller, so it is registered at platform level and takes effect wherever that person has bookings. The Controller is put on notice of that effect by this clause: an objection registered by a person who is also another platform controller's customer removes that person from the Controller's populations as well. Conversely, the Controller cannot register, lift or consult an objection, and no door is provided to it for that purpose — a controller able to mark its own customers out of the population would hold exactly the filter the commitment exists to exclude, wearing a data-protection name. The fact of an objection is not disclosed to the Controller: the state it sees for such a booking is the label shared with several situations unrelated to any objection, and no separate reason is shown to it. The only elements on which the objection has no effect are the fingerprint value already committed in a published and anchored root, and its position, for the reasons set out in point (i); those reasons are communicated to the person with their justification. Commitments already published are not withdrawn. The objection may be exercised through any of the channels by which Primer receives data subject requests, including by automated means, under art. 21(5) GDPR. Under art. 21(4) GDPR, Primer brings this right to the data subject's attention explicitly and separately from any other information, at the latest at the time of the first communication it addresses to them concerning the processing under this article; the published policy does not take the place of that notice, it accompanies it. Primer answers an objection within the time limit of art. 12(3) GDPR.

Annex 1 — Sub-processors