Vendor Management Policy

This policy describes how SendTax selects, evaluates, contracts with, monitors, and terminates relationships with third-party vendors and sub-processors that touch customer data or operate infrastructure on which SendTax depends.

It is a companion to our Information Security, Access Control, Encryption, Incident Response, and Data Retention and Deletion policies. The current list of sub-processors is maintained as a separate Sub-processors page within our Trust Center.

Items marked Roadmap are not yet in production.

---

1. Principles

1. Customer trust is non-transferable. When a vendor handles customer data on SendTax's behalf, the customer's trust still sits with SendTax. We are responsible for our vendors' behavior with respect to customer data.
2. Necessity before convenience. Every vendor relationship begins with a question: is this service necessary, or are we adding surface area for ergonomic reasons? Vendor count is treated as a cost, not as a free decision.
3. U.S. data residency by default. Customer data is kept with U.S.-based providers and U.S. data regions wherever commercially reasonable, to avoid cross-border transfer complexity. Exceptions are documented and justified.
4. Defense in depth across the supply chain. No single vendor's compromise should be sufficient to expose customer data; our encryption and access controls remain in place even when a vendor is involved.
5. Transparent to customers. The current list of sub-processors is published. Material changes are communicated in advance where feasible.

---

2. Definitions

---

3. Vendor tiering

Every vendor is classified into one of three tiers. The tier determines what evidence is required at onboarding, what monitoring is required ongoing, and what changes require customer notification.

Tier 1 — Customer-data sub-processors

Definition. The vendor processes, stores, or transmits identifiable customer personal data (including tax-return data, identity documents, contact information, authentication data, or behavioral telemetry tied to identified users).

Examples in current use: Fly.io (hosting + database), Cloudflare R2 (document storage), Clerk (identity), Google Cloud KMS (key management), Resend (email), Sentry (error monitoring with PII scrubbing), PostHog (product analytics), Modal (ML inference).

Onboarding requirements:

• Signed Data Processing Agreement (DPA).
• Documented data flows: what personal data category goes to the vendor, why, and how it returns or is destroyed.
• Review of the vendor's most recent independent security attestation (SOC 2 Type II, ISO 27001, equivalent) or, if none is available, a documented compensating-controls analysis.
• Confirmation of U.S. data residency, or documented exception (see § 6).
• Listing on the public Sub-processors page before production cutover.

Ongoing requirements:

• Annual review of the vendor's published security posture (refreshed SOC 2, breach disclosures, status-page incidents).
• Inclusion in our internal vendor inventory with the data categories they touch.
• Material changes (vendor swap, new data category, change of data residency) trigger customer notification.

Tier 2 — Operational vendors with incidental customer-data exposure

Definition. Vendors that, in the course of normal operation, do not handle identified customer personal data, but could see limited customer data in operator-driven workflows (e.g., debugging sessions, support escalations).

Examples in current use: GitHub (source control — should never contain customer data; checked by automated secret-scanning).

Onboarding requirements:

• DPA where the vendor provides one as a standard offering.
• Confirmation that customer personal data is not deliberately written to the vendor.
• Internal access controls limiting which operators can pull customer data into the vendor's surface.

Ongoing requirements:

• Reviewed at the annual vendor review.
• Not listed on the customer-facing Sub-processors page (because they are not sub-processors in the technical sense), but listed in our internal vendor inventory.

Tier 3 — Internal-only tools

Definition. Vendors used by SendTax operators that have no exposure to customer personal data in any normal or abnormal mode of operation.

Examples in current use: 1Password (operator credentials), design tools, productivity software.

Onboarding requirements: Standard vendor terms-of-service acceptance. No formal DPA required.

Ongoing requirements: No active monitoring beyond normal account hygiene; covered at the annual vendor review only by inventory verification.

---

4. Selection criteria

When evaluating a candidate vendor for any tier, SendTax considers:

For Tier 1 vendors, the evaluation is recorded internally and the DPA filed. A formal templated vendor-review checklist is on our roadmap. (Roadmap)

---

5. Contractual requirements

For Tier 1 sub-processors

Each Tier 1 sub-processor relationship is governed by a written DPA (or equivalent contract clause). The DPA must address, at minimum:

• The categories of personal data processed and the purposes of processing.
• The vendor's obligation to process personal data only on documented instructions from SendTax.
• Confidentiality commitments for the vendor's personnel.
• The vendor's technical and organizational security measures.
• The vendor's obligation to notify SendTax of any personal-data breach without undue delay (and within any contractually agreed timeline).
• The vendor's use of further sub-processors, including SendTax's ability to object.
• The vendor's obligation to assist SendTax with data-subject requests, data protection impact assessments, and breach notification.
• Deletion or return of personal data on termination of the relationship.
• Audit rights — typically satisfied by the vendor's independent attestation reports rather than on-site audits.

For cross-border data transfers

Where personal data of EU/UK data subjects flows to a vendor outside the EU/UK, SendTax relies on:

• An adequacy decision (where applicable), or
• Standard Contractual Clauses (SCCs) as published by the European Commission and incorporated into the vendor's DPA, or
• An equivalent transfer mechanism approved under UK GDPR.

SendTax's default is to keep customer data within the U.S. and to serve EU/UK customers (when in scope) from U.S. operations rather than to add EU/UK sub-processors. Exceptions are documented.

---

6. Data residency

