This is version 2.9, which has been superseded for new agreements. It still governs a customer whose Order Form names this version, for the rest of that customer's current Term (Standard Terms, Section 15.1), and it is kept at this permanent address for that reason. Version 2.12 is the current version: the current Data Processing Agreement.

Data Processing Agreement — version 2.9
Published 2026-10-16. Previous versions remain available at /legal/dpa/versions/. Schedule 2 is published separately at /legal/dpa-schedule-2.

Aporta Systems, LLC - Data Processing Agreement

Version 2.9 - published 16 October 2026.

This Data Processing Agreement (this “DPA”) is posted at aportasystems.com/legal/dpa. It forms part of the agreement under which Aporta Systems, LLC (“Aporta”) provides the Service to a customer (“Customer”): an Order Form under Aporta’s Master Services Agreement — Standard Terms, a Pilot Evaluation Agreement, or Aporta’s online sign-up once it exists (in each case, with what it incorporates, the “Agreement”). References to an Order Form include a Pilot Evaluation Agreement. Customer accepts this DPA by entering into the Agreement, and it takes effect when the Agreement does. No separate signature is needed: the DPA is in writing, including in electronic form, as GDPR Article 28(9) requires. Aporta will provide a countersigned copy on request. Schedules 1 to 3 form part of this DPA.

1. Roles and Scope

1.1 Customer is the controller (and, under United States state privacy laws, the business) for Personal Data processed through the Service. Aporta is the processor (and service provider) and processes Personal Data only on Customer’s documented instructions.

1.2 The Agreement, this DPA and Customer’s configuration of the Service are Customer’s complete documented instructions. Aporta will tell Customer if, in its opinion, an instruction infringes applicable data protection law.

1.3 Where Customer is itself a processor for its own clients, Customer warrants that it has authority to appoint Aporta as a sub-processor and has given any notices and obtained any consents required.

1.4 “Personal Data,” “processing,” “controller,” “processor,” “data subject,” and “personal data breach” have the meanings given in applicable data protection law. “Applicable Data Protection Law” means the laws applicable to the processing, which may include the Tennessee Information Protection Act, other United States state privacy statutes including the CCPA as amended, and, where Customer or a data subject is in scope, the EU and UK General Data Protection Regulation.

2. Aporta’s Obligations

2.1 Purpose limitation. Aporta will process Personal Data only to provide, secure, support and maintain the Service and as otherwise instructed by Customer, and for no purpose of its own.

2.2 No sale or sharing. Aporta will not sell or share Personal Data; will not retain, use or disclose it outside the direct business relationship with Customer; and will not combine it with personal information from another source, except as Applicable Data Protection Law permits.

2.3 No model training. Aporta will not use Customer’s prompt text, token-to-value mappings or custom lexicon terms to train, fine-tune or evaluate any machine learning model, its own or a third party’s.

2.4 Permitted derived statistics. Aporta may derive and use counts of which detection categories fired and how often, to improve detection. Aporta will not derive, retain, disclose or export the underlying values, the prompt text or Customer’s lexicon terms, and the counts will not identify Customer. Aporta may also count, without recording the format itself, how many customers have submitted a format of the same kind, for the sole purpose of Section 5.4 of the Standard Terms. This is Aporta’s entire right to derived data. No broader right follows from any reference to “anonymized” or “aggregated” data elsewhere.

2.5 Personnel. Aporta will ensure that persons authorized to process Personal Data are bound by confidentiality obligations and receive appropriate training.

2.6 Security. Aporta will implement and maintain the measures in Schedule 3 and in Exhibit B to the Agreement.

2.7 Assistance. Taking into account the nature of the processing and the information available to it, Aporta will give Customer reasonable assistance with data subject requests, data protection impact assessments and consultations with supervisory authorities.

3. Sub-processors

3.1 Customer gives general written authorization for Aporta to engage the sub-processors listed at aportasystems.com/legal/subprocessors, as updated under Section 3.2 (the “Sub-processor List”). The Sub-processor List is the one list of sub-processors Aporta may engage, and it governs. Each version is dated, and each earlier version stays available at aportasystems.com/legal/subprocessors/versions/. Schedule 2 reproduces the Sub-processor List for reference only.

3.2 Aporta will give Customer at least thirty (30) days’ notice before a Sub-processor Change takes effect. A “Sub-processor Change” means engaging a new sub-processor, replacing one, or materially extending what an existing sub-processor does for the Service. Aporta will send the notice by email to the “Administrative contact and notice email” named in the Order Form and publish the change on the Sub-processor List, in each case naming the sub-processor, its location and the processing concerned. Customer may object on reasonable data protection grounds within that period. If the parties cannot resolve the objection, Customer may terminate the affected Order Form without penalty and receive a pro-rata refund of prepaid fees.

