Соглашение об обработке данных

This Data Processing Addendum ("DPA") forms part of the Penny Terms of Service (the "Agreement") between the Customer and Mintry Software, Inc. ("Mintry"). The team's owner accepts it on the Customer's behalf by accepting the Agreement when creating the team (or when accepting a new version). A countersigned copy is available on request at legal@ipenny.app.

1. Definitions

"Data Protection Law" means all laws on the processing of personal data that apply to a party's processing under the Agreement, including Regulation (EU) 2016/679 ("GDPR"), the GDPR as retained in UK law and the UK Data Protection Act 2018 ("UK GDPR"), the Swiss Federal Act on Data Protection ("FADP"), and the California Consumer Privacy Act as amended by the CPRA ("CCPA"), each as amended.

"Customer Personal Data" means personal data in Customer Content (as defined in the Agreement) that Mintry processes on the Customer's behalf.

"Subprocessor" means a processor engaged by Mintry that processes Customer Personal Data.

"Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.

"SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914.

Terms such as "controller", "processor", "data subject", "personal data" and "processing" have the meanings in the GDPR; "business", "service provider", "sell" and "share" have the meanings in the CCPA.

2. Roles and scope

2.1 For Customer Personal Data, the Customer is the controller (or a processor acting for its own controller) and Mintry is the processor (or subprocessor). Annex I describes the processing.

2.2 Mintry is an independent controller of: account, membership, sign-in, billing, abuse-prevention and security-log data about the Customer's members; messages held for an unclaimed Telegram chat for up to 7 days before any customer claims it; and correspondence with data subjects who contact Mintry directly. The Privacy Policy governs that processing, not this DPA.

2.3 Where the Customer is itself a processor, it confirms that its controller has authorised the instructions and the appointment of Mintry, and that it will relay Mintry's notices to that controller.

3. Customer's instructions and obligations

3.1 Mintry processes Customer Personal Data only on the Customer's documented instructions, which are: the Agreement and this DPA; the Customer's use and configuration of the Service by any member of its team (connecting and disconnecting sources, choosing backfill depth, binding chats and choosing how Penny answers in them, asking questions, choosing digest recipients, deleting a source); instructions reserved to the team's owner (deleting the team, accepting new versions of this DPA); and other written instructions agreed by the parties. Mintry will inform the Customer if, in its opinion, an instruction infringes Data Protection Law, and may suspend the instruction until it is confirmed or changed.

3.2 If a law requires Mintry to process Customer Personal Data otherwise, Mintry will inform the Customer before processing unless that law forbids it.

3.3 The Customer is responsible for the lawfulness of the processing it instructs, including: having a lawful basis for processing the personal data of every person in the sources it connects (including people outside its organisation and messages from before Penny was added); giving those people the information required by Articles 13 and 14 GDPR; obtaining any consent required; and consulting employee representatives where required. The Customer's warranties in section 3.4 of the Agreement apply.

3.4 The Customer will not instruct Mintry to process special categories of data or data of children except as the Agreement allows.

4. Confidentiality

Mintry ensures that everyone it authorises to process Customer Personal Data (employees and contractors) is bound by a duty of confidentiality and processes it only as needed to provide, secure and support the Service.

5. Staff access to content

5.1 Mintry personnel do not read Customer Content, except: (a) at the Customer's request, for support, limited to what the request needs; (b) to investigate or prevent a Security Incident, abuse or a breach of the Agreement; (c) to comply with law; or (d) where automated processing has failed and a member has asked Mintry to repair it.

5.2 For content from Gmail or Google Calendar, Mintry personnel read it only with the affirmative agreement of the member who connected the mailbox or calendar for specific messages or events, or for security, legal compliance, or in aggregated and anonymised form, as required by Google's Limited Use requirements.

5.3 Access to production systems is logged. Planned: a per-access justification record for any read of Customer Content by personnel.

6. Security

Mintry implements the technical and organisational measures in Annex II, appropriate to the risk under Article 32 GDPR. Mintry may update them provided the overall level of protection is not reduced.

