Where your data lives
Customer data is hosted in Australia. Our database (Supabase Postgres) and our 7-year audit log (AWS S3 with Object Lock Compliance Mode) both run in the AWS Sydney region (ap-southeast-2). Backend compute is migrating from Singapore to AWS Sydney during Phase 2 of our build (ADR-005, locked 2026-04-24).
Disaster recovery replication target is Melbourne (ap-southeast-4). Data does not leave Australia.
How your data is protected
All data in transit uses TLS 1.3 via Cloudflare. All data at rest is encrypted with AES-256-GCM. Our key management uses AWS KMS, which is backed by FIPS 140-3 Security Level 3 validated hardware security modules in every AWS Region including Sydney.
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.
Last reviewed: 2026-04-25.
Next review: 2026-07-25.
Operator: IRONBARKTECH (ABN 29659123086).
Source policies and control library (public, CC BY 4.0): ironbark-portfolio-policies