Access Control 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 access to the Company’s production systems, administrative consoles, source code, and customer data, and the authentication of the users of its products.

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.

Principles

• Least privilege: every account, role, and key holds the minimum access its purpose requires.
• Individual accountability: no shared accounts. Every action on a production console is attributable to a named person.
• Authorization is enforced by the database, not only by application code: row-level security and explicit grants are the last line of defence for every customer table.
• Access is time-bound to a role. It is revoked the same day a role ends.

Administrative access to production

• Production systems are: the hosting platform (Vercel), the database and auth platform (Supabase), the source-control platform (GitHub), the email provider (Resend), the AI provider (Anthropic), the bank-data provider (Plaid), the accounting-data provider (Intuit), and the Company’s email domain. Access is limited to the Security Owner and to any personnel whose role requires it, approved in writing by the Security Owner.
• Multi-factor authentication is mandatory on every production account. Phishing-resistant methods (passkeys or hardware security keys) are used wherever the provider supports them; time-based one-time codes otherwise. SMS is not used as a factor.
• Direct database access is not used for routine operations. Schema changes are applied through versioned migrations; data changes ride the application’s server-side code. Where a provider allows it, direct database connections are restricted to approved networks.
• Service credentials (database secret keys, encryption keys, vendor API keys, cron secrets) exist only in the hosting platform’s encrypted environment configuration and in git-ignored local files on managed workstations. They are never committed, shared in chat, or logged. Keys are rotated on personnel change, on suspected exposure, and otherwise at least annually.
• Access review: the Security Owner reviews every production account, collaborator, and API key at least quarterly and removes anything not tied to a current need. The review is recorded in the risk register.

Staff access inside the product

For the business product, firm staff are enrolled by an administrator and carry a role (owner, admin, or staff) plus an explicit per-client allowlist; a staff member sees only the clients they are assigned. Staff identity is verified on every security-relevant request by re-validating the session with the auth provider, never from a cached claim. Removing a staff member deletes their sessions.

User authentication

• Sign-in is passwordless. A six-digit one-time code (or equivalent link) is emailed to the address requesting access; the code is single-use and expires quickly. The Company stores no passwords.
• Membership is the authorization: a business-product address can sign in only if a firm has authorized it for a client; a personal-product address is bound to exactly its own household. Membership is checked live in the database on every request that touches customer data, so removal takes effect immediately.
• Sessions are refreshed through secure, HTTP-only cookies and re-validated server-side on every sensitive action.
• Bank connections (personal product) are established through Plaid Link. Bank credentials are entered directly into Plaid’s hosted interface and are never visible to, transmitted through, or stored by the Company. The Company receives only a Plaid access token, which is encrypted at the application layer on receipt.
• The personal product does not currently add a second authentication factor of its own before Plaid Link is shown: possession of the user’s email account is the factor. This is recorded in the risk register with its compensating controls (single-use short-lived codes, provider rate limiting, and the bank’s own authentication inside Plaid Link) and the addition of an optional second factor is a planned improvement.

Rate limiting and abuse controls

Sign-in code requests ride the auth provider’s rate limits. Every user-originated write to the database is metered by a database-enforced ledger (at most 120 write events per email per hour). Self-signup on the personal product is capped per hour. Automated demo sessions are disposable and purged daily.

Physical access

The Company owns no production facilities; physical access to the data centers hosting its providers is controlled and attested by those providers (AWS for Supabase, Vercel’s infrastructure providers). Company workstations are personally attended, full-disk encrypted, and locked when unattended, per the Information Security Policy.

Review

Reviewed at least annually and on any material change.