Information Security Policy
Skrilla Plan, LLC ("the Company"), operator of SkrillaPlan (skrillaplan.com) — a personal budgeting application.
Version 1.0 · Effective 2026-07-06 · Owner: Founder (acting Security Officer) · Review cadence: at least annually and on material change.
1. Purpose & scope
This policy documents how Skrilla Plan, LLC identifies, mitigates, and monitors information-security risks across the systems, data, and vendors that make up the SkrillaPlan service. It covers all Company data and infrastructure, including customer financial data accessed via Plaid, and applies to every person with access to Company systems (currently the founder; contractors and interns as they are added).
Skrilla Plan, LLC is an early-stage company. This program is deliberately scaled to that size — a single accountable owner, a small, well-understood cloud footprint, and controls chosen for real risk reduction rather than checkbox breadth. It is reviewed and expanded on a schedule (§12) as the Company grows.
2. Roles & responsibilities
- Security Officer (the Founder) owns this policy, the risk register, vendor review, incident response, and access decisions.
- All personnel (contractors, interns) must follow this policy, use MFA on all Company accounts, and report suspected incidents immediately.
- Access is granted on least privilege and removed promptly on offboarding.
3. Risk management — identify
- The Security Officer maintains a risk register reviewed at least quarterly and on any material change (new data type, new vendor, new feature touching financial data).
- Each risk is rated by likelihood × impact; the dominant identified risks are: (a) exposure of Plaid access tokens or customer financial data, (b) account-takeover of a customer or an admin account, (c) a compromised third-party dependency or vendor. Mitigations for each are in §5–§9.
- New features that touch sensitive data get a lightweight security review before release (data flow, where secrets live, what rules enforce access).
4. Data classification & handling
| Class | Examples | Handling |
|---|---|---|
| Secret | Plaid access tokens, API keys, OAuth refresh tokens, webhook secrets | Server-side only; stored in Google Secret Manager or in access-denied datastore collections; never sent to the browser; never in source control |
| Sensitive (customer financial) | Transactions, balances-derived budget data, email/identity | Encrypted in transit and at rest; access gated by per-user security rules; isolated per household |
| Internal | Application config, logs | Least-privilege access |
| Public | Marketing pages, docs, this policy | No restriction |
- We never receive or store customer bank credentials. Bank authentication is handled entirely by Plaid; the Company holds only Plaid access tokens, which are write-only from the client's perspective and readable only by trusted server code.
- No selling or ad-tech. The Company runs no third-party advertising or analytics SDKs and never sells customer data. (Public commitment: skrillaplan.com/privacy.)
5. Access control — mitigate
- Customer data isolation is enforced by Firestore Security Rules: deny-by-default, membership-based, and covered by an automated test suite run in the Firestore emulator on every change. Collections holding secrets (Plaid access tokens, Gmail OAuth refresh tokens) are deny-all to all clients — reachable only by server-side Admin SDK code.
- Authentication uses Google Firebase Authentication (Google sign-in); server callables verify the caller's identity and household membership before any privileged action.
- Administrative access to cloud infrastructure (Google Cloud / Firebase, Stripe, Plaid, domain, source control) is protected by multi-factor authentication (authenticator/passkey, not SMS where avoidable) and limited to the Security Officer. Cloud IAM follows least privilege.
- Application roles (admin / editor / viewer) enforce least privilege within each customer household.
6. Data protection & cryptography
- In transit: all traffic is served exclusively over HTTPS/TLS (enforced by the Google Cloud / Firebase platform).
- At rest: all customer data (Google Cloud Firestore) and secrets (Google Secret Manager) are encrypted at rest with Google-managed keys by default.
- Secrets management: API keys and tokens live in Google Secret Manager, injected into server functions at runtime; they are never embedded in client code or committed to source control (enforced by ignore rules). Third-party keys use restricted/least-privilege scopes where the vendor supports it (e.g., Stripe restricted keys).
7. Application & infrastructure security — mitigate
- Serverless, managed footprint: the app runs on Google Cloud (Firebase Hosting / App Hosting on Cloud Run, Cloud Functions, Firestore). There are no self-managed servers or databases to patch; the Company relies on Google's continuously-patched managed platform for OS/runtime security.
- Secure SDLC: all code is version-controlled (GitHub), changed through reviewed commits, and protected by an automated test suite (unit tests plus Firestore-rules tests in an emulator) that runs before deployment. Access-control rules are treated as code and tested like code.
- Dependency management: third-party dependencies are kept current; the Company monitors for known-vulnerability advisories and patches promptly.
- Least-privilege services: server functions hold only the scopes and secrets they need; cost/abuse guardrails (e.g., per-account connection ceilings, invite-gated signup) limit blast radius.
8. Third-party / vendor management
The Company uses a small set of reputable subprocessors and reviews them at least annually:
| Vendor | Purpose | Data shared |
|---|---|---|
| Google Cloud / Firebase | Hosting, database, auth, secrets | All application data (encrypted) |
| Plaid | Bank connectivity | Access tokens; bank credentials never touch the Company |
| Stripe | Payments & tax | Billing/customer data (PCI handled by Stripe; the Company stores no card data) |
| Google (dedicated project) | Optional Gmail receipt matching | Per-user OAuth, opt-in |
New vendors are assessed for security posture and data handling before adoption.
9. Logging & monitoring — monitor
- Centralized logging via Google Cloud Logging captures application and function activity; server routines write operational logs the Security Officer reviews.
- Alerting: Google Cloud budget alerts are configured as an early anomaly signal (a spend spike often indicates abuse or misconfiguration); authentication and infrastructure events are available through the platform console.
- In-product reporting: every screen includes a one-tap issue reporter feeding an admin review queue, giving fast signal on user-visible problems.
- Access review: administrative access and third-party grants are reviewed on a recurring basis and immediately on any personnel change.
10. Incident response & breach notification
- Suspected incidents are reported to the Security Officer immediately.
- Response follows: contain (revoke tokens/keys, disconnect affected integrations, disable compromised accounts) → assess scope via logs → remediate and patch → notify affected customers and relevant parties (including Plaid and other vendors as required) without undue delay, consistent with applicable law → document and fold lessons into the risk register and this policy.
- The architecture supports rapid containment: tokens/keys can be revoked in Secret Manager and integrations disconnected per-household.
11. Business continuity & data integrity
- Customer data resides in Google Cloud Firestore, a managed, replicated datastore; the Company relies on Google's platform durability and is enabling point-in-time recovery / scheduled backups as part of its pre-scale hardening.
- Customers can export their own data at any time, and retain read/export access to their data even if they stop paying — reducing lock-in and single-point-of-failure risk for the customer.
12. Compliance, training & review
- Personnel: all personnel are briefed on this policy and secure-handling basics before receiving access; the team is small enough for direct oversight.
- Compliance calendar: annual review of this policy, vendor posture, and access grants; the Plaid production security questionnaire refreshed annually; where restricted data scopes are used (e.g., Gmail), the required independent security assessment (CASA) is scheduled before that feature is offered broadly.
- This document is reviewed at least annually and after any material change to systems, data handling, or vendors. Version history is tracked in the Company's source control.
Skrilla Plan, LLC — Information Security Policy v1.0. Contact: security@skrillaplan.com.