3.3 Aporta will have a written agreement with each sub-processor imposing data protection obligations, and remains liable to Customer for each sub-processor’s performance.

3.4 Section 3.2 is Aporta’s commitment to Customer. It applies to sub-processors Aporta engages directly. Some of Aporta’s sub-processors give Aporta less than thirty days’ notice of changes to their own sub-processors; the Sub-processor List states each one’s period. When Aporta learns of such a change, it will update the Sub-processor List as soon as practicable and tell Customer where the change is material to the Service.

4. Personal Data Breach

4.1 Aporta will notify Customer without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a personal data breach affecting Customer’s Personal Data.

4.2 The notice will describe the nature of the breach; the categories and approximate volume of data and data subjects affected, as far as known; the likely consequences; the measures taken or proposed; and a contact point. Where information is not yet available, Aporta will provide it in phases as it becomes available.

4.3 Aporta will not make a public statement identifying Customer without Customer’s prior written consent, except where required by law.

4.4 Customer decides whether the breach requires notice to data subjects, regulators, insurers or, where applicable, courts or bar authorities, and gives that notice.

5. Deletion and Return

5.1 On termination and on request, Aporta will delete or return Personal Data, subject to Sections 5.2 and 5.3.

5.2 Audit records. “Crypto-shredding” means permanently destroying the encryption key that protects a set of records. The encrypted records remain, but they cannot be read without that key. Where deletion of audit records is requested, Aporta crypto-shreds them instead of deleting them. Audit records are hash-chained, so deleting them would break the chain and destroy the evidence the retention period exists to keep. They are stored under a seven-year retention configuration, which does not prevent deletion by an account credential, so it makes tampering detectable, not impossible. Aporta will confirm the crypto-shredding in writing.

5.3 What survives. On termination Aporta will give Customer a written statement of the data that still exists after Aporta has performed its deletion obligations. As of the date of this DPA that includes:

  • Customer’s own exports and the recovery code that opens them, which are in Customer’s custody;
  • the tokenized conversation history in each Authorized User’s account with an AI vendor, which is governed by that vendor’s terms and which Aporta cannot delete;
  • the crypto-shredded audit records described in Section 5.2, and any tokenized file copies stored with them, which still exist but cannot be read without the destroyed key;
  • where Customer connected its own storage for export delivery, the exports already delivered there, and the permission Customer granted Aporta at that provider. Aporta destroys the key that protects its copy of the credential, which ends Aporta’s ability to use it but does not revoke the permission at the provider. Customer removes it in its own account with that provider; and
  • copies a sub-processor keeps for a limited period in its backups or logs under its own terms.

A statement that all of Customer’s data has been deleted would be inaccurate as to each of these, and Aporta will not make one.

6. International Transfers

6.1 Storage. Aporta stores Personal Data in the United States. This includes the token vault, the per-tenant databases and the audit record. For the audit record and other object storage, a jurisdictional restriction on the storage itself enforces this; it is not a location preference. An export delivered into Customer’s own storage is held under Customer’s agreement with that provider, in the location that agreement and Customer’s account settings set.

6.2 Processing. Aporta configures server-side detection to run in a United States region. That is a configuration Aporta has applied and has observed in effect; it is not a guarantee given by the detection vendor. The vendor schedules work across a published pool of providers, and the configuration does not select the provider. Where a Super User turns on answers through Google’s Gemini model (Schedule 2), those requests go to Google’s United States endpoint. Request handling (authentication, routing and sending text for detection) runs on a global edge network, at the point of presence nearest the Authorized User. When an Authorized User works from outside the United States, that user’s request content, including prompt text, is processed in transit outside the United States. It is not stored there and is not kept after the request ends.

6.3 Aporta does not offer regional confinement of edge processing. Section 6.2 says where processing happens. Where edge processing happens depends on where Authorized Users access the Service, which Customer controls and Aporta does not. If Customer requires confinement, Aporta will quote it as a separate change.

6.4 Transfers. Aporta provides the Standard Contractual Clauses on request. Where a transfer from the European Economic Area, the United Kingdom or Switzerland is in scope, the parties will execute the applicable Standard Contractual Clauses, which on execution form part of this DPA, with Customer as data exporter and Aporta as data importer, under Module Two (controller to processor) or Module Three (processor to processor) as applicable. For a transfer from the United Kingdom or Switzerland, Aporta will prepare the UK Addendum or the Swiss amendments to the Clauses when Customer signs, and the parties will execute them with the Clauses.

