Olvoma

Olvoma · Security

Information Security

We build systems that touch financial and operational data, so security is a working practice, not a page of promises. Below is our Information Security Policy in full — the same document we hand to partners during security reviews.

Version 1.0 · Adopted October 16, 2026

1. Purpose and scope

This policy defines how Olvoma Technologies, Inc. ("Olvoma") identifies, mitigates, and monitors information security risks. It applies to all Olvoma personnel and contractors, to all systems Olvoma builds and operates for its clients, and to all data handled in the course of that work — including financial account data received through data providers (e.g. Plaid), payroll data, and client business data.

2. Roles and responsibilities

  • Security owner. The CEO owns this policy, approves exceptions, leads incident response, and reviews the policy at least annually. Contact: [email protected] (monitored group address).
  • All personnel and contractors must follow this policy, use the approved tools listed in it, complete a walkthrough of this policy before receiving production access, and report suspected security issues to the security owner immediately.

3. Data classification and handling

  • Restricted — consumer/business financial data (bank transactions, balances), payroll data, access tokens, API keys and secrets. Encrypted at rest and in transit; access on a need-to-know basis; never in source code, logs, chat tools, or email; retained only as long as the engagement requires.
  • Confidential — client business data, contracts, internal documents. Access limited to the engagement team; shared externally only with the client's consent.
  • Public — published websites and marketing material. No restrictions.

Consumer financial data is used solely to provide the contracted reporting functionality. Olvoma does not sell or monetize it, and does not store end-user banking credentials — authentication happens on the financial institution's own pages via OAuth, and Olvoma receives only revocable, read-only tokens.

4. Access control and authentication

  • Least privilege. Every account gets the minimum access its role requires. Production systems sit behind identity-aware access controls (e.g. Google Cloud IAP) with per-user accounts; shared accounts are prohibited.
  • Multi-factor authentication is required on every service that supports it (Google Workspace, cloud consoles, GitHub, password manager, data-provider dashboards).
  • Role-based access in products. Applications Olvoma builds enforce roles at the data layer, including column-level masking of sensitive fields and audit logging of access.
  • Offboarding. When a person leaves an engagement, their access is revoked within one business day and shared secrets they held are rotated.

5. Secrets and credential management

  • All credentials, API keys, and tokens live in the company password manager (1Password) or in server-side environment files readable only by the service account that needs them.
  • Secrets never appear in source code, commits, tickets, logs, chat, or documentation. Repositories are checked before release; a leaked secret is rotated immediately and the leak treated as an incident (section 8).
  • Long-lived credentials (OAuth client secrets, service-account keys) are rotated on compromise, on personnel change, and otherwise at least annually.
  • Access tokens for financial data providers are stored encrypted and are revocable at any time by the data owner at their institution.

6. Encryption and infrastructure security

  • In transit: TLS 1.2+ for all external connections; no plaintext protocols.
  • At rest: databases and disks on managed cloud infrastructure (Google Cloud) with provider-managed encryption; sensitive fields such as provider access tokens are additionally encrypted at the application level.
  • Change management: all code changes go through version control (GitHub) and pull-request review before reaching production; production deployments are performed by authorized personnel only and are traceable to a specific commit.
  • Hardening: production services run with least-privilege service accounts; unused services and ports stay closed; dependencies are updated when security advisories affect them.
  • Backups of application databases are taken regularly and access to them is restricted the same as production data.

7. Vendor and third-party management

  • Before adopting a vendor that will store or process Restricted data, the security owner reviews its security posture (certifications, data-handling terms, breach history) and the applicable data agreement.
  • Current material vendors: Google Cloud / Google Workspace (infrastructure, email), GitHub (source control), 1Password (secrets), Plaid (financial data connectivity), Stripe (corporate services), Hetzner and Cloudflare (hosting/DNS for non-client systems).
  • Vendor access is granted per engagement, under least privilege, and revoked when no longer needed.

8. Incident response

  1. Report. Anyone who suspects a security issue reports it to the security owner immediately ([email protected] or directly).
  2. Contain. The security owner assesses severity, revokes or rotates affected credentials and tokens, and isolates affected systems.
  3. Notify. Affected clients and data providers are notified without undue delay once impact is understood, with the facts known at the time; legal notification obligations are honored.
  4. Recover and review. Service is restored from clean state; within one week a written post-incident review records the cause, the fix, and the preventive change adopted.

An incident log is kept with date, summary, impact, and resolution for every event.

9. Logging, monitoring, and policy review

  • Production applications keep audit logs of sign-ins and access to sensitive data (including who viewed what, where the product requires it); infrastructure alerting (uptime checks, error alerts) notifies the team of anomalies.
  • Logs exclude secrets and full financial account numbers.
  • Review and adoption. The security owner reviews this policy at least annually and after any material incident or change in services, and records each revision.

Revision history: v1.0 — October 16, 2026 — initial adoption, approved by the CEO of Olvoma Technologies, Inc.

Questions

Security reviews, questionnaires, or anything in this document: [email protected]. A signed copy of this policy is available on request.