Information Security Policy

Last updated: March 10, 2026

Document:
Helm Information Security Policy (ISP)
Version:
1.0
Effective Date:
March 10, 2026
Next Review:
June 10, 2026 (Quarterly)
Classification:
Public
Owner:
Helm Security Team

1. Purpose

This Information Security Policy (ISP) establishes the security requirements, controls, and responsibilities for protecting the confidentiality, integrity, and availability of consumer financial data processed by Helm. It applies to all systems, personnel, and third-party services involved in the operation of the Helm platform.

2. Scope

This policy covers:

  • All production systems that store, process, or transmit consumer financial data
  • All personnel (employees, contractors, agents) with access to production systems or consumer data
  • All third-party services and integrations (Plaid, Supabase, Vercel, Polygon.io)
  • The Helm web application, API layer, database layer, and supporting infrastructure

Consumer financial data includes: account balances, transaction history, account identifiers, portfolio holdings, and any personally identifiable information (PII) associated with user accounts.

3. Roles & Responsibilities

3.1 Security Owner

The Security Owner is responsible for maintaining this policy, conducting access reviews, managing incident response, and ensuring compliance with security requirements from integration partners (including Plaid). The Security Owner has final authority over access grants, revocations, and security exceptions.

3.2 Engineering Personnel

All personnel with access to Helm systems must:

  • Enable multi-factor authentication on all accounts that access production systems
  • Follow the principle of least privilege when requesting or granting access
  • Report suspected security incidents immediately to the Security Owner
  • Complete security onboarding before receiving production access
  • Return or destroy all access credentials upon departure or role change

3.3 Third-Party Services

Third-party services processing consumer data must maintain SOC 2 Type II certification or equivalent security controls. Helm currently uses:

  • Plaid - Account aggregation (SOC 2 Type II certified)
  • Supabase - Database and authentication (SOC 2 Type II certified)
  • Vercel - Application hosting (SOC 2 Type II certified)
  • Polygon.io - Market data (public data only, no consumer PII shared)

4. Access Control Policy

4.1 Principle of Least Privilege

Access to systems and data is granted on a need-to-know basis. Personnel receive only the minimum access required to perform their assigned duties. Elevated access (service-role database access, infrastructure admin) requires explicit approval from the Security Owner.

4.2 Authentication Requirements

  • Internal systems: All accounts that access production infrastructure (Supabase, Vercel, GitHub, Plaid dashboard) must have multi-factor authentication enabled. Password-only access is not permitted.
  • Consumer accounts: Password strength is enforced (must meet 4 of 5 complexity requirements). TOTP-based two-factor authentication is available and recommended for all users.
  • Service accounts: API keys and service-role credentials are stored in encrypted environment variable vaults. Keys are scoped to minimum necessary permissions and rotated at least annually.

4.3 Access Grant Process

  • New access requests must be approved by the Security Owner
  • Access is provisioned with MFA enabled before any production data is accessible
  • Access grants are documented and included in the quarterly access review

4.4 Access Revocation & De-provisioning

When a team member departs, is terminated, or transfers to a role that no longer requires access to consumer data, the following automated de-provisioning steps are executed within one (1) business day:

  • Removal from Supabase organization (database and auth management access)
  • Removal from Vercel team (deployment and environment variable access)
  • Removal from GitHub organization/repository (source code and CI/CD access)
  • Removal from Plaid dashboard (account aggregation configuration)
  • Revocation of any personal API keys or tokens
  • Rotation of any shared secrets the individual had access to

De-provisioning is tracked via a checklist maintained by the Security Owner and verified during the next quarterly access review.

5. Zero Trust Architecture

Helm implements a zero trust security model with the following controls:

  • No implicit trust: All API requests require valid, non-expired authentication tokens. There are no trusted networks, IP allowlists, or bypassed endpoints
  • Database-level enforcement: Row-Level Security (RLS) policies enforce per-user data isolation at the PostgreSQL level, independent of application logic
  • Token lifecycle: JWT access tokens are short-lived and automatically refreshed. Refresh tokens are stored in secure, HTTP-only, SameSite cookies
  • Privilege separation: Application code uses user-scoped database clients by default. Service-role access is limited to specific server-side operations (audit logging, account deletion, admin workflows) and is never exposed to client-side code
  • MFA enforcement: When a user enables two-factor authentication, the middleware enforces AAL2 (Authenticator Assurance Level 2) on all protected routes. Users at AAL1 are redirected to complete TOTP verification before accessing any dashboard functionality
  • Rate limiting: Authentication endpoints enforce per-identity rate limits backed by database state (not in-memory), ensuring limits apply consistently across serverless function instances

6. Data Protection

6.1 Encryption in Transit

All data transmitted between the client and Helm servers is encrypted using TLS 1.2 or higher. HTTPS is enforced on all endpoints with HSTS headers. There is no fallback to unencrypted HTTP.

6.2 Encryption at Rest

All data at rest is encrypted using AES-256 encryption provided by the infrastructure layer (Supabase / AWS RDS). Database backups are encrypted with the same standard. Encryption keys are managed by the infrastructure provider via AWS KMS and are not accessible to application code.