6.5 Section 6.2 describes where processing physically happens. The Standard Contractual Clauses are offered under Section 6.4 where Customer is subject to the data protection law of the EEA, the United Kingdom or Switzerland. Aporta asks at onboarding whether Customer has an establishment in those places, and sends the transfer question to counsel for the first customer that does.

7. Audits

7.1 Aporta will make available the information reasonably necessary to demonstrate compliance with this DPA, including its current security documentation and, once obtained, third-party audit reports.

7.2 Customer may audit no more than once in any twelve-month period, on thirty (30) days’ notice, during business hours, under confidentiality, at Customer’s expense, and without compromising the confidentiality of other customers. A regulator with jurisdiction may audit as required by law.

7.3 Aporta holds no third-party security certification. SOC 2 and ISO 27001 are phased and not yet certified; the roadmap is in Exhibit B to the Agreement. Aporta will not represent otherwise.

8. Liability and Precedence

8.1 Each party’s liability under this DPA is subject to the limitations of liability in the Agreement.

8.2 If this DPA and the rest of the Agreement conflict on the processing of Personal Data, this DPA controls. If executed Standard Contractual Clauses conflict with this DPA, the Clauses control.

Countersigned copy. This DPA binds on acceptance of the Agreement. The lines below are completed only for a countersigned copy provided on request.

APORTA SYSTEMS, LLC

By: ________________________________________

Name: ____________________________________

Title: ____________________________________

Date: ______________________________________

CUSTOMER

By: ________________________________________

Name: ____________________________________

Title: ____________________________________

Date: ______________________________________

SCHEDULE 1 — DETAILS OF PROCESSING

Item Detail
Subject matter Detecting and tokenizing sensitive data in text that Customer’s personnel send to the five supported third-party generative-AI tools, and keeping an evidentiary record of what was sent. Two optional activities, each off until Customer turns it on: answering a request through Google’s Gemini model on Aporta’s account while a supported tool is blocked because Aporta’s protection for it has broken; and delivering Customer’s sealed export into Customer’s own Google Drive or Microsoft 365 storage.
Duration The term of the Agreement, plus the audit retention period stated in the Order Form (default seven years), subject to Section 5.
Nature and purpose Reading text from the composer of a supported AI tool in the browser and, where Customer turns attachment scanning on, reading attached spreadsheets, Word documents and presentations in the browser; pattern and natural-language detection; replacing detected values with tokens; encrypted storage of token-to-value mappings; encrypted, tamper-evident logging of the tokenized submission and its metadata; restoring tokens to values in surfaces Aporta controls.
Categories of data subjects Customer’s personnel; and any individual whose personal data appears in text Customer’s personnel send to an AI tool. For a law-firm Customer this includes clients, opposing parties, witnesses and others named in matter content.
Categories of Personal Data Identifiers (names, email addresses, telephone numbers, postal and location references); government identification numbers; payment card and financial account numbers; credentials and API keys; professional identifiers (bar numbers, matter and docket numbers); dates; and the free text of the prompt itself, which may contain any category of personal data the sender chose to include.
Special categories Not intentionally processed and not solicited by the Service. Because the Service processes free text written by a person in real time, Aporta cannot exclude special-category data (for example health or criminal-offense information in matter content). Customer’s AI-use policy is the primary control on this, not the Service.
Frequency Continuous while Authorized Users are active.
Data retained by Aporta Encrypted token-to-value mappings. Aporta holds the vault key, and can read the mappings, until a Super User takes custody of it; after that they are readable only with Customer’s key. Encrypted audit records containing the tokenized text as sent, readable with the Aporta-held audit key. Tokenized copies of attached files, where Customer turns keeping them on, sealed under the audit key. Operational metadata, including device identity, coverage tier, extension health and detection counts. Where Customer connects an export destination: a credential for each connected provider, sealed under an Aporta-held key (Schedule 3), and, during each delivery, the sealed export in Aporta’s storage in the United States until delivery finishes, for no more than seven days.
Data not retained AI tools’ responses are not recorded. Plaintext values are not stored outside the encrypted vault.

Text in progress. Server-side detection runs when the Authorized User pauses typing, not only at submission. Partial text therefore reaches Aporta’s detection service, including text the Authorized User later deletes and never sends to an AI tool. It is processed in memory and not kept. Customer must tell its personnel this. The product says so too.

Customer’s custom lexicon. Terms Customer adds to its custom detection lexicon are sent to the browser extension on Customer’s devices, so they can be detected without a network round-trip and while offline. Customer’s chosen sensitive terms are therefore present on each device. Customer should decide what to add with that in mind.

SCHEDULE 2 — AUTHORIZED SUB-PROCESSORS

