Information Security Policy

How we protect consumer financial data and other sensitive information.

Information Security Policy

Organization: System4IPS (operated by DiBro Holdings Inc.) Document version: 1.0 Effective date: May 1, 2026 Next review date: May 1, 2027 Document owner: Max Bertman, President


1. Purpose and Scope

This Information Security Policy defines how System4IPS protects the confidentiality, integrity, and availability of consumer financial data and other sensitive information processed by the System4IPS Billing Portal (the "Application"), located at https://system4ips-billing.vercel.app.

This policy applies to:

  • All systems, services, and infrastructure used to operate the Application
  • All personnel with access to the Application or its supporting systems
  • All consumer data received from third-party providers including Plaid, Stripe, and Webster Bank
  • All vendors and sub-processors used in the operation of the Application

This policy does not apply to general System4IPS business operations outside the scope of the Billing Portal.


2. Roles and Responsibilities

System4IPS operates with a small team. Information security responsibilities are assigned as follows:

Role Responsibility Assigned to
Information Security Officer Overall accountability for this policy, incident response, vendor risk review Max Bertman, President
System Administrator Day-to-day operation of cloud infrastructure, key rotation, access provisioning Max Bertman, President
Privacy Officer Privacy policy compliance, consumer rights requests, breach notification Max Bertman, President

A primary security contact email (security@system4ips.com) is monitored daily for incident reports, vulnerability disclosures, and consumer privacy requests.


3. Data Classification

System4IPS classifies data into three tiers:

3.1 Highly Sensitive (Tier 1)

  • Bank account numbers (encrypted at rest with AES-256-GCM)
  • Bank routing numbers
  • Card numbers (never stored — held by Stripe under PCI scope)
  • Plaid access tokens (not retained beyond initial use)
  • Stripe payment method identifiers
  • Authentication credentials and encryption keys

3.2 Sensitive (Tier 2)

  • Customer business name, contact name, and email address
  • Authorization records (Nacha consent, signing IP, timestamps)
  • Audit logs (admin reveal events, charge attempts)
  • Onboarding session tokens

3.3 Internal (Tier 3)

  • Application source code (private repository)
  • Operational logs and metrics
  • Aggregate or anonymized data

Tier 1 data receives the strongest controls: encryption at rest and in transit, access logging, deletion when no longer required, and separation of encryption keys from encrypted data.


4. Access Control

4.1 Principle of Least Privilege

All accounts and service identities receive the minimum permissions required to perform their function. Access is reviewed when responsibilities change and revoked promptly when no longer needed.

4.2 Administrative Access

  • The administrative console of the Application is protected by a strong password (16+ characters) stored in a password manager (LastPass)
  • Multi-factor authentication (TOTP) is planned and will be implemented before live consumer data is processed
  • Administrative session cookies are HTTP-only, Secure, SameSite=lax, and signed with HMAC-SHA256

4.3 Database Access

  • The Application database (Supabase Postgres) is accessed only by the Application server using a service-role key
  • Row-level security (RLS) is enabled on all tables with default-deny policies
  • The anonymous (public) database role has no permissions on any table containing Tier 1 or Tier 2 data
  • The service-role key is stored as an encrypted environment variable in the deployment platform (Vercel) with Sensitive flag enabled and access restricted to Production

4.4 Third-Party Service Access

  • Plaid, Stripe, Webster Bank, and other vendor accounts are protected by strong unique passwords and multi-factor authentication where supported
  • API keys are rotated annually or immediately upon suspected compromise

4.5 Source Code Access

  • The Application source code is hosted in a private GitHub repository
  • All code changes go through pull request review by the Information Security Officer
  • Direct push to the production branch is restricted

5. Encryption and Key Management

5.1 In Transit

All connections between consumers, the Application, and third-party services use TLS 1.2 or higher. TLS 1.3 is in use across all platform endpoints (Vercel, Supabase, Stripe, Plaid).