6.3 Data Isolation

Every database table containing consumer data enforces Row-Level Security (RLS) at the PostgreSQL level. Queries are scoped to the authenticated user's ID via the JWT token. Even in the event of an application-level vulnerability, cross-user data access is prevented by the database engine itself.

6.4 Sensitive Credential Handling

  • Passwords are hashed using bcrypt - plaintext passwords are never stored or logged
  • Plaid access tokens are stored encrypted in the database and are never exposed to client-side code
  • API keys and service secrets are stored in Vercel's encrypted environment variable vault
  • No consumer credentials (bank logins) are received or stored by Helm - Plaid handles all bank authentication directly

7. Vulnerability Management

7.1 Automated Scanning

  • Dependency scanning: GitHub Dependabot monitors all npm dependencies for known CVEs on a weekly basis and creates automated pull requests for remediation
  • Static code analysis: GitHub CodeQL runs on every pull request and weekly on the main branch, detecting security vulnerabilities (injection, XSS, insecure crypto, etc.) before code reaches production
  • Infrastructure scanning: Vercel and Supabase perform continuous vulnerability assessments on their managed infrastructure

7.2 Remediation SLAs

  • Critical (CVSS 9.0+): Remediated within 48 hours
  • High (CVSS 7.0-8.9): Remediated within 7 days
  • Medium (CVSS 4.0-6.9): Remediated within 30 days
  • Low (CVSS 0.1-3.9): Remediated within 90 days or next release cycle

7.3 Responsible Disclosure

External security researchers can report vulnerabilities to security@helmterminal.dev. Reports are acknowledged within 48 hours and triaged according to the remediation SLAs above.

8. Audit Logging & Monitoring

All security-relevant events are logged to a tamper-resistant audit table with the following attributes:

  • Event type (login success, login failure, password change, session revocation, account deletion, MFA enrollment)
  • User identifier
  • IP address
  • User agent (parsed to browser, OS, and device type)
  • Timestamp (UTC)
  • Event-specific metadata

Audit logs are retained for a minimum of 12 months. Users can view their own login activity from the Settings page. Logs are protected by RLS - users can only view their own events. Administrative log access (via service-role) is restricted to the Security Owner.

9. Periodic Access Reviews

Access to all production systems and consumer data is reviewed on a quarterly basis. Each review includes:

  • Enumeration of all personnel with access to each production system
  • Verification that MFA is enabled on all privileged accounts
  • Confirmation that departed or transferred personnel have been fully de-provisioned
  • Review of API key scopes and last usage dates
  • Review of database RLS policies for correctness and completeness
  • Review of third-party service permissions and data sharing agreements

Reviews are documented and retained. Findings requiring remediation are tracked to completion by the Security Owner.

10. Incident Response

10.1 Detection

Security incidents may be detected via audit log anomalies (unusual login patterns, repeated failed attempts), automated vulnerability scanning alerts, user reports, or third-party notifications (Plaid, Supabase, Vercel security advisories).

10.2 Response Procedure

  • Identify: Determine scope, affected systems, and impacted users
  • Contain: Isolate affected systems, revoke compromised credentials, block malicious access
  • Eradicate: Remove the root cause (patch vulnerability, rotate keys, remediate code)
  • Recover: Restore normal operations and verify integrity
  • Notify: Inform affected users within 72 hours if consumer data was compromised. Notify integration partners (Plaid) as required by their security agreements
  • Review: Conduct post-incident review and update this policy if needed

11. Consumer Application Security

  • Multi-factor authentication: TOTP-based 2FA is available on all consumer accounts and enforced at the middleware level when enabled
  • Password policy: Minimum 8 characters, must meet 4 of 5 complexity requirements (uppercase, lowercase, number, special character, length). Strength is enforced on both client and server
  • Session management: Users can view active sessions, sign out other devices, and monitor login activity
  • Account deletion: Users can self-service delete their account and all associated data from Settings. Deletion cascades through all data tables and removes the auth record
  • Rate limiting: Login (5 attempts / 15 min), signup (5 / hour), password reset (3 / hour)

12. Third-Party Integration Security

12.1 Plaid

  • Helm never receives or stores bank login credentials - Plaid handles all bank authentication
  • Read-only access only - no transaction initiation or fund transfer capabilities
  • Plaid access tokens are encrypted at rest and never exposed to client code
  • Separate API keys for sandbox and production environments
  • Webhook signatures verified on all incoming Plaid events

12.2 Market Data (Polygon.io)

  • No consumer PII is shared with Polygon - only ticker symbols are queried
  • Market data (prices, news, dividends) is stored in shared tables not subject to user RLS
  • API key stored in server-side environment variables only

13. Policy Review & Maintenance

This Information Security Policy is reviewed and updated on a quarterly basis, or sooner if triggered by:

  • A security incident
  • A material change to the application architecture or data processing
  • New regulatory or partner requirements (e.g., Plaid attestation updates)
  • Findings from an access review or vulnerability scan

All policy changes are versioned and approved by the Security Owner before taking effect.

14. Contact

For questions about this policy or to report a security concern, contact: security@helmterminal.dev