7. Subprocessors

7.1 General authorisation. The Customer authorises Mintry to engage the Subprocessors listed at Subprocessors (Annex III).

7.2 Changes. Mintry will give at least 30 days' notice of a new or replacement Subprocessor by updating the list and emailing the members of every team. In an emergency (for example, a provider failure), notice may be shorter, and Mintry will explain why.

7.3 Objection. The Customer may object on reasonable data-protection grounds within the notice period. The parties will discuss in good faith; if no solution is found, the Customer may terminate the affected part of the Service and Mintry will refund unused paid credit for it.

7.4 Flow-down. Mintry imposes on each Subprocessor data-protection obligations that offer at least the same level of protection as this DPA, and remains liable for its Subprocessors' performance.

7.5 Not Subprocessors. Slack, Telegram, Google (as Gmail provider), GitHub, the Customer's database host, and AI assistants the Customer connects through MCP are services the Customer chooses and uses under its own agreements. Mintry reads from and writes to them on the Customer's instruction; they are not Mintry's Subprocessors.

8. International transfers

8.1 Customer Content is stored in the European Union (Google Cloud europe-west1, Belgium). Some Subprocessors process it in other countries, as listed in Annex III.

8.2 SCCs. To the extent a transfer of Customer Personal Data subject to the GDPR is to a country without an adequacy decision:

• from the Customer to Mintry (a US company), Module Two (controller to processor), or Module Three (processor to processor) where the Customer is a processor, of the SCCs are incorporated by reference (unless and until Mintry self-certifies under the EU-US Data Privacy Framework, in which case the DPF applies and the SCCs remain as a fallback);
• from Mintry to a Subprocessor, Mintry relies on SCCs (Module Three) entered into with that Subprocessor, or on the EU-US Data Privacy Framework where the Subprocessor is certified.

For the incorporated SCCs: Clause 7 (docking) applies; Clause 9 option 2 (general authorisation) with the notice period in section 7.2; the optional wording in Clause 11 does not apply; Clause 13: where the Customer is established in the EU, the supervisory authority of its establishment; otherwise, the supervisory authority of the Member State in which Mintry's Art. 27 representative is established; Clauses 17 and 18: the law and courts of Ireland. Annexes I–III of this DPA complete the SCCs' annexes.

8.3 UK and Switzerland. For UK GDPR transfers, the UK International Data Transfer Addendum (version B1.0) is incorporated, with Table 4 "neither party". For FADP transfers, the SCCs apply with the FDPIC as competent authority and "member state" read to include Switzerland.

8.4 Transfer impact. Mintry has assessed its transfers and applies supplementary measures: encryption in transit, zero-data-retention settings at AI providers, minimisation (only the excerpts needed for a request are sent to AI models), and a policy of challenging government access requests where there are grounds to do so.

9. Assistance

9.1 Data subject requests. Mintry will, taking into account the nature of the processing, assist the Customer by appropriate technical and organisational measures to respond to requests to exercise data subject rights. The Customer can itself disconnect a source, which deletes that source's history (section 11.2). Export of the team's memory and deletion of the team are available on request to support@ipenny.app (self-service in the product is planned). For requests about one person (access or erasure of everything a given identity wrote or is named in), Mintry will carry out the Customer's instruction within 30 days (a per-person search, export and erase tool is planned).

9.2 Requests received by Mintry. If Mintry receives a request from a data subject about Customer Personal Data, it will not answer it on the merits (except to confirm receipt and redirect), and will forward it to the Customer within 5 business days where Mintry can identify the Customer.

9.3 Platform-required requests and opt-outs. The Customer instructs Mintry to honour, without further instruction: (a) opt-outs made by individuals through Penny's in-chat commands (such as /forgetme), by no longer capturing that person's messages in the chat concerned and deleting what was captured from them there within 30 days; and (b) deletion requests that the terms of a connected platform (in particular Telegram's Bot Platform Developer Terms and Slack's API Terms) require Mintry, as the app developer, to honour. Mintry will inform the Customer of each such action.

