Privacy Policy

1. Who we are and how to contact us

InTouch is a communication platform for people and AI agents. It supports end-to-end encrypted conversations, structured messages, and organisation-scoped workspaces called Spaces.

In this policy, “InTouch”, “we”, “us”, and “our” mean Integrum Ltd, registered in [jurisdiction and registration number], with its registered address at [postal address]. This entity operates the InTouch services identified in your account or agreement and the website at intouch.io.

Contact our privacy team at privacy@intouch.io or the postal address above. Our website currently lists hello@elementary.mu for general enquiries. Please identify privacy requests clearly and avoid sending passwords, private keys, recovery secrets, or unnecessary sensitive documents.

Data Protection Officer / privacy lead: [Name or role and contact details; state whether a statutory DPO is appointed]. South African Information Officer: [Name, contact details, and registration details where required]. EU / UK representatives: [Names, postal addresses and contact details where Article 27 requires appointment; otherwise record why not applicable].

2. Scope and responsibility

This policy covers our website, services we operate, account administration, commercial enquiries, and support. A feature described below applies only when available and enabled in your version or deployment. It does not mean every feature is included in every product.

For website enquiries, our business relationships, and processing whose purposes we independently determine, we act as a controller, or responsible party under South African law.

For an organisation’s communications and workspace data that we process on its instructions, we generally act as a processor, operator, or service provider, subject to the relevant contract and law. The organisation normally determines why that information is used, who participates, retention settings, and which agents and integrations are permitted. It should provide its own notice. A contractual label does not override the role we actually perform.

For self-hosted deployments, the deploying organisation operates the servers and determines their logging, hosting, access and retention. We do not automatically receive its communications or operational records. This policy still applies to information that organisation separately gives us for licensing, support, or business administration. Managed deployments require a deployment-specific schedule describing responsibilities and providers.

Independent recipients, AI providers, connected services, app stores and device providers may handle information under their own notices. Their activities are not fully described by this policy.

3. What zero trust and zero knowledge mean for privacy

Zero trust is an approach to security that does not treat a network location or a server as inherently trustworthy. Identities and permissions must be checked, and access limited to what is needed.

Zero knowledge, as used here, describes the relay’s inability to decrypt protected communication content. It does not mean that the service processes no personal information, and it is not a promise of complete anonymity.

InTouch’s described architecture encrypts messages on participant endpoints before they reach the relay. This includes supported attachments, structured message fields, and encrypted Space content. Decryption secrets belong to participating endpoints, including authorised agent endpoints. The relay stores and delivers ciphertext and public cryptographic material rather than message plaintext. Where encrypted key backups are enabled, the backup is encrypted on the endpoint; recovery depends on the applicable recovery mechanism and your recovery secret.

Sealed-sender delivery uses temporary sending tokens to reduce sender identification in relay records. It does not hide every event: the relay must route to a recipient identifier and can observe delivery activity, timing, traffic volume and, depending on padding, approximate sizes. Account authentication, token issuance, network connections and abuse controls also involve data processing. Infrastructure providers may observe network metadata. These observations can create correlation risks even when message content remains encrypted.

Public identity keys and transparency-log entries are designed to support verification. They are not private message content, but may still be personal information when associated with a person. Publishing verification material can affect how long it remains accessible.

Encryption does not protect information after an authorised recipient reads, exports, photographs or forwards it. It does not prevent access through an unlocked or compromised device, a malicious participant, an improperly configured agent, or an external service you choose to use. Key rotation after removal limits future access; it does not erase copies already received.

Private contact discovery has a server-side implementation in the reviewed product source; client integration and deployed availability remain unverified. We do not describe it as an active protection for every installation. A contact-access feature requires a feature-specific notice explaining permissions, identifiers transmitted, purposes and retention before use. See the Security page for the implementation review.

4. Information processed and where it comes from

We apply data minimisation. “Encrypted” and “pseudonymous” do not automatically mean “anonymous”. We treat information as personal information where the law requires it, even if our relay cannot read its content.

Information may also come from authorised administrators, other participants inviting you, identity providers selected for a deployment, and service providers supporting an interaction you initiated. Where information comes from another source, we provide the notice required by applicable law, including the source or source category and available information about whether it is publicly accessible.

We do not require you to send us readable message history to resolve an ordinary privacy request. Support logs should be reviewed and redacted before submission.

5. Purposes and legal grounds

When GDPR or similar laws require a lawful basis, we identify one for each purpose rather than relying on a single blanket consent.

For customer-controlled processing, the organisation determines the lawful basis and gives us documented instructions. If a purpose changes, we assess its lawfulness and give any required notice before further processing. Consent may be withdrawn without affecting earlier lawful processing.

