Security 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 defines how the Company identifies, evaluates, treats, and monitors information security risks to its products, data, and operations. It applies to all systems, integrations, vendors, and personnel.

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.

Risk assessment method

• Assets: the assessment starts from the asset inventory and the information classification in the Information Security Policy. Consumer and client financial data, authentication, encryption keys, and vendor tokens are always in scope.
• Threats: for each asset the Security Owner considers unauthorized access (including cross-tenant access), credential or key compromise, data loss, vendor failure, supply-chain compromise of dependencies, and misuse by an authorized user.
• Rating: likelihood and impact are each rated 1 (low) to 3 (high). The product is the risk score; scores of 6 or 9 are High, 3 or 4 are Medium, 1 or 2 are Low.
• Treatment: each risk is mitigated, accepted with a written reason, transferred (for example to a vendor’s attested controls), or avoided. High risks must be mitigated or explicitly accepted by ownership before the related change ships.
• Record: every identified risk, its rating, treatment, owner, and next review date is recorded in the Company’s risk register.

When assessments happen

• Annually, as a full review of the register against the current architecture and vendor list.
• Before any new integration or data category ships. The Company’s standing practice is a vendor-facts gate: the vendor’s real API behaviour, data shapes, token lifecycle, and pricing are captured and documented before any schema or code is written for it.
• Before any change to the authorization layer: new tables, new access paths, new grants, or new user roles. Each such change must extend the automated tenant-isolation test suite and, after deployment, is followed by an audit of the live database grants.
• After any security incident or near miss, as part of the post-incident review.
• When a vendor materially changes its terms, security posture, or ownership.

Assurance activities

The Company gains assurance on its controls through internal, largely automated means rather than external audit at its current size:

• The tenant-isolation test suite runs on every pull request and on every push to the main branch and must pass before merge. It is extended with every new access path.
• A grants audit of each hosted database is performed after any migration that adds a table or function, comparing live privileges against the intended read-only posture.
• Dependency vulnerability alerts from the source-control platform are reviewed as they arrive; advisories rated high or critical are patched or mitigated within seven days.
• Independent penetration testing is not currently performed. The Company relies on its providers’ attested security programs for infrastructure and on the controls above for the application. Commissioning a third-party application penetration test is a planned improvement tracked in the risk register, scheduled before the personal product is opened to paid customers.

Remediation

Findings from any assessment, audit, alert, or incident are recorded with a severity and an owner. High findings are remediated before the affected change ships or, if already live, within seven days; Medium within thirty days; Low at the next scheduled review. Remediation is verified by re-running the relevant automated test or audit, and the result is recorded in the register.

Reporting

The Security Owner reports the state of the register, open findings, incidents, and planned improvements to Company ownership at each quarterly security review. Reviewed at least annually and on any material change.