9.4 Platform incident notices. Where a Security Incident affects data obtained from a platform whose terms require Mintry to notify the platform (for example Slack), the Customer agrees that Mintry may do so.

9.5 DPIAs and consultation. Mintry will provide reasonable information to help the Customer carry out data protection impact assessments and prior consultations with authorities, as far as they concern the Service.

10. Security Incidents

10.1 Mintry will notify the Customer without undue delay, and in any case within 48 hours, after becoming aware of a Security Incident affecting the Customer's data, by email to the team's members.

10.2 The notice will describe, as far as then known: the nature of the incident, the categories and approximate number of data subjects and records, likely consequences, measures taken or proposed, and a contact point. Mintry will provide further information as it becomes available.

10.3 Mintry will take reasonable steps to contain, investigate and remedy the incident. Notification is not an acknowledgement of fault.

10.4 A Security Incident does not include unsuccessful attempts that do not compromise security (for example pings, port scans, failed log-ins).

10.5 Disclosure of information to people in a chat through Penny's answers, as configured by the Customer (see section 4 of the Agreement), is processing on the Customer's instructions, not a Security Incident of Mintry. The Customer decided which chats to bind and whether to switch on "Answer only from this chat" (Agreement, sections 3.4(h) and 4).

11. Deletion and return

11.1 On termination of the Agreement or deletion of the team, Mintry deletes Customer Personal Data from active systems within 30 days (normally within 24 hours of the deletion taking effect) and from backups within a further 7 days, as set out in the Retention and Deletion Policy, unless a law requires retention. Before deletion, the Customer may export its data as the Agreement allows.

11.2 When the Customer disconnects a source, a platform reports that Penny was uninstalled or its access revoked, or the Penny bot is removed from a chat, Mintry deletes the data from that source and everything derived from it immediately: a deletion job starts at the event and completes normally within hours and at the latest within 24 hours; connector credentials are destroyed at once; backup copies expire within a further 7 days. This is the Customer's standing instruction; it cannot be undone.

11.3 Mintry will certify deletion in writing on request.

12. Audits

12.1 Mintry will make available the information necessary to demonstrate compliance with Article 28 GDPR, in the form of: this DPA and its annexes; answers to a reasonable security questionnaire once a year; and, when available, third-party reports or certifications (none yet; SOC 2 Type I or ISO 27001 is planned before public launch at scale).

12.2 If that information is not sufficient, or an authority requires it, the Customer may carry out an audit (itself or by an independent auditor bound by confidentiality) at most once a year, with 30 days' notice, during business hours, at its own cost, without access to other customers' data.

13. CCPA service-provider terms

For CCPA purposes Mintry is a service provider. Mintry will not: sell or share Customer Personal Data; retain, use or disclose it for any purpose other than the business purposes in the Agreement, or outside the direct business relationship with the Customer; or combine it with personal information from other sources, except as the CCPA permits. Mintry will comply with the CCPA's applicable obligations and notify the Customer if it can no longer do so. The Customer may take reasonable steps to stop unauthorised use.

14. AI processing

14.1 Mintry will never use Customer Personal Data to train, fine-tune or evaluate any AI model, and will configure its AI Subprocessors so that they do not use it for training and do not retain it beyond the request, where such options exist (see Annex III).

14.2 Settings that tune Penny's extraction and classification for the Customer are stored per team and are never used for another customer.

15. Liability and precedence

Each party's liability under this DPA is subject to the limitations in the Agreement (including the data-protection cap). Nothing in this DPA limits either party's liability to data subjects or authorities under Data Protection Law where it cannot be limited. If this DPA conflicts with the Agreement, this DPA prevails; if it conflicts with the SCCs, the SCCs prevail.

Annex I. Description of the processing

A. Parties

• Data exporter (controller): the Customer, as identified at sign-up. Contact: the team's owner. Activities: use of Penny as a team memory.
• Data importer (processor): Mintry Software, Inc., a Delaware corporation, 16192 Coastal Highway, Lewes, DE 19958, USA. Contact: privacy@ipenny.app; legal notices legal@ipenny.app. EU and UK representatives: being appointed (until named, contact privacy@ipenny.app). Activities: provision of Penny.

