How we protect customer audit data, who we share it with, and where we are on our independent-assurance roadmap. This page is updated as the underlying controls change — every claim here corresponds to code that ships in our production environment today, unless explicitly marked as roadmap.
Time-based one-time codes (TOTP) with single-use bcrypt-hashed backup codes. Compatible with any authenticator app.
12-character minimum, 3-of-4 character classes, common-password blocklist, and a no-personal-information rule. NIST 800-63B aligned.
5-attempt threshold, 15-minute cooldown. Every attempt is logged with IP and user agent and surfaced to tenant admins.
30-minute idle timeout, 12-hour absolute cap. Session cookies carry HttpOnly + Secure + SameSite=Lax in production.
Enterprise customers can restrict sign-ins to corporate networks or VPN ranges. Off by default; opt-in per workspace.
Every privileged action is recorded into an append-only log with a SHA-256 hash chain. Silent DB-level tampering becomes detectable.
TLS 1.2+ on every endpoint, HSTS with a 1-year max-age, strict Content-Security-Policy, and a deny-by-default permissions policy.
Daily digest to the workspace owner when we detect lockouts, IP-enumeration sweeps, or distributed brute-force patterns.
Self-serve admin export of every field we hold about a user, and one-click anonymisation that preserves history under redacted placeholders.
The technical controls behind every request. All are live in the production environment today.
User passwords are hashed with bcrypt (per-credential salt, adaptive work factor). Password-reset, activation, and MFA backup tokens are bcrypt-hashed at rest, so a database leak never exposes a usable secret.
Every state-changing request carries a per-session CSRF token validated server-side (Flask-WTF). Combined with SameSite=Lax cookies, cross-site request forgery is blocked at two layers.
All database access uses parameterised queries with bound parameters — user input is never concatenated into SQL. Output is auto-escaped by the template engine to prevent stored/reflected XSS.
Deny-by-default Content-Security-Policy, X-Frame-Options: DENY (anti-clickjacking), X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a locked-down Permissions-Policy on every response.
Tenant data is stored on managed PostgreSQL and encrypted persistent disks with AES-256 encryption at rest. In transit, TLS 1.2+ is enforced end to end with HSTS.
Every query is scoped to the caller's workspace (account_id). No cross-tenant read or write path exists; a token or session is only ever honoured against the data of the tenant it belongs to.
Sliding-window per-IP rate limits on sign-in, password-reset, account-activation, and resend-activation endpoints throttle credential-stuffing and brute-force attempts before lockout even triggers.
Auditee response and evidence links are unguessable, single-purpose tokens that grant access only to one audit's content — never a login session and never another tenant's files.
Sign-in, reset, and activation flows return a single generic outcome regardless of whether the account exists, is locked, or is inactive — so the login surface cannot be used to enumerate valid users.
How we keep the codebase and the organisation around it disciplined between releases.
pip-audit runs in strict mode against the pinned dependency manifest on every push, every pull request, and on a daily schedule — so a CVE disclosed after our last commit is caught within 24 hours.
A Bandit static-security scan runs over the application code in CI on every change, flagging insecure patterns before they can reach production.
Dependabot opens pull requests for outdated and vulnerable dependencies automatically, keeping the supply chain current without waiting on a manual review cycle.
CODEOWNERS and a security-aware pull-request template enforce review on every change to the main branch. Change management is a documented, repeatable process.
Documented change-management, access-review, vendor-risk, asset-inventory and environment-isolation policies, plus operational runbooks for incident response, secrets rotation, backup/DR, and email authentication (SPF/DKIM/DMARC).
A maintained PII inventory and risk register underpin a Data Processing Agreement mapped to GDPR and the Saudi, UAE, and Egyptian PDPLs. A published disclosure policy gives researchers explicit safe harbor.
We're being transparent: we are pre-revenue on independent assurance reports, and we'd rather show you where we are than overclaim.
Controls foundation in place — access management, audit logging, change management documented. Auditor selection in progress.
ISMS scope and statement of applicability drafted. Combined gap assessment alongside SOC 2 audit.
Currently single-region. Saudi / UAE / EU data residency available for enterprise tier on request.
These are the third parties who process customer data on our behalf. We will notify customers of any addition to this list with 30 days' advance notice.
| Provider | Purpose | Data hosted | Region |
|---|---|---|---|
| Render | Web application hosting + managed Postgres | All tenant data at rest | US East |
| OpenAI | AI-generated risk / finding / recommendation drafts | Audit content sent only when AI features are invoked | Multi-region (opt-out of training) |
| SMTP provider | Outbound system mail (activation, reset, distribution) | Recipient addresses + message bodies | Provider region |
If you believe you have found a vulnerability in AuditFlow, please email info@audit-flow.net. We aim to acknowledge within one business day. We do not currently operate a public bug-bounty programme but we credit responsible disclosure in our release notes.