Data Processing Agreement — version 2.12
Published 2026-10-26. Supersedes version 2.11. Previous versions remain available at /legal/dpa/versions/.

Aporta Systems, LLC - Data Processing Agreement

Version 2.12 - published 26 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/. An entry the Sub-processor List marks as website only is Aporta’s own processing as a controller, not processing of Customer Personal Data, and is outside this Section 3.

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 destroying the encryption key that protects a set of records. The encrypted records remain, but they cannot be read without that key. Aporta’s copies of that key are kept in Customer’s database at Aporta’s database provider, which keeps restore points of the database for a period; until the restore points from before the crypto-shredding expire, restoring one would bring Aporta’s copies of the key back. The same applies to a backup of that database and to overwritten copies the database may keep in its log or free space until that space is reused, and an Aporta server process that had already unwrapped the key may keep using it until that process is recycled. 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;
Customer’s token vault database, which Aporta does not delete on termination. Its stored values stay, encrypted, until the seven-year retention period removes them. Aporta destroys its copies of the vault key, subject to the restore-point limit in Section 5.2. If the database is deleted, Aporta’s database provider may be able to recover it for up to five days after deletion;
where Customer used Aporta Chat, the stored conversations, which are kept in Customer’s token vault database and whose key Aporta destroys, subject to the restore-point limit in Section 5.2, which still exist but cannot be read without it until the retention period removes them;
where Customer connected its own storage for export delivery, the exports already delivered there, and the permission Customer granted Aporta, or the access key Customer created for Aporta, at that provider. Aporta deletes its copy of the credential and destroys the key that protects it, subject to the restore-point limit in Section 5.2, which ends Aporta’s ability to use it but does not revoke the permission or delete the access key at the provider. Customer removes it in its own account with that provider;
Aporta’s own record of actions taken on the Service, which identifies Authorized Users and in some entries gives their email address, and records of decisions about Customer’s keys, which identify the user who made them;
each Authorized User’s sign-in account at Aporta’s sign-in provider, which can belong to other organizations, that provider’s record of past invitations, and Customer’s organization record there. Aporta removes Customer’s memberships and pending invitations;
the record of Customer’s acceptance of the Agreement, until its retention period ends, and billing records, as tax and accounting law requires; 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 Aporta Chat (Sub-processor List), its 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: Aporta Chat, where the Service offers it: detecting and tokenizing a conversation in the Aporta console, relaying it to Google’s Gemini model on Aporta’s account while a supported tool is blocked because Aporta’s protection for it has broken, and keeping it for the Authorized User who started it; and, where the Service offers that destination, delivering Customer’s sealed export into Microsoft OneDrive or a SharePoint document library in Customer’s own Microsoft 365, or an Amazon S3 bucket in Customer’s own Amazon Web Services account.
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, and, where the Service offers it, the text of attached PDFs it can read as text, which is sent to the AI tool as a new file built from that text in place of the PDF; 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; for Aporta Chat, relaying the tokenized conversation to Google and storing it, with Google’s answers, encrypted.
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. Where the extension stops a visit to an AI site, or to another site Customer has blocked, because Customer does not allow it, because Customer’s subscription is not active, or because the Service cannot protect the site at that moment, the audit record holds the site’s domain, the reason, the time, the Authorized User and the device, and not the rest of the page’s address or anything typed. Tokenized copies of attached files, sealed under the audit key, unless Customer turns keeping them off. Where Customer turns Aporta Chat on, each conversation, tokenized: the Authorized User’s messages, the text extracted from attached files and Google’s answers. It is sealed under an Aporta-held key, so Aporta’s service can read it whoever holds the vault key, and it is kept for the audit retention period. An Authorized User may remove a conversation from their own list; that deletes nothing. Files attached in Aporta Chat are kept under the sentence above, on the same switch, after a further sweep for the conversation’s values; a file that cannot be swept safely is not kept. 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	The supported AI tools’ responses are not recorded. Google’s answers in Aporta Chat are kept with the conversation, not in the audit record. 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

Aporta’s authorized sub-processors are those on the Sub-processor List (Section 3.1). This DPA does not reproduce the list. The version in effect on a given date is the one published for that date at aportasystems.com/legal/subprocessors/versions/.

