Trust Centre · Security
Security, stated with evidence
This page documents only the security controls that can be verified in the TruzBiz application today. Where a control cannot be verified, it is omitted — not implied. No internet-based system can guarantee absolute security.
Controls in place today
Passwords are never stored in readable form
Account passwords are stored only as bcrypt hashes (cost factor 12). TruzBiz cannot read your password, and a database read alone does not reveal it.
Sessions are signed, short-lived and revocable
Sign-in sessions use signed tokens carried in HttpOnly, SameSite=Lax cookies (Secure in production). Business-user sessions last up to 14 days; administrator sessions expire after 8 hours. Changing your password invalidates existing sessions immediately.
Sensitive actions are confirmed with one-time codes
Registration, business claims, re-verification and contact changes require a one-time code sent to the relevant channel. Codes expire after 10 minutes and are limited in attempts and re-sends — confirming control of a channel, not legal existence.
Administrators clear extra checks
Administrator accounts support multi-factor authentication, and sensitive administrative actions — such as verification decisions, suspensions, claims decisions and imports — require a recent second-factor (step-up) proof bound to the current session.
Access follows roles, not trust
Permissions are role-based (business user or administrator). Claimants can only see and act on their own claims; businesses only on their own records; document access requires an authorisation check on every request.
Verification evidence stays private
Uploaded evidence is stored in private, access-controlled storage — never at a public link. Uploaded files are restricted by type and size, and the application verifies file contents before accepting them.
Every response carries baseline security headers
Strict transport security, content-type protection, framing denial, a content-security policy, restrictive referrer and permissions policies are applied to every page and API response.
Production refuses insecure configuration
The application validates its production configuration at startup — database, session secret, email provider, storage, rate limiting and proxy trust must all be explicitly and securely set, or the application will not start on a hosted production deployment. (A local testing override exists for non-hosted use only and is unavailable on the hosting platform.)
Significant actions are audit-logged
Verification decisions, claim decisions, status changes and administrative actions are written to an audit log and a per-verification history with actor, action and reason — recorded in the same transaction as the change they describe.
Abuse is rate-limited
Authentication, one-time-code and mutation endpoints are rate-limited by client, backed by Redis in production, to blunt credential-stuffing and enumeration.
What we do not claim
To avoid any misunderstanding, TruzBiz does not currently claim — and this Trust Centre does not display — any of the following:
- ISO 27001, ISO 27701 or any other security certification;
- SOC 1, SOC 2 or SOC 3 attestation;
- HIPAA, PCI-DSS or GDPR certification;
- an independent security audit or independent verification of our systems;
- that penetration testing has been performed;
- 24/7 security monitoring or a security operations centre;
- stated backup, disaster-recovery, RPO or RTO commitments;
- encryption-at-rest specifications, SSO, VPN or zero-trust architecture.
Some of these may become appropriate as TruzBiz matures and as enterprise customers require them. If that happens, they will appear here with their evidence — certificate numbers that can be checked independently, dated test scopes, and defined commitments. Until then, their absence from this page is the accurate statement.
Found a security issue? Please report it through Report an issue so it reaches the right people with the detail needed to investigate.