Logging and Monitoring 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 defines the audit trails the Company keeps for its production systems, how they are protected and reviewed, and how security-relevant events are detected.

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.

What is logged

• Platform request and function logs (hosting platform): every request to the application with timestamp, route, status, and duration; function errors with stack traces.
• Database, authentication, and API logs (database platform): connections, queries through the API gateway, authentication events (code requests, sign-ins, failures), and storage access.
• Application audit tables (in the production database, sealed from API roles): every AI question and answer with the asking identity; every client-authored answer and note with author and time; a write-event ledger for all user-originated writes; bank-connection status history (connected, error, disconnected) and every sync run; accounting-sync runs; staff notification deliveries.
• Source-control audit log: pushes, merges, reviews, collaborator changes, and secret-scanning alerts.
• Vendor dashboards: Plaid and Intuit record API usage and item lifecycle per connection; the email provider records every delivery.

What is never logged

Vendor access tokens, refresh tokens, encryption keys, API secrets, session cookies, one-time sign-in codes, and bank credentials (which never reach the Company at all). Code paths that handle these are written so the values cannot be printed, and error handlers report identifiers, not secrets.

Retention and protection

• Application audit tables are retained for the life of the tenant and are readable only by server-side code holding the secret key; no public API role can read or alter them.
• Platform logs are retained for the provider’s standard period for the Company’s plan tier and are accessible only to accounts protected by multi-factor authentication. Streaming platform logs to longer-term retention (a log drain) is a planned improvement recorded in the risk register.
• Source-control audit history is retained by the platform indefinitely.

Monitoring and alerting

• Deployment and build failures, cron-job failures, and function errors are surfaced by the hosting platform and reviewed on the day they occur.
• Dependency-vulnerability and secret-scanning alerts from the source-control platform notify the Security Owner on creation.
• Bank-connection and accounting-sync failures are recorded per connection and shown in the product so they are acted on at the next sync cycle; repeated failures are reviewed weekly.
• The Security Owner reviews authentication logs and function error logs at least weekly, and immediately when an incident is suspected.
• Real-time alerting on anomalous authentication or access patterns is not yet automated beyond the provider defaults; adding threshold alerts on the database platform is a planned improvement in the risk register.

Use in incident response

During an incident the Security Owner preserves the relevant logs (export from the platform, snapshot of the audit tables) before remediation changes them, and the timeline is reconstructed from those sources per the Incident Response Policy.

Review

Reviewed at least annually and on any material change.