Garuna Group · Enhanced Due Diligence

Effective 2 September 2026 · Version 1.1 ·

GARUNA GROUP — Enhanced Due Diligence Privacy Policy

Provider: Garuna Group ("Garuna", "Provider", "we", "us") — Garuna Inc., a corporation incorporated under the laws of the Province of Ontario and operating as "Garuna Group", with registered office at 10 Thornmount Drive, Toronto, Ontario M1B 3J4, Canada Product: Enhanced Due Diligence ("EDD" or the "Service") Governing law: Province of Ontario and the federal laws of Canada applicable therein Primary privacy regime: Personal Information Protection and Electronic Documents Act (Canada) ("PIPEDA"); the General Data Protection Regulation (EU) and UK GDPR are addressed for EU/UK individuals Effective date / Last updated: 2026-09-02 Version: 1.2

This Privacy Policy is incorporated by reference into, and forms part of, the Terms of Service / Master Services Agreement (the "Terms"), which is the master agreement governing the Service. Capitalised terms used but not defined here have the meanings given in the Terms.

1. Introduction and scope

This Privacy Policy explains how Garuna handles Personal Data in connection with the Service. The Service is a business-to-business application: it is licensed to organisations ("Clients") and operated by the individuals a Client authorises ("Authorised Users"). It is not offered to, or directed at, consumers or the general public.

The Service is currently provided on an Early Access basis, with warranties limited accordingly as set out in the Terms and the Disclaimers & Legal Notices. Access is account-gated (controlled by a garunagroup.com account login) and sold by monthly membership; every membership covers individual, entity and cryptocurrency searches. Every account holder warrants a documented lawful purpose for each query, and a holder who relies on a professional licence warrants that it is current. This is a warranty and account-gating control; the Service does not perform in-app verification of any licence number.

This Policy distinguishes two fundamentally different categories of Personal Data, because Garuna's role and responsibilities differ for each:

Category A — Client and Authorised User data: account, contact, authentication, usage/log, and billing information about the people who hold and operate Client accounts. For this category Garuna is the controller (PIPEDA: the "organization" determining purposes and means).
Category B — Subject data: Personal Data about the third-party persons or entities that are the object of a Sweep, processed when an Authorised User runs the Service. For this category the Client is the Controller and Garuna is the Processor / service provider, acting only on the Client's Documented Instructions — except for the narrow, self-purpose operational logging described in section 11, for which Garuna acts as a controller of that limited log data.

Sections 2–7 address Category A. Sections 8–14 address Category B. Sections 15 onward apply to both.

In this Policy, "Personal Data" and "Personal Information" are used interchangeably and mean information about an identifiable individual ("Personal Information" in the PIPEDA sense; "personal data" in the GDPR/UK GDPR sense).

PART A — CLIENT AND AUTHORISED USER DATA (Garuna as controller)

2. What we collect about Clients and Authorised Users

When a Client subscribes to the Service and its Authorised Users operate it, we process:

Account and identity data: organisation name, the name, job title, and business email of Authorised Users and Client administrators.
Contact data: business contact details used for support, service notices, and legal/privacy correspondence.
Authentication and security data: credentials, session identifiers, and related authentication metadata used to control access to the Service.
Usage and operational log data: records of access to and operation of the Service — including the timing of Sweeps, which optional capabilities and Investigation Sessions were used, and the scope and mode (e.g. Deep Mode) selected. As explained in section 11, these operational logs also transiently record a Subject's name and type and the connecting Authorised User's own session handle; that aspect is treated as Category B data.
Billing data: subscriptions, top-up purchases, rush-priority fees, and add-ons are processed by an established third-party payment processor under its own terms; we do not receive or store full payment-card numbers. We store the limited billing information needed to operate the account and issue receipts: the subscription plan, its status and billing-period dates, purchase and receipt records (description, amount, taxes, currency, date), a payment-processor customer/transaction reference, and any billing details the Client chooses to save in the account tab (company name, tax registration number, billing address).

We do not collect Personal Data about Authorised Users beyond what is necessary to provide, secure, support, and bill for the Service.

3. Why we use it, and our lawful basis (Category A)

