How we protect your financial data

This policy states how BreathEasy Administrative Services LLC identifies, mitigates, and monitors information security risk for BreathEasy | Ledger, the accounting application published at ledger.breatheasy.net. It is written to be used, not filed away: every control named here has a named owner, a cadence, and a place where the work is recorded.

The scope covers the Ledger application and its database, the marketing site, the company email and domain accounts, the hosting and database platform, any financial account data received from a data aggregator such as Plaid, and the laptops and mobile devices used by anyone with access to production.

The policy applies to every employee, owner, and contractor who is granted access to company systems or customer data. Acceptance of this policy is a condition of that access.

The company is intentionally small. Where a control would normally be split between separate people, the Security Owner performs it and records the result so the work is reviewable after the fact.

Security risks are recorded in a risk register maintained inside the Ledger administration area. Each entry names the risk, the systems affected, the likelihood and impact, the control that reduces it, the owner, and the date it was last reviewed. The register is reviewed at least annually and whenever a significant change occurs, such as adding a new data source, a new vendor, or a new person with production access.

The register opens with the risks that matter most to this application:

Restricted and Confidential data are never copied to a personal device, a personal cloud account, or an unmanaged spreadsheet.

Access is granted on a least-privilege basis and only for a documented business reason. Every account is individually named; shared logins are prohibited.

• Role-based access control is enforced in the database itself, not only in the interface. Every table carries a workspace identifier and a row-level policy, so a request for another workspace's rows returns nothing regardless of what the client asks for.
• There are two role families: platform administrators, who operate the service, and workspace members, whose access is limited to the workspaces they belong to. Workspace roles range from viewer through owner.
• Privileged operations such as creating an administrator, resetting a password, or resetting demonstration data verify the caller's role on the server before doing anything.
• Access reviews are performed at least every six months. The administration area lists every account, its roles, its workspaces, its last sign-in, and the date it was last reviewed. Each review is recorded in the security review log.
• When a person leaves or changes role, their access is removed or reduced the same day. Removing the account revokes application access, active sessions, and role assignments together, so there is no partial de-provisioning to remember.
• Machine-to-machine access uses OAuth tokens or API credentials issued to the service, never a person's password. Credentials are held in the platform secret store and are rotated when a person with access departs or when a compromise is suspected.

Every account that can reach customer financial data uses multi-factor authentication. Three enrollment methods are offered so that no one is locked out of their own records:

• Passkey or hardware security key using WebAuthn, including platform authenticators such as Face ID, Touch ID, and Windows Hello. This method is phishing resistant because the credential is bound to the real site origin and will not sign a challenge from a lookalike domain.
• Authenticator application generating time-based one-time codes.
• Emailed one-time code, available as a fallback for ordinary sign-in only.

• Platform administrators must enroll a passkey. An emailed code alone is never sufficient for an administrator.
• A passkey or an authenticator application is required before a bank connection can be created or viewed, so the aggregator connection flow is always behind a factor that an emailed code cannot satisfy.
• Text-message codes are not offered. They are the weakest widely used factor and are excluded by design.
• Recovery codes are issued at enrollment. A locked-out account is restored by an administrator only after the person's identity is confirmed through a channel other than the one that failed.
• Passwords must be at least ten characters, are stored only as salted hashes by the identity platform, and are never reused across systems. Company email, domain registration, hosting, and database platform accounts also have multi-factor authentication enabled.

• All traffic between clients and servers uses TLS 1.2 or better. Plain HTTP is redirected, and modern cipher suites are negotiated by the managed edge platform.
• All data at rest is encrypted by the managed database and object storage platform using AES-256.
• Aggregator access tokens and account holder identity fields receive a second layer of encryption inside the application before they are written, using a key held in the platform secret store rather than in the database. A copy of the database alone therefore yields no usable tokens.
• Encryption keys are managed by the platform key service or the secret store. Keys are never committed to source control, never placed in client-side code, and are rotated when a compromise is suspected or when a person with access departs.
• Backups inherit the encryption of the platform that produces them.

• Automated security scanning runs against the application and its database configuration on every significant change and before each publish. Findings are triaged immediately.
• Automated dependency scanning identifies vulnerable third-party packages in the production build.
• End-of-life software and unsupported dependency versions are actively monitored and replaced before support ends where practical, and promptly after where it is not.
• All input from users and from external services is validated on the server. Database access uses parameterized queries. Output is escaped by the rendering framework; raw HTML injection is prohibited.
• Endpoints that accept external callbacks verify the caller's signature before processing any data.
• Secrets are never committed to source control. Published client code contains only publishable keys.

Identified vulnerabilities are remediated within the following windows, measured from the time the finding is confirmed:

Each remediation cycle is recorded in the security review log with the finding, the action taken, and the date closed. Where a finding is accepted rather than fixed, the acceptance, the reason, and the compensating control are recorded in the risk register and approved by the Security Owner.

Every laptop, desktop, or mobile device used to reach production or customer data must meet all of the following before it is used for that purpose:

