Security by Design
Encryption, access control, audit logging, and secure development practices — built into IRIS from the ground up, not added on afterwards.
Encryption at Every Layer
Data is encrypted at rest and in transit across both hosting regions. The same encryption standard applies whether you’re on Render in Singapore or AWS in Sydney.
At Rest
All data stored in IRIS databases and file storage is encrypted using AES-256. On AWS Sydney, encryption is backed by AWS Key Management Service (KMS) for additional key management controls.
- AES-256 across all stored data
- AWS KMS key management on Sydney deployments
- Passwords stored as one-way hashes — never in plain text
- No sensitive credentials stored in source code
In Transit
All communication between your browser or app and IRIS servers is encrypted with TLS 1.2 or higher. Older, insecure protocol versions are not accepted.
- TLS 1.2+ enforced on all connections
- HSTS applied where applicable — prevents protocol downgrade
- Applies to all API, web, and mobile traffic
- Internal service-to-service communication also encrypted
Authentication & Access Control
MFA is enforced for all users. Four login methods are supported, including enterprise SSO via Microsoft Entra ID, Google, and OIDC. Access within the platform is controlled by role.
Microsoft Entra ID
Enterprise SSO via Entra ID (formerly Azure AD)
● LiveGoogle SSO
Sign in with your Google Workspace account
● LiveOIDC
Generic OpenID Connect for custom identity providers
● LiveUsername + Password
Standard credentials with bcrypt/argon2 hashing
● LiveMFA — Enforced for All Users
Multi-factor authentication is not optional in IRIS — it is enforced for every user account, including staff and roster builders. This eliminates the risk of compromised credentials being used alone to gain access.
Role-Based Access Control
Access within IRIS is governed by RBAC. Staff can only see their own data. Roster builders access their designated departments. Administrators manage their organisation’s configuration. No user has more access than their role requires.
Tenant Isolation and Audit Logging
Every organisation’s data is isolated at the database level. Every action in the platform is logged — immutably.
Database-Level Tenant Isolation
IRIS uses PostgreSQL Row-Level Security (RLS) to enforce data isolation at the database layer — not just at the application layer. This means that even in a shared-infrastructure deployment, one organisation’s data cannot be accessed by another, regardless of application-level errors.
- PostgreSQL RLS enforced at the DB layer
- Each tenant’s data scoped by row-level policy
- Isolation holds even if application logic fails
Immutable Audit Logging
All actions within IRIS — roster changes, user access events, administrative actions, and system events — are written to an immutable audit log. Logs cannot be altered or deleted by application users, providing a complete, trustworthy record for compliance and incident investigation.
- All user and system actions logged
- Logs are immutable — cannot be altered via the app
- Available for compliance review and security investigation
Backup and Recovery
We target high availability and maintain database backup capabilities. No formal uptime SLA is published at this time.
Point-in-Time Recovery
PostgreSQL point-in-time recovery (PITR) is enabled, allowing the database to be restored to any point within the backup retention window in the event of data loss or corruption.
- PITR enabled on the production database
- Backup retention period defined and maintained
- Recovery capability verified periodically
Availability Target
We target high availability through managed infrastructure, health checks on every deployment, and automated failover where available. We do not publish a formal uptime SLA at this time — contact us if your procurement requires specific availability commitments.
No formal SLA publishedHow We Build Securely
Security is considered at every stage of development — not only before release. These are the practices currently in place.
Password Hashing
All passwords are stored using bcrypt or argon2 — one-way, salted hashes. Plain-text passwords are never stored or logged anywhere in the system.
No Secrets in Code
Credentials, API keys, and secrets are never stored in source code or version control. All secrets are managed through provider-native secret stores (AWS Secrets Manager, Render environment secrets).
OWASP Top 10
Development considers the OWASP Top 10 web application security risks, including injection, broken authentication, and insecure design — at the design and code review stage.
When Something Goes Wrong
We have a baseline incident response plan in place. We are honest about its current maturity and what we are working towards.
Incident Response Plan
A baseline incident response plan exists, covering detection, containment, notification, and recovery steps. The plan has not yet been formally tested through a tabletop exercise or simulation — this is on our roadmap.
- Documented response procedures in place
- Covers detection, containment, and recovery
- Formal testing planned — not yet conducted
Breach Notification
In the event of a data breach that meets the threshold under Australia’s Notifiable Data Breaches (NDB) Scheme, we will notify affected individuals and the OAIC as required by law. Affected customers will also be notified promptly.
- NDB Scheme obligations understood and documented
- OAIC notification as required by law
- Customer notification procedures in place
Security Controls at a Glance
A single-page reference for security and procurement reviews.
| Control | Status | Detail |
|---|---|---|
| Encryption at rest | ✓ Live | AES-256; AWS KMS on Sydney deployments |
| Encryption in transit | ✓ Live | TLS 1.2+ enforced; HSTS applied |
| MFA | ✓ Enforced | Required for all users — not optional |
| SSO | ✓ Live | Entra ID, Google, OIDC |
| RBAC | ✓ Live | Role-based access; least-privilege enforced |
| Tenant isolation | ✓ Live | PostgreSQL Row-Level Security (DB layer) |
| Audit logging | ✓ Live | Full, immutable log of all actions |
| Password hashing | ✓ Live | bcrypt / argon2; no plain-text storage |
| Secrets management | ✓ Live | Provider-native (AWS Secrets Manager, Render env) |
| Point-in-time recovery | ✓ Live | PITR enabled; backup retention defined |
| WAF | AWS Sydney only | AWS WAF active on public edge (Sydney deployment) |
| Penetration testing | Roadmap | Not yet conducted — planned |
| Automated vuln scanning | Roadmap | Not yet implemented — planned |
| Incident response plan | Partial | Plan exists; formal testing not yet conducted |
| Uptime SLA | No formal SLA | High availability targeted; no published SLA |
Honest About Where We Are
We are a growing platform. We are transparent about what is live, what is on our roadmap, and what we don’t yet have — because overclaiming security posture is itself a risk.
Live and Verified
Encryption, MFA, SSO, RBAC, RLS tenant isolation, immutable audit logs, and password hashing are all in production today — not aspirational.
Honest About Gaps
Penetration testing, automated dependency scanning, and formal incident response testing are on our roadmap. We document these gaps clearly rather than obscuring them.
Continuously Improving
Security is not a one-time effort. We review controls as the platform evolves, and update this page when the posture changes. If something here is out of date, let us know.
Security Reviews Welcome
We’re experienced with health-sector procurement and security questionnaires. Get in touch for architecture detail, control evidence, or a technical discussion.