Parties. This DPA is between Adrologic Pvt Ltd, 30/160, Sector 3, Pratap Nagar, Sanganer, Jaipur 302033, Rajasthan, India (CIN U62011RJ2023PTC088227) ("Adrologic", the "Processor") and the customer that accepted the CRAIVIS Terms of Service (the "Customer", the "Controller"). It forms part of the Terms and applies automatically; no signature is needed. A Customer that needs a signed copy for its own records can request one at contact@adrologic.com.
1. Definitions
1.1 "Customer Personal Data" means personal data contained in Customer Content, approver data, agency-client data, WhatsApp opt-in contacts, Search Console data, and any other personal data Adrologic processes on the Customer's behalf through the Service. It excludes Account Data (the Customer's members' sign-in, billing status and usage data), for which Adrologic is the controller / data fiduciary under the Privacy Policy.
1.2 "Data Protection Law" means the DPDP Act, 2023 and the DPDP Rules, 2025 (India); the GDPR and UK GDPR, where applicable; and any other privacy law that applies to the processing.
1.3 "Sub-processor" means a third party Adrologic engages to process Customer Personal Data.
1.4 "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
1.5 Terms defined in the Terms of Service (Brand, Channel, Organisation, Approver, brand_grant, brand_transfer, Platform, Aggregator, Connector) have the same meaning here. "Data fiduciary" and "data processor" (DPDP) correspond to "controller" and "processor" (GDPR).
2. Roles and scope
2.1 The Customer is the controller / data fiduciary of Customer Personal Data and Adrologic is its processor. Where the Customer is an agency acting as processor for its own clients, the Customer warrants that it has the client's authorisation to engage Adrologic as a sub-processor on these terms, and Adrologic's obligations here run to the agency.
2.2 The subject matter, duration, nature and purposes of processing, the categories of data subjects and the categories of personal data are described in Annex A.
2.3 This DPA does not apply to Account Data or to data the Platforms process as independent controllers once content is published.
3. The Customer's instructions
3.1 Adrologic processes Customer Personal Data only on the Customer's documented instructions, which are: (a) the Terms of Service and this DPA; (b) the Customer's configuration of the Service (brands, channels, posting modes, disclosure settings, occasion settings, approvers, grants, transfers); (c) each approval, rejection, edit and schedule the Customer or its Approvers make; (d) any other written instruction the Customer gives that is consistent with the Terms. Processing required by law that applies to Adrologic is also permitted; Adrologic informs the Customer before such processing unless the law forbids it.
3.2 Adrologic will tell the Customer if, in its opinion, an instruction infringes Data Protection Law, and may suspend that instruction until it is resolved.
3.3 The Customer's responsibilities. The Customer (a) has a lawful basis and, where required, valid consent for the Customer Personal Data it gives Adrologic (including consent of people whose likeness appears in photos and of WhatsApp contacts); (b) gives the notices Data Protection Law requires to its own data subjects, naming Adrologic as processor; (c) uses the Service's controls (roles, grants, deletion) to keep processing to what it needs; (d) does not give Adrologic special or sensitive categories of data except where the Service asks for an optional field and the Customer chooses to fill it.
4. Adrologic's obligations
4.1 Confidentiality. Only people who need access to provide the Service have it; all are under a written duty of confidentiality. At launch that is the founder; the staff roles (support, trust and safety, finance, superadmin) are scoped in code so that any later hire receives only the access its role needs. Staff support access to a Customer's account is limited to one-hour sessions, logged in an audit log the Customer can see, and never exposes channel tokens.
4.2 Security. Adrologic implements the technical and organisational measures in Annex B and keeps them under review; they may be improved but not materially weakened during the term.
4.3 Assistance with data subject requests. If a data subject writes to Adrologic about Customer Personal Data, Adrologic forwards the request to the Customer within 2 business days and does not respond on the merits except as instructed. The Service provides in-product tools that help the Customer respond: brand export on request, brand and organisation deletion, approver removal, and consent-record management.
4.4 Assistance with compliance. Taking into account the nature of the processing and the information available to it, Adrologic assists the Customer with security, breach notification, data protection impact assessments and prior consultation where Data Protection Law requires the Customer to do these things. Assistance beyond what the Service and its documentation provide may be charged at a reasonable rate agreed in advance.
4.5 Records and information. Adrologic keeps a record of processing activities for Customer Personal Data and makes available to the Customer the information reasonably necessary to demonstrate compliance with this DPA, including this DPA, Annex B, Annex C, the change log for sub-processors, and, when they exist, audit reports (for example a SOC 2 report when agencies ask for one).
4.6 Audits. Not more than once a year, or after a Personal Data Breach affecting the Customer, or when a regulator requires it, the Customer (or an independent auditor bound by confidentiality and not a competitor of Adrologic) may audit Adrologic's compliance with this DPA on 30 days' written notice, during business hours, in a way that does not disrupt the Service or expose other customers' data. Adrologic may satisfy an audit by providing a recent third-party report covering the same scope. The Customer bears its own audit costs.
4.7 Data minimisation in vendors. Adrologic sends Sub-processors only what each needs (Annex C): identifiers rather than content wherever the function allows (Inngest, Upstash, Sentry, PostHog, Slack alerts); content only to the vendors that generate, store, render, publish or e-mail it; tokens only to the Aggregator during the bridge.
5. Sub-processors
5.1 General authorisation. The Customer authorises Adrologic to engage the Sub-processors in Annex C and to add or replace Sub-processors under 5.2.
5.2 Changes. Adrologic publishes any intended addition or replacement at craivis.com/legal/subprocessors and e-mails Organisation Owners at least 30 days before the new Sub-processor processes Customer Personal Data. Emergency replacements needed to keep the Service secure or available may take effect sooner, with notice as soon as practicable.
5.3 Objection. A Customer with reasonable data-protection grounds may object in writing within the notice period. Adrologic will try to offer a change that removes the objection (for example not using that Sub-processor for the Customer's data, or routing to an alternative provider in the media router). If it cannot, either party may terminate the affected feature or, if the Sub-processor is essential to the Service, the Terms, with a pro-rata refund of prepaid fees for the unexpired period, as the Customer's sole remedy.
5.4 Flow-down. Adrologic imposes on each Sub-processor data-protection obligations no less protective than this DPA, by written contract (the vendor's DPA or terms), and remains liable to the Customer for the Sub-processor's performance.
5.5 Vendor terms as a hard filter. Adrologic's provider router uses each generative-AI vendor's commercial rights, training-opt-out, indemnity, branding and territory terms as a filter before price; vendors that train on customer inputs or do not offer commercial rights at Adrologic's tier are excluded from processing Customer Content (currently: Runway below Enterprise; Sora, Midjourney, Suno and Udio never; HunyuanVideo excluded for EU, UK and Korean tenants).
6. International transfers
6.1 Customer Personal Data is stored in Singapore (database) and processed in India (application, Mumbai region), on global storage and CDN infrastructure with an Asia-Pacific jurisdiction hint, and by Sub-processors in the United States and Germany, as set out in Annex C.
6.2 India (DPDP). Transfers outside India are permitted except to countries the Central Government restricts by notification. Adrologic monitors notifications and will stop or relocate an affected transfer within the period the notification allows.
6.3 EU / UK. Adrologic does not offer EU or UK data residency in the first 12 months. If Customer Personal Data of EU or UK data subjects is processed, transfers from the EU/UK to India, Singapore and the United States are made under the EU Standard Contractual Clauses (Module 2 controller-to-processor, or Module 3 processor-to-processor for agencies) and the UK International Data Transfer Addendum, which the parties are deemed to have executed as set out in Annex D, together with Adrologic's transfer impact assessment available on request.
6.4 Residency later. The Service is built with a region column per Organisation and per-region storage so EU/UK residency (a second database project and storage bucket) can be switched on later without a migration of other customers. Nothing here promises a date.
7. Personal Data Breach
7.1 Adrologic notifies the Customer without undue delay and within 24 hours of confirming a Personal Data Breach affecting Customer Personal Data, by e-mail to the Organisation Owner(s) and in-product, with: what happened, the categories and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and a contact. Information may be given in phases as it becomes available.
7.2 Adrologic follows BREACH-RUNBOOK.md: containment; the DPDP Rules' notifications (to affected data principals without delay; to the Data Protection Board of India: an initial intimation without delay and the detailed report within 72 hours) for data for which Adrologic is the fiduciary; and support for the Customer's own notifications for Customer Personal Data. The Customer is responsible for notifying its own regulators and data subjects for Customer Personal Data, and Adrologic will help.
7.3 Adrologic does not make a public statement naming the Customer without the Customer's consent unless the law requires it.
8. Return and deletion
8.1 During the term the Customer can export Customer Content and Outputs (JSON plus media links) on request, and can delete brands, approvers, channels, media and the Organisation itself in-product.
8.2 On termination or expiry of the Terms, Customer Personal Data stays readable for 30 days so the Customer can export it; then Adrologic deletes it from live systems within 30 days (target 7 days) and it expires from encrypted backups within a further 30 days. The exact timelines and what is retained are on the Data Deletion page, which forms part of this DPA. Adrologic may retain what the law requires (invoices and ledger for statutory periods; permanent audit rows for brand transfers, identifiers only) and what is needed to establish, exercise or defend legal claims, under the same protections.
8.3 Deletion runs tenant-scoped through every store that holds Customer Personal Data (database rows including Brand Brain chunks, media in storage, generated assets, LLM traces, the Aggregator profile, push tokens, analytics person profiles) and is confirmed with a confirmation code and a status URL.
9. Liability and term
9.1 Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service, except that nothing limits liability for a party's fines imposed by a data-protection regulator for that party's own breach, to the extent the law does not allow such limitation.
9.2 This DPA lasts as long as Adrologic processes Customer Personal Data, including the deletion period.
9.3 If this DPA conflicts with the Terms, this DPA prevails for the processing of personal data. If it conflicts with the Standard Contractual Clauses (where they apply), the Clauses prevail.
9.4 Governing law and dispute resolution follow the Terms (India; arbitration), except where the Standard Contractual Clauses require otherwise for EU/UK data.
Annex A: Details of processing
| Item | Description |
|---|---|
| Subject matter | Providing the CRAIVIS Service: building brand profiles, planning and generating content, obtaining approvals, publishing to connected Channels through Official APIs, reading published-post analytics, billing, support, and the add-ons the Customer buys. |
| Duration | The term of the Terms of Service plus the readable and deletion periods in Section 8. |
| Nature | Collection (from the Customer, its website, the Platforms' APIs with consent), storage, organisation, structuring, adaptation (generation, transcoding, templating), retrieval, consultation, use, transmission (to Sub-processors and, on approval, to Platforms), erasure. |
| Purposes | Only those in 3.1. No profiling of data subjects for advertising; no sale; no training of general-purpose AI models. |
| Categories of data subjects | The Customer's members and staff; the Customer's Approvers (including an agency's clients' staff); people who appear in photos the Customer uploads; the Customer's customers and prospects whose phone numbers are in a WhatsApp opt-in list (add-on); people whose data appears in the Customer's website content, reviews or Search Console data; the Customer's social-media audience only as aggregate metrics. |
| Categories of personal data | Names, e-mail addresses, phone numbers, job roles; approver decisions with IP address and user agent; images and likenesses in uploaded photos and generated content (only with a recorded consent); business contact details in website text; WhatsApp phone numbers and opt-in proof; Search Console query data; platform account identifiers and usernames; access tokens (ciphertext; or held by the Aggregator); aggregate audience metrics. |
| Special categories | None requested. The optional "religions served" field in the brand profile and any photos the Customer chooses to upload may reveal such data; the Customer controls whether to provide it. |
| Frequency | Continuous while the Service is used; scheduled jobs weekly (planning), daily (token refresh), at publish times, and at +1 h, +24 h, +7 d for analytics. |
Annex B: Technical and organisational security measures
| Area | Measure |
|---|---|
| Tenant isolation | Every tenant table carries owner_org_id (and brand_id where applicable); Postgres row-level security enforces owner_org_id = current org OR brand_id in granted brands on every query; the API layer sets the acting context per transaction; automated cross-tenant tests run in CI on every deploy. |
| Access control | Roles (Owner, Admin, Editor, Approver, Viewer, Agency Manager via brand_grant) enforced in the API and the database; staff roles scoped; staff impersonation limited to one hour, admin-on-admin disabled, acting_user_id on every request, red banner, append-only audit log visible to the affected Organisation. |
| Authentication | One-time codes by e-mail or SMS, or an e-mail address and a password, stored only as a salted scrypt hash in a table the application's own database role cannot read; passkeys later; multi-factor authentication for staff and agency owners; magic links expire in 7 days, are bound to the approver's e-mail or phone, optionally behind a one-time code. |
| Channel tokens | During the Aggregator bridge, tokens are held by the Aggregator under its approvals and Adrologic stores only a profile identifier and a health flag. With Adrologic's own connectors, tokens are stored as ciphertext only, envelope-encrypted (per-tenant data keys under a master key; rotation re-wraps keys), decrypted only in the publish function or worker at publish time, never logged, never in workflow payloads, never returned by any API; access audited. |
| Encryption | TLS in transit everywhere; encryption at rest on the database, object storage and backups (provider-managed keys); envelope encryption for tokens as above. |
| Secrets | In a secrets vault, never in code, never in a person's head; rotated on staff change. |
| Logging and monitoring | Error monitoring (Sentry) with IP scrubbing and no tokens; product analytics with pseudonymous IDs; append-only audit_log of plan-catalogue, role, grant, transfer and deletion events; alerts on connector failure rate, re-auth backlog, provider latency, credit-reservation leaks and per-brand cost ceilings. |
| Webhooks | Signed and verified (Razorpay, Meta, Aggregator, providers); idempotent processing keyed on unique indexes. |
| Backups and recovery | Nightly encrypted database dump to object storage with 30-day retention plus the database provider's point-in-time recovery window; restore tested before Week 8 hardening and quarterly thereafter. |
| Availability | Publishing runs on a separate durable-workflow path from rendering; public status page; failure-notification target 5 minutes; runbooks for the ten most likely incidents (Week 8). |
| Data minimisation | Draft-tier previews before paid renders; only user-confirmed business facts stored from Google Places (30-day cache, place ID excepted); Sub-processors receive identifiers rather than content where the function allows. |
| Change and vulnerability management | Dependency audits in CI; security pass (RLS audit, webhook signatures, dependency audit) at Week 8 and before each major release; policy watch quarterly. |
| Deletion | Tenant-scoped erasure walking every store (Section 8.3); Meta Data Deletion Callback with confirmation code and status URL; in-app account deletion on web and mobile. |
| Personnel | Founder-only at launch; confidentiality written into every contractor agreement; least-privilege roles pre-defined for the first hire; a second production operator with break-glass access before the investor demo. |
| Independent assurance | SOC 2 controls that cost nothing from month 1 (RLS tests in CI, append-only audit log, secrets vault, access log); SOC 2 Type 1 when agencies ask; Type 2 later. |
Annex C: Sub-processors (as of 2026-09-17)
Legend for "From": the point in our rollout when the vendor first processes customer data (Day 0 = the first two days of the build; Day 30 = public launch). "Conditional" means the vendor is engaged only if the stated condition occurs; it will be added to the public list with 30 days' notice at that time.
| # | Sub-processor | Service to CRAIVIS | Data it processes | Location / region | From | Safeguard |
|---|---|---|---|---|---|---|
| 1 | Neon, Inc. | Managed Postgres with pgvector: the primary database for every tenant table (organisations, brands, Brand Brain, posts, ledger, audit) | All Customer Personal Data in Annex A, tokens as ciphertext only | Singapore (Neon has no Mumbai region, C21) | Day 0 | Vendor DPA; encryption at rest; RLS |
| 2 | Vercel, Inc. | Web application hosting, serverless functions (still-image rendering in Weeks 1-3, the exact-minute publish path via Inngest), preview environments | Requests and responses, session data in transit, rendered stills in transit | Mumbai (bom1) primary; global edge for static assets | Day 0 | Vendor DPA |
| 3 | Cloudflare, Inc. | R2 object storage (originals, renders, backups), Cloudflare Images (variants), CDN for public media URLs, Turnstile bot protection | Media files (which may contain likenesses), backup files (encrypted), IP addresses for bot checks | Global network; storage with Asia-Pacific jurisdiction hint | Day 0 | Vendor DPA; jurisdiction restriction |
| 4 | Inngest, Inc. | Durable workflows: generate → wait for approval → sleep to the minute → publish → verify → metrics | Post, brand, organisation and job identifiers; step state; error messages. Never tokens, never media | United States | Day 0 | Vendor DPA; identifiers only |
| 5 | Railway Corp. | Rendering worker (ffmpeg, Remotion) for motion posts (Week 4) and reels (Week 6) | Media during rendering, transient | Region chosen at setup, closest available to India | Week 4 | Vendor terms; transient storage |
| 6 | Upload-Post (the launch Aggregator) | Publishing bridge for Instagram, Facebook Pages and, if supported, Threads and LinkedIn member profiles, under its own Platform approvals, with white-labelled consent screens | Platform OAuth tokens, connected-account identifiers, media URLs, captions, schedules, AI-disclosure flag, publish results | Week 3 (Professional tier); until Adrologic's own connector migrates each Channel | Vendor DPA and written answers on quota partitioning and data handling; Adrologic stores only a profile ID and health flag | |
| 6a | Ayrshare (fallback Aggregator) | Same function as #6 | Same as #6 | Conditional: only if Upload-Post cannot serve | Vendor DPA at engagement | |
| 7 | fal.ai (Features and Labels, Inc.) | Image and video generation (FLUX.2, Nano Banana via fal, Ideogram, Recraft, Seedream, Kling, Hailuo, Wan) | Prompts (which include brand facts: products, city, tone; never approver or member data), reference images the Customer approved, generated media | United States | Week 3 | Vendor terms with commercial rights and no training on inputs (licence flag in the router) |
| 8 | WaveSpeed | Draft-tier images (FLUX.2 Klein) and animated draft previews (Wan 2.2 Ultra Fast); Standard fallback route | As #7 | Week 6 | Vendor terms; router licence flags | |
| 9 | Anthropic, PBC | Language models (Claude Haiku, Sonnet, Opus): brand extraction from website text, weekly plans, captions, hashtags, alt text, per-platform variants, moderation and output review, the assistant | Website text, brand facts, captions, review-card content, moderation inputs; no channel tokens; approver names only if present in content | United States | Day 0 / Week 2 | Anthropic commercial terms (no training on API inputs); prompt caching within Anthropic's retention |
| 10 | Google LLC | (a) Gemini API: classification, TTS voice-over (Week 13), Lyria music beds; (b) Vertex AI: Veo for Cinematic reels (conditional on C16); (c) Places API: onboarding pre-fill; (d) PageSpeed Insights API and Search Console API (read-only, webmasters.readonly): SEO add-on (Week 11); (e) Google Play and Firebase Cloud Messaging: Android distribution and push; (f) Google OAuth |
Per API: text for classification and scripts; website URLs; place lookups (cached ≤ 30 days, place ID excepted); Search Console query data under Limited Use; push tokens and notification text | United States / global | Day 0 (Gemini, Places); Week 8 (Play, FCM); Week 11 (Search Console); Cinematic conditional | Google API terms and Cloud DPA; Google API Services User Data Policy (Limited Use) |
| 11 | Razorpay Software Pvt Ltd | Payments: subscriptions, UPI AutoPay and e-NACH mandates, international cards (USD-priced, INR-settled, eFIRC), invoices, refunds | Billing name, address, e-mail, phone, amounts, mandate and subscription IDs; card and bank credentials are collected by Razorpay directly and never reach Adrologic | India | Week 3 (test mode); Week 4 (live) | Razorpay terms; PCI DSS on Razorpay's side |
| 12 | Resend, Inc. | Transactional e-mail: one-time codes, magic links, digests, "needs attention", client-approval requests, receipts | Recipient e-mail address, message content (which may include brand names and post previews), delivery status | United States | Day 0 | Vendor DPA |
| 13 | PostHog, Inc. | Product analytics and feature flags per Organisation | Pseudonymous user and organisation IDs, event names and properties (screens, timings, plan), device and browser information; no content, no tokens | EU cloud | Day 0 | Vendor DPA; person-deletion API used on erasure |
| 14 | Functional Software, Inc. (Sentry) | Error and performance monitoring | Stack traces, request metadata, user ID; IP addresses scrubbed; tokens and secrets excluded by filter; events expire after 90 days | European Union | Day 0 | Vendor DPA; data scrubbing rules |
| 15 | Calendarific | Licensed holiday and occasion feed for the Occasion Graph | No personal data. Adrologic queries dates by country and year; no customer data is sent. Listed for completeness as a data source | — | Day 0 | Commercial licence (Business tier; C32 closed) |
| 16 | 650 Industries, Inc. (Expo) | Mobile builds (EAS) and the Expo push notification relay | Device push tokens, notification text (for example "7 posts ready for {brand}"), app version | United States | Week 6 (push); Week 7-8 (builds) | Vendor terms |
| 17 | Apple Inc. | App Store distribution, TestFlight, Apple Push Notification service | Device tokens, notification text; App Store account data under Apple's terms | Global | Week 7-8 | Apple developer terms |
| 18 | Upstash, Inc. | Redis for rate buckets and idempotency keys | Identifiers and counters only | Region chosen at setup | Week 6, only if publish volume needs it | Vendor DPA; identifiers only |
| 19 | Langfuse GmbH | LLM tracing and evaluation | Prompts and outputs (brand facts, captions); traces deleted on tenant erasure | Germany (EU) | Month 4 (conditional on adoption) | Vendor DPA |
| 20 | Instatus or BetterStack | Public status page under status.craivis.com |
E-mail addresses of people who subscribe to status updates; no other customer data | (per vendor) | Week 4 | Vendor terms |
| 21 | Slack Technologies (or WhatsApp Business, Meta) | Internal alert to the founder on every publish failure | Post ID and brand display name only; no approver or member data | United States (Slack) | Week 4 | Internal use policy; minimal fields |
| 22 | ElevenLabs, Inc. | Premium voice-over (ElevenLabs v3) and Eleven Music fallback | Reel scripts (brand facts); no personal data by design | United States | Conditional: Premium voice tier (month 4+) | Vendor terms (commercial use on paid plan) |
| 23 | Stability AI | Stable Audio 2.5 as the second music fallback | Music prompts; no personal data | United States / UK | Conditional | Vendor terms |
| 24 | Black Forest Labs (direct) | FLUX image models as a direct fallback route behind fal and WaveSpeed | As #7 | Germany | Conditional (fallback chain from Week 6) | Vendor terms |
| 25 | Runway AI, Inc. | Video generation, only under an Enterprise agreement with no training on inputs and with indemnity | As #7 | United States | Conditional: never below Enterprise (router licence flag) | Enterprise agreement if ever signed |
| 26 | Polotno | In-browser design editor SDK (v2) | Design JSON in the Customer's browser; server-side rendering of designs if used | Conditional: v2 | Vendor terms | |
| 27 | Adrologic Pvt Ltd services team (internal) | Receives "Request a fix" leads from the SEO add-on | Name, e-mail, website, the report | India | Week 11 | Same entity; separate service terms |
| 28 | DeepSeek | Draft-tier weekly-plan route (DeepSeek V4.1 Flash) in the media router | Brand facts and occasion context inside planning prompts; no member, approver or contact data | Conditional: from Week 6 at the earliest (Weeks 1-5 run on fal, Anthropic and Google only), and only once its terms pass the vendor-terms filter in 5.5 (commercial rights, no training on inputs) | Vendor terms; router licence flags; added to the public list with 30 days' notice before first use | |
| 29 | Luma AI; Higgsfield | Last-resort video fallbacks in the media router | As #7 | United States | Conditional: only if every earlier route in the fallback chain fails and the vendor passes the filter in 5.5 | Vendor terms; router licence flags |
Not sub-processors (independent controllers): the Platforms the Customer connects (Meta: Instagram, Facebook, Threads, WhatsApp Business Platform; LinkedIn; X; Bluesky; Google Business Profile; later TikTok, YouTube, Pinterest). They receive content on the Customer's instruction and process it under their own terms. Meta's WhatsApp Business Platform processes the Customer's opted-in contacts' numbers under the Customer's own WhatsApp Business Account when the add-on is used.
Change log. Every change to this Annex is recorded with the date, the vendor, the change and the notice sent, at craivis.com/legal/subprocessors and in docs/COMPLIANCE-PACK/POLICY-CHANGELOG.md.
Annex D: Transfer mechanism (EU / UK data, when applicable)
D.1 Standard Contractual Clauses. Where the GDPR applies to a transfer, the parties are deemed to have entered into the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor) or Module Three (processor to processor) as the Customer's role requires, with: Clause 7 (docking) included; Clause 9 Option 2 (general authorisation) with the 30-day period in Section 5.2; Clause 11 optional language not included; Clause 13 and the competent supervisory authority as the authority of the Member State where the Customer is established; Clause 17 Option 1 governed by the law of Ireland; Clause 18 courts of Ireland; Annex I completed by this DPA's Annex A and the parties' details; Annex II completed by Annex B; Annex III completed by Annex C.
D.2 UK. For UK GDPR transfers, the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner applies, with the tables completed by reference to D.1 and this DPA.
D.3 Onward transfers. Adrologic ensures each Sub-processor in Annex C that receives EU/UK data is bound by equivalent clauses or another valid mechanism.
D.4 Activation. This Annex has no effect until Adrologic processes EU or UK personal data. EU/UK selling is not planned in the first 12 months; when it is switched on, Adrologic will offer EU residency (a second database project and bucket) and re-issue this DPA with a signed version of the Clauses.