Incident Response Plan
Balance On Hand treats any unauthorized access to its systems seriously. This page explains how we classify security incidents, how we respond, and why our encrypted backup design is intended to reduce user harm even if a security incident occurs.
Our goal: Even if a security incident occurs, Balance On Hand is designed to prevent it from becoming a harmful or actionable data breach. Budget backups are encrypted before they reach our servers, and recovery phrases and decryption keys are designed to never be stored server-side.
How we classify incidents
Not all security events are the same. Balance On Hand classifies incidents into three categories based on what was accessed and the potential for user harm:
Security incident
Someone accessed something they should not have. For example, a database was copied, but all budget data is encrypted and no identifying fields are present. The system was accessed, but the attacker should not have obtained readable or actionable user information.
Privacy incident
Some user-related metadata was exposed. For example, account identifiers, timestamps, subscription status, payment provider references, or log data. The attacker may have obtained limited information about users, but should not have obtained readable financial details.
Harmful or actionable data breach
The attacker obtained enough information to target or harm a user. For example, email addresses combined with bill names, income dates, account balances, creditor details, or recovery phrases. This is the most serious category and requires urgent notification.
Severity levels
| Level | Example | User harm risk | Notify users? |
|---|---|---|---|
| Level 0 | Failed attack, no access | None known | No |
| Level 1 | Database accessed, only encrypted backups copied, no keys or recovery phrases | Low | Maybe transparency notice, depending on assessment |
| Level 2 | Encrypted backups + account metadata exposed (such as account identifiers or payment references) | Moderate | Likely yes |
| Level 3 | Decryption keys or recovery phrases exposed, or decrypted budget data exposed | High | Yes, urgent |
| Level 4 | Active account takeover, payment abuse, or identity risk | Critical | Yes, urgent + law enforcement and regulators |
Response procedure
Balance On Hand follows a structured response process when a security incident is identified:
- Preparation: Maintain security practices, data minimization, and encrypted backup design to reduce the impact of potential incidents before they occur.
- Detection and analysis: Investigate promptly to determine what systems and data were affected, how access occurred, and what information may have been involved.
- Containment: Stop unauthorized access and limit further exposure as quickly as possible.
- Eradication and recovery: Remove the threat, restore affected systems, and verify the integrity of remaining data and services.
- Post-incident improvement: Review what happened, identify improvements, update security practices and policies as needed, and apply lessons learned.
Notification standards
Balance On Hand will notify affected users when required by law or when we believe notice is appropriate based on what was accessed and the potential for user harm.
- Notifications depend on whether readable or actionable data, account metadata, keys, logs, or payment-related identifiers were involved.
- Balance On Hand follows applicable state and federal notification requirements.
- At meaningful user volume, Balance On Hand will maintain awareness of multi-state notification obligations.
- When notification is warranted, Balance On Hand will communicate clearly about what happened, what data was involved, what we did to address it, and what users should do next.
Why encrypted backups are designed to reduce user harm
Balance On Hand encrypts budget backups on the user's device before they reach our servers. The recovery phrase and decryption key are designed to never be stored server-side. This means that if an attacker copies the backup database, they should not be able to read the budget data without the user's recovery phrase.
However, metadata such as account identifiers, timestamps, and subscription status may still be present in the database. Balance On Hand treats any unauthorized access seriously because metadata can still matter, even when the core financial data should not be readable.
What a stolen database would likely reveal
Based on Balance On Hand's current architecture and prior security review, the following table describes what an attacker would likely find if they obtained a copy of the backup database:
| Data type | Risk level |
|---|---|
| Encrypted backup payload | Low — designed to not be readable without the user's recovery phrase |
| Account identifiers | Low to moderate |
| Backup timestamps | Low |
| Subscription status | Low to moderate |
| Payment provider references | Moderate |
| Readable budget data | Designed to be unavailable |
| Recovery phrase or decryption key | Designed to never be stored |
As part of a prior security review, user email was removed from backup records and server response data was trimmed to further reduce the information available in the database.
Our commitment
Balance On Hand cannot prevent every possible security incident, but the system is designed so that a stolen backup database should not expose readable budget data or enough information to financially target users. We still treat any unauthorized access seriously because account metadata can matter.
If Balance On Hand discovers unauthorized access to systems that may affect user data, we will investigate promptly, contain the issue, determine what information was involved, and notify affected users when required or when we believe notice is appropriate.
This page is provided for general informational purposes. Balance On Hand uses reasonable security measures but does not guarantee that any system is completely immune to unauthorized access. Security practices and this incident response plan are reviewed and updated as needed. For questions, please visit the contact page. Last updated: 2026.