Third-Party Risk Management Policy

Purpose and scope

Alta Vista (“the Company”) — the operator of the Alta Vista client-reporting product at myaltavista.com and The Alta Vista Way personal budgeting service at thealtavistaway.com.

This policy governs the selection, onboarding, monitoring, and offboarding of third parties that process, store, or can access Company or customer data, or that form part of the production service.

The Company is a small, founder-operated business. The Security Owner is the founder, who is also the sole engineer with production access. Where a policy refers to a governing body, that body is the Company’s ownership, which reviews the security program on the cadence stated in the Information Security Policy. Policies are written so that they apply unchanged as staff are added: every clause that says “personnel” binds any future employee or contractor from their first day.

Vendor tiers

• Tier 1 (Restricted data): vendors that store or process customer financial data, authentication, or secrets. Currently: Vercel, Supabase, Plaid, Intuit, Anthropic.
• Tier 2 (Confidential data): vendors that handle contact details or operational data. Currently: Resend (email delivery), GitHub (source and CI), Google Workspace (Company email and, for firms that opt in, a report rendered into the firm’s own Google Sheet), Slack (staff notifications, for firms that opt in).
• Tier 3: tools with no customer data. Reviewed for basic security hygiene only.

Requirements before onboarding

• Tier 1 and 2 vendors must hold a current independent security attestation (SOC 2 Type II, ISO 27001, or equivalent) and publish their security practices, breach-notification commitments, and data-processing terms. Attestation status is recorded in the vendor register.
• Data sent to a vendor is limited to what its function needs (data minimization). AI providers are used under terms that exclude training on the Company’s data.
• Encryption in transit is required of every vendor; encryption at rest of every Tier 1 vendor.
• Integration design follows the vendor-facts gate in the Security Risk Management Policy: real API behaviour, token lifecycle, and data shapes are captured and documented before code is written, and the resulting risks are entered in the register.
• Vendor credentials are stored per the Access Control Policy, scoped to the minimum product and environment (for example, sandbox keys until production use is explicitly approved), and rotated on the vendor’s schedule or on exposure.

Technical and administrative enforcement

• Vendor access tokens obtained on behalf of users (Plaid, Intuit) are encrypted at the application layer, stored in tables no API role can read, and revoked at the vendor when the user disconnects or is deleted.
• Each integration writes only to draft or system-owned records; no vendor process can alter published customer reports.
• Outbound vendor calls are made only from server-side code with the credentials in the hosting platform’s encrypted environment; no vendor secret is shipped to a browser.
• New vendors, and any change in the data a vendor receives, require the Security Owner’s written approval, an update to the vendor register, and, where users are affected, an update to the published privacy policies.

Ongoing monitoring

• The vendor register is reviewed at least annually: attestation currency, incident history, changes to terms or ownership, and whether the vendor is still needed.
• Vendor security bulletins and status pages are followed for Tier 1 vendors; a vendor incident affecting Company data is handled under the Incident Response Policy.
• Dependency (open-source library) risk is handled under the Change Management Policy through pinned versions and automated vulnerability alerts.

Offboarding

When a vendor is retired, its credentials are revoked, its data is deleted or returned per its terms, the integration code and configuration are removed through change management, the vendor register and privacy policies are updated, and the removal is verified.

Review

Reviewed at least annually and on any material change.