Security Policies

The information-security policies governing In My Stash. These describe controls that are in place or committed to on a defined cadence; they are reviewed at least annually.

1. Information Security Policy · 2. Access Control Policy · 3. Vulnerability Management & Patch Policy · 4. Data Retention & Deletion Policy

1. Information Security Policy

1.1 Scope

Applies to the In My Stash application, the stateless bank-data relay (Cloudflare Worker and KV store), the source repositories, and all accounts and systems used to build and operate them.

1.2 Roles & responsibility

In My Stash is operated by a single owner who is the responsible party for information security, incident response, and privacy. The security contact (security@inmystash.com) is monitored.

1.3 Risk management

Primary risks are identified as: exposure of the relay master key; exposure of a user's on-device vault key; account takeover of an administrative console; and vulnerable application dependencies. These are reviewed at each policy review and on any material architecture change, and are mitigated by the controls in §1.4–1.8 and the companion policies below.

1.4 Data protection

• In transit: TLS 1.2+ for all traffic (Cloudflare, GitHub, Plaid, SimpleFIN).
• At rest: every relay KV record is AES-256-GCM encrypted under a master key held as a platform secret; there is no plaintext at rest. Each user's read-only bank token carries an additional device-key envelope, so the relay cannot read finances without the user present. On-device data is AES-GCM encrypted when the app lock is enabled.
• Data minimization: the relay never stores transactions or balances; it retains only an encrypted read-only token. No consumer PII is collected server-side.

1.5 Access control

Least privilege, MFA-enforced administrative access, scoped machine credentials, and periodic review — see §2.

1.6 Vulnerability & patch management

Managed serverless infrastructure, dependency review, and a defined patch SLA — see §3.

1.7 Secrets management

Secrets (relay master key, aggregator credentials, deployment tokens) are stored only as platform secrets, never in source. Deployment tokens are least-privilege and time-limited. Any secret suspected of exposure is rotated immediately.

1.8 Incident response

On suspected compromise: (1) rotate affected secrets; (2) revoke affected tokens/connections; (3) assess scope from logs; (4) notify affected users where their data may be affected; and (5) meet applicable state breach-notification duties. By design, a relay compromise exposes no financial data and no usable token.

1.9 Change management & review

Changes are deployed from source, and the deployed build is verified byte-identical to the reviewed source. This policy and its companions are reviewed at least annually and after any material change.

2. Access Control Policy

2.1 Principle

Least privilege. Access to production assets and sensitive data is limited to the minimum required and to the fewest people.

2.2 Administrative access

Production is administered through the Cloudflare (relay, KV, secrets), GitHub (source, hosting), Plaid, and SimpleFIN consoles.

• Multi-factor authentication is required and enforced on every administrative account.
• Strong, unique credentials via a password manager; no shared logins.

2.3 Non-human authentication

• The relay authenticates to Plaid and SimpleFIN using scoped, read-only API credentials stored as platform secrets.
• Deployment uses scoped, expiring API tokens — never global keys.
• Clients authenticate to the relay with a per-user bearer capability secret over TLS.

2.4 Production data access

The relay master key exists only as a platform secret; no human reads it. There is no standing human access to consumer financial data, because that data is never stored server-side.

2.5 Provisioning & de-provisioning

Access is granted per least privilege. If personnel are added, access is granted to the minimum required and removed immediately on offboarding, and this policy is updated accordingly.

2.6 Review cadence

Administrative access, active API tokens, and secrets are reviewed at least annually and whenever a credential is rotated; unused tokens are revoked and expirations re-confirmed.

3. Vulnerability Management & Patch Policy

3.1 Infrastructure model

Production runs on managed serverless infrastructure (Cloudflare Workers and KV). There are no self-managed servers or long-lived virtual machines; the provider patches the underlying operating systems, runtimes, and network stack continuously.

3.2 Dependency management

Dependencies are minimal and pinned. Third-party components are reviewed and updated on each release, and advisories affecting components in use are monitored.

3.3 Patch SLA

Provider-managed platform vulnerabilities are remediated by the provider on their own timeline.

3.4 End-of-life software

End-of-life components are actively avoided and monitored. The serverless runtime is vendor-maintained; pinned client libraries are reviewed each release and upgraded before reaching end of support.

3.5 Endpoint hygiene

Developer machines run a supported operating system with automatic security updates, full-disk encryption, and screen lock enabled. Secrets are never stored in plaintext on disk or in shell history.

4. Data Retention & Deletion Policy

4.1 Principle

Hold as little as possible for as short a time as possible.

4.2 Retention schedule

4.3 Deletion

• In-app: the user can erase all on-device data at any time; immediate and irreversible.
• Disconnect: removing a bank connection revokes the read-only token and deletes its encrypted record from the relay.
• On request: deletion requests to the security contact are honored promptly, consistent with applicable law.

4.4 Compliance

Designed to meet CCPA/CPRA and other U.S. state privacy-law retention and deletion requirements, applied to all users regardless of residence. Reviewed at least annually.

Questions or auditor due-diligence: security@inmystash.com.