Schedule 2 is issued as a separate document, “Data Processing Agreement — Schedule 2: Authorized Sub-processors”. Version 2.9 reproduces version 1.21 of the Sub-processor List, dated 13 October 2026, for reference only. Section 3.1 governs its status.

SCHEDULE 3 — TECHNICAL AND ORGANIZATIONAL MEASURES

The measures in place on the date of this DPA.

Measure Implementation
Encryption at rest AES-256-GCM at the application layer before data reaches storage, with a unique initialization vector per encryption and each ciphertext bound to its tenant and token, so records cannot be moved between tenants and decrypted.
Encryption in transit TLS for all connections. TLS ends at Aporta’s edge, so this is not end-to-end encryption. Prompt text, and text extracted from attached files, is unencrypted on Aporta’s edge infrastructure while detection runs, including the values detection then replaces with tokens. While Aporta holds the vault key, detected values are unencrypted at the edge where the Service restores them into an AI tool’s reply; after a Super User takes custody, token mappings pass through the edge only sealed and are opened in the browser. The audit payload is unencrypted at the edge until it is sealed there, and is opened there again for an authorized query or export; it carries tokens in place of detected values. A file submitted for attachment review is the unscanned original: it is received unencrypted at the edge, stored sealed for up to 72 hours, and opened at the edge for the approver.
Key separation Separate per-tenant keys for the token vault and for audit records. Aporta provisions and holds the vault key until a Super User takes custody of it. After that, Customer holds it, wrapped to each enrolled device and to Customer’s recovery code, and custody does not move back to Aporta. Aporta holds the audit key. Reading the audit log gives no ability to unmask a token.
Key handling Unwrapped keys are non-extractable and cannot be written into logs or responses. Device keypairs are generated in the browser, and the private half cannot be read out, including by Aporta’s own extension code. Non-extractability prevents export of a key, not use of it. Key material is bound to a browser profile, not a person, so where Authorized Users share a profile, authorization separates them, not cryptography. Aporta recommends a separate profile per Authorized User. When an Aporta-held key is unwrapped through AWS KMS, the data key reaches Aporta’s edge in the response and is imported as non-extractable on arrival.
Master key Aporta-held data keys are wrapped by a key in AWS KMS, generated in the provider’s hardware and not exportable. Every use is logged on Aporta’s account. Aporta’s edge holds a long-lived access credential permitted to use the key; that credential can be revoked without losing the key.
Export credential Where Customer connects its own Google Drive or Microsoft 365 storage, Aporta holds one credential per connected provider, sealed in Customer’s tenant database under a per-tenant key that Aporta holds and AWS KMS wraps. Disconnecting deletes Aporta’s copy. The key is destroyed when Customer leaves. Destroying it ends Aporta’s ability to use the credential but does not revoke the permission at the provider. On disconnect Aporta asks Google to revoke it. Microsoft offers no way for an application to do so, so Customer removes it in its Microsoft account.
Tenant isolation Per-tenant databases; audit objects written under a tenant-scoped prefix; no Aporta account is a member of a customer organization. No browser profile is enrolled to more than one tenant, so no device can unwrap a second customer’s key material. The Service refuses this; it is not a configuration option.
Access control Six least-privilege roles. Support and reseller roles have no access to prompt text. Aporta staff identities are kept in a separate identity organization from customer users. An exception to send a value the Service has tokenized needs approval. For government identification numbers, payment card and financial account numbers, and credentials, two people must approve; this is fixed in application code and no configuration or identity-provider role can lower it. One exception: where Customer has a single Super User and has not required a second person, that Super User approves alone, and the record says so.
Integrity Audit events are hash-chained and sequence-numbered per device. Alteration, deletion or reordering breaks verification, independently of the storage retention setting.
Availability and continuity Serverless infrastructure with provider-managed redundancy. Customer can produce an encrypted export of its own token mappings on demand, with an offline reader that works without any Aporta system. Where Customer connects its own storage, exports are delivered there on a schedule.
Monitoring Device heartbeat reporting coverage and audit-chain position; an automated nightly check that each AI tool integration still works, with alerts to Aporta staff when one fails; the ability to fail an integration closed on all devices within minutes.
Personnel Confidentiality obligations; multi-factor authentication on every administrative account, with hardware security keys or passkeys where the provider supports them; credentials kept in a password manager; a named owner for credential rotation.
Deletion Crypto-shredding (Section 5.2) for audit records under the retention setting, with written confirmation.

Stated limitation. Aporta’s previous master key was retired from the Service on 5 October 2026, and every existing wrap was re-wrapped under the AWS KMS key. An archived copy of the previous key is kept. It opens no current wrap, but it would open an older copy of a wrap, such as one in a database backup.

Generated from docs/governance/internal/dpa.md. The source of truth is the governance register in the application repository, not this page.