Tenant isolation
Every tenant’s data is isolated at the database row level using PostgreSQL Row-Level Security (RLS). Every table that contains tenant data carries a tenant_id column with a forced RLS policy. The session-local tenant identifier is set per-transaction by an authenticated interceptor and cannot be unset. Cross-tenant foreign-key references are validated at write time; the validation is covered by automated repository checks.
Authentication
Tokens are PASETO v4.public signed with Ed25519. We do not use JWT. Passwords are hashed with Argon2id (memory 64 MB, three iterations, parallelism four). Multi-factor authentication via TOTP is mandatory for owner and tenant-admin roles.
Financial-data controls
- Issued invoices are immutable. Corrections are made via credit notes.
- Audit log is append-only, hash-chained monthly, and tamper-evident.
- Four-eyes on rate-card publish (configurable per tenant).
- Segregation of duties enforced in the role model.
- Electronic signature on contract documents.
Hosting & encryption
Data location is set by the customer’s order and deployment configuration. HTTPS protects data in transit. Stored integration credentials are encrypted and are excluded from application logs. Database backups are stored separately from the primary host. Specific residency, encryption-key management and recovery commitments are documented in the applicable order or security schedule.
Compliance
- Privacy requests and complaints are handled under our published privacy policy.
- Australian tax-invoice validation checks flag missing supplier details before issue.
- Card checkout is handled by a third-party payment provider; Reckon3PL does not store full card numbers.
- Additional assurance reports, Peppol delivery and customer-managed keys apply only when stated in an order.
Reporting a vulnerability
Email security@reckon3pl.au. We acknowledge within one business day. We have a coordinated disclosure policy and will credit you publicly if you wish.