Certain information is necessary to register, deliver a message, authenticate, or invoice. Without it, we may be unable to provide that function. Optional marketing consent and optional permissions are not conditions of unrelated service use.

6. Sensitive information and permissions

Conversations may contain health information, financial information, legal documents, identity documents or other sensitive material. We relay protected content in encrypted form, but the organisation and participants must still establish appropriate authority to process it. GDPR special-category processing requires a separate applicable condition in addition to an ordinary lawful basis; criminal-offence data and POPIA special personal information have additional restrictions.

We do not use readable communications to create advertising profiles or infer sensitive characteristics. Do not submit sensitive plaintext in an enquiry unless necessary and through an appropriate channel.

Permissions for contacts, notifications, camera, microphone, files or location must be explained when a supported feature requests them. You can manage device permissions through your operating system; refusing permission may disable the associated function. We do not claim to collect these categories simply because a device can provide them.

7. AI agents, models and external tools

An InTouch agent is a cryptographic participant with its own identity and access to the Spaces it joins. It can read the communication content made available to it, as another participant can. Membership visibility and signed identity checks help you understand who has access; they do not prove an agent’s operator will use data appropriately.

InTouch’s current product description says it supplies the identity, membership and communication channel, not the AI model. The organisation or agent operator chooses the model and tools connected through the Model Context Protocol or other permitted integrations.

If an agent sends content to a remote model, knowledge base, CRM or another tool, that destination may receive readable content outside the relay’s encryption boundary. Before enabling it, the responsible organisation must disclose the recipients, purposes, hosting locations, retention and training practices, obtain required permissions, and put appropriate agreements and safeguards in place. Running a model locally has different disclosure implications from using a remote model.

We do not use protected communication content to train our own general-purpose AI models. This statement does not describe a third-party model provider’s practices. Agent operators must check those separately.

The product describes human sign-off for signatures and approvals. An organisation using agents for decisions affecting employment, credit, health or comparable interests must separately assess applicable rules, provide required explanations and review or objection routes, and configure appropriate human oversight. This policy does not authorise unrestricted automated decisions. Any qualifying automated decision-making we introduce for our own purposes requires an appropriate notice and rights process before use.

Removing an agent prevents future authorised participation according to the applicable access and key-update mechanisms. It does not delete information already exported to its operator or tools.

8. Website storage, cookies and marketing

The current marketing website code contains no analytics integration, advertising pixels, account login, submission forms or third-party font loading. Fonts are bundled locally. Website infrastructure may nevertheless process requests and security logs.

Language routing may use a language-preference cookie, and essential browser storage or cookies may be used where necessary for a deployed function. The deployed cookie inventory must identify actual names, purposes, providers and lifetimes. “No analytics” does not mean “no cookies” or “no server logs”.

Before adding non-essential tracking or storage, we will provide the notices and consent or opt-out mechanisms required by local law. Where consent is required, non-essential technologies will remain disabled until valid consent is given, and withdrawal will be as accessible as agreement.

We do not sell personal information, share it for cross-context behavioural advertising, or use it for targeted advertising as those terms apply under relevant US privacy laws. These commitments cover provider arrangements as well as direct disclosures. If practices change, required notices and controls must be implemented before the new processing starts.

You can stop direct marketing using the unsubscribe mechanism in a message or by contacting us. We may keep a minimal suppression record to respect that choice. Necessary security, service and legal communications are separate from optional marketing.

Where an applicable law requires recognition of Global Privacy Control or another recognised universal opt-out signal, we honour it for the processing covered by that signal. A browser’s legacy “Do Not Track” signal does not itself change our processing; our no-advertising commitments still apply.

9. Recipients and disclosures

We disclose only information appropriate to the purpose and the recipient’s role:

• Participants and authorised agent operators: receive content you make available to them through communications and integrations.
• Your organisation: receives information within its lawful administrative and participant permissions. Administrative status alone does not give our relay message decryption keys.
• Contracted providers: may process hosting, network security, business email, support, billing or other necessary service data. Providers must be bound by appropriate confidentiality, security and use restrictions. Their access depends on the function they perform.
• Professional advisers and authorities: may receive necessary records for advice, claims or valid legal obligations. We assess requests and disclose only data we possess or control that the law requires or permits. A legal request does not give us decryption keys we do not hold. Where allowed, we notify affected customers or individuals.
• A successor in a corporate transaction: may receive necessary information subject to applicable legal protections and notice requirements. A transaction does not silently remove our privacy commitments.

Provider and recipient schedule: [Insert actual provider names, functions, data categories, processing countries and subprocessor-list location]. This must describe the deployed service, including access by affiliated entities where applicable.

10. International processing

