Flow-er Power — Information Security & Change Management Policy

Version: 1.0
Effective date: 2026-11-09
Policy owner and production approver: Flow-er Power application owner
Scope: The private Flow-er Power dashboard and its integrations with Plaid, TD, Cloudflare, GitHub, and authorized development assistants.
Review: After the initial trial, following any material security incident or architecture change, and at least annually.

1. Purpose and accountability

This application exists to help authorized members of one household understand balances, spending, upcoming debits, and cash-flow needs. Its financial integrations are read-only. The owner is accountable for access permissions, deployments, incident decisions, data retention, and policy exceptions. AI development assistants may propose or write code but are not security approvers, data custodians, or independent reviewers.

2. Data collected and permitted use

• Only bank accounts that an authorized account holder intentionally links through Plaid may be accessed.
• The intended Plaid products are Transactions and Balance; additional product permissions, including Liabilities, require separate owner authorization when needed.
• The app may display account labels, available/current balances, transaction dates, merchant/descriptions, amounts, categories, and limited synchronization metadata, solely to provide household finance functions.
• The app will not initiate payments, transfers, or changes to bank accounts. A planned feature named Transfer Guard is advisory only and may not initiate transfers.
• Household members must be authorized to view the financial information being shared. Where joint-account data affects another person, the owner will ensure appropriate household consent.
• Financial data may not be sold, used for advertising, provided to external analytics or AI services, or copied into source code, prompts, issue trackers, or development logs.

3. Information classification and minimization

Restricted: TD credentials (which this app must not collect); Plaid production secret; Plaid access tokens; financial account identifiers and raw transactions; session and administrative authentication tokens.
Internal: Repository code, infrastructure diagrams, deployment records, risk reviews, and vulnerability details.
Household-visible: Financial data displayed inside the authenticated dashboard.
Public-facing: This policy, a high-level privacy summary, and non-sensitive product information.

Collect only fields needed for approved features. Mask account numbers in the user interface. Do not use actual financial data in tests or preview environments. No analytics, session-replay, or crash-reporting service may receive banking data.

4. Identity and access management

• Require multifactor authentication on Plaid, GitHub, Cloudflare, and any connected identity provider wherever supported.
• Restrict the dashboard to explicitly authorized household identities using Cloudflare Access or an equivalent identity boundary. Protect all production hostnames, API routes, and preview domains that could otherwise reach real data.
• Verify the trusted identity token server-side on every sensitive API request; hiding pages in the browser is not sufficient.
• Follow least privilege for GitHub apps, deployment tokens, Cloudflare service credentials, and Plaid roles. Grant only the necessary repositories and environments.
• The owner must review access at launch, after an access or household-member change, and at least quarterly. Remove unauthorized or obsolete access promptly.
• Do not place financial data or production credentials in browser localStorage, readable cookies, public client bundles, or front-end environment variables.

5. Secrets, encryption, and transport

• Use HTTPS/TLS for browser-to-application, application-to-Plaid, and other sensitive network communications.
• Store the Plaid Client ID and production secret in Cloudflare's encrypted server-side secret mechanism. Treat both as confidential under Plaid's Developer Policy, even if a Client ID appears less sensitive than a secret.
• Exchange Plaid Link public tokens only on the backend. Plaid access tokens must remain server-side, stored in an approved encrypted secret or data store; where a data store can expose plaintext to its administrators or exports, use application-level encryption with separately managed keys.
• Never place credentials, access tokens, private keys, raw transaction data, or actual account identifiers in GitHub, ChatGPT conversations, build artifacts, CI logs, screenshots, support tickets, or plaintext backups.
• Limit secret availability to the production execution environment. Preview/test deployments must use mocked or sandbox data and must not inherit production secrets or live financial-data bindings.
• Rotate or revoke credentials promptly following suspected exposure, personnel or permission changes requiring it, or vendor guidance. Document a successful recovery and reconnection procedure before launch.

6. Application, network, and data security