We use Category A data to: provide and operate the Service; authenticate users and secure accounts; maintain service integrity and investigate misuse; provide support; communicate service, security, and legal notices; and administer billing and our contractual relationship with the Client.

Our lawful basis under PIPEDA is the Client's and Authorised Users' consent to the processing described here in the course of using a service they have engaged, together with our legitimate business interests in operating, securing, and being paid for the Service. For Authorised Users in the EU/UK, our bases under GDPR/UK GDPR Article 6 are performance of a contract (or steps to enter one), legitimate interests (operating and securing the Service, fraud and misuse prevention), and legal obligation where applicable. We do not use Category A data for advertising and do not sell it.

4. Retention (Category A)

We retain Category A account, contact, and authentication data for the duration of the Client's participation in the Early Access pilot or subscription and for a reasonable period afterward — up to twelve (12) months — as needed to close out the relationship, resolve disputes, and meet legal obligations, and we retain financial and accounting records (such as invoices, where any apply) for seven (7) years as required by applicable tax and accounting law. Operational log data is retained on the schedule described in section 11. When data is no longer required for these purposes, we delete or de-identify it.

5. Disclosure (Category A)

We disclose Category A data only: to service providers that help us host, secure, support, and bill for the Service, under contract and only as needed; where required by law or valid legal process; and in connection with a corporate transaction, subject to confidentiality. We do not sell Category A data.

6. Rights (Category A)

Authorised Users and Client administrators may request access to, correction of, or deletion of their Category A Personal Data, and may withdraw consent (which may affect the ability to use the Service), by contacting our privacy office (section 18). EU/UK individuals additionally have the rights described in section 16. We respond within the timeframes required by applicable law.

7. Security (Category A)

Category A data is protected by the security measures described in section 15.

PART B — SUBJECT DATA (Garuna as processor for the Client)

8. Our role for Subject data, and yours

When an Authorised User runs a Sweep, the Service processes Personal Data about the Subject — a third party (a person or entity) who is not the user and is generally unaware of the Sweep.

For this Subject data:

The Client is the Controller (PIPEDA: the "organization"). The Client determines the purpose and means of each Sweep, selects the Subject, and is responsible for ensuring there is a lawful basis and authority for the processing and for any transparency or notice obligations owed to the Subject.
Garuna is the Processor / service provider. We process Subject data only on the Client's Documented Instructions — comprising the Terms, the Data Processing Addendum ("DPA"), the Client's configuration of the Service, and each Sweep the Client initiates. Garuna does not determine the purpose of any Sweep, and does not use Subject Personal Data for its own purposes. The one exception is the limited operational logging in section 11, which Garuna performs for its own service-operation and security purposes and as to which Garuna acts as a controller; that logging is narrow, bounded, and time-limited.

Because Subjects are generally unaware of a Sweep, the Client — as Controller — is the party accountable for any applicable transparency and notice obligations to Subjects. Where the Client must establish a lawful basis to process a Subject's Personal Information without consent, it typically relies on PIPEDA's investigation, fraud-prevention, business-transaction, and due-diligence provisions (including the relevant grounds in sections 7(1)–7(3) of PIPEDA); for Subjects in the EU/UK it typically relies on GDPR/UK GDPR Article 6(1)(f) legitimate interests (with a recorded balancing assessment, and consideration of Article 9 where special-category data may arise). Garuna does not warrant the Client's basis and processes on the Client's instruction. Garuna assists the Client as Processor as described in section 14.

9. Categories of Subject data processed

A Sweep can process the following Personal Data about a Subject:

Subject Inputs submitted by the Client/Authorised User to define the Subject: legal full name, optional jurisdiction, email, phone, alias/username, domain, and free-text context.
Collected open-source material about the Subject gathered from the sources in section 10, which may include: profile and digital-footprint information; existence of online accounts; corporate, registry, and ownership records; court and litigation references; sanctions and watchlist screening results; adverse-media references; breach/leak presence indicators; and a Subject's public social-engagement signals (follows, likes, replies, boosts).
Personal Data contained in the Report produced from the above, including the identity-resolution disclosure, confidence breakdown, gaps list, and risk score.