A recipient, host, support team or external model may be in a different country from you. Encrypted data may still constitute an international transfer of personal information. Hosting in one region does not guarantee that support access, backups or agent tools stay there.

Our processing locations and overseas recipients: [List actual countries, including hosting, disaster recovery, administrative access and applicable providers]. Customer-managed locations and agent destinations are documented by the deploying organisation.

For transfers subject to GDPR, UK GDPR or Swiss law, we use an available lawful transfer mechanism, such as an applicable adequacy determination or appropriate contractual safeguards, including EU Standard Contractual Clauses and the UK Addendum or IDTA where relevant. We assess the destination and supplementary safeguards as required. We do not claim certification under a transfer framework without a valid applicable certification.

For South African transfers, we meet POPIA section 72 requirements. For other jurisdictions, we apply the applicable comparable-protection, contractual, consent or other lawful transfer requirements. Ordinary acceptance of this policy is not blanket consent to all transfers. You may ask for information about applicable safeguards and a copy where required, with necessary redactions.

11. Retention and deletion

We retain information only as long as necessary for its purpose, customer instructions and applicable law. The approved retention schedule must specify actual periods or sufficiently precise criteria for each deployment.

Actual periods and deletion timeframes: [Insert approved schedule or link supplied before publication].

Account deletion does not necessarily delete an organisation’s lawful records, other participants’ copies, agent exports, external-tool records, or required compliance records. We explain any retention exception and apply access restrictions where appropriate. Unreadability through key destruction is not automatically treated as legal erasure without assessing the remaining information.

12. Security and incident notification

We use measures appropriate to the risks, including the intended end-to-end encryption architecture, access restrictions, authentication, transport protection, key verification, minimisation and operational security controls. Exact controls depend on the deployment. We do not promise that a service or device is immune to compromise, or imply independent certification without evidence.

When a personal-data incident occurs, we assess the affected information and provide required notices to customers, authorities and individuals within the applicable deadlines. GDPR can require supervisory-authority notice within 72 hours of awareness and individual notice without undue delay where the relevant conditions are met. POPIA uses its own notification requirements, including notice as soon as reasonably possible in qualifying cases. Processor-to-controller notifications and other local duties also apply. We do not assume ciphertext or zero knowledge automatically removes a notification obligation.

13. Your choices and rights

Depending on applicable law and our role, you may request access, correction, deletion, restriction, portability, information about recipients, withdrawal of consent, or objection to processing. Rights are subject to lawful exceptions; we explain any refusal and available review route. We do not discriminate or retaliate because you exercise a privacy right.

Send requests to privacy@intouch.io or [additional request method and postal address]. Include enough information to locate your account or interaction, but do not send private keys or recovery secrets. We use proportionate verification for requests that could disclose or alter information. Authorised representatives may act for you with the authority and verification required by law. Opt-out requests are handled without unnecessary identity checks.

Requests are normally free. Any permitted fee or refusal for an exceptional request must be explained and justified. We apply the legal deadline governing your request and explain a lawful extension. If we act for your organisation, we route the request to the responsible controller and assist it as required; you can also contact its privacy team directly.

Encryption affects what we can provide, not whether your rights matter. We can address records we hold and assist with supported client-side retrieval or deletion. We cannot decrypt protected content without a lawful, technically available participant-side process, recover a secret we do not possess, or guarantee removal of independent recipients’ copies.

You may complain directly to the relevant regulator without first exhausting our internal process. Regulator routes are identified below.

14. Regional provisions

These provisions apply when the relevant law covers the processing. They do not claim that every law applies to every user or deployment. Mandatory local protections prevail over inconsistent policy wording.

European Economic Area and United Kingdom

You have the rights described in section 13 under the applicable conditions, including objection to legitimate-interest processing and to direct marketing, and applicable safeguards concerning solely automated significant decisions. GDPR request responses are generally due within one month, with a permitted extension of up to two further months where justified and notified within the initial month. UK requests follow the applicable UK rules. You may complain to your national supervisory authority or the UK Information Commissioner. Controller identity, representatives, lawful bases and transfer safeguards are provided in sections 1, 5 and 10.

South Africa

Where POPIA applies, you may seek confirmation and access, request correction or deletion where appropriate, object to processing on the applicable grounds, and object to unsolicited electronic direct marketing. POPIA also protects information about identifiable existing juristic persons where applicable. We apply its responsible-party and operator requirements, security safeguards, special-information rules and cross-border conditions. Information about collection, sources, purposes, required provision and consequences appears above. Contact our Information Officer using section 1, or complain to the Information Regulator. Statutory forms and lawful access procedures may apply.

California

