Security Policy

LedgerFlow holds the financial record of your business, so security is treated as a product requirement rather than an add-on. Controls are designed around least privilege, defence in depth and verifiable audit trails.

This document describes the controls in place today. It is reviewed at least annually and whenever we make a material change to our architecture.

All traffic between your browser and our infrastructure is encrypted using TLS 1.2 or higher. Older protocols and weak cipher suites are disabled.

Data at rest — including the primary database, backups and uploaded documents — is encrypted using AES-256 managed keys.

Every record in LedgerFlow carries a business identifier, and access is enforced at the database layer through row-level security policies rather than only in application code.

A single login may belong to several businesses. Switching business context re-scopes every query; there is no path that returns records across businesses you do not belong to.

Users authenticate with email and password over an encrypted session, and sessions expire after a period of inactivity.

Within a workspace, roles determine what a member can see and do — for example, who may approve a bill, post a journal entry or lock an accounting period.

Our own staff access to production is restricted to named engineers, requires multi-factor authentication, and is logged. It is granted only for support or incident response and revoked when no longer required.

All financial modules post through a single double-entry journal funnel. Posted entries are immutable — corrections are made by reversal, never by silent edit.

Privileged actions (approvals, reversals, period locks, member and role changes) are written to an append-only audit log with actor, timestamp and before/after context.

The application runs on managed, edge-deployed infrastructure with a managed Postgres database. There are no long-lived servers holding customer data on local disk.

Changes are peer-reviewed and deployed through an automated pipeline. Database changes are applied as versioned migrations, allowing every schema change to be traced.

Secrets and credentials are held in a managed secret store, never in source control.

The database is backed up on a continuous basis with point-in-time recovery, and backups are encrypted and rotated on a fixed schedule.

Restore procedures are tested periodically so that recovery objectives can be met in the event of data loss.

Application and infrastructure telemetry is monitored for errors, anomalous access and availability problems.

If a security incident affects your data, we will investigate, contain and remediate it, and notify affected workspace owners without undue delay — and, where the Data Protection Act, 2019 requires it, the Office of the Data Protection Commissioner.

We use a small number of sub-processors for hosting, database, email delivery and payments. Each is assessed for security posture and bound by contractual confidentiality and security obligations.

A current list of sub-processors is available on request and is also referenced in our Data Processing Agreement.

Keep credentials confidential, use a strong unique password, review workspace membership regularly, and remove members who leave your organisation.

Grant approval and posting rights only to people who need them, and use period locks at month end to protect closed books.

We welcome responsible disclosure. Email security@ledgerflow.africa with steps to reproduce; we acknowledge reports within two business days and will keep you updated through to resolution.

Please do not test against other customers' data, degrade the service, or publicly disclose an issue before we have had a reasonable opportunity to fix it.