Data Processing Addendum

Most DPA templates assume the vendor operates infrastructure that receives, stores, and processes the customer’s data — that premise drives the standard processor obligations (data return/deletion on termination, audit of the vendor’s own systems, sub-processor flow-down, vendor-detected breach notification).

Katmai’s Native Applications do not do that. The Application is a Snowflake Native Application: its code runs inside Customer’s own Snowflake account, on infrastructure Customer already owns and controls. Katmai operates no server, database, or cloud environment that receives a copy of Customer Data as part of normal operation. The Application declares no external network access integration in its Snowflake manifest.

This changes what several clauses below actually say: “return or delete Customer Data on termination” does not apply the ordinary way, because there is nothing to return. “Audit our processing environment” does not apply the ordinary way, because the environment is Customer’s own account, which Customer already audits directly. Sub-processor flow-down does not apply, because Katmai engages no sub-processors for Customer Data.

Katmai’s processing role, given this architecture, is treated in this DPA as a processor under GDPR Article 4(8) (or “service provider”/“contractor” under the CCPA/CPRA), because Katmai’s application code executes processing operations on Customer Data even though that execution occurs entirely within Customer’s own environment. Katmai does not, by default, receive, view, copy, export, or hold Customer Data outside that environment.

This DPA supplements and is incorporated into the Katmai Native Application Terms of Service (the “Agreement”). In the event of a conflict between this DPA and the Agreement regarding the processing of personal data, this DPA controls.

• “Personal Data” — any information relating to an identified or identifiable natural person, as defined under Applicable Data Protection Law.
• “Applicable Data Protection Law” — the EU/UK GDPR, the California Consumer Privacy Act as amended by the California Privacy Rights Act (“CCPA/CPRA”), and any other data protection law applicable to the processing of Personal Data under this DPA.
• “Customer Data” — has the meaning given in the Agreement: the data Customer loads into or generates within its own Snowflake account through the Application, including any Personal Data contained in it.
• “Process” / “Processing” — has the meaning given under Applicable Data Protection Law.
• “Sub-processor” — a third party engaged by Katmai to Process Customer Data on Katmai’s behalf. As of the effective date, Katmai engages no Sub-processors — see Section 5.

• Customer is the Controller (or "Business" under the CCPA/CPRA) of any Personal Data within Customer Data.
• Katmai acts as Processor (or “Service Provider”/“Contractor” under the CCPA/CPRA), subject to the architectural framing in Section 0: Katmai's Application code Processes Customer Data entirely within Customer's own Snowflake account, on infrastructure Customer controls. Katmai does not, by default, receive, view, copy, export, or hold Customer Data outside that environment.

Katmai currently engages no Sub-processors for Customer Data. This follows directly from the architecture: because the Application runs entirely inside Customer’s own Snowflake account and makes no outbound network calls, there is no third party in the data path for Katmai to engage.

• Snowflake is not a Katmai Sub-processor. Snowflake is the infrastructure Customer independently selected and contracts with directly; Katmai does not engage Snowflake on Customer’s behalf.
• If this ever changes (for example, if Katmai adds an optional feature that calls a genuinely external service, rather than an in-account Snowflake service), Katmai will give Customer at least 30 days' notice and a right to object on reasonable data-protection grounds before the new Sub-processor is used to Process Customer Data.

Annex III (Sub-processors): none as of the effective date above.

Katmai has no standing access to Customer Data. The only circumstance in which Katmai personnel may access Customer Data is Customer-initiated, Customer-scoped, Customer-revocable support access — for example, a temporary Snowflake role grant — provided explicitly by Customer to troubleshoot a specific support request. Katmai will not access Customer Data outside an active, Customer-granted support session, and any data Katmai personnel locally retain in connection with such a session (for example, a log excerpt) will be deleted within 30 days after the related support request is closed.

• Platform-level controls, inherited from Snowflake: AES-256 encryption at rest, TLS 1.2+ in transit, and private networking with no public ingress to the Application's containers — all managed by Snowflake within Customer's own account.
• Application-level controls Katmai is responsible for: role-based access control mapped to Customer’s own Snowflake roles with server-side enforcement of separation of duties (e.g., preparer/approver separation); tenant- and entity-level data isolation, enforced by database-level row-access policies on Snowflake Enterprise Edition and above, or by application-layer filtering on Standard Edition; CI-gated checks against SQL-injection and tenant-isolation regressions; and a secrets-hygiene audit of the codebase and CI pipeline.
• What is not yet in place, stated plainly: Katmai has not completed a SOC 2 examination and has not engaged a third-party penetration-testing firm as of the effective date above. The current architecture materially reduces the scope of what a SOC 2 or penetration test would need to cover, because there is no separate Katmai-operated environment holding Customer Data — see the public architecture page at katmaicapital.org/docs/security/close-consolidation. Katmai will notify Customer of any material change to this status upon request.

Because Customer Data never leaves the Snowflake account, region, and cloud that Customer itself selected, there is generally no cross-border transfer of Customer Data by Katmai to consider. If a transfer mechanism is required — for example, if a support-access session described in Section 6 involves Katmai personnel located outside Customer’s region, or a future feature calls an external service — the parties incorporate by reference, and will execute as needed, the EU Standard Contractual Clauses (Module 2 or 3, as applicable) or the UK International Data Transfer Addendum.

Because Katmai does not hold a separate copy of Customer Data, Customer already has direct, complete access to Personal Data within Customer Data in its own Snowflake account, and can fulfill data-subject requests (access, deletion, correction, portability) directly, without routing the request through Katmai. Katmai will provide reasonable technical assistance — for example, identifying the relevant tables or views — if Customer requests it in writing, within 15 business days.

Katmai will notify Customer without undue delay, and in any event within 72 hours, of becoming aware of a confirmed Personal Data breach affecting Customer Data within Katmai’s possession or access (for example, arising from a support-access session under Section 6). Notification is not an acknowledgment of fault or liability. Given the architecture described in Section 0, the realistic breach scenarios for Katmai are narrower than for a typical SaaS vendor, since Katmai holds no standing copy of Customer Data.

Customer may request reasonable information about Katmai’s security practices (including Katmai’s published architecture and security documentation) no more than once per 12-month period, absent a security incident. Because there is no separate Katmai-operated environment holding Customer Data, an on-site or systems audit of “where the data lives” is not applicable — the relevant environment is Customer’s own account, which Customer already controls and can audit directly. Following a confirmed security incident, Customer may request a review of Katmai’s software development and security practices (CI gates, secrets audits) at Customer’s expense, on reasonable notice, during business hours, subject to confidentiality.

Because Katmai never holds a copy of Customer Data outside Customer’s own Snowflake account, there is no data-return or data-deletion obligation in the traditional sense — the data was always, and remains, exclusively Customer’s, in Customer’s own environment. Upon termination, Customer may uninstall the Application from its Snowflake account; Customer Data that lived in Application-created tables within Customer’s account remains under Customer’s control and subject to Customer’s own retention and deletion decisions. Any support-access extracts described in Section 6 are deleted per that Section regardless of termination.

Each party’s liability arising out of or related to this DPA is subject to the limitations and exclusions of liability in Section 16 of the Agreement. This DPA does not create any liability in addition to, or broader than, the Agreement’s liability cap.

For Customer Data that constitutes “Personal Information” under the CCPA/CPRA:

• Katmai is a "Service Provider" (or "Contractor") and will Process such Personal Information only for the "Business Purpose" of providing the Application, per Customer's instructions as reflected in the Agreement and this DPA.
• Katmai will not sell or share such Personal Information, and will not retain, use, or disclose it for any purpose other than providing the Application, outside the direct business relationship with Customer.
• Katmai certifies that it understands and will comply with these restrictions.