FinOpHQ · Financial Operations HQ

Information Security Policy

Michael Crews, d/b/a Finophq
Version 1.2 — Adopted July 27, 2026; revised July 28, 2026
Policy owner: Michael Crews, Owner/Developer (michael@finophq.com)

1. Purpose and Scope

This policy defines how Finophq (the “Service”) identifies, mitigates, and monitors information security risks. It applies to all systems that store or process user data — the production application, its managed database and authentication provider, the source-code repository, and the single development workstation — and to all user data the Service handles, including financial and operational data received from every platform a user connects (accounting platforms, bank connections, and field-service/CRM platforms), current and future. It is written for what the Service is: a single-operator business; the controls below are proportionate to that scale and are technical and automatic wherever possible, rather than procedural.

2. Roles and Responsibility

The policy owner is responsible for all information security functions: risk assessment, secure development, access management, vendor review, incident response, and the maintenance of this policy. There are no other employees or contractors with access to production systems or user data.

Workforce provisioning and de-provisioning. Because there is no workforce beyond the policy owner, there is currently no one to provision or de-provision. Should any employee or contractor ever be granted access, that access will be provisioned exclusively through the centralized identity providers named in §4 (never through shared credentials or copied keys), so that on termination or role change a single revocation at the provider removes all access immediately. Standing secrets they may have touched are rotated in the same pass.

3. Risk Identification, Mitigation, and Monitoring

Security risk is managed through a written security-gates register maintained in the project repository alongside the code:

1. Identification. Each identified risk is recorded as a numbered gate with a plain-language description of the threat and what closes it. New risks are added when a feature that could introduce them is designed, not after it ships.
2. Mitigation. Every gate is assigned to a tier tied to a business milestone (beta with real users; general availability / first paying user; conditional on a named trigger feature). A gate must be closed before its tier's milestone is reached. Closures are dated and reference the change that closed them.
3. Monitoring. The register is reviewed and updated in the same pass as every release. It ends in an append-only, dated history log of security incidents and decisions; old entries are never rewritten. Standing rules from closed gates (for example: secrets never in code, tokens never in logs or error messages, all stored secrets encrypted) are enforced by automated tests where feasible.

4. Access Control

• Zero-trust posture. There is no trusted internal network and no perimeter behind which requests are implicitly trusted: every request that touches user data is authenticated and authorized per-request at the data layer — the database's Row Level Security policies evaluate the authenticated user's identity (and, for MFA-enrolled accounts, the session's authentication level) on every query, regardless of where the request originates. There are no VPN-gated paths, IP-allowlisted bypasses, or location-trusted routes; access is granted to verified identities, never to networks or devices.
• Centralized identity. Application identity is managed by a single centralized identity provider (Supabase Auth) for all end users. Administrative identity consists of the provider accounts named in §9's infrastructure list (database/hosting console, source-code repository), each held solely by the policy owner with multi-factor authentication; no access to production systems exists outside these providers.
• Tenant isolation. User data lives in a managed Postgres database with Row Level Security enabled and enforced on every table holding user data, keyed to the authenticated user's ID.
• Least privilege. Administrative and infrastructure access is limited to the policy owner, with multi-factor authentication on the infrastructure accounts (database/hosting console and source-code repository). There are no shared accounts.
• End-user authentication. End users authenticate through a hosted, industry-standard authentication provider (Supabase Auth). The Service implements no custom password handling. TOTP-based multi-factor authentication (authenticator app) is offered to all end users; once enrolled, sign-in requires the second factor, enforced both in the application flow and by the database's row-level policies, which reject password-only sessions for enrolled accounts.
• Secrets. API keys and encryption keys live only in environment configuration, never in code or the repository.
• Periodic access reviews. At least quarterly, and after any material infrastructure change, the policy owner reviews: accounts with access to each infrastructure provider (confirming the list is still exactly the policy owner), active API keys and OAuth application credentials, repository collaborators and deploy keys, and MFA status on every infrastructure account. Each review is recorded as a dated entry in the security register's append-only history log; anything unexpected is treated as an incident under §8.

5. Data Protection

• In transit. All client–server and server–provider connections use HTTPS/TLS 1.2 or better.
• At rest. The managed database encrypts all data at rest. In addition, access tokens for every connected platform (accounting — QuickBooks Online; banking — Plaid; field-service/CRM — Jobber; and any platform added later) receive application-layer envelope encryption: each token is encrypted with authenticated symmetric encryption under a data key unique to that user, and the data key is stored only wrapped by a master key held in environment configuration. Nothing secret is ever stored in plaintext. Every new integration's tokens must use this same envelope-encryption path before it ships — it is a standing rule in the security-gates register, not a per-integration choice.
• Credentials. The Service never receives, transmits, or stores bank, accounting, or CRM credentials; authentication happens directly between the user, the platform, and the institution. Access is read-only: the Service initiates no payments and writes nothing to any connected platform.
• Retention and disposal are governed by the separately adopted Data Retention and Disposal Policy (v1.1).

6. Secure Development and Change Management

Changes are small, deliberate, and tested: the application ships with an automated test suite (2,600+ tests at the time of the v1.2 revision) that runs before release and includes security regression tests — among them tenant cache-isolation guards, token-handling checks, and a network block that prevents test code from reaching live providers. Secrets are excluded from version control by standing rule and .gitignore. Database schema changes are applied through reviewed, numbered migration files.

7. Vulnerability and Patch Management

• Production infrastructure is fully managed (Supabase); the provider patches and maintains the underlying servers. The Service operates no server instances of its own.
• Dependencies. Automated dependency vulnerability alerts and security updates (GitHub Dependabot) are enabled on the source-code repository. Flagged vulnerabilities are patched within defined windows by severity: critical within 72 hours of the alert, high within 14 days, medium within 30 days, and low with the next regular dependency update (no later than 90 days). If a patch is unavailable within its window, a mitigation or the dependency's removal is evaluated instead, and the decision is recorded in the security register.
• Endpoint. The single development workstation receives automatic operating-system security updates. There are no employee or contractor machines.

8. Incident Response

On discovery of a suspected security incident, the policy owner will: contain it (revoking or rotating affected tokens and keys, which the per-user envelope-encryption design allows without affecting other users); assess what data was involved; notify affected users and relevant providers without undue delay, as applicable law and provider agreements require; remediate the root cause; and record the incident, dated, in the security register's append-only history log. Users can reach the policy owner at the published contact address, and can themselves immediately revoke any connected data source in-app.

9. Vendor and Sub-processor Management

The Service relies on a deliberately short list of established providers: Supabase (database, authentication, hosting) and the platforms users choose to connect — currently Intuit (QuickBooks Online API), Plaid (bank connectivity), and Jobber (field-service/CRM API) — each disclosed in the published Privacy Policy before it handles user data. New vendors and new connected platforms are added only with a recorded reason and a review of what data they would touch.

10. Review and Revision History

This policy is reviewed by the policy owner upon any material change to the Service's systems or data handling, and at least annually. The security-gates register it references is reviewed far more often — in the same pass as every release.

• v1.0 (July 27, 2026) — initial adoption.
• v1.1 (July 28, 2026) — token-encryption and vendor language generalized to every connected platform category (accounting, banking, field-service/CRM); no control changed.
• v1.2 (July 28, 2026) — documented the zero-trust posture and centralized-identity model (§4), adopted a defined vulnerability-patch SLA (§7), committed to quarterly recorded access reviews (§4), and recorded the workforce provisioning/de-provisioning rule (§2).