How we run security.

Where your data lives

Customer data is not yet hosted in Australia, and this page says so rather than describing the plan as the present. As at 5 September 2026 the service runs on Railway: the Postgres database, the Redis cache and the dashboard in the United States (us-west2), and the API in Singapore (asia-southeast1). The audit log is a hash-chained, append-only table in that database, queryable by customers through the API.

The migration target, locked in ADR-005 on 2026-04-24, is AWS Sydney (ap-southeast-2) with disaster recovery in Melbourne (ap-southeast-4) and the audit log moved to S3 with Object Lock Compliance Mode, none of which is in place yet: the migration has not started. This section is updated on the day that changes, and the sub-processor register shows the same facts per vendor.

How your data is protected

All data in transit uses TLS 1.3 via Cloudflare. Data at rest sits in Railway managed Postgres and Redis, whose disk encryption is Railway's control rather than ours; we do not hold our own keys today. AWS KMS with FIPS 140-3 Security Level 3 validated hardware security modules is part of the Sydney migration target and is not in use.

Customer-managed encryption keys (BYOK) are available at Phase 4 enterprise tier. AWS KMS External Key Store (XKS), where keys never leave the customer's HSM, is available at Phase 6 on customer pull.

How tenants are isolated

We use Postgres Row-Level Security on every tenant-bearing table. Each row in scans, scan_results, cases, case_events, credits_ledger, monitoring_subscriptions, webhook_deliveries, and jobs carries an organisation_id column with a policy that filters on the JWT org_id claim.

Architecture decisions ADR-001 (Trust Score), ADR-003 (Tenant Isolation), and ADR-004 (RBAC + Audit Log) publish the design.

How access is controlled

Every API call uses OAuth 2.0 client credentials with scoped tokens (scans:read, scans:write, cases:read, cases:write, reports:read, monitoring:write, batch:write). API key expiry warnings ship in every response header (X-ApiKey-Expires-In) at 30-day, 7-day, and 24-hour thresholds.

Multi-factor authentication is enforced for administrative access. Our role model uses 4 default roles (Principal, Senior, Member, Auditor) across 16 permissions, totalling 64 explicit role-permission bindings (ADR-004).

How code reaches production

Every pull request runs static analysis (GitHub CodeQL, with Semgrep Pro added at Phase 3) and dependency vulnerability scanning (Dependabot + pip-audit). Critical CVEs block merge. All container images run as non-root users.

The Evaluator smart contract is reviewed internally before any testnet deployment, and will undergo external audit (Sherlock, Code4rena, or Trail of Bits class) before any mainnet USDC handling.

How we respond to incidents

Our incident response plan follows NIST SP 800-61 Revision 3 (April 2025), aligned to NIST Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). Severity levels P0 to P3 are documented. We commit to the Australian Notifiable Data Breaches scheme: assessment within 30 days of becoming aware, notification to OAIC and affected individuals as soon as practicable once an eligible breach is confirmed.

Sub-processors

A current list of every third party that processes customer data sits at /security/subprocessors. We update this page within 30 days of any change.

AI governance

Which AI models we use, what data they see, whether your data trains them (it does not), and how to opt out is published at /security/ai. Updated within 30 days of any change.

MCP server

If you call Ironbark from your own agent over the Model Context Protocol, how that surface is authenticated, gated, billed, and audited is published at /security/mcp.

Vulnerability disclosure

Found something? Email security@ironbarkaml.com.au or reach us via /.well-known/security.txt. We commit to acknowledge within 2 business days, triage within 5 business days, and credit you (with consent) on /security/disclosure after fix.

What is coming

SOC 2 Type I and ISO 27001 Stage 1 readiness work begins when we accept our first enterprise pilot. SOC 2 Type II and ISO 27001 certification land at Phase 5 alongside the bug bounty program. IRAP assessment is on the table when we serve our first Australian Government customer.

The roadmap with phase-trigger-revenue triggers lives at /security/roadmap.

Why we publish all this

Published beats proprietary. Every weight in the Trust Score, every sub-processor, every certification window, every gap is a fact you can audit. That is the only business model we will run.

The act of publishing forces every claim to be evidenced. It is the forcing function we choose against marketing drift.