SendTax operates from the United States and processes customer data in the United States by default. This is reflected in our Privacy Policy.

A vendor whose default data region is non-U.S. requires either:

• Configuration into a U.S. region during onboarding, or
• A documented exception identifying the data category, the destination region, and the legal basis for the transfer.

Exceptions are reviewed at least annually and at any time the underlying regulatory landscape changes (e.g., adequacy decisions, new transfer mechanisms).

---

7. Onboarding process

For a Tier 1 vendor, the onboarding process is:

1. Need check. Document the specific job the vendor will do and confirm no existing vendor already covers it.
2. Candidate evaluation. Apply § 4 criteria to a short list (typically two or three candidates).
3. Security and contractual review. Pull the vendor's SOC 2 or equivalent; review the DPA against § 5 requirements; negotiate changes where necessary.
4. Data-flow mapping. Document what personal-data categories will leave SendTax, in what form (plaintext, encrypted-by-us, etc.), and how they return.
5. Integration with security baseline. Configure access controls, audit logging, and secret storage per Information Security and Access Control.
6. Sub-processors page update. Add the vendor to the public Sub-processors page before any production data flows.
7. Customer notification (where applicable). Material new vendors (touching new data categories) trigger advance notification per § 10.
8. Cutover. Production traffic begins.

For Tier 2 and Tier 3 vendors, onboarding is documented in the internal vendor inventory but does not require the full checklist above.

---

8. Ongoing monitoring

What we monitor

• Published security incidents. Vendor status pages and breach disclosures are checked when a vendor publicly reports an incident affecting customers.
• DPA and policy changes. Notifications from vendors about changes to their DPAs, sub-processor lists, or data-handling policies are reviewed and acknowledged.
• Attestation renewals. Annual confirmation that the vendor's SOC 2 (or equivalent) is current.
• Service health. Vendor outages are tracked when they affect SendTax service delivery and are recorded in our incident timelines per the Incident Response Policy.

How often

• Tier 1: Reviewed at least annually. Material vendor events (breach, ownership change, region change) trigger out-of-cycle review.
• Tier 2 and Tier 3: Reviewed at the annual cycle only, unless an event warrants attention.

What we don't do

• We do not conduct on-site vendor audits; we rely on independent attestations and the DPA's audit-rights framework. This is standard practice for a company of our size and a deliberate scope decision.
• We do not run automated vendor-risk-scoring tools. A formal vendor risk register and structured annual scoring is on our roadmap. (Roadmap)

---

9. The Sub-processors page

SendTax maintains a public list of Tier 1 sub-processors as part of its Trust Center. The list includes, for each entry:

• The vendor's name and the URL of their security/trust page.
• The service they provide to SendTax.
• The category of personal data they may process.
• The processing region.
• A link to their published DPA, sub-processor list, or relevant security documentation.

The page is updated whenever a Tier 1 vendor is added or removed, and reviewed for accuracy at the annual vendor review.

---

10. Customer notification of changes

When a Tier 1 sub-processor is added, removed, or replaced — or when an existing sub-processor expands the data categories it handles — SendTax notifies customers in advance.

The standard mechanism is the same incident- and announcement-fan-out infrastructure documented in our Incident Response Policy § 8: each notification ties to a specific change, is sent at most once per recipient, and is auditable.

Customers who object to a new sub-processor may contact SendTax at [email protected]. We will work with the customer to identify a mutually acceptable path; if no acceptable path is available, the customer may terminate their use of the affected service.

---

11. Incidents involving vendors

When a security incident originates with or is exacerbated by a sub-processor, the incident is handled per the Incident Response Policy, with two specific obligations:

• We engage the vendor's published incident-response or support channel without delay.
• The vendor's communications are tracked on our own incident timeline so customer notifications reflect the full picture, not just SendTax's actions.

SendTax remains responsible for customer notification regardless of whether the underlying issue was within SendTax-operated infrastructure or a vendor's.

---

12. Termination and offboarding

When a vendor relationship ends — whether at SendTax's initiative or the vendor's — the offboarding process includes:

1. Migration. Customer data, where applicable, is migrated to a replacement vendor or back to SendTax-operated infrastructure.
2. Deletion request. SendTax issues a formal deletion request to the vendor under the terms of the DPA. The vendor's confirmation of deletion is captured for our records.
3. Credential rotation. All API keys, OAuth grants, and service-account credentials issued to the vendor are revoked at the source and the references in SendTax secret storage are removed.
4. Sub-processors page update. The vendor is removed from the public page.
5. Customer notification. Where the offboarding constitutes a material change, customers are notified per § 10.

---

13. Internal records

SendTax maintains an internal vendor inventory recording, for each vendor:

• Tier classification.
• Service description and data categories.
• Region(s).
• DPA / contract status and renewal date.
• Most recent SOC 2 (or equivalent) review date.
• Listing status on the public Sub-processors page (Tier 1 only).
• Owner inside SendTax for ongoing relationship management.

The inventory is reviewed at the annual vendor review and updated whenever a vendor changes tier, scope, region, or contractual status.

---

14. Policy review

This policy is reviewed at least annually, and additionally whenever:

• A new vendor tier or category is introduced.
• A material change in applicable cross-border-transfer law occurs.
• A vendor-driven incident reveals a gap in this policy.

Material changes are noted in the version line at the top of this document.

---

15. Contact