Information Security Policy and Procedures

This policy sets the rules LedgerDude, LLC follows to protect the information trusted to us. It covers the LedgerDude web application, its database and file storage, the connected accounting and banking integrations, the third-party services we rely on, and every person who is given access to those systems, including owners, employees, and contractors.

It applies to all client information we handle: business and contact details, bookkeeping records, uploaded documents and receipts, accounting data retrieved from connected systems, and financial account and transaction data retrieved through our data providers.

The Owner of LedgerDude, LLC serves as the Security Officer and is accountable for this policy: approving it, reviewing it at least once a year, granting and removing access, reviewing security findings, and handling incidents. Security questions and reports go to security@myledgerdude.com, which is monitored during business days.

Everyone who is given access is responsible for following this policy, protecting their own credentials, and reporting anything suspicious to the Security Officer without delay.

We identify, reduce, and watch the security risks that matter to a bookkeeping platform: unauthorized access to client financial data, exposure of credentials or access tokens, incorrect or unauthorized changes to a client's books, loss of data, and weaknesses in the third-party services we depend on.

How we operate that in practice:

• Automated security scanning runs against the application and its database access rules, and findings are reviewed and either fixed or documented with an accepted reason.
• Dependency vulnerability scanning runs on the codebase, and flagged packages are updated.
• Access to production data is reviewed when anyone joins or leaves, and at least once a year otherwise.
• Before a new third-party service is connected, we confirm what data it will receive and that it is appropriate for financial data.
• The Security Officer reviews this policy and its controls at least annually.

• Named accounts only. Every person has their own account. Shared or generic logins are not permitted.
• Least privilege. Access is granted only to what a role requires. Staff roles (platform owner, admin, reviewer, bookkeeper) and client roles are separate, and a client organization's users can reach only their own organization's records.
• Enforced in the database, not just the interface. Row-level security is enabled on the tables holding client data, so access rules are enforced by the database itself on every request rather than by application screens alone.
• Privileged actions are gated. Roles are stored separately from user profiles so they cannot be changed by the user they describe, and role checks are performed on the server.
• Phishing-resistant multi-factor authentication. Every staff member must pass a FIDO2 / WebAuthn passkey check, with device biometric or PIN verification required, before the staff workspace renders anything at all. The passkey is bound to our domain, so a look-alike phishing site cannot obtain a usable credential, and nothing is typed that could be captured or replayed. Staff cannot turn this off. Sign-in sessions are additionally elevated with an authenticator-app code, and a code alone is never enough to reach client financial data.
• The same standard applies to clients. Client accounts must pass the same passkey check before any bank or accounting connection screen opens. Ten one-time backup recovery codes, stored only as hashes, prevent lockout if a device is lost. Full detail is published in our phishing-resistant MFA attestation.
• Vendor consoles. MFA is also required on the administrative accounts used to reach the hosting platform, the production database and secret storage, the source repository, the payment processor, and the accounting integration developer account. Passwords are checked against known-breached password lists.
• Removal of access. Access is revoked on the last day of an engagement or employment, and immediately if credentials are suspected of being compromised.
• No standing production console access for others. There is no shared server login; production data is reached only through the application's authorized paths or the platform account held by the Security Officer.

• In transit. All traffic between browsers and our servers is encrypted with TLS 1.2 or higher. Plain HTTP requests are redirected to HTTPS. Connections to our database, storage, and third-party APIs also travel over TLS.
• At rest. The production database and file storage are encrypted at rest with AES-256 by our hosting provider.
• Extra protection for credentials and tokens. Third-party access tokens are encrypted a second time with AES-256-GCM before being stored, using a key held in managed secret storage outside the database. Secrets and API keys are never committed to the codebase or exposed to browsers.
• Documents. Uploaded documents and receipts are stored in private buckets with no public links. They are reachable only through short-lived, authorized links issued to a user permitted to see that organization's files.