Export delivery into Customer’s own storage. When Customer connects Microsoft OneDrive or a SharePoint document library in its own Microsoft 365, or an Amazon S3 bucket in its own Amazon Web Services account, where the Service offers that destination, Aporta delivers Customer’s sealed export there. Microsoft or Amazon Web Services holds that file for Customer under Customer’s agreement with it, and is not Aporta’s sub-processor for it. Nor is Microsoft Aporta’s sub-processor when Customer’s SharePoint administrator grants Aporta’s application access to one site from the Aporta console, where the Service offers that: the grant is made in Customer’s own Microsoft 365. Microsoft and Amazon Web Services are Aporta’s sub-processors only for the purposes the Sub-processor List gives them. The file’s contents are encrypted before it leaves Aporta and open with Customer’s recovery code; the provider is given no key that opens it. Where Customer has left its vault key with Aporta, Aporta can open the file, and the file says so. The provider can read the file name, size and arrival time, and the unencrypted headers a reader needs before a key is entered: Aporta’s identifier for Customer’s organization, Customer’s organization name, the period covered, sealing and delivery times, internal storage references including a device identifier, and each part’s size, fingerprint and record count.

AI tools Customer’s personnel use are not sub-processors. ChatGPT, Claude, Gemini, Microsoft Copilot and Perplexity are not engaged by Aporta. An Authorized User sends to them directly, under that vendor’s terms and the user’s own account tier. Aporta reduces what is sent and records what was. Whether Customer has a data processing agreement with those vendors, and whether an account tier permits training on content, is Customer’s to manage; the Service reports the account tier and training setting it observes. The one exception is Aporta Chat, listed under Google LLC on the Sub-processor List, which Aporta sends on its own account.

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. Aporta Chat conversations are opened at the edge to send them to Google and to show them to the Authorized User who owns them.
Key separation	Separate per-tenant keys for the token vault and for audit records. Aporta Chat conversations are sealed under a third per-tenant key, which Aporta holds in every case and which a custody move does not change. 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, with one exception: when a Super User takes custody, Aporta unwraps the vault key so that it can wrap it to that Super User’s enrolled device, and the key leaves Aporta’s edge only in that wrapped form. 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 Microsoft OneDrive, a SharePoint document library or an Amazon S3 bucket of its own, Aporta holds one credential per connected destination, sealed in Customer’s tenant database under a per-tenant key that Aporta holds and AWS KMS wraps. For OneDrive it is a delegated permission, granted by the person who connects it, that reaches only a folder of Aporta’s own in that person’s OneDrive; for SharePoint it is a delegated permission on the one site Customer’s administrator granted Aporta’s application, and the Service refuses to store a SharePoint connection whose sign-in carries a permission to other sites or files, apart from Aporta’s own OneDrive folder for a person who connected OneDrive before; for Amazon S3 it is an access key Customer creates, which Aporta’s setup asks Customer to limit to adding files under one prefix. 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 or delete the access key at the provider. Customer removes the OneDrive permission, the site permission or the Aporta application in its Microsoft account, or deletes the access key in its Amazon Web Services account.
SharePoint site grant	Where the Service offers it, a Super User who is also Customer’s SharePoint administrator can grant Aporta’s application `write` on one site from the Aporta console, by signing in with Microsoft through a separate Aporta setup application that asks for full control of SharePoint sites for that one action. Alternatively a Super User creates a single-use link, valid for 72 hours, either naming an existing site, which the administrator cannot then change, or leaving the administrator to enter the address of a site they create for Aporta’s copies, for an administrator who needs no Aporta account; it leads to the same sign-in and grant, and Aporta sends no email for it. Aporta uses the sign-in once, to make that grant, and keeps no credential from it: no refresh token is requested and the access token is not stored. The audit record names the address of the site granted and the Super User who made the grant or created the link. Microsoft records the administrator’s approval for the setup application; Customer can remove that approval, and the site permission, in its Microsoft account at any time. The grant is made in Customer’s own Microsoft 365, and Microsoft is not Aporta’s sub-processor for it.
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 browser extension refuses this; it is not a configuration option. Because each tenant’s database is separate, Aporta’s edge cannot see a second enrollment and does not itself refuse it.
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. The archived copies of the previous key were deleted on 22 October 2026, so it can no longer 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.