• Full-disk encryption enabled (FileVault on macOS, BitLocker on Windows, device encryption on mobile).
• Automatic operating system and browser updates enabled, so security patches apply without waiting for a person.
• Screen lock requiring a password or biometric after no more than five minutes of inactivity.
• Reputable endpoint protection running with current definitions, and the built-in firewall enabled.
• No shared user profiles, and no administrative account used for day-to-day work where the operating system supports separation.
• Remote wipe or remote sign-out available, and used immediately if a device is lost or stolen.

Each device is recorded in a machine register inside the administration area with its owner, its operating system, and the date each requirement above was verified. Verification is repeated at least annually and after any operating system upgrade. A device that cannot meet these requirements is not used to access production or customer data.

There is no company data center. Physical security of servers and storage is provided by the managed hosting and database platforms. Paper records containing customer data are avoided; where one exists, it is stored in a locked location and shredded when no longer needed.

• Authentication events, administrative actions, and server errors are logged by the application and the identity platform.
• Bank connection events, including creation, synchronization, re-authentication, and disconnection, are recorded with the acting account and timestamp.
• Logs never contain passwords, authentication tokens, aggregator access tokens, or full account numbers.
• Logs are reviewed when an incident is suspected and at least quarterly as part of the periodic security review, and the review is recorded in the security review log.
• Application error reporting alerts the Security Owner to unexpected failures in production.

Before a vendor is given access to customer data, its security posture, published certifications, data handling terms, and breach notification commitments are reviewed and the decision is recorded. Only the minimum data necessary is shared. Vendors are re-reviewed annually alongside this policy.

The current subprocessor list is published at ledger.breatheasy.net/security. Customers are notified before a new subprocessor with access to customer data is added.

Where a customer chooses to connect a bank account through Plaid, the following controls apply specifically to that data:

• Access is read-only. The application requests transactions, balances, and account ownership. It does not request, and cannot perform, payment initiation, transfers, or any movement of money.
• Credentials are never seen by BreathEasy. The customer authenticates with their institution inside Plaid Link; the application receives only an access token.
• The customer must be signed in and past a passkey or authenticator factor before Link is surfaced.
• A consent screen naming the data requested, the purpose, the retention period, and a link to the privacy policy is shown before Link opens. The consent is recorded with the account, the timestamp, and the scopes agreed to.
• Access tokens are encrypted at the application layer before storage and are never returned to the browser, never logged, and never included in an export.
• Retrieved transactions enter the same review queue as an uploaded bank file. Nothing posts to the books without a person approving it.
• Identity data is used only to confirm account ownership at connection time. It is stored encrypted and minimized to what is necessary for that confirmation.
• The customer can disconnect at any time from inside the application. Disconnection revokes the item at Plaid and deletes the stored token and aggregator-sourced account data.
• Callbacks from Plaid are verified before any data is processed.

A security incident is any event that compromises, or is reasonably suspected to compromise, the confidentiality, integrity, or availability of company or customer data. Anyone who suspects an incident reports it to the Security Owner immediately at sales@breatheasy.net; there is no penalty for a report that turns out to be a false alarm.

Applicable state breach notification laws are followed, including notice to affected residents and to regulators where required. Every incident, including those closed as false alarms, is recorded in the security review log.

Data is kept only as long as it serves the purpose it was collected for, or as long as tax and accounting record-keeping requires. This schedule is reviewed at least annually as part of the policy review.

A customer may request access to, correction of, or deletion of their data at any time by emailing sales@breatheasy.net or by using the deletion controls inside the application. Requests are acknowledged within 5 business days and completed within 30 days. Deletion is real deletion of the records, not a hidden flag, subject only to backups aging out and to records we are legally required to keep.

• The managed database platform performs automated encrypted backups with point-in-time recovery.
• Recovery point objective: 24 hours. Recovery time objective: 24 hours for full service restoration.
• Restore capability is verified at least annually and the verification is recorded in the security review log.
• Application code and database schema are held in version control, so the service can be rebuilt from source and a database restore.
• If the Security Owner is unavailable, recovery credentials are held in a password manager with a documented emergency access procedure so the business can continue.

• All changes to the application are made in version control with a full history of who changed what and when.
• Changes are exercised in a preview environment before they are published to production.
• Automated security and dependency scanning runs before publishing; a critical finding blocks the release.
• Database schema changes are applied as reviewed, versioned migrations, never as ad-hoc edits to production.
• A change that materially affects security or the handling of customer data is recorded in the security review log.

• Everyone with access to customer data acknowledges this policy before access is granted and again every year. Acknowledgments are recorded with the person and the date.
• Contractors are bound by written confidentiality terms before access is granted.
• Security awareness covering phishing, credential handling, device hygiene, and incident reporting is refreshed annually at the same time as the acknowledgment.
• On departure, access is revoked the same day, company data is removed from personal devices, and shared credentials that the person could have known are rotated.

• An exception to this policy requires written approval from the Security Owner, a stated compensating control, and an expiry date. Open exceptions are listed in the risk register.
• Violation of this policy may result in loss of access, termination of employment or contract, and legal action where warranted.
• This policy is reviewed at least annually, and additionally after any significant incident, new data source, new vendor with access to customer data, or material change to the application.
• Each review is recorded with the reviewer, the date, and any changes made. The version history below is the record of those changes.