• All application and database changes are version-controlled and reviewed before release.
• Database structure and access-rule changes are applied as reviewed migrations, not ad-hoc edits to production.
• Automated static security review and database access-rule review run against changes before release, and type and test suites must pass.
• Server-side input validation is applied to submitted data, and privileged operations verify the caller's role on the server before acting.
• Test and demonstration work uses sandbox or sample data. Production client data is not copied into demonstration environments.

• Dependency vulnerability scanning of the codebase, with flagged packages updated.
• Automated application and database security scanning, with findings triaged by the Security Officer.
• Managed platform patching: the hosting platform, runtime, and database are maintained by our provider, and available updates are applied.
• Endpoint hardening: company laptops used to access production run supported operating systems with automatic security updates, full-disk encryption, a screen lock, and endpoint protection enabled.
• Remediation targets: critical findings are addressed within 7 days, high within 30 days, and medium or low within 90 days, or documented with an accepted reason and a compensating control.

We use a small set of established providers to run the platform: cloud application hosting, a managed PostgreSQL database and file storage, a payment processor, an accounting system integration, a financial data provider for bank connectivity, an email delivery provider, and an AI provider used to draft suggestions for staff review. Each receives only the data needed for its function, is accessed over encrypted connections with credentials held in managed secret storage, and is reviewed before connection.

We do not sell client data, and we do not share it with anyone other than these providers except at your direction or where the law requires it.

Clients accept our Terms of Service and Privacy Policy when they create an account. Connecting an outside accounting or financial account is always started by the user, who is told what will be retrieved and why before authorizing it, and can disconnect at any time. We collect and use data only for the bookkeeping services being provided.

We keep information only as long as it is needed for the service or required by law, and we review this schedule at least once a year:

• Bookkeeping and transaction records: retained for 7 years from the end of the applicable tax year, to meet financial record-keeping expectations, then deleted.
• Uploaded documents and receipts: retained for the life of the engagement, then deleted within 90 days after the account is closed unless they are part of a record we must keep under the 7-year rule above.
• Financial account and connection tokens: deleted promptly when a connection is removed or the account is closed.
• Account and contact information: deleted or anonymized within 90 days after the account is closed.
• Security and audit logs: retained for at least 12 months to support investigations.
• Backups: encrypted and retained on a rolling basis by our hosting provider; deleted records age out of backups within that window.

A client may request deletion or a copy of their data by emailing security@myledgerdude.com. We acknowledge requests within 5 business days and complete them within 30 days, except for records we are required to retain, which we will identify in our response.

The platform records who did what and when for the actions that matter: sign-ins, changes to client records, document access, approvals, and any change written back to a connected accounting system. Changes to a client's books require a person to review and approve them before they are sent, and higher-risk changes require a second approver. Logs are reviewed when something looks wrong and as part of periodic access review.

The production database is backed up automatically by our hosting provider with point-in-time recovery, and backups are encrypted. Recovery is the responsibility of the Security Officer, who verifies that backups are present and restorable at least annually. Our target is to restore service within 24 hours and to lose no more than 24 hours of data in a worst-case event.

Anyone who suspects a security problem reports it to security@myledgerdude.com immediately. The Security Officer then:

1. Confirms and records the report, with the time it was received.
2. Contains the issue — revoking credentials, disabling access, or pausing an integration.
3. Assesses what data and which clients are affected.
4. Notifies affected clients and any required partners or providers without undue delay, and in any event within 72 hours of confirming an incident involving their data.
5. Fixes the root cause and records what changed to prevent a repeat.

Security researchers may report suspected vulnerabilities to security@myledgerdude.com. We acknowledge reports within 5 business days and will not pursue action against good-faith research that avoids privacy violations, data destruction, and service disruption.

Everyone with access reviews this policy when granted access and at least once a year afterward. Client data may be accessed only to perform the work, never copied to personal accounts or unmanaged devices, and never shared outside an approved channel. Failure to follow this policy can result in access being removed and the engagement ending.

LedgerDude, LLC
8628 Alnwick Drive
Odessa, TX 79765
Security contact: security@myledgerdude.com