Sécurité et confiance

Every organisation's data is isolated in the database itself, not only in the application. Access is evaluated on every query against the identity making it, so one customer cannot reach another customer's people, simulations, transcripts or results — including through a bug in application code. That boundary is exercised automatically on every change we ship.

Within an organisation, access follows role: administrators, team leaders and learners each see what their role permits. Bespoke characters and scenarios built for a customer are private to that customer.

• Single sign-on via SAML, so a customer manages accounts in its own identity provider and joiners and leavers follow existing HR process.
• Multi-factor authentication available to every user, and a customer can require it of everyone holding administrative rights.
• Passwords are checked against known-breached credential lists and refused if they appear, with a minimum length and character requirement applied at sign-up and on every change.
• Role-based permissions enforced on the server and in the database, not in the browser.
• Administrative and privileged actions are recorded, and authentication and access events are logged for investigation.

• Encrypted in transit with industry-standard TLS, and encrypted at rest by our database and storage providers.
• Session data is deleted on a retention schedule the customer controls, rather than kept indefinitely.
• Regular automated backups of the production database.
• Error monitoring is configured to strip conversation content, transcripts, prompts and credentials before anything leaves the platform.

• Dependencies, source code and secrets are scanned automatically on every change, against a defined patch policy.
• Application and database changes go through review and an automated test suite before release.
• Hosting, database and AI services are managed enterprise platforms, with application compute and the primary database in Australia.
• Requests to the platform are rate-limited, and a web application firewall sits in front of it.
• Accessibility is checked automatically on every change, against WCAG 2.2 AA — see our Accessibility statement.

We maintain an incident register and a documented response process, with a defined timeline for assessing whether an incident is notifiable. Where a customer must be told, we tell them, and we support their own notification obligations. Security incidents and AI-specific incidents are tracked as distinct categories, because they call for different responses.

Billing runs through Stripe's hosted, PCI-compliant payment processing. Evolve does not store payment card numbers. Every third-party service that supports the platform is published on our Subprocessors page, with the regions it processes and stores data in and what it retains. A Data Processing Agreement is available on request — see our Data Processing overview.

Where a simulation is scored, the score is an automated decision about a person, and we treat it as one: every result records the model and version that produced it, an administrator can override or void it, and the participant can challenge it. Organisations can switch individual AI features off. This is set out in full on our AI transparency page.

Where we stand

We align our practices with the Australian Privacy Act 1988 (Cth) and the Australian Privacy Principles, and apply equivalent standards for customers in other jurisdictions. We are not currently ISO 27001 or SOC 2 certified and do not claim to be; independent certification is on our roadmap. We are glad to complete a security questionnaire or walk your security team through our controls in detail.

If you believe you have found a security issue, please contact us at security@evolvesimulations.com. We appreciate responsible disclosure and will work with you to investigate and resolve valid reports.