Compliance & Security

Last reviewed: September 1, 2026

This document describes Bitment's security architecture and control posture at a level appropriate for a vendor risk review, security questionnaire, or internal IT assessment. It is organized by control domain. Where a control is still in progress, we say so plainly. Bitment makes no certification claims in this document beyond what is explicitly stated.

1. Organization and Program

Bitment Inc. owns and operates the platform described in this document. Bitment's Chief Executive Officer is the executive owner of the security program, with day-to-day responsibility delegated to the engineering team.

SOC 2 audit in progress. Bitment is undergoing a SOC 2 audit against the AICPA Trust Services Criteria (security, availability, and related categories); the report will be available to customers on request once issued. Bitment does not represent any other third-party certification (HIPAA, ISO 27001, GDPR) unless and until a corresponding audit report exists.

Written information security policies covering acceptable use, access control, change management, vendor management, and incident response are maintained and are available to customers under NDA on request.

2. Infrastructure and Network Security

Every paying customer ("firm") is provisioned a dedicated, network-isolated AWS stack. Firms are not co-located in a shared database or application instance; each stack has its own virtual private cloud (VPC), its own database, and its own application host. Bitment also operates a shared stack of the same design for its own internal testing; it holds no customer data and no customer firm is provisioned on it.

No inbound SSH. No stack accepts direct SSH connections. Operational shell access, when needed, is performed exclusively through AWS Systems Manager Session Manager, which is identity-based, requires AWS IAM authorization, and is logged by AWS.

Segregation between customers. Because each firm's stack is a fully separate VPC, database instance, and application host, there is no shared compute or shared database boundary between customers to misconfigure. Segregation is structural (separate AWS resources), not solely logical (row-level access control within a shared database).

3. Data Protection

• In transit. All traffic to the platform is encrypted in transit via TLS, terminated at CloudFront and the Application Load Balancer.
• At rest, infrastructure level. The RDS database and the EBS data volume are encrypted at rest using AWS-managed encryption.
• At rest, application level. A defined set of sensitive credentials receives an additional layer of application-side encryption using AES-256-GCM, keyed by a 256-bit secret held in AWS Secrets Manager and scoped per individual or per firm (not a single global key). This covers: OAuth refresh tokens (Google, Microsoft), two-factor authentication (TOTP) secrets once that feature is released, Signal and Telegram linking secrets, and connected banking/payment credentials such as Plaid access tokens and payment processor API keys.
• What is not field-level encrypted. General business records, including client names, email addresses, and other personally identifiable information, are protected by the infrastructure-level encryption described above (encrypted database and disk), but are not individually encrypted at the field level within the database. We state this plainly rather than imply a stronger guarantee than exists today.
• Key handling. Application-layer encryption keys are provisioned per entity, stored in AWS Secrets Manager rather than in application code or configuration, and are never logged or displayed.
• Session security. Signed-in sessions use signed JSON Web Tokens stored in HttpOnly, host-scoped cookies, which are not accessible to page scripts and are not sent across unrelated hosts.
• Funds and custody. Bitment never holds, transfers, or controls customer or client funds or digital assets. All bank, exchange, wallet, Lightning, and payment-processor connections available in the platform are read-only. Bitment never holds private keys, seed phrases, or spending credentials, and cannot initiate a transaction on a customer's behalf. Payments on invoices are processed by the connected payment processor under that processor's own terms.

4. Identity and Access Management

Sign-in methods. Email and password, secure single-use email link ("magic link"), Google sign-in, and Microsoft sign-in. A single account may hold multiple verified email addresses.

Two-factor authentication. Coming soon. Time-based one-time password (TOTP) authenticator apps and SMS-based codes are planned as the supported second factors; until release, the secure email link provides inbox-verified sign-in.

Provisioning. Accounts are provisioned by invitation: firms and their members are staged and invited rather than self-registering, with the exception of the self-serve bookkeeping product and accepting a pending team invitation, both of which support self-serve sign-up.

Firm roles and permissions. Each firm defines roles for its team members, with per-resource sharing grants layered on top so specific clients, files, or projects can be scoped to specific people beyond their base role. Every firm is required to retain at least one owner at all times.

Least privilege for AI agents. AI agents do not have standing write access. Actions that change data are represented as proposals that a human team member must approve before they take effect. A time-limited "elevation" exists for specific, trusted, pre-approved flows, scoped in time and function rather than granted permanently.

Client portal isolation. Client and contact sessions are locked to a single client record. A client portal user can see only the files, signature requests, forms, and bookkeeping data their firm has explicitly shared with them, and cannot browse other clients' data or the firm's internal workspace.

Group-less operator model. An operator who works across multiple firms does not "switch workspaces" with a single session-scoped permission set. Instead, every request is checked server-side against that individual's actual current memberships, so access reflects real-time membership rather than a session that could go stale.

Engineer access. Bitment engineers do not have standing SSH access to any customer environment. Operational access, when required, is through AWS Systems Manager Session Manager only, and is bounded by AWS IAM policy.

Diagnostics / impersonation. By accepting the Terms of Service and using the Services, a customer authorizes Bitment support and engineering personnel to access the customer's account and workspace, including by viewing the Services as a specific Authorized User, solely to diagnose and resolve issues, provide support, and maintain security. Bitment limits this access to what is necessary for those purposes. An individual user may additionally control this access through the in-product Diagnostics setting in their account, and may revoke it at any time. Current limitation, stated honestly: this access does not currently generate its own dedicated audit log entry. This is a known gap and is on our roadmap to close.

Permission audit limitation, stated honestly: Bitment currently records who granted each specific permission at the time it was granted. A complete, queryable history of every permission change over time (a full "who changed what, when" audit log) is a planned enhancement, not yet available. We do not represent that Bitment maintains a full audit trail of every data interaction today.

5. AI Governance

• Human-in-the-loop by default. Data-changing AI actions are represented as proposals. A human reviews and approves before the action executes.
• Permission-gated tools. The set of actions available to an AI agent is scoped by the same permission system that governs human team members; an agent cannot exceed the access of the context it operates in.
• Bring-your-own model provider. Each firm connects its own credentials for the AI provider it selects (Anthropic, AWS Bedrock, OpenRouter, or a self-hosted Ollama instance). Bitment routes requests to the provider the firm chose and does not substitute its own provider behind the scenes.
• No training on customer data. Bitment does not use customer conversations, files, or agent activity to train any AI model.
• Sandboxed code execution. Where an agent runs code as part of completing a task, execution is isolated to a sandboxed environment scoped to that task.
• Spend visibility and limits. Every AI request is recorded against a token usage and cost ledger, giving firms visibility into consumption; usage-based limits are configurable by the firm.

6. Application Security

• The production application is deployed as a single compiled binary embedding the web frontend, reducing the deployed attack surface compared to a multi-service deployment.
• The client application communicates with the backend through a typed API client generated directly from the backend's own API definitions, reducing the risk of request/response shape mismatches that could otherwise create validation gaps.
• Every API request passes through per-request authentication and authorization middleware before reaching business logic.
• Input validation is enforced at the API boundary for structured requests.
• Third-party dependency management: dependencies and operating system packages are updated on a regular cadence, critical vulnerabilities are prioritized for prompt remediation, and infrastructure is deployed from version-controlled templates.
• Desktop applications (Mac and Windows) are code-signed and notarized with Apple's notarization service before distribution.
• Inbound webhooks from third-party services that support signature verification, including Plaid, Twilio, and Stripe, are verified using each provider's signature scheme before being processed.

7. Logging and Monitoring

• System logs. The application emits structured logs at debug, info, warn, and error levels, reviewed by Bitment engineering for operational monitoring and incident diagnosis.
• Network flow logs. VPC Flow Logs are retained for 30 days per stack.
• Feedback and incident intake. Users can submit feedback, including attachments, directly through the product, which reaches Bitment's engineering backlog for triage.
• What is not yet logged. Bitment does not yet provide a complete, customer-facing audit log of every individual data read or write, nor a dedicated audit log entry for each use of the support "view as" diagnostics capability. Both are described honestly above and are roadmap items.

8. Backup and Recovery

• Database backups. RDS automated backups are retained for 7 days, with point-in-time recovery available within that window.
• Storage snapshots. The encrypted EBS data volume follows a defined snapshot lifecycle policy.
• Teardown. A final snapshot is taken as part of decommissioning a stack.
• Recovery objectives. Recovery objectives are defined per stack and available to customers on request. Automated daily database backups with 7-day point-in-time recovery, together with volume snapshots, support recovery.

9. Vulnerability and Incident Management

• Vulnerability management process. Dependencies and operating system packages are updated on a regular cadence, critical vulnerabilities are prioritized for prompt remediation, and infrastructure is deployed from version-controlled templates.
• Incident response process. Incidents are classified by severity and handled per an internal runbook.
• Customer notification timeline for a confirmed incident affecting customer data. Bitment will notify affected customers of a confirmed security incident involving their Customer Data without undue delay, and no later than 72 hours after confirmation.

10. Vendor and Subprocessor Management

The table below lists services that may process data on Bitment's or a firm's behalf, the category of data involved, and the hosting region where known. Entries marked "firm-connected" are used only if and when a specific firm chooses to connect them.

Vendor-specific compliance documentation is available on request.

11. Business Continuity

• Infrastructure redundancy. Database high-availability configuration is available per stack on request.
• Disaster recovery testing cadence. Restore procedures are exercised as part of stack provisioning and are reviewed at least annually.
• Communication plan during an extended outage. Service notices are sent to customer administrators by email (contact@bitment.co for inquiries).

12. Data Lifecycle

• Customer-controlled deletion. Users and firms can delete files, AI conversations, and synced messaging threads (with purge-and-exclude for messaging integrations), and can disconnect any third-party integration at any time.
• Firm deletion. A firm owner can delete a firm entirely; this cascades to delete all data owned by that firm.
• Export. Customer Data can be exported through in-product download and export tools (files, reports, statements, transcripts, conversation PDFs, CSV exports) or by request to contact@bitment.co.
• Post-termination retention. Following contract termination, Customer Data remains available for export for 30 days, after which Bitment deletes it from production systems, absent a longer legal retention requirement or an active legal hold. Backups age out on the 7-day schedule described in Section 8.

13. Compliance Mapping

Bitment's controls map to the following frameworks and regulatory concerns. SOC 2 audit in progress; the other rows describe how Bitment supports a customer's own compliance program and are not certifications.

For accounting and tax firms specifically: Bitment's architecture, including per-firm network isolation, encryption practices, and access controls, is intended to support a customer firm's own compliance obligations, including those arising under the Gramm-Leach-Bliley Act Safeguards Rule and the practices described in IRS Publication 4557 (Safeguarding Taxpayer Data). Bitment does not itself certify compliance with GLBA or Publication 4557 on a firm's behalf; each firm remains responsible for its own compliance program, of which Bitment's platform is one component.

14. Responsible Disclosure

If you believe you have discovered a security vulnerability affecting Bitment, please report it to contact@bitment.co. Please include enough detail to reproduce the issue and avoid accessing or modifying data beyond what is necessary to demonstrate it. We ask that you give us a reasonable period to investigate and remediate before any public disclosure.

Bitment will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give Bitment reasonable time to remediate a reported issue. We will acknowledge a report within 5 business days.

Contact

For security or compliance questions related to this document, contact:

Bitment Inc. contact@bitment.co 1521 Concord Pike, Suite 201, Wilmington, DE 19803