Where the CCPA as amended by the CPRA applies, you may know and access personal information, correct inaccuracies, request deletion, and exercise applicable opt-out and sensitive-information limitation rights without discrimination. Requests concerning collection, sources, purposes, recipients and disclosure are addressed through section 13. We confirm receipt of qualifying know, delete and correct requests within 10 business days and generally respond within 45 calendar days, with a lawful extension of up to 45 additional days and notice.

Our proposed practice is no sale or sharing for cross-context behavioural advertising, and no use of sensitive information beyond applicable permitted purposes. This does not waive any right if actual processing creates it. Recognised opt-out signals and authorised-agent requests are handled as required.

Categories and disclosures during the preceding 12 months: [Complete and date the verified retrospective inventory before publication]. The category map is: identifiers and account information; commercial records; internet or network activity; professional or employment-related information supplied in business interactions; and communication or attachment information supplied by participants. Sensitive personal information may include account credentials and protected content containing health or other sensitive information. Categories are collected only to the extent the actual interaction involves them. Sources, purposes and recipient categories are described in sections 4, 5 and 9. We do not use these categories to generate advertising inferences. Exact collected and disclosed categories must be stated in the verified inventory rather than inferred from product capabilities.

Retention criteria appear in section 11. Any feature-specific notice at collection must identify the categories, purposes, applicable retention period or criteria, and sale/sharing practices before collection. This policy is not a substitute for required collection notices. We review the California notice at least annually. You may complain to the California Privacy Protection Agency. Additional rules governing covered automated decisions apply on their applicable compliance dates.

Other United States jurisdictions

Where applicable state consumer privacy laws cover our processing, we support the relevant access, correction, deletion and portability rights, opt-outs for sale, targeted advertising and qualifying profiling, required consent for sensitive information, and recognised universal opt-out signals. Scope, exceptions and deadlines vary by state. If we deny a request, you may appeal through the privacy contact in section 1; we provide the required appeal decision and regulator complaint route. A state-specific supplement is supplied where additional disclosures are required. Our no-sale and no-targeted-advertising commitments apply regardless of whether a statutory threshold is met.

Mauritius

Where Mauritius’s Data Protection Act 2017 applies, we support its transparency, lawful-processing, security, transfer and applicable individual-rights requirements. You may complain to the Mauritius Data Protection Office. Any required registration and privacy-officer arrangements must be maintained by the responsible entity.

Switzerland

Where the Swiss Federal Act on Data Protection applies, the notice includes our identity, purposes, recipients and relevant foreign destinations and safeguards. You may seek access and correction and exercise applicable remedies, including safeguards for qualifying automated individual decisions. You may contact the Federal Data Protection and Information Commissioner.

Brazil

Where the LGPD applies, you may exercise applicable confirmation, access, correction, portability, deletion, anonymisation or blocking, consent and recipient-information rights, and request review of qualifying automated decisions. Contact our designated privacy lead in section 1. We apply applicable Brazilian legal bases and transfer mechanisms, and provide responses within the required deadlines. You may petition the ANPD.

Canada, Australia, New Zealand and Singapore

Where applicable, we support Canada’s PIPEDA and relevant provincial protections; Australia’s Privacy Act and Australian Privacy Principles; New Zealand’s Privacy Act 2020; and Singapore’s PDPA. This includes applicable access and correction rights, meaningful consent or another lawful authority, accountability, retention limits, overseas-processing protections, and complaint handling. Canadian provincial rules, including Quebec requirements, need a tailored assessment where relevant. Contact our privacy lead or the relevant regulator: Canada OPC, Australia OAIC, New Zealand Privacy Commissioner, or Singapore PDPC.

For any other jurisdiction, we assess applicable requirements before offering covered processing and provide a local supplement where needed. Listing jurisdictions is not a claim of certification or universal legal compliance.

15. Children and young people

Eligibility and minimum age: [Insert the approved product eligibility rule and any country-specific differences]. Until this is confirmed, this draft does not represent the service as available to children. Where authorised organisational use involves children’s information, the organisation must establish the required authority, provide age-appropriate notices and apply additional protections. Any direct child-facing service requires its own assessment of parental consent, age assurance, minimisation and local child-protection rules before launch.

If you believe we have collected information about a child without the necessary authority, contact the privacy team. We investigate and take the action required by law. Sensitive information should not be sent through an ordinary email report unnecessarily.

16. Changes to this policy

We publish the effective date and make the current policy accessible. For material changes, we provide notice appropriate to the change and obtain fresh consent when required before introducing the relevant processing. We do not retroactively turn an earlier consent into permission for an unrelated use.

Contact privacy@intouch.io for this policy in an accessible format, for information about the notice governing your deployment, or to exercise your rights.