Skip to content
VaretIQVaretIQ

Security & trust

Specifics, not badges.

Financial records are the last place for vague reassurance. Here is what VaretIQ does structurally to protect your books — and what we are not claiming.

VaretIQRoles & Permissions
6 rolesSegregation enforced
RoleLedgerApprovalsCloseSettings
OwnerFullApproveLock / reopenFull
ControllerFullApproveLockLimited
BookkeeperPost entriesPrepare onlyPrepareNone
Outside CPAAdjust (attributed)NoneSign offNone
ManagerRead own locationApprove to limitNoneNone
Document viewerNoneNoneNoneNone

A person who prepares an entry cannot also approve it under the default configuration.

Roles & Permissions interface preview. No live financial data is shown.
Every permission
Role-based

By module, action, and entity.

Audit log
Append-only

Entries cannot be edited or removed.

Period reopenings
Recorded

With a reason and a person.

Professional access
Client-held

Granted and revoked by you.

Design position

The strongest control is a system that cannot quietly change your books

VaretIQ will suggest, flag, rank, and draft. It will not post to your general ledger on its own. Every ledger change is attributable to a person, carries a timestamp, and remains visible after the fact — including changes made by an outside accountant.

That is a deliberate constraint on the software rather than a setting you have to find and enable.

Structural controls

  • Separate credentials for every person — no shared logins
  • Multi-factor authentication required before the financial workspace opens
  • Step-up (AAL2) authentication enforced for sensitive actions
  • Preparer and approver separation on entries and bills
  • Approval thresholds by amount, vendor, or account
  • Closed periods locked; reopening requires a role and a reason
  • Scoped, expiring access for outside professionals and lenders
  • Document sharing that never exposes the ledger
  • Complete, exportable audit log of every change

Implemented controls

What is actually in place

Specific, verifiable controls in the platform, the data layer, and the delivery pipeline.

Identity and access

  • Separate credentials per user — no shared logins
  • MFA required before the financial workspace loads
  • AAL2 step-up authentication for sensitive actions
  • Role-based access by module, action, and entity
  • Tenant and legal-entity isolation on every request
  • Accounting data reachable only through private, permission-checked server procedures

Data protection

  • Sensitive fields protected with AES-256-GCM (A256GCM) envelope encryption
  • Secrets isolated in Supabase Vault, never in application code
  • Private document storage with authorized, scoped retrieval
  • Tamper-evident hashing of audit events
  • Period locking, with every reopening recorded against a person and a reason
  • Complete, exportable audit log of ledger changes

Pipeline and runtime

  • CodeQL static analysis on the codebase
  • Gitleaks secret scanning
  • Dependency vulnerability scanning
  • Trivy scanning for high and critical findings
  • Continuous security posture monitoring
  • Automated safe containment where the response is deterministic, with human escalation when automatic repair is unsafe

Browser responses are served with HTTP Strict Transport Security, X-Content-Type-Optionsnosniff, X-Frame-Options DENY, a strict-origin-when-cross-origin referrer policy, and aframe-ancestors 'none' directive.

Your data

What we do with your records, stated plainly

It is yours

Full export of ledger, documents, and audit log at any time, in standard formats, at no charge — including if you leave.

It is not for sale

We do not sell customer financial data, and we do not share identifiable financial records with third parties for marketing.

It is minimised

We collect what the accounting requires. Where a capability needs more, we ask for it explicitly rather than assuming consent.

Limits

What we are not claiming

A security page that lists only strengths is not a security page.

  • No SOC 2, ISO 27001, PCI, or HIPAA certification is claimed
  • No external penetration-test attestation is claimed
  • No “bank-grade”, “unhackable”, or guaranteed-breach-prevention claim is made
  • No representation is made about suitability for any specific regulatory obligation
  • Controls described here are product capabilities, not a guarantee against loss
  • Nothing here is legal, tax, or accounting advice for your organization

Where a certification, attestation, or regulatory determination is completed in future, it will be published here with its scope, date, and issuing body — not implied by a logo.

Ask us something specific

If your organization has a security questionnaire, a lender requirement, or an auditor with questions, send them over and we will answer directly.