B. Categories of data subjects

1. Members of the Customer's team (as authors and askers);
2. The Customer's employees, contractors and advisers who write in connected sources;
3. Third parties in connected sources who are not Penny users: clients, partners, suppliers, candidates, and anyone else in a connected chat or channel, anyone who emails or is emailed from a connected mailbox, anyone named in those messages or files;
4. Authors of commits and content in connected GitHub repositories;
5. Individuals whose data is stored in a connected customer database (for example the Customer's own end users).

C. Categories of personal data

• Identity and contact data: names, usernames, platform user ids, email addresses, profile pictures and job titles as provided by the platform;
• Communications content: message text, threads, reactions, edits, email subject, body, headers and attachments, files posted in chats, links;
• Metadata: timestamps, chat and channel names, membership of chats, email recipients;
• Code and repository metadata: source files, commit messages, author names and emails;
• Database content: schemas, table and column names, and rows returned by read-only queries the Service runs to answer a question or describe the database;
• Derived data: extracted facts (decisions, promises, numbers, attributed to people), entities, summaries, digests, answers, search indexes and vector embeddings;
• Usage data: questions asked, by whom, and the answers given.

D. Sensitive data

Not intended. Special-category data, data about criminal convictions, government identifiers and credentials may occur incidentally in communications. Safeguards: automatic masking of many recognisable secrets before storage of facts and before display; held-back ("hidden") mail threads classified as personal or irrelevant; the restrictions in the Agreement; the measures in Annex II.

E. Frequency Continuous, for as long as a source is connected; one-off for history backfills and uploaded exports.

F. Nature of the processing Collection from connected sources (API reads, event webhooks, uploaded exports), storage, parsing, classification, extraction and summarisation by AI models, embedding and indexing, search and retrieval, answering questions, generating and delivering digests, deletion.

G. Purpose To provide Penny to the Customer: a searchable team memory with answers and digests.

H. Duration and retention For the term of the Agreement; per source, until the Customer disconnects it or deletes its history; then as the Retention and Deletion Policy states.

I. Subprocessors Annex III.

J. Competent supervisory authority As in section 8.2 (Clause 13 SCCs).

Annex II. Technical and organisational measures

This describes Penny's measures as of September 2026. Planned marks measures that are committed but not yet built.

1. Tenant isolation

• One shared PostgreSQL schema; every table carries tenant_id and has row-level security enabled and forced (FORCE ROW LEVEL SECURITY), with the policy tenant_id = current_setting('brain.tenant').
• The application connects as brain_app, which does not own the tables and cannot bypass RLS. A connection without a team set sees no rows.
• Cross-team system work (webhook routing, connector sweeps, billing reconciliation) uses a separate role (brain_system), confined to a short, named allow-list of modules; the webhook inbox holding messages before routing is readable only by that role and short-lived.
• The team id is an explicit input of every background workflow and activity.
• Automated guard tests check that every table has tenant_id and a policy, that the app role is not a member of the privileged roles, and that team B cannot see team A's data through the API, MCP, bots and digests.
• Each external account (Slack workspace, Telegram chat, mailbox, GitHub installation, database) can belong to only one team; refusals never reveal the other team.
• Files are stored under per-team prefixes in object storage; code checkouts are per source.

2. Encryption

• In transit: TLS for all public endpoints, for calls to platforms, AI providers, payment and email providers; TLS required (with certificate verification recommended) for connections to customer databases.
• At rest: Google Cloud default encryption (AES-256) for Cloud SQL, Cloud Storage, persistent disks and Secret Manager. Optional, planned: customer-managed keys (CMEK) for Cloud SQL and Cloud Storage.
• Temporal workflow payloads: Planned: a payload codec that encrypts workflow inputs and results with a key held by Mintry, or a guarantee that payloads carry only ids, never content.

3. Secrets and credentials

• Connector credentials (Slack tokens, Gmail refresh tokens, database passwords, GitHub App key) are stored in Google Secret Manager, one secret per connection, named per team, never in the database or in logs.
• When a platform reports an uninstall or a token revocation, or the Customer disconnects, the secret's versions are destroyed.
• Card data never reaches Mintry (Stripe Checkout and Customer Portal).
• Magic-link tokens are stored hashed, valid 15 minutes, single use.

4. Access control

• Members sign in with Google or a one-time email link; sessions are signed, HttpOnly, Secure, SameSite cookies that expire after 14 days; team membership is re-checked on every request, so removing a member takes effect at once.
• MCP tokens are issued per (account, team) after an explicit consent screen; access tokens live one hour.
• Webhooks are authenticated: Slack request signatures; Telegram's secret-token header; OAuth state cookies protect connect flows.
• Mintry personnel access to production is limited to named engineers, through separate credentials with the minimum roles needed, from a dedicated, audited configuration; Google Cloud admin activity is logged by Cloud Audit Logs. Planned: MFA enforced on all Mintry Google accounts with production access; quarterly access review; a break-glass procedure for reading Customer Content, with a logged justification.
• The database has a private IP only; Penny's workloads that reach customer databases or providers run on private nodes behind Cloud NAT with a static egress IP.

5. Least privilege towards sources

• Slack: read scopes for the channels the Customer enables; public channels are joined only when ticked; private ones only when a member invites the bot.
• Gmail: gmail.readonly only.
• GitHub: a GitHub App with read-only Contents and Metadata, on the repositories the Customer selects.
• Databases: a read-only database user that the Customer creates; SSRF protection prevents a supplied host from reaching Mintry's own network.
• Telegram: groups and channels the bot is added to; no access to personal chats or user accounts.

6. Data minimisation and content safeguards

• Automatic detection and masking of recognisable secrets (passwords, API keys, tokens) in extracted facts and displays; a second AI check of extracted statements for secrets.
• Gmail threads classified as personal or irrelevant are held separately and not searchable or used for answers.
• The Telegram export guide asks users to export without media.
• Only the excerpts needed for a request are sent to AI models.
• AI routing restricted to zero-data-retention endpoints that do not train on inputs: account-wide ZDR on OpenRouter, data_collection: "deny" and pinned providers on every request, enforced by a test (planned; see Subprocessors).
• Message deletions reported by Slack (message_deleted, file_deleted) delete the record and what was derived from it.

7. Availability and resilience

• Managed Cloud SQL with automated daily backups kept 7 days and point-in-time recovery; managed Kubernetes (GKE) with multiple replicas; durable webhook inbox so acknowledged events are not lost; durable workflows (Temporal).
• Planned: a documented restore test at least twice a year.

8. Secure development

• Code review, automated tests on every change, independent review for changes to authentication, secrets, visibility, migrations and concurrency; database migrations are immutable once shipped.
• Dependency updates and vulnerability scanning (automated scanning in CI is planned).

9. Logging and monitoring

• Application logs avoid message content and record ids and amounts only for billing failures. Planned: a check that no content or secrets reach logs. Infrastructure audit logs by Google Cloud.
• Alerts for unusual billing activity (recharge limits), abuse and failures.

10. Incident response

• Planned: a written incident response plan with roles, a 48-hour customer notification commitment (section 10), a 72-hour authority-notification path for Mintry-as-controller incidents, and a post-incident review.

11. Personnel and vendors

• Confidentiality undertakings for everyone with access; security onboarding.
• Subprocessors are chosen for their security posture and bound by data processing terms (Annex III).

12. Deletion

• Per the Retention and Deletion Policy: tenant deletion removes workflows, secrets, files, code checkouts and all database rows (by cascade), after writing a content-free billing archive kept for tax purposes (planned); source disconnect, uninstall or bot removal deletes that source's data by an immediate background job (within 24 hours); backups roll off within 7 days; object storage soft-deleted copies within 7 days.

Annex III. Subprocessors

The current list, with locations, purposes and transfer mechanisms, is maintained at Subprocessors and forms part of this Annex.