Sensitive and special-category information. Open-source and public-record material about a Subject may, depending on the Subject, reveal or imply information that is sensitive or constitutes special-category data under GDPR/UK GDPR (for example, information from which political opinions, religious beliefs, health, sexual orientation, or trade-union membership might be inferred), as well as adverse-media, sanctions, watchlist, and litigation/criminal-allegation information. The Service does not deliberately seek out special-category data, but such data may surface in publicly available sources. The Client, as Controller, is responsible for ensuring any necessary additional condition for processing such data is met.

Same-name and accuracy note. The Service grades, clusters, and resolves findings to the correct individual and excludes and flags same-name strangers; it never fabricates a face. Despite these controls, open-source material can be incomplete, outdated, or mis-attributed, and AI-assisted synthesis can contain errors. Accuracy limitations are addressed in the Disclaimers & Legal Notices and disclosed in-product.

10. Sources of Subject data

Subject data is derived from the Subject Inputs the Client provides and from publicly available information that the Service collects on the Client's instruction, including: open web search results; public-record and registry services; sanctions, court, corporate, securities, trademark, and entity-resolution sources; breach/leak presence checks; account-discovery checks; and — only where an Authorised User has established an Investigation Session by signing in themselves — a Subject's public social-engagement graph and authenticated public profile information on a platform the Authorised User has connected.

Investigation Sessions — supported platforms. An Investigation Session may be established on any of X, Instagram, Reddit, LinkedIn, and Facebook. A connected session may be reused both to read a Subject's public engagement graph (currently supported for X and Instagram) and to retrieve a Subject's publicly displayed profile photo on any connected platform (including LinkedIn and Facebook). Several of these platforms — notably LinkedIn and the Meta properties (Facebook and Instagram) — prohibit automated access and the use of investigation/"burner" accounts in their terms of service; the Authorised User is solely responsible for ensuring any connected account is their own or duly authorised and for compliance with each platform's terms, and acknowledges this per platform at the in-app gate. The Service never cracks, guesses, or bypasses authentication; an Investigation Session only reuses a session the Authorised User created by logging in themselves.

The specific backends and sources that may be engaged, and what each receives, are listed in our Sub-processor List / Annex and summarised in section 12.

11. Ephemerality, caches, and retention of Subject data

Subject-data handling is designed to minimise retention. The following statements are accurate to the Service's architecture:

Processing and limited retention. Subject Personal Data is processed during a Sweep, and the resulting Report is retained on Garuna's servers for a limited period (currently thirty (30) days) so that the requesting Client can retrieve it (for example through an e-mailed delivery link), after which it is deleted automatically. There is no standing, searchable database of Subjects.
Reports, monitoring, and record checks. A Report is streamed to the requesting Client in their browser and held for the limited retention period above. The Client may export it; once exported, the Client controls that copy and is responsible for its security, retention, and lawful use. Where the Client enables continued monitoring, the Subject identifiers needed to re-run the search are stored for the life of that monitoring entry and deleted when it is removed. Where the Client orders a paid record check, the additional inputs it supplies (for example a date of birth) are held only until the check is fulfilled or cancelled, and in any event no longer than seven (7) days from the order, whether or not the check has been completed. An input exists to run one registry search; it is not retained on the chance that someone returns to it.
In-memory search cache. Web-search results are cached in memory for approximately one hour (a size-capped least-recently-used cache) to avoid duplicate calls. This cache is not written to disk and is not a Report store.
Persistent on-disk cache (reference data only). The only persistent on-disk cache maintained by the Service is the consolidated government sanctions & watchlist reference lists — public reference data, refreshed approximately every 24 hours. This is not Subject-specific and is not a record of any Sweep or Subject.
Short-lived temporary working files. Certain account-discovery checks write Subject identifiers (such as an email, username, or phone number) and their results to short-lived temporary working files on the server while the check runs; these working files are deleted at the end of the check. In the rare event of an abnormal termination before clean-up completes, such a temporary file could persist until the next clean-up; outside of that exception these files do not survive the check.
Authenticated-tool credential note. One optional authenticated-lookup capability that queries a major email/account provider's account surface using the Subject's email (see section 12) relies on a session with that provider that an Authorised User authenticates once. The optional authenticated-lookup credential (the analyst's own credential, not Subject data) for that session is stored on the server's disk (it is not a Report, a Subject record, or part of any export), and it relates to the Authorised User's own authenticated session rather than to any Subject. This is a deliberate exception to the in-memory-only handling described above and is disclosed here for openness. This authenticated-lookup capability is disabled by default; it operates only in a deployment where the Provider (or the Authorised User) has separately configured and authenticated it, and in the Early Access (invite-only pilot) it is off unless a Client is specifically notified that it has been enabled for that Client's deployment. Where it is disabled, this note and the corresponding sub-processor entry do not apply to that deployment.
Investigation Session cookies. With the exception noted immediately above, the captured browser session state of an Investigation Session (the analyst's investigation-account cookies for mainstream social platforms such as X, Instagram, Reddit, LinkedIn, and Facebook) is held in process memory only. It is never written to disk, never logged (only a cookie count is logged), and never serialised into a Report or export. The Service's interface exposes only status indicators and the analyst's own handle. The analyst can disconnect the session.
Operational logs (stated honestly). The Service writes informational server logs that transiently record the Subject's name and type, which Investigation Sessions and scope were used, the Deep-Mode flag, and timing, and — on session connect — the connecting Authorised User's own session handle. As a result, a Subject's name can appear transiently in operational logs. Garuna processes these logs as a controller, for its own narrow service-operation, troubleshooting, and security purposes only; its lawful basis is its legitimate interests in operating and securing the Service (and, for EU/UK individuals, GDPR/UK GDPR Article 6(1)(f)). These logs are access-controlled, are not a Report store, and are retained only for a short, fixed maximum period — thirty (30) days — after which they are rotated and deleted. Rotation and deletion are performed automatically on an hourly timer by a single retention process that also enforces every other window in this section; a log that has not been written to since before the window is emptied even if it is small.

In short: outside of the limited Report retention period, active monitoring entries, pending paid record checks, access-controlled time-limited operational logs, the non-Subject-specific government sanctions & watchlist reference cache, short-lived temporary working files that are deleted at the end of a check, and (where enabled) the single authenticated-tool credential file described above, Garuna does not retain Subject Personal Data.

12. Disclosure of Subject data — Sub-processors and Independent Public Sources

To perform a Sweep, the Service transmits Subject identifiers and/or query terms to third-party services. We distinguish two kinds:

Sub-processors — third parties that process Subject data on Garuna's behalf in delivering the Service. These include web-search providers (open-web search backends) that receive the Subject name and query terms across several independent search backends, where configured; a commercial web-retrieval / proxy provider, which is used to fetch certain anti-bot-protected pages (including, for entity trademark checks, a top trademark-registry result); data-breach & credential-exposure intelligence providers, which receive the Subject's email and/or phone number; and, in Deep Mode only, a cloud AI synthesis & verification provider (which performs higher-tier AI synthesis and independent claim verification, and includes a verification-fetch component). In default/fast mode, AI synthesis stays on-device and no external-model transfer occurs.
Independent / Public Sources — third-party public-record, registry, and open-source services that we query with Subject identifiers and that act as independent controllers of their own data. These include: government sanctions & watchlist sources; U.S. court, tribunal & case-law repositories; Canadian court, tribunal & case-law repositories; U.S. securities & corporate-disclosure filings; corporate / business registries & legal-entity identifiers (UK / Australia / global) (some if keyed); a structured public knowledge graph (nonprofit reference); global news & media archives; official motor-carrier safety & licensing records (US) (some if keyed); email / identity reputation services (which receive the Subject's email, sent as a one-way hash where supported); domain registration & certificate-transparency records (which receive the Subject's domain); the patent & trademark registries (US / international) queried for entity trademark checks (which receive the Subject name); public code / developer-platform presence; a web archive & historical snapshots (nonprofit) service; federated and community platforms; and — if keyed — data-breach & credential-exposure intelligence and an aggregated international sanctions / PEP reference. Where an Authorised User connects an Investigation Session, the relevant mainstream social platform (such as X, Instagram, Reddit, LinkedIn, and Facebook) likewise acts as an independent platform receiving requests through the analyst-authenticated session. These Independent Public Sources are not Garuna's Sub-processors; we list them for transparency and cross-border disclosure.

Account-discovery checks. The Service runs account-existence discovery tooling — open-source techniques that submit Subject identifiers directly to many third-party websites to test for the existence of accounts. Depending on the identifier supplied, the Subject's email, phone number, and/or username is sent to the relevant target sites to detect whether associated accounts exist; and, where enabled and authenticated, an authenticated account lookup against a major email/account provider sends the Subject's email to that provider to surface the public account surface associated with it (for example a profile name and photo, associated services, and a public review count). These checks transmit Subject identifiers to numerous third-party sites, and the authenticated lookup transmits the Subject's email to that major email/account provider; many of these recipients are based in the United States or other countries.

The complete, current inventory — naming each component, what it receives, its category (Sub-processor vs Independent Public Source), its location and transfer exposure, and whether it is on-device, default, configurable, keyed-optional, or Deep-Mode-only — is maintained in our Sub-processor List / Annex, which is incorporated into the DPA and into this Policy and is kept in line with the Service as actually deployed. To request or subscribe to changes, contact our privacy office (section 18).

On-device and minimal-transfer configurations. Several components run on Garuna's own infrastructure or on-device (a self-hosted private meta-search layer; an on-device AI model for synthesis and on-device identity adjudication of ambiguous same-name clusters) and involve no third-party transfer. In a configuration that uses only the self-hosted search backend and on-device models, and that does not engage the external sources, account-discovery checks, or Investigation Sessions described above, a Sweep can run with minimal third-party transfer. Cross-border and third-party transfer occurs only when the relevant external backends, sources, checks, or sessions are used.

We do not sell Subject data, and we do not use it for advertising.

13. International transfers of Subject data

Many of the Sub-processors and Independent Public Sources used by the Service — including the web-search providers, the commercial web-retrieval / proxy provider, the data-breach & credential-exposure intelligence providers, the email / identity reputation services, the patent & trademark registries, the Deep-Mode cloud AI synthesis & verification provider, the account-existence discovery target sites, the authenticated lookup against a major email/account provider, and the Investigation Session platforms — are based in the United States or other countries outside Canada. Accordingly, when those backends, sources, checks, or sessions are engaged, Subject data is transferred across borders and becomes subject to the laws of the receiving country, including lawful access by that country's authorities. As noted in section 12, a fully on-device configuration minimises such transfer, and no cross-border transfer occurs for the on-device components.

Under PIPEDA, Garuna uses contractual and other means to provide a comparable level of protection to Subject Personal Data processed by our Sub-processors while it is in their hands; Independent Public Sources are independent controllers of their own data and process it under their own terms.

For Subjects in the EU/UK, transfers of Subject data to a country without an adequacy decision are made under an appropriate transfer mechanism — the Standard Contractual Clauses (and the UK International Data Transfer Addendum, where relevant) — as incorporated into the DPA. The Client, as Controller, remains responsible for its own transfer-mechanism obligations and for any information owed to data subjects under GDPR/UK GDPR Article 14.

14. Subject (data-subject) rights and how they are handled

Garuna respects individuals' rights in their Personal Data. However, the way a Subject's request is handled follows from the architecture and from the controller/processor allocation:

Because Subject data is retained only for the limited period described in section 11, Garuna holds a record of a Subject only while a Report, monitoring entry, or pending record check exists; requests received during that period are actioned against those records (including deletion on request), and afterwards only short-lived, access-controlled operational logs may remain.
The Client is the Controller of Subject data and is the party responsible for receiving and actioning Subject access, correction, erasure, objection, restriction, and related requests, and for any notice to Subjects. Garuna, as Processor, assists the Client in responding to such requests to the extent the data exists and is identifiable, as set out in the DPA.
Any exported Report is controlled by the Client; requests concerning an exported Report are a matter for the Client.

If an individual contacts Garuna directly about a Sweep concerning them, we will, where lawful and appropriate, route the request to the relevant Client as Controller and assist that Client in responding. Subjects in the EU/UK have the rights described in section 16, which are generally exercised against the Client as Controller.

PART C — PROVISIONS COMMON TO BOTH CATEGORIES

15. Security

We maintain technical and organisational measures appropriate to the sensitivity of the data, including: access controls and authentication for the Service and its logs; the privacy-by-design measures described in section 11 (time-limited retention of Reports with automatic deletion, no standing Subject database, deletion of temporary working files at the end of each account-discovery check, and Investigation Session cookies held in memory only — never written to disk, never logged, never exported, subject only to the single disclosed authenticated-tool credential exception in section 11); encrypted transport for data in transit; short-lived, access-controlled operational logging with rotation; and contractual security commitments from our Sub-processors. The DPA describes our security measures in further detail. No method of transmission or storage is perfectly secure; we cannot guarantee absolute security, but we work to protect Personal Data against unauthorised access, use, disclosure, alteration, and loss.

Under PIPEDA, individuals may, subject to legal exceptions, request access to and correction of their Personal Information, withdraw consent, and ask questions about our handling of it. For Category A data, address requests to us (section 18). For Subject (Category B) data, see section 14 — such requests are generally directed to the Client as Controller, with Garuna assisting.

Under GDPR / UK GDPR, individuals in the EU/UK have the rights of access, rectification, erasure, restriction, portability, and objection, and rights concerning automated decision-making (Article 22). For Category A, Garuna is the controller and will action these directly. For Category B, the Client is the controller and is the primary point of contact for these rights, with Garuna assisting as processor.

Automated decision-making. No solely-automated decision producing legal or similarly significant effects may be made on the Service's Output without meaningful human review. The Output is intelligence to inform human judgement, and a human-in-the-loop with independent verification is required (consistent with PIPEDA, Quebec's Law 25 automated-decision transparency, and GDPR/UK GDPR Article 22).

We respond to verifiable requests within the timeframes required by applicable law and may need to verify identity before acting.

17. Cookies and local storage

The Service uses strictly necessary session/authentication cookies required to operate the Service securely. It also stores a single functional flag in your browser's local storage to record that an Authorised User has accepted the in-app legal acknowledgements (the acceptance gate), so the gate is not shown again on that browser; the same acceptance is also recorded server-side as evidence of acceptance. We do not use advertising cookies, cross-site tracking, or third-party analytics/advertising trackers in the Service. The only browser storage the front end sets is a single local-storage flag (edd_legal_accept_v1) recording that an Authorised User has accepted the in-app legal gate, together with the strictly-necessary session/authentication cookies required to operate the Service securely.

18. Privacy officer, contact, and complaints

Questions, requests, and concerns about this Policy or our handling of Personal Data may be directed to our privacy office:

Privacy / data protection: [email protected]
Legal notices: [email protected]
General enquiries: [email protected]
Postal address / Privacy Officer: The Privacy Officer, Garuna Inc. (operating as "Garuna Group"), 10 Thornmount Drive, Toronto, Ontario M1B 3J4, Canada ([email protected])

Right to complain. If you are not satisfied with our response, you may complain to the Office of the Privacy Commissioner of Canada (www.priv.gc.ca). Individuals in the EU/UK may also complain to their local supervisory authority — in the UK, the Information Commissioner's Office (ICO) — and Subjects in the EU/UK may direct complaints to the relevant Client as Controller and/or to the competent supervisory authority.

19. Children

The Service is a business-to-business tool intended for use only by Authorised Users acting on behalf of a Client. It is not directed to children and is not intended for use by anyone under the age of majority. We do not knowingly collect Personal Data of children as Authorised Users. The Service may, however, process publicly available information about a Subject as instructed by the Client; the Client, as Controller, is responsible for the lawfulness and appropriateness of selecting any Subject.

20. Changes to this Policy

We may update this Policy from time to time. The "Effective date / Last updated" and "Version" fields at the top reflect the current version. Material changes will be communicated to Clients in accordance with the Terms. Changes to our Sub-processors are notified through the mechanism described in the Sub-processor List / Annex. Continued use of the Service after an update takes effect constitutes acknowledgement of the updated Policy.

This Privacy Policy is Version 1.2, effective 2026-09-02, and is governed by the laws of the Province of Ontario and the federal laws of Canada applicable therein. It forms part of the Terms of Service / Master Services Agreement, which is the master agreement for the Service. On matters of Personal Data processing, the Data Processing Addendum prevails over the body of the Terms.