Information Security Policy

Effective date: 12 June 2026 Last updated: 12 June 2026 Owner: Founder & Security Lead, BMRTECKBUSINESS LLC Review cadence: at least annually, and after any significant change or incident.

This document describes the information security program for BMRTECKBUSINESS LLC and the Piggy application ("the App"). It governs how we protect our systems and the data of our users.

1. Purpose and scope

The purpose of this policy is to protect the confidentiality, integrity, and availability of:

• User personal data and bank-connection credentials;
• Our production systems, source code, and infrastructure;
• Third-party integrations (financial data providers, payments, messaging).

It applies to all personnel, contractors, systems, and environments (development, staging, production) operated by us.

2. Security principles

• Data minimization. We collect and retain the least data necessary. We do not store user transactions, balances, incomes, or expenses on our servers — financial data is retrieved on demand and delivered to the user's device.
• Least privilege. Access to systems and data is granted only as needed to perform a task.
• Defense in depth. We layer controls (network, application, data, identity).
• Secure by default. New systems and code follow secure configuration and review practices.

3. Data protection

3.1 Encryption in transit

All communication between the App, our backend, and third-party providers is encrypted using TLS 1.2 or higher. Public traffic is delivered over HTTPS via Cloudflare.

3.2 Encryption at rest

• Bank access tokens are encrypted at rest using AES-256-GCM before being written to the database. They are never returned in API responses.
• Encryption keys are stored as secrets in our deployment environment, never committed to source control, and rotated when warranted.

3.3 Data we do and do not store

• Stored (minimal): account identifier, encrypted bank access token, institution name/ID, connection status, subscription/entitlement state, device push tokens.
• Not stored: online banking credentials (never seen by us), bank transactions, balances, incomes, expenses, or other retrieved financial detail.

4. Identity and access management

• Multi-factor authentication (MFA) is required on all critical administrative systems (source control, cloud/hosting, DNS/network, payments, and the Plaid dashboard). We prefer phishing-resistant MFA (passkeys / hardware keys / biometrics) where available.
• Role-based access control (RBAC) governs access to production systems and the database.
• Centralized identity (SSO) is used for administrative tooling where supported.
• Periodic access reviews are performed to confirm access remains appropriate; access is revoked promptly when no longer required.

5. Infrastructure and network security

• Production services run in isolated containers; the database is not exposed to the public internet and is reachable only within the internal network.
• Public ingress is fronted by Cloudflare, providing TLS termination and network protection.
• Secrets and credentials are managed through environment-level secret storage, not in code.

6. Secure development and vulnerability management

• Dependency scanning: automated vulnerability scanning of backend dependencies (e.g. govulncheck and Dependabot) is enabled.
• Patching SLA: identified vulnerabilities are remediated within a defined timeframe — critical within 7 days, high within 30 days, others as prioritized.
• End-of-life monitoring: we track runtime, base image, and dependency versions and address end-of-life software.
• Code review: changes are reviewed before deployment to production.
• Secrets hygiene: .env and credential files are excluded from source control via .gitignore.

7. Third-party / vendor security

We rely on reputable providers and review their security posture:

• Financial data providers: Plaid.
• Infrastructure: our server host and Cloudflare.
• Payments: RevenueCat and the Apple App Store / Google Play.
• Messaging: Google Firebase.

We integrate using least-privilege credentials and the providers' recommended security practices.

8. Logging and monitoring

• Application and access logs are retained to support operations, troubleshooting, and incident investigation.
• Logs are scoped to avoid storing sensitive financial data.

9. Incident response

In the event of a suspected security incident or data breach:

1. Contain — isolate affected systems and revoke compromised credentials/keys.
2. Assess — determine scope, root cause, and data impact.
3. Remediate — patch, rotate secrets, and restore secure operation.
4. Notify — inform affected users and relevant authorities/partners (including Plaid) as required by law and contract, without undue delay.
5. Review — conduct a post-incident review and update controls.

Security concerns can be reported to contact@bmrteck.com.

10. Business continuity

• Database backups are performed and access to restore is restricted.
• Critical configuration and secrets are recoverable through our secret-management process.

11. Responsibilities and review

• The Founder & Security Lead owns this policy and the security program.
• This policy is reviewed at least annually and after material changes or incidents.
• All personnel and contractors are expected to follow it.

12. Remediation commitment (Plaid)

We commit to remediating any security gaps identified by our partners, including Plaid, within a reasonable timeframe as part of ongoing security diligence.

Contact: contact@bmrteck.com · BMRTECKBUSINESS LLC