Access Controls Policy

This policy states how BreathEasy Administrative Services LLC grants, reviews, and removes access to the systems and data behind BreathEasy | Ledger, the accounting application published at ledger.breatheasy.net. It is a companion to the Information Security Policy and Procedures and carries the same authority.

The scope covers the Ledger application and its user roles, the production database, the hosting and deployment platform, the domain, DNS, and email accounts, any financial data aggregation service such as Plaid, the source code repository, and the laptops and mobile devices used to reach any of those systems.

The policy applies to every owner, employee, and contractor granted access to company systems or customer data, and to every automated identity such as a service account, deployment token, or scheduled job. Acceptance of this policy is a condition of that access.

• Least privilege. Every person and every automated identity receives the narrowest set of permissions that allows the work to be done, and nothing beyond it.
• Need to know. Access to customer financial records is granted only when a specific support, billing, or legal obligation requires it, and the reason is recorded.
• Deny by default. New tables, routes, and storage locations start closed. Access is opened deliberately, never inherited by accident.
• Separation of duties. Administrative capability in the application is separated from ordinary bookkeeping work, and privileged database credentials are never embedded in code that runs in a browser.
• Individual accountability. Every human account is tied to one named person. Shared logins are prohibited.
• Access is time-bound. Any elevated or temporary access carries an expiration date and is removed when the reason ends.

Ledger uses role-based access control. Roles are stored in dedicated database tables, never on a user profile record, and every role check runs on the server. The application never trusts a role value supplied by the browser.

Separation between customer workspaces is enforced in the database itself, not only in application code. Row level security is enabled on every table that holds customer data, and each policy resolves the caller's identity from the verified session token and matches it against that caller's workspace membership.

• Every customer table carries a workspace identifier that is set by a database trigger, so a client cannot write a record into another workspace by tampering with a request.
• Role lookups run through security-definer database functions, which prevents a user from editing their own permissions and prevents recursive policy loops.
• Table privileges are granted explicitly to the signed-in role and to service identities. No blanket privileges are granted to anonymous callers on customer data.
• Privileged database credentials that bypass row level security are used only in server-side code, after the caller has been authenticated and authorized, and are never shipped to the browser.
• Public marketing endpoints are separated from authenticated application endpoints, and public endpoints do not return customer records.

• Every account authenticates with a unique email address and a password of at least ten characters, checked against a breached-password screen at the platform layer.
• Multi-factor authentication is required for all administrative access. The preferred and default factor is a passkey, which is phishing resistant and bound to the device.
• Authenticator app codes are supported as a secondary factor. Emailed one-time codes are available for ordinary members but are not accepted alone for platform administrators or for changes to bank connections.
• Sessions expire on inactivity, tokens are refreshed with rotation, and signing out invalidates the session on the server.
• Passwords and factor secrets are never sent by email or chat. Password resets are performed with a single-use, time-limited link sent to the address on record.
• Automated identities authenticate with scoped tokens or keys held in the platform secret store, never with a human account.

• The Access Owner reviews every platform administrator, every service identity, and every third-party integration once per quarter.
• Workspace user lists are confirmed with each customer administrator at least once per year, and any time a customer reports a staffing change.
• Each review records the date, the reviewer, the accounts examined, and the accounts removed or re-scoped. The record is kept in the security program area of the admin portal and retained for at least three years.
• Any account that cannot be tied to a current person and a current business reason is disabled during the review, not after it.

• Application secrets, API keys, and aggregator credentials live in the platform secret store and are injected at runtime. They are never committed to source control and never written to logs.
• Access tokens for financial data aggregation are encrypted at the application layer with a key held separately from the database, so a database copy alone does not yield a usable token.
• Personnel use a password manager for all work credentials. Reuse of a work password on a personal service is prohibited.
• Secrets are rotated on personnel departure, on suspected exposure, and on the schedule stated in the Information Security Policy.
• Service role and administrative database keys are restricted to server-side execution paths and are not retrievable through the application interface.

• Administrative access is performed only from company-registered devices listed in the machine register, with full-disk encryption, automatic screen lock, current operating system patches, and endpoint protection enabled.
• There is no direct network access to production infrastructure. All administration happens through authenticated provider consoles and the application's own administrative interface over TLS.
• Public or untrusted networks require a VPN for administrative work.
• Personal devices may be used for ordinary email and messaging only, with device passcode and remote wipe enabled. They are not permitted for administrative access.

• Sign-ins, failed sign-in attempts, factor enrollments, password changes, and administrative actions are logged with a timestamp and the acting account.
• Changes to roles, memberships, and bank connections are recorded and are visible to the Access Owner.
• Logs are reviewed on a monthly cadence and immediately following any suspected incident. Anomalies such as repeated failures or an unexpected administrative action open an incident record.
• Log records are retained for at least twelve months and are protected from alteration by ordinary application users.

• Vendors receive access only through their own authenticated platform, scoped to the function they perform, and are recorded on the subprocessor list published on the trust page.
• Financial data aggregation is read-only. Ledger can read transactions, balances, and account ownership. It cannot initiate payments or move funds.
• A customer's bank connection is established by the customer through the aggregator's own interface. Ledger never receives or stores bank usernames and passwords.
• Support access to a customer workspace is used only to resolve a specific request, is logged, and ends when the request is closed.
• Disconnecting a bank connection deletes the stored token and the synced data associated with it.

The access model described above is a zero trust model. No request is trusted because of its network origin, every request is authenticated on the server and authorized again at the data layer, identity and device are re-verified during a session rather than only at sign in, and the environment is segmented into trust zones that must be crossed by an explicit authorization decision.

The full framework, including the identity, device, network, application, and data pillars, the micro-segmentation map, the continuous monitoring practices, and the control status roadmap, is published separately as the Zero Trust Architecture Policy at ledger.breatheasy.net/security/zero-trust.

Any deviation from this policy requires written approval from the Access Owner, a stated compensating control, and an expiry date. Approved exceptions are recorded in the risk register and revisited at each quarterly review.

Violation of this policy may result in immediate removal of access and, for employees and contractors, termination of the relationship. Suspected unlawful activity is referred to the appropriate authorities.

This policy is reviewed at least annually and after any significant change to systems, staffing, or regulatory obligations. Questions and reports go to sales@breatheasy.net.