5.2 At Rest

  • Tier 1 data (bank account numbers) is encrypted at the application layer using AES-256-GCM before storage in the database
  • The encryption key is a 32-byte random value stored in the deployment platform's secret store (Vercel environment variables, marked Sensitive, restricted to Production)
  • The key is separated from the encrypted data: the key lives in Vercel's secret store; the data lives in Supabase
  • The database provider (Supabase) additionally encrypts all data at rest at the storage layer using AES-256

5.3 Key Rotation

  • The application encryption key is reviewed annually and rotated upon any suspected compromise
  • Plaid, Stripe, and other API keys are rotated annually or upon suspected compromise
  • Rotation procedure: provision new key → deploy with both keys active → re-encrypt existing data → remove old key

5.4 Key Recovery

The encryption key is stored only in the Vercel secret store. The Information Security Officer maintains an encrypted offline backup in a password manager to prevent total loss.


6. Vendor and Sub-Processor Management

System4IPS uses the following vendors as sub-processors:

Vendor Function Data accessed
Vercel, Inc. Application hosting, edge network, secret storage Tier 1, 2, 3 (in memory only)
Supabase, Inc. Database hosting, authentication infrastructure Tier 1 (encrypted), Tier 2
Stripe, Inc. Card processing, off-session charging Tier 1 (cards), Tier 2
Plaid, Inc. Bank account verification, identity verification Tier 1 (bank info), Tier 2
Webster Bank ACH origination and settlement Tier 1 (manually entered)
Resend, Inc. Transactional email delivery (planned) Tier 2 (email addresses)

Each vendor is selected based on:

  • Demonstrated security posture (SOC 2, PCI DSS, or equivalent attestations)
  • Acceptable data processing terms
  • Operational track record and incident response capability

The vendor list is reviewed annually. Adding a new sub-processor requires review and approval by the Information Security Officer and an update to the consumer Privacy Policy.


7. Vulnerability Management

7.1 Dependency Scanning

The Application's source repository has GitHub Dependabot enabled. Security advisories for any dependency trigger an alert; high and critical advisories are remediated within 14 days, medium within 30 days.

7.2 Platform Updates

  • Next.js, Node.js, and other framework versions are reviewed quarterly
  • Security patches from Vercel, Supabase, Stripe, and Plaid SDKs are applied promptly upon release

7.3 Endpoint Security

The administrator's workstation runs macOS with native security features enabled (Gatekeeper, XProtect, FileVault full-disk encryption, automatic security updates). The workstation is screen-locked when unattended.

7.4 Manual Review

The Information Security Officer reviews security-sensitive code paths (authentication, encryption, API routes handling Tier 1 data) quarterly or upon significant change.


8. Incident Response

8.1 Detection

Incidents may be detected through:

  • Vendor security alerts (Plaid, Stripe, Supabase, Vercel)
  • Dependabot or other automated scanning
  • Consumer reports to security@system4ips.com
  • Anomalies in audit logs (reveal_log, charges)
  • External security researcher disclosures

8.2 Response Procedure

Upon detection of a suspected security incident, the Information Security Officer will:

  1. Contain — within 1 hour, take action to halt ongoing harm (rotate keys, disable accounts, take Application offline if necessary)
  2. Assess — within 24 hours, determine scope: what data was potentially exposed, which consumers are affected, whether the threat is ongoing
  3. Notify — affected consumers and relevant regulatory bodies (state attorneys general, Plaid, Stripe, Webster Bank) within timeframes required by applicable breach notification laws (typically 30-72 hours)
  4. Remediate — address the root cause, deploy fixes, restore service safely
  5. Document — record the incident, root cause, response timeline, and lessons learned in an incident log
  6. Review — within 30 days, conduct a post-incident review and update procedures as needed

8.3 Breach Notification

System4IPS commits to consumer breach notification consistent with the most stringent applicable law in any jurisdiction where affected consumers reside. As of this policy's effective date, this includes (without limitation) Connecticut (CTDPA), California (CCPA/CPRA), New York (SHIELD Act), and any other state with applicable breach notification statutes.


9. Physical Security

System4IPS does not operate physical infrastructure for the Application. All compute, storage, and networking is provided by cloud vendors (Vercel, Supabase) with their own physical security controls (typically SOC 2-attested data centers with biometric access, 24/7 monitoring, and environmental controls).

The administrator's workstation is a macOS laptop kept in a private residence or carried personally. The workstation is encrypted (FileVault), screen-locked when unattended, and never left in a vehicle or unattended public space.


10. Personnel Security

System4IPS currently operates with a single principal (Max Bertman, President), supported by occasional contractors for specific tasks (e.g., software development).

10.1 Onboarding

Any new personnel with access to the Application or its supporting systems will:

  • Read and acknowledge this Information Security Policy
  • Receive a unique login (no shared credentials)
  • Be granted minimum necessary access
  • Sign a confidentiality agreement covering customer data

10.2 Offboarding

Within 24 hours of departure or contract end:

  • All accounts are revoked
  • All shared secrets the person had access to are rotated
  • Returned hardware (if any) is wiped

10.3 Background

Personnel with access to consumer financial data are personally known to the Information Security Officer. Background checks are not currently required given the small scale of operations but will be implemented if the organization grows beyond five total personnel with system access.


11. Backup and Disaster Recovery

11.1 Database Backups

The database provider (Supabase) maintains automated daily backups with point-in-time recovery for the most recent 7 days as part of its standard service.

11.2 Source Code

The Application source code is hosted in GitHub with full revision history. The Information Security Officer maintains a local clone of the repository on their workstation as a redundant copy.

11.3 Configuration

Environment variables and infrastructure configuration are documented and stored in a password manager (LastPass) accessible only to the Information Security Officer.

11.4 Recovery Objective

  • Recovery Time Objective (RTO): 4 hours for the Application; consumer onboarding can be performed manually if the Application is unavailable
  • Recovery Point Objective (RPO): 24 hours; daily backups provide acceptable data recency for the Application's role as an onboarding broker (the source-of-truth for invoice and payment data lives in separate franchisor software)

12. Audit and Logging

The Application maintains the following audit logs:

Log Contents Retention
reveal_log Every administrator-initiated reveal of consumer bank account data, with timestamp, IP, and reason 2 years
charges Every Stripe charge attempt with status, amount, description, and outcome 2 years
authorizations Nacha authorization snapshots with consumer IP, user agent, signing time, and exact terms agreed to 2 years post-revocation (Nacha requirement)
Vercel access logs HTTP request logs to all Application endpoints Per Vercel retention (typically 30 days on current plan)
Stripe event log All API calls and webhook events to/from Stripe Per Stripe retention (multi-year)

Logs are reviewed periodically for anomalies and on demand during incident investigation.


13. Compliance

The Application is designed to meet or exceed the following compliance requirements:

  • PCI DSS (SAQ A scope): Card data is never received, stored, or transmitted by System4IPS systems. All card handling is performed by Stripe via Stripe Elements with the publishable key, keeping System4IPS at SAQ A scope (the lowest tier of PCI compliance).
  • Nacha Operating Rules: ACH authorizations are captured with explicit consumer consent, IP address, timestamp, and the exact terms agreed to. Records are retained for 2 years post-revocation.
  • State data privacy laws: Including CCPA/CPRA (California), CTDPA (Connecticut), VCDPA (Virginia), CPA (Colorado), and others as applicable. Consumer data subject rights (access, deletion, portability) are honored upon verified request to privacy@system4ips.com.
  • ESIGN Act and UETA: Electronic authorizations meet federal and state requirements for valid electronic signatures, including consent to electronic transactions, intent to sign, and audit trail.

14. Policy Review and Maintenance

This policy is reviewed at minimum annually by the Information Security Officer, and additionally upon:

  • Any significant change to the Application architecture
  • Addition or removal of a sub-processor
  • Any security incident
  • Material change to applicable law or regulation

The current version of this policy is maintained in the Application's source repository at docs/information-security-policy.md. A copy is provided to vendors and customers upon reasonable request.


15. Approval

This policy is approved and in effect as of the effective date listed at the top of this document.

Approved by:

Max Bertman President, DiBro Holdings Inc. (operating as System4IPS) Date: May 1, 2026