• Restrict server-side endpoints to authenticated, authorized users. Validate parameters and apply appropriate request limits, error handling, and CSRF protection wherever state-changing requests exist.
• Minimize externally loaded scripts, fonts, widgets, and third-party network destinations. Apply a restrictive Content Security Policy and other relevant response headers.
• Return sensitive responses with Cache-Control: no-store; do not expose transaction contents in URLs, page metadata, analytics, or error messages.
• Use supported dependencies; scan code and dependencies for known vulnerabilities and accidental secrets. Patch critical and high-risk findings promptly, prioritizing exploitable issues.
• Log authentication failures, denied access, suspicious API usage, material configuration changes, secret rotations, and deployments without logging sensitive financial values or tokens. Review alerts and suspicious events regularly.
• Maintain backups only for necessary retained data; protect backups to the same standard and test restore procedures before relying on them.

7. Storage, retention, deletion, and consent

• Trial default: No persistent copy of raw transaction history. Retrieve data only as needed for an authenticated session and do not retain it in application logs or browser storage. A securely stored Plaid access token may be needed to maintain the connection.
• Any subsequent persistent transaction store requires an owner-approved data inventory and written retention schedule before activation. Retention must be limited to the household budgeting need and consider the consequences of account disconnection.
• On a disconnect or deletion request, stop synchronization, revoke/remove the relevant Plaid Item when applicable, delete application-held tokens and financial records within the configured deletion process, and disclose any backup-retention limitation.
• Revoking access in this application does not itself establish deletion from TD or Plaid systems; those organizations retain control of their own data practices.
• Maintain a short register of data categories, storage locations, purposes, access roles, and deletion methods. Never record actual account numbers or tokens in the register.

8. Secure development and change approval

Changes are classified by effective risk, not only by filename. A change described as cosmetic is not low-risk if it can affect scripts, build tooling, dependencies, data access, or security behavior.

Initial trial rule (2026-11-09 through 2026-11-15): Every production change, including low-risk changes, requires manual owner approval. Automatic promotion must remain disabled until the owner verifies technical enforcement. After the trial, the default remains manual approval unless the owner explicitly approves and verifies a restricted low-risk automation mechanism. Lack of enforceable branch protection or other equivalent gating means no automatic production deployment.

All production changes must be traceable to a commit or deployment record, include a brief rationale and test evidence, and be reversible. Development assistants may author pull requests or branches but may not independently authorize their production promotion. A self-approval by the owner is not an independent security review; high-risk changes should receive an additional substantive security check where feasible.

9. Incident response and notification

If unauthorized access, leakage, malicious code, exposed secrets, or suspicious account usage is suspected:

1. Contain: Pause deployments and financial synchronization; restrict Cloudflare access and revoke affected secrets/tokens or Plaid Items as warranted.
2. Preserve: Retain only necessary security-event metadata, affected commit/deployment identifiers, and timestamps; avoid copying bank data into incident reports.
3. Assess: Determine which accounts, data, and systems were affected, and whether a data export or unauthorized API request occurred.
4. Notify: Notify Plaid promptly at security@plaid.com where its account or end-user data may have been compromised; contact affected household members, TD, or regulators where appropriate or legally required.
5. Recover: Patch and review code, rotate secrets, verify access controls, and cautiously restore service.
6. Learn: Record the root cause, corrective measures, and policy changes required.

The owner makes incident decisions and keeps a minimal incident log. Report and disclosure timeframes must also follow applicable law and vendor commitments; this policy does not replace them.

10. Vendors, documentation, and review

The initial service providers are TD (financial institution), Plaid (authorized data connectivity), Cloudflare (hosting, access and execution), and GitHub (source control). ChatGPT may be used as an authorized development assistant to write and review non-sensitive source code only. Changes to vendors, third-party processors, or external network destinations require high-risk approval before production use.

Maintain developer procedures in docs/SECURITY_OPERATIONS.md and docs/CHANGE_CONTROL.md. Make this policy accessible from the dashboard under Security & Privacy. Review it after the trial, after significant incidents or architectural changes, and no less than annually. Record versions, approvals, exceptions, and any unimplemented controls accurately.

11. Exceptions and launch condition

Exceptions require a written owner decision recording the reason, duration, compensating control, and expiry. Exceptions must not contradict mandatory Plaid contract terms or applicable laws. Do not connect live accounts until all mandatory launch controls are demonstrably in place.

External references: Plaid Developer Policy; Plaid Trial plan; Cloudflare Pages Git integration.