Security and controls

Security claims should be specific enough to verify.

LedgerHQ combines signed-in access, organization and company scope, role permissions, encrypted transport, protected integration secrets, confirmation gates, and audit records across supported workflows. This page describes current controls without implying an unearned certification.

Scoped access

Protected workflows resolve organization or company scope and current membership before returning or changing accounting data.

Protected secrets

Supported provider and integration secrets use authenticated encryption at rest and are not returned through normal responses.

Audited actions

Supported accounting and administrative changes write organization-scoped audit or activity evidence.

LedgerHQ Chart of Accounts with account types and account rows
The chart of accounts provides the accounting spine for coding and reports.Real product view
01

Authentication, roles, and company access

LedgerHQ requires authenticated access for the firm and accounting workspace. Protected REST and agent workflows resolve an authorization context that includes the organization, role, and relevant permission before proceeding.

Company access remains a separate boundary inside a firm. A firm-wide view does not mean every user or action can silently reach every company's books.

  • Signed-in protected workspaces
  • Current membership checks
  • Role and custom permission enforcement
  • Company selection and access validation
02

Organization and company data boundaries

Accounting queries and writes are expected to be organization-scoped after access is resolved. LedgerHQ's API and MCP conventions require protected routes and tools to use that scope rather than relying on a record identifier alone.

Public token workflows, such as supported invitation or connection tasks, are kept outside the indexable marketing surface and return noindex signals. Their token remains a credential and should not be shared.

  • Organization-scoped queries
  • Company-scoped accounting services
  • Noindex treatment for token and private routes
  • Separate support-access auditing where supported
03

Transport and stored-secret protection

The hosted site enforces HTTPS transport policy through strict transport security headers, and the privacy policy states TLS protection for data in transit.

Supported stored integration and provider credentials use AES-256-GCM authenticated encryption. Responses and administrative views expose status or limited metadata rather than returning the underlying secret.

  • TLS for data in transit
  • HSTS response policy
  • AES-256-GCM for supported stored secrets
  • Write-only or secret-free credential responses
04

Confirmations, validation, and audit evidence

Sensitive, destructive, externally visible, billing-related, integration-changing, or unusually broad actions can require explicit confirmation or a short-lived confirmation token. Accounting services also validate conditions such as scope, posting state, warning evidence, and period locks.

LedgerHQ stores organization-scoped audit records for supported actions, and Tally work can also leave job, action, approval, or activity evidence. Retention and exact fields vary by workflow and package.

  • Explicit user intent for sensitive actions
  • Short-lived confirmation tokens in selected workflows
  • Service-level accounting validation
  • Organization-scoped audit and activity records
05

Security is a shared operating responsibility

Firms remain responsible for choosing appropriate staff access, protecting sign-in methods and token links, reviewing AI authority, disconnecting stale integrations, and investigating unexpected activity.

Security questions or suspected issues should be sent through LedgerHQ support so the relevant account, company, action, and time window can be investigated without exposing private details publicly.

  • Use least-necessary staff and company access
  • Review Tally duties and authority
  • Protect invitation and task links
  • Report unexpected activity promptly

How the workflow moves

A visible sequence, not a black box.

The exact action depends on permissions, company context, and the evidence available. The workflow stays inspectable from intake through review.

  1. 1A user or approved agent authenticates through a supported access path.
  2. 2LedgerHQ resolves the organization, company, role, and required permission.
  3. 3The service validates the requested operation and any confirmation or safety conditions.
  4. 4The result is recorded in the accounting workflow with available audit evidence.

Human control

LedgerHQ uses layered application controls, but no system can promise absolute security. Firms should maintain appropriate access, device, credential, and review practices.

Product boundary

LedgerHQ does not claim SOC 2, ISO 27001, PCI certification, bank-grade certification, or another third-party security status on this page.

Questions

What firms usually ask.

Is data encrypted in transit?

LedgerHQ states TLS protection for data in transit and sends a strict transport security policy on hosted responses.

How are supported integration secrets stored?

Supported integration and AI-provider secrets use AES-256-GCM authenticated encryption and normal application responses expose only limited status metadata rather than the secret.

Does every action appear in one universal audit log?

No such blanket claim is made. Supported workflows write organization-scoped audit, activity, job, action, approval, or accounting evidence; the exact record depends on the workflow.

Is LedgerHQ SOC 2 certified?

LedgerHQ does not claim SOC 2 certification on this page. Ask support for the current security and compliance posture needed for your review.