PostalDataPI Partner Data Protection Addendum — DRAFT v1.1

Status: DRAFT — privacy counsel review pending. Companion document to the PostalDataPI Partner Agreement v1.3.2. Author: PE (PostalDataPI, non-attorney draft) Purpose: Data protection terms for partners located in the European Economic Area (EEA), the United Kingdom, or Switzerland, or who otherwise process personal data subject to GDPR, UK GDPR, or Swiss FADP in the course of participating in the PostalDataPI Partner Program. Effective: Automatically on acceptance of the Partner Agreement by partners to whom this Addendum applies. URL: postaldatapi.com/partners/dpa

Scope note: US partners and partners in jurisdictions without comprehensive cross-border privacy obligations accept the PostalDataPI Partner Agreement and Privacy Policy; the Privacy Policy addresses US state privacy rights (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA, TDPSA, OCPA, and other applicable state laws). This Addendum does not duplicate those rights; it focuses on cross-border and joint-controller complexities specific to EEA/UK/Swiss partners.

Partner Data Protection Addendum

Version 1.1 — Effective [DATE]

This Addendum supplements the PostalDataPI Partner Agreement (the "Agreement") between PostalDataPI LLC, an Idaho limited liability company with principal place of business in Eagle, Idaho, United States ("PostalDataPI," "we," or "us"), and you (the "Partner"). Where this Addendum and the Agreement conflict on matters of personal data processing, this Addendum controls.

This Addendum applies to you if any of the following is true:

• You are located, organized, or ordinarily resident in the European Economic Area (EEA), the United Kingdom, or Switzerland.
• You process personal data of EEA, UK, or Swiss data subjects in the course of your promotional activities for PostalDataPI.
• The EU General Data Protection Regulation (GDPR), UK GDPR, Swiss Federal Act on Data Protection (FADP), or materially analogous law applies to any aspect of your participation in the Partner Program.

If none of the above applies to you, this Addendum does not apply. Your data protection relationship with PostalDataPI is governed by the Agreement and the PostalDataPI Privacy Policy at postaldatapi.com/privacy, which addresses US state privacy rights and other applicable rights.

1. Definitions

Terms used in this Addendum have the meanings given in Article 4 of GDPR (or their analogues under UK GDPR and Swiss FADP), including:

• "Personal Data": any information relating to an identified or identifiable natural person.
• "Data Subject": the natural person to whom Personal Data relates.
• "Controller": the party that determines the purposes and means of processing.
• "Processor": a party that processes Personal Data on behalf of a controller.
• "Joint Controllers": two controllers that jointly determine purposes and means of processing.
• "Processing": any operation performed on Personal Data.
• "Sub-processor": a third party engaged by a processor to process Personal Data on behalf of the controller.
• "Standard Contractual Clauses" or "SCCs": the European Commission's Standard Contractual Clauses for the transfer of personal data to third countries, Commission Implementing Decision (EU) 2021/914.
• "UK Addendum": the "International Data Transfer Addendum to the EU Commission Standard Contractual Clauses," version A1.0, issued by the UK Information Commissioner's Office (ICO) under section 119A of the Data Protection Act 2018 and in force as of 21 March 2022. This Addendum relies on the UK Addendum (which bolts onto the EU SCCs) rather than the standalone UK International Data Transfer Agreement (IDTA).
• "Agreement": the PostalDataPI Partner Agreement v1.3.2 or any successor version.
• "ICO": the UK Information Commissioner's Office.
• "FDPIC": the Swiss Federal Data Protection and Information Commissioner.

2. Scope and Roles

2.1 Roles for each data flow

This Addendum addresses the data flows in the Partner Program. For each, the data-protection role of each party is as follows:

2.2 Current Program design is not a processor relationship

Under the current Partner Program design, neither party acts as a processor for the other. Partners do not process personal data on PostalDataPI's behalf, and PostalDataPI does not process personal data on the Partner's behalf.

If a future Partner Program feature introduces processor-like processing (for example, a PostalDataPI-hosted lead-capture form embedded on a Partner's site, or Partner-operated infrastructure that handles PostalDataPI customer data), the parties will execute Article 28 processor terms before enabling that feature.

If Partner incidentally receives customer data outside the attribution-confirmation flow (for example, a customer CCs Partner on a PostalDataPI support email), Partner acts as independent controller for that incidental disclosure and is responsible for applying appropriate data protection to it.

2.3 Joint-controller arrangement for attribution confirmation

When a customer identifies the Partner as their referral source (Agreement §3.2) and PostalDataPI confirms the attribution in writing with both parties, PostalDataPI and the Partner are Joint Controllers under GDPR Article 26 for the purpose of establishing the referral relationship.

Lawful basis: the processing is conducted on the basis of the legitimate interests of both Joint Controllers (GDPR Art. 6(1)(f)) in establishing the referral relationship that underlies the Partner Program. A Legitimate Interest Assessment (LIA) has been documented and is available to supervisory authorities on request. The LIA balances:

• Our legitimate interest: accurately attributing customers to partners so commissions are paid correctly and partners can verify their work.
• Partner's legitimate interest: receiving confirmation of attribution to support commission entitlement and record-keeping.
• Data subject impact: minimal — the disclosure is limited to signup date and a claim reference (not email, billing, or usage data); the customer voluntarily identified the Partner; the customer is informed of the disclosure at the moment of identification.

The Data Subject's voluntary identification of the Partner (via the "Who referred you?" field or subsequent email) is evidence that the processing is within the Data Subject's reasonable expectations.

Joint Controller arrangement summary (GDPR Art. 26): A summary of this arrangement — including the essence of the allocation of responsibilities between Joint Controllers and the Data Subject's ability to exercise rights against either party (Art. 26(3)) — is published in accessible form at postaldatapi.com/partners/joint-controller-summary. The summary is also linked from the signup page adjacent to the "Who referred you?" field, and from our Privacy Policy. See Appendix D for the text of the summary.

Data minimization: the Partner receives only the minimum data needed to confirm attribution — typically signup date and a claim reference, not the customer's email or further contact information. The customer is informed at the moment of identification that selecting a name will cause their identification to be shared with that Partner.

3. Categories of Personal Data and Purposes

3.1 Partner Personal Data processed by PostalDataPI

3.2 Attribution Confirmation Data (Joint-Controlled)

3.3 Special Category Data

PostalDataPI does not intentionally collect special category data (GDPR Art. 9) from partners. Partner tax IDs are not special category data under GDPR, though they are "Sensitive Personal Information" under CCPA/CPRA and some other US state laws (covered in the Privacy Policy for US partners); under GDPR, their use is limited by our contractual purpose limitations (tax reporting, identity verification, sanctions screening).

4. Data Subject Rights

4.1 Rights

Partners and, where applicable, individuals whose data partners share with us, have the following rights subject to applicable law:

• Right of access (Art. 15 GDPR / UK GDPR)
• Right to rectification (Art. 16 GDPR / UK GDPR)
• Right to erasure (Art. 17 GDPR / UK GDPR), subject to the Partner Agreement's retention and dispute-support requirements and applicable legal obligations (tax records, etc.)
• Right to restriction of processing (Art. 18 GDPR / UK GDPR)
• Right to data portability (Art. 20 GDPR / UK GDPR)
• Right to object (Art. 21 GDPR / UK GDPR), including the right to object to processing based on legitimate interest (Art. 21(1))
• Right not to be subject to automated decision-making (Art. 22 GDPR / UK GDPR) — we do not use automated decision-making in the Partner Program
• Right to withdraw consent (Art. 7(3) GDPR / UK GDPR) where processing is based on consent
• Right to lodge a complaint with a supervisory authority (Art. 77 GDPR / UK GDPR)

UK Data Subjects: you may lodge a complaint with the UK Information Commissioner's Office at ico.org.uk/make-a-complaint, in addition to any other applicable remedies under UK Data Protection Act 2018 s.165.

Swiss Data Subjects: you may lodge a complaint with the Swiss Federal Data Protection and Information Commissioner (FDPIC) at edoeb.admin.ch.

4.2 Exercising rights

Submit requests to privacy@postaldatapi.com with sufficient detail to identify you and the request.

• We acknowledge within 5 business days.
• We respond substantively within one calendar month of receipt, extendable by two additional months for complex or numerous requests (Art. 12(3)). Where we extend, we inform you of the extension and the reason within the first month.
• We do not charge a fee for rights requests except where a request is manifestly unfounded or excessive (Art. 12(5)).

4.3 Operational handling of specific rights

Restriction (Art. 18). On receiving a restriction request, we flag the relevant Personal Data in our systems and cease processing it for purposes other than storage, legal claims, or protection of another person, pending resolution of your restriction. Flagged data remains accessible for audit and legal-claim purposes only.

Objection (Art. 21). On receiving an objection to processing based on legitimate interest, we cease such processing unless we can demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or the processing is necessary for legal claims. We inform you of the outcome within the response window above.

Withdrawal of consent (Art. 7(3)). Where processing is based on your consent (rare in the Partner Program; generally limited to optional communications), you may withdraw at any time; withdrawal does not affect the lawfulness of processing before withdrawal.

4.4 Verification

We verify the identity of the requester before disclosing Personal Data, but only where we have reasonable doubts about the identity of the requester (GDPR Art. 12(6)). Verification may require confirmation from your registered email, Stripe Connect account, or analogous authenticated channel. We do not impose blanket re-authentication for every request.

5. International Data Transfers

Because PostalDataPI is located in the United States, processing of Personal Data of EEA, UK, or Swiss Data Subjects involves a transfer to a third country. The following transfer mechanisms apply.

5.1 EU Standard Contractual Clauses

For Personal Data of Data Subjects in the EEA transferred to PostalDataPI in the United States, the EU Standard Contractual Clauses 2021/914 are incorporated by reference into this Addendum:

• Module 1 (Controller to Controller) applies to transfers of Partner PII from the Partner (as exporter) to PostalDataPI (as importer). The Partner is the data exporter and PostalDataPI is the data importer.
• Module 4 (Processor to Controller) is reserved for any transfer where PostalDataPI, as controller, receives Personal Data back from a processor sub-processor that transferred it from the EEA (this applies to certain Stripe Connect flows where Stripe acts as processor).
• Module 1 with roles reversed applies to any scenario where PostalDataPI, as controller of attribution data involving an EEA data subject, transfers that data to a Partner in a non-adequate country for attribution confirmation. In that scenario, PostalDataPI is the exporter and the Partner is the importer.

The full text of the SCCs is available at https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj and the full clauses are incorporated as if set forth here.

Annex I.A (List of Parties):

• Data Exporter: the Partner as identified in the Partner Agreement, acting as Controller of their own Personal Data disclosed to PostalDataPI.
• Data Importer: PostalDataPI LLC, principal place of business in Eagle, Idaho, United States.
• Key contacts: Partner's registered email as recorded on acceptance; PostalDataPI's contact is privacy@postaldatapi.com.

Annex I.B (Description of Transfer):

• Categories of Data Subjects: Partners (natural persons or natural persons representing partner entities).
• Categories of Personal Data: identity, contact, financial, technical, and communication data as described in Section 3.1 of this Addendum.
• Frequency: continuous during the term of the Partner Agreement, and as needed for post-termination retention and tax compliance.
• Nature of Processing: as described in Section 3.1.
• Purposes: Partner Program operation, payout, tax compliance, fraud prevention, dispute resolution.
• Retention: per the retention schedule in the Partner Agreement §9.5.3 and Section 9 of this Addendum.

Annex I.C (Competent Supervisory Authority): the supervisory authority of the Member State in which the Partner has their habitual residence. If no EU Member State is the Partner's habitual residence, the Irish Data Protection Commission (DPC) is the competent authority for transfers conducted under Module 1 with the Partner as exporter in the EU. For UK transfers under Section 5.2, the competent supervisory authority is the UK Information Commissioner's Office (ICO). For Swiss transfers under Section 5.3, the competent authority is the Swiss Federal Data Protection and Information Commissioner (FDPIC). Partners outside the EEA, UK, and Switzerland whose data is transferred under this Addendum are outside the scope of EU/UK/Swiss supervisory authority jurisdiction for that transfer; rights in those cases arise under local law.

Annex II (Technical and Organizational Measures): as described in Appendix E of this Addendum.

Annex III (List of Sub-processors): not applicable under Module 1 (controller-to-controller does not formally involve sub-processors in the SCC sense); however, see Section 6 and Appendix F of this Addendum for full transparency.

Clause 17 (governing law) election for the underlying EU SCCs: the SCCs themselves are governed by the law of Ireland. This does not affect the governing law of the Partner Agreement (Idaho) or of the UK Addendum (English law, mandatory).

Clause 11 election: the Parties choose not to opt for independent dispute resolution. Dispute resolution under the SCCs follows the competent-supervisory-authority and competent-court mechanisms.

Transfer Impact Assessment: PostalDataPI has conducted a Transfer Impact Assessment (TIA) concerning United States laws that may affect the level of protection of Personal Data transferred under Module 1, particularly in light of the Schrems II judgment (C-311/18) and the EDPB Recommendations 01/2020 and 02/2020. The TIA addresses, at minimum:

• US FISA Section 702 (50 U.S.C. §1881a). PostalDataPI does not qualify as an "electronic communications service provider" under 50 U.S.C. §1881(b)(4), which covers providers of electronic communication services, remote computing services, or similar. PostalDataPI is a software-as-a-service provider of postal code data APIs, not an ECSP. Section 702 collection is therefore extremely unlikely to reach Partner PII or attribution data in our systems.
• US Executive Order 12333. Bulk collection under EO 12333 targets communications-in-transit, not data at rest in US-based SaaS systems. PostalDataPI's data is at rest in Neon PostgreSQL (encrypted) and cached in Vercel (encrypted in transit). Practical exposure to EO 12333 collection is low.
• US CLOUD Act. US law enforcement can issue subpoenas for data held by US companies, including data about EEA/UK/Swiss Data Subjects. PostalDataPI does not have an operational pattern of receiving such requests (we have not received any to date); if we do, we will respond in accordance with applicable law, notify the data subject where legally permitted, and challenge orders that conflict with the Data Subject's rights under GDPR/UK GDPR/FADP.
• Practical likelihood of access given data categories. Partner financial and KYC data is of low interest to US intelligence collection (no national security or communications-surveillance value). The data categories in the Partner Program are routine business data, not the high-value targets that drove Schrems II concerns.
• Supplementary measures: (a) TLS 1.2+ encryption in transit; (b) AES-256 encryption at rest in Neon; (c) data minimization (we collect only what we need); (d) pseudonymization where operationally feasible; (e) strict access controls; (f) contractual commitment to challenge CLOUD Act orders where they conflict with Partner rights; (g) commitment to notify affected data subjects where legally permitted.

For UK transfers: the TIA has also been conducted against the ICO's Transfer Risk Assessment (TRA) guidance (June 2022), which expressly departs from the EDPB's 6-step methodology. The ICO TRA reaches the same conclusion: practical risk of US government access to routine Partner PII and attribution data is low.

The full TIA (internal document with public summary) is available to Data Subjects and supervisory authorities on request to privacy@postaldatapi.com.

5.2 UK Addendum

For Personal Data of Data Subjects in the United Kingdom, the UK Addendum to the EU SCCs, version A1.0 effective 21 March 2022, is incorporated by reference into this Addendum.

Table 1 (Parties):

• Start Date: the effective date of this Addendum for the Partner (date of acceptance).
• Exporter: the Partner as identified in the Partner Agreement, with the Partner's registered email as the key contact address.
• Importer: PostalDataPI LLC, 2357 W Burns Street, Eagle, Idaho 83616, United States; key contact: privacy@postaldatapi.com.
• Signature: acceptance of this Addendum through the click-acceptance mechanism in Section 12, with the same integrity hash and timestamp as the Partner Agreement acceptance.

Table 2 (Selected SCCs, Modules and Selected Clauses):

• Approved EU SCCs referenced: Commission Implementing Decision (EU) 2021/914 of 4 June 2021, Module One.
• Docking clause (Clause 7): not opted in. The parties may in the future agree to dock in an additional party by amendment.
• Clause 11 option (independent dispute resolution): not opted.
• Clause 17 (governing law for underlying SCCs): Ireland.
• All modules and optional clauses not otherwise elected default to the Approved EU SCCs' defaults as modified by the UK Addendum.

Table 3 (Appendix Information): as described in Annex I of Section 5.1 above.

Table 4 (Ending the Addendum when the Approved Addendum Changes): either the Importer or the Exporter may end the UK Addendum if the Approved Addendum changes and the parties cannot agree on how to address the change. This is a symmetric termination right.

UK competent supervisory authority: the Information Commissioner's Office. UK Data Subjects may lodge complaints at ico.org.uk/make-a-complaint.

5.3 Swiss FADP

For Personal Data of Swiss Data Subjects, we incorporate the following adaptations of the SCCs in Section 5.1, consistent with the Swiss Federal Data Protection and Information Commissioner's guidance:

• References in the SCCs to "Regulation (EU) 2016/679" are also deemed to refer to the revised Swiss Federal Act on Data Protection (in force September 2023).
• The term "Member State" is interpreted to include Switzerland where contextually appropriate for supervisory-authority purposes.
• Data Subjects located in Switzerland may bring claims before the FDPIC in addition to or in lieu of the competent EU supervisory authority.
• The Transfer Impact Assessment in Section 5.1 applies equally to Swiss transfers.

5.4 Data Privacy Framework

PostalDataPI does not currently self-certify under the EU-US, UK-US, or Swiss-US Data Privacy Framework (DPF). If PostalDataPI self-certifies in the future, we will:

• expressly elect the UK Extension to the EU-US DPF for UK transfers (not just the EU-US DPF);
• update this Section to reflect DPF as an alternative transfer mechanism;
• maintain the SCCs and UK Addendum as a fallback until DPF self-certification is formally active;
• notify Partners of the change.

Self-certification does not reduce the protections of the SCCs and UK Addendum incorporated above.

6. Sub-processors

6.1 List of sub-processors

Our current sub-processors are listed at postaldatapi.com/subprocessors. The list is updated as sub-processors change and is current as of the date of your acceptance of this Addendum. For each sub-processor, the list describes: name, purpose, categories of Personal Data processed, location of processing, and the applicable transfer mechanism.

Appendix F of this Addendum contains the sub-processor list as of v1.1.

6.2 Changes to sub-processors

We notify Partners of any addition or change of sub-processor at least 30 days before the change takes effect, via email to the address subscribed at postaldatapi.com/subprocessors or via direct notice.

Partners may object to a new sub-processor within 30 days of notice if the sub-processor presents specific, material privacy risks not already present in our sub-processor list. If we cannot accommodate the objection, the Partner may terminate the Agreement under §7.1 without penalty, and existing commissions continue to pay under the ordinary-termination terms.

6.3 Voluntary flow-down commitments

Because this Addendum governs primarily a controller-to-controller relationship, Article 28 processor terms do not strictly apply. However, as a voluntary contractual commitment (not Article 28 mandate), for sub-processors that process Personal Data subject to GDPR, UK GDPR, or Swiss FADP, PostalDataPI maintains written agreements with the sub-processor addressing data protection, security measures, and cross-border transfer mechanisms. These commitments do not create third-party-beneficiary rights for Partners beyond what GDPR otherwise provides.

7. Technical and Organizational Measures

See Appendix E for the list of technical and organizational measures implemented to protect Personal Data. We commit to maintaining measures appropriate to the risks of the processing and to the maturity of the Company. We are transparent about current capabilities and planned upgrades.

8. Personal Data Breach Notification

8.1 Notification to PostalDataPI

If you become aware of a Personal Data Breach in connection with your participation in the Partner Program, notify PostalDataPI at privacy@postaldatapi.com without undue delay, and in any event within 72 hours of becoming aware. Include:

• Nature of the breach (categories and approximate number of Data Subjects and records)
• Likely consequences
• Measures taken or proposed to address the breach
• Contact details for follow-up

We acknowledge receipt of any breach notification from you within 24 hours.

8.2 Notification to you

If PostalDataPI experiences a Personal Data Breach affecting your Personal Data or Personal Data for which you are a Joint Controller (attribution data), we notify you without undue delay, and in any event in time for you to meet your own GDPR/UK GDPR/Swiss FADP obligations where applicable (generally within 72 hours of our becoming aware, consistent with Article 33).

Notification is made via email to your registered address and includes information consistent with Article 33(3).

8.3 Notification to supervisory authorities, Data Subjects, and under US state laws

Each party fulfills its own obligations under applicable law, including:

• GDPR / UK GDPR / Swiss FADP: Articles 33 (notification to supervisory authorities) and 34 (notification to Data Subjects) are the respective responsibilities of the controller involved.
• US state breach-notification laws: Idaho Code §28-51-104, California Civil Code §1798.82, and analogous laws in other US states impose independent statutory notification requirements that run independently of this contractual notice regime. Each party complies with those laws for their own breach events.

Joint Controllers coordinate on notifications concerning Joint-Controlled attribution data; PostalDataPI takes the lead on coordination and drafting of any notification to supervisory authorities unless the parties agree otherwise.

9. Retention

Personal Data is retained per the schedule in the Partner Agreement §9.5.3, reproduced here for reference:

10. Audit Rights

10.1 For Partners subject to this Addendum

You may, no more than once per 12-month period and at your own reasonable expense, request an audit of PostalDataPI's compliance with this Addendum for Personal Data pertaining to you or Joint-Controlled attribution flows involving you. Audits are limited to information reasonably necessary to verify compliance and are subject to:

• At least 30 days advance notice
• Reasonable confidentiality undertakings by your auditor
• Scheduling that does not disrupt normal operations
• The 2%-of-active-partners concurrent-audit throttle described in Partner Agreement §6.8

10.2 Alternative: third-party attestation and roadmap commitment

In lieu of a direct audit, you may accept a current SOC 2 Type II report, ISO 27001 certification, or equivalent third-party attestation we provide, if it covers the systems and controls relevant to your concern.

Attestation commitment. PostalDataPI commits to obtaining and maintaining a SOC 2 Type II attestation within 12 months of the earlier of (a) reaching $100,000 in annual recurring revenue, or (b) executing a commercial contract with an enterprise customer that requires SOC 2 Type II as a condition of doing business. The attestation will be made available on request and under reasonable confidentiality to Partners who subscribe to this Addendum. Until that milestone is reached, the Company relies on the security postures of its sub-processors (Stripe PCI DSS Level 1 and SOC 2 Type II; Vercel SOC 2 Type II; Neon SOC 2 Type II; Sentry SOC 2 Type II) plus the TOMs described in Appendix E, and is transparent with Partners about its current bootstrapped maturity.

11. Term, Termination, Amendments

11.1 Term

This Addendum is effective from your acceptance of the Partner Agreement and continues for as long as PostalDataPI processes Personal Data subject to it. Specific provisions survive termination as provided in the Partner Agreement §9.10.

11.2 Termination

This Addendum terminates automatically on termination of the Partner Agreement, except for provisions concerning retention (Section 9), data subject rights (Section 4), and international transfer mechanisms for data already transferred (Section 5), which survive as needed.

11.3 Amendments

We may amend this Addendum with at least 30 days advance notice to you, via email to your registered address, using the same amendment and off-ramp mechanism as Partner Agreement §9.12. If you do not accept an amendment, you may terminate the Partner Agreement and this Addendum under §7.1 without penalty.

Amendments required to reflect changes in applicable law (including updated SCCs, UK Addendum updates published by the ICO, or new guidance from supervisory authorities) take effect on the date required by law, with as much notice as reasonably possible and no less than any transition period specified by the ICO, the EU Commission, or the FDPIC.

11.4 Relationship to Partner Agreement

This Addendum supplements and is incorporated into the Partner Agreement. Where the two conflict on data protection matters, this Addendum controls. On all other matters, the Partner Agreement controls.

12. Acceptance

Partners subject to this Addendum accept it simultaneously with acceptance of the Partner Agreement. The acceptance is recorded with the same IP address, timestamp, and integrity hash as the Partner Agreement acceptance, per Partner Agreement §10(5).

If you are an EU, UK, or Swiss Partner and require a countersigned physical or electronic-signature copy for your records, email privacy@postaldatapi.com and we will execute one at no cost.

Questions? Email privacy@postaldatapi.com. We answer honestly and seriously about privacy matters.

Appendix A — EU Standard Contractual Clauses 2021/914

The European Commission's Standard Contractual Clauses for the transfer of personal data to third countries, Commission Implementing Decision (EU) 2021/914 of 4 June 2021, are incorporated by reference into this Addendum in their entirety, with Module One (Controller to Controller) as the primary module, Module Four (Processor to Controller) reserved for Stripe Connect processor flows, and Module One with roles reversed reserved for scenarios where PostalDataPI exports attribution data to non-adequate-country Partners. The Annex information is specified in Section 5.1 of this Addendum.

The full text of the SCCs is available at: https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj

Appendix B — UK Addendum

The UK Addendum to the EU Commission SCCs, version A1.0, issued by the UK ICO under s.119A Data Protection Act 2018 and in force 21 March 2022, is incorporated by reference into this Addendum with the table information specified in Section 5.2 of this Addendum.

The full text is available at: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/international-data-transfer-agreement-and-guidance/

Appendix C — Swiss FADP Adaptations

As specified in Section 5.3 of this Addendum, the SCCs in Appendix A are adapted for Swiss Data Subjects as follows:

1. References to GDPR are also deemed to refer to the Swiss FADP (revised, in force September 2023).
2. "Member State" is interpreted to include Switzerland where contextually appropriate for supervisory-authority purposes.
3. Swiss Data Subjects may bring claims before the FDPIC in addition to or in lieu of the competent EU supervisory authority.
4. Transfer Impact Assessment applies equally to Swiss transfers.

Appendix D — Article 26 Joint Controller Summary

Published in accessible form at postaldatapi.com/partners/joint-controller-summary and linked from the customer signup page and our Privacy Policy.

For PostalDataPI customers: how your referral-source identification is used

When you sign up for PostalDataPI and tell us who referred you (via the "Who referred you?" field at signup or by a later email), PostalDataPI and that referring Partner become joint controllers of your identification for the specific purpose of establishing that you were referred by them.

What this means

• What we share with the Partner. The date of your signup and a claim reference — enough for the Partner to confirm they referred you. We do not share your email, billing information, usage patterns, or account activity with the Partner through this mechanism.
• Why. Both PostalDataPI and the Partner have a legitimate interest in accurate attribution: we need to pay partners correctly, and the Partner needs to confirm the referral relationship. You can learn more about this legitimate-interest basis at postaldatapi.com/privacy.
• Your choice. Your identification of the Partner is voluntary. You can decline to identify anyone at signup, and no pressure is placed on you.
• Your rights. You have the full set of GDPR rights (access, rectification, erasure, restriction, portability, objection) and UK GDPR / Swiss FADP / applicable US state equivalents over this data. Under GDPR Article 26(3), you may exercise these rights against either PostalDataPI or the Partner, and we will coordinate our response. PostalDataPI is your primary contact.
• Your primary contact. privacy@postaldatapi.com. We acknowledge within 5 business days and respond substantively within one month (extendable by two months for complex requests).

Responsibility allocation between PostalDataPI and Partner

• PostalDataPI is responsible for: maintaining the secure system, coordinating Data Subject rights requests, notifying Data Subjects of breaches, overall compliance coordination, publishing this joint-controller summary in accessible form, and informing Data Subjects at the moment of identification.
• The Partner is responsible for: keeping any attribution records they receive confidential (per Partner Agreement §9.4), not further disclosing your identification without a lawful basis, and complying with Data Subject rights requests that reach them directly.

Complaint path

• EEA Data Subjects: supervisory authority of your habitual residence, or the Irish DPC as default for cross-border matters.
• UK Data Subjects: UK Information Commissioner's Office at ico.org.uk/make-a-complaint.
• Swiss Data Subjects: Swiss Federal Data Protection and Information Commissioner at edoeb.admin.ch.

Appendix E — Technical and Organizational Measures

Transparency note: PostalDataPI is a bootstrapped single-member Idaho LLC. This section states what we actually do today and what we commit to doing at specific growth milestones. We deliberately avoid over-claiming a security maturity we have not yet achieved.

E.1 Access Controls

• PostalDataPI is currently operated by a single operator (Thomas W. Ives) with administrative access to all systems. Contractors engaged from time to time have access only to the specific systems and data needed for their engagement, under signed confidentiality agreements.
• Multi-factor authentication is required for all accounts with administrative access to production systems, including Vercel, Neon, Stripe, GitHub, Sentry, Google Workspace, and the domain registrar.
• Administrative actions on Personal Data are logged by the underlying sub-processors (Vercel deployment logs, Neon audit logs, Stripe activity logs, GitHub audit log). We retain these logs per sub-processor retention policy.
• Commitment: as the team grows beyond the solo operator, we will implement a documented role-based access control matrix with RBAC separation and periodic access reviews (committed within 12 months of hiring the second person with administrative access).

E.2 Encryption and Secrets

• In transit: TLS 1.2 or higher for all data in transit (HTTPS, API endpoints, sub-processor connections).
• At rest: AES-256 or equivalent for data at rest in Neon PostgreSQL and Vercel-managed storage. Stripe Connect KYC/PII is protected per Stripe's security measures.
• Secrets management: application secrets (API keys, database credentials, OAuth tokens) are stored in Vercel Environment Variables. This is not a full secrets manager in the SOC 2 sense; rotation is manual. We do not commit secrets to source control.
• Commitment: migrate to a centralized secrets manager with automated rotation and access audit (committed before SOC 2 Type II engagement).

E.3 Network Security

• Production services hosted on Vercel (SOC 2 Type II certified).
• Database (Neon) accessible over TLS from the application only. On current Neon tiers, IP allowlisting may or may not be enforced depending on tier; we verify our current tier's capabilities and use the most restrictive option available.
• No direct public database access; connection strings are stored in Vercel Environment Variables and rotated on material personnel changes.

E.4 Logging and Monitoring

• Error monitoring: Sentry integration with PII filtering configured. Error alerts for production issues.
• Access logging: by sub-processors as described in E.1.
• Commitment: implement access-anomaly detection (unusual access patterns, bulk data export alerts) committed within 12 months of SOC 2 trigger or first enterprise contract, whichever is earlier.

E.5 Incident Response

• A written incident response runbook is maintained internally, covering detection, triage, containment, notification obligations (including the 72-hour breach-notification window in Section 8), and post-incident review.
• The solo operator is on-call for production incidents, supplemented by Sentry alert delivery to email and mobile.
• Commitment: on-retainer incident response counsel or firm at the first enterprise contract or SOC 2 engagement, whichever is earlier.

E.6 Personnel

• PostalDataPI has no employees as of this Addendum's effective date. The sole operator has signed no employment agreement, being the owner of the LLC.
• Contractors and any future employees sign confidentiality agreements before accessing Personal Data and receive baseline security guidance appropriate to their role.
• Background checks are not performed on the sole operator or on short-term contractors. Commitment: background checks for employees with administrative access, once employees exist.

E.7 Vendor / Sub-processor Management

• Sub-processors are reviewed for security posture before engagement. Our current sub-processors (Stripe, Vercel, Neon, Sentry, ImprovMX, Google Workspace) were selected in part for their published SOC 2 Type II or equivalent certifications.
• Sub-processor certifications are point-in-time statements. We periodically verify that our sub-processors' stated security postures remain current; as of v1.1's effective date, all named sub-processors publish current SOC 2 Type II reports or equivalent (Stripe PCI DSS Level 1 + SOC 2 Type II; Vercel SOC 2 Type II; Neon SOC 2 Type II; Sentry SOC 2 Type II).
• Commitment: formal annual vendor security review with documented evidence retained, committed within 12 months of SOC 2 trigger.

E.8 Data Minimization and Pseudonymization

• Personal Data collected is limited to what is necessary for stated purposes (Section 3.1).
• Partner dashboards aggregate data to minimize per-customer exposure (Partner Agreement §3.6).
• K-anonymity floor (cohort ≥ 5) applied to per-campaign reporting to prevent re-identification of small cohorts.
• Customer-identifying fields in Joint-Controlled attribution data are minimized to signup date and claim reference.
• Pseudonymization (Art. 32(1)(a)): we pseudonymize internal analytics where operationally feasible (customer identifiers in aggregate reporting, error logs with PII filtering in Sentry).

E.9 Physical Security

• PostalDataPI does not operate its own data centers.
• Cloud sub-processors (Vercel, Neon, Stripe, Sentry, Google) maintain physical security controls per their published security posture.

E.10 Business Continuity and Disaster Recovery

• Current state: Neon PostgreSQL provides point-in-time recovery (PITR) per their tier (7-day window on Launch tier, longer on higher tiers). Backups are managed by Neon per their backup policies. Vercel deployments are versioned and rollback-able.
• RPO (Recovery Point Objective): up to 24 hours (based on Neon backup cadence on current tier).
• RTO (Recovery Time Objective): under 4 hours for a restoration from sub-processor backups.
• Current testing: informal — restoration procedures have been verified conceptually but not via a dedicated annual DR test.
• Commitment: documented DR plan with annual tested-restoration exercise, committed within 12 months of the SOC 2 trigger (Section 10.2).

E.11 Vulnerability Management

• Dependency scanning via GitHub Dependabot; updates applied on material CVSS findings within 30 days.
• Secret scanning enabled in source control.
• Commitment: formal vulnerability management program with SLAs by CVSS score, committed within 12 months of SOC 2 trigger.

E.12 Secure Software Development Lifecycle (SDLC)

• Production changes flow through version control with documented commits.
• Self-review by the sole operator plus pre-deployment checks in CI (linting, tests).
• No pre-merge review partner currently exists (solo operator). Commitment: formal two-eyes code review for all production changes once a second engineer is engaged.
• Branch protection on main branches; no direct pushes to production without CI passing.

E.13 Endpoint Security

• Operator workstation has full-disk encryption (FileVault / BitLocker / LUKS), auto-lock enabled, and MFA on all critical accounts.
• No corporate mobile device management (MDM) today; sole operator's devices are personally managed with consumer-grade security.
• Commitment: MDM on any future employee-issued devices.

E.14 Cryptographic Key Management

• PostalDataPI does not hold or manage encryption keys for customer data at rest; Neon, Vercel, Stripe, and Sentry manage their own keys per their security posture.
• Application-level secrets rotated on operator change or suspected compromise.
• Commitment: formal key-management policy with rotation schedule, committed before SOC 2 Type II engagement.

E.15 Data Deletion and Retention Enforcement

• Retention schedule is specified in Section 9 and Partner Agreement §9.5.3.
• Deletion mechanism: database deletions remove Personal Data from active storage; Neon PITR may retain the data in backup for up to 7 days (or longer on higher tiers) before rolling off. Sentry event retention is configured per Sentry's retention setting. Stripe retains KYC for 7 years per their policy regardless of our deletion.
• Right-to-erasure mechanics: we can hard-delete from Neon active storage within the response window; backup rollover completes within the Neon PITR window. For Sentry, we can scrub events. For Stripe, we rely on Stripe's retention policies and provide the Data Subject with notice of this limitation.
• Commitment: automated retention-enforcement jobs (scheduled purges) with documented execution, committed within 12 months of SOC 2 trigger.

E.16 Security Training

• Sole operator maintains current security awareness through industry publications and direct engagement with sub-processor security updates.
• Commitment: formal annual security awareness training once employees exist.

Appendix F — Sub-processor List (as of v1.1)

The current sub-processor list is maintained at postaldatapi.com/subprocessors and is updated as sub-processors change.

As of v1.1's effective date, our sub-processors are:

Revision Log

• v1.0 — 2026-04-22 (early afternoon): Initial draft by PE, incorporating findings from the data privacy specialist review of Partner Agreement v1.3.1. Structured as a Partner Data Protection Addendum (PDPA) rather than a conventional Art. 28 DPA, reflecting the controller-to-controller and joint-controller nature of the relationships.
• v1.1 — 2026-04-22 (late afternoon): Incorporates findings from the four-agent committee review (EU privacy counsel, UK privacy counsel, US state patchwork counsel, security CISO). Scope narrowed to EEA/UK/Swiss only per Thom decision (US state privacy rights handled in Privacy Policy instead). TOMs (Appendix E) rewritten for honest minimalism plus roadmap with SOC 2 Type II trigger at $100K ARR or first enterprise contract. TIA expanded with FISA 702, EO 12333, CLOUD Act, non-ECSP assertion, and UK TRA methodology. Art. 6 basis for attribution recharacterized from "consent analogue" to legitimate interest with documented LIA. UK Addendum Tables 1-4 populated. ICO designated as UK competent supervisory authority. Breach notification window 48h→72h with 24h our acknowledgment. Article 26 summary (Appendix D) made URL-specific with Art. 26(3) explicit. Section 2.2 absolutism softened. Missing TOMs control domains added (vulnerability management, SDLC, endpoint, key management, deletion mechanism, retention enforcement, security training).