We don't ask you to take compliance on trust.
This page describes controls that are actually operating in Auregis 2 Comply today. Where something depends on a supplier, or has not been independently tested, we say so rather than claim it. Auregis 2 Comply holds no security certification.
Isolation enforced in the database
Row-level security on every application table, not application checks alone.
Evidence, not assumption
Compliance status follows verified, human-approved evidence — never an inspection alone.
Deterministic compliance logic
AI assists analysis. It never writes compliance status.
Controls that are in place today.
Described at the level procurement needs, without publishing detail that would itself create risk.
Organisation isolation enforced by the database
Every record belongs to an organisation, and that boundary is enforced by row-level security in the database itself rather than by application code alone. It applies to all application data, including demonstration and trial organisations.
Permission-controlled access
Access is granted by role and permission, scoped to modules and entities, with approval actions separated from day-to-day recording. Platform access is granted by invitation of a customer organisation; there is no public self-service signup.
Private evidence storage
Uploaded certificates, reports and photographs are held in private storage that is not publicly addressable. Access is mediated by the platform against the requesting user's organisation and permissions.
Append-only audit history
Compliance-relevant changes are written to an append-only history that users cannot edit or delete. Corrections are made by supersession, so the earlier state remains visible. Reads and exports are not individually logged.
Controlled, versioned regulatory releases
Regulatory content is released as governed, versioned catalogues with recorded lineage and supersession. A released catalogue is frozen: regulatory change produces a new version rather than an edit to history.
Fail-closed release governance
Automated release gates run before a regulatory catalogue can be activated. If a gate cannot prove the condition it tests, activation is refused rather than allowed through.
An inspection, a certificate and proven compliance are three different things.
Most systems can store a certificate. Auregis 2 Comply distinguishes what was done, what was submitted, what was verified and what is actually assured — and only the last of those changes a compliance status.
- Step 1
Applicability
The requirement is resolved from the property, building, scheme or asset characteristics that legislation actually keys on — not from an asset type alone.
- Step 2
Inspection or activity
Work is scheduled and carried out. Completing an inspection does not, by itself, make anything compliant.
- Step 3
Evidence
A document or record is attached to the obligation it is meant to satisfy. Uploading a certificate does not, by itself, make anything compliant.
- Step 4
Verification
The evidence is checked against what the requirement actually asks for, including the competency evidence a duty depends on where legislation mandates it.
- Step 5
Human approval
A permitted user approves the evidence. Approval is the only event that can establish satisfaction, and it is recorded with actor and timestamp.
- Step 6
Compliance assurance
Only then does the obligation become satisfied and the next due date follow from the requirement. Provenance is retained, so evidence verified in A2C is never presented as equivalent to history imported from a previous system.
What this means in practice
- Being inside a due date is not proof of compliance. An obligation with no recognised satisfaction event is reported as unknown, not compliant.
- An asset or property is not compliant while any applicable duty on it remains unproven.
- Imported or declared history keeps its provenance and is never relabelled as evidence verified in A2C.
AI assists the reading. It never decides compliance.
Where AI is used
Two defined functions: assisted extraction of fields from uploaded evidence, and a read-only compliance assistant that answers questions over the signed-in user's own organisation records.
What AI cannot do
No AI path writes compliance status. AI cannot approve evidence, close an inspection, alter a due date, change a regulatory catalogue or create, edit or delete records.
Deterministic compliance logic
Requirement applicability, rule evaluation, due dates, scheduling, workflow state and compliance roll-ups are produced by deterministic logic, not by a model.
Human approval remains mandatory
AI-extracted values are proposals. A person must verify and approve the evidence before an obligation can be satisfied.
Controllable and auditable
AI features are off by default and can be enabled or disabled per organisation. Each AI interaction is recorded against the organisation, user, document and time, including failed attempts.
We do not make claims about our AI provider's data retention, processing location or exclusion of customer content from model training. Those are supplier arrangements we are verifying, and we will publish them only once they are confirmed contractually.
Privacy & data protection
The public website uses first-party, cookie-free analytics: no advertising pixels, no session recording, no cross-site tracking, and nothing you type into a form is ever sent to analytics. Platform data is processed for a customer organisation under its own agreement. Personal information is handled under our Privacy Policy.
Read the Privacy PolicyData location
Customer platform data, including evidence files, is stored at rest in a managed database and private object storage located in Australia (Sydney). There is no customer-selectable hosting region today.
Some processing happens outside Australia: the application is delivered from a globally distributed edge platform, AI-assisted extraction transmits the submitted document to our AI processing provider, and transactional email is dispatched through a delivery provider. Encryption in transit and at rest is provided by our hosting, database and storage providers rather than operated independently by Auregis 2 Comply. We do not claim that data remains in Australia at all times.
Platform resilience
Auregis 2 Comply runs on managed, provider-operated infrastructure with provider-managed backups. We are currently verifying backup frequency, recovery capability and restore testing with our providers, and we publish no recovery objectives, backup schedule or restore-testing claim until that verification is complete and evidenced.
Reporting a security concern
If you believe you have found a vulnerability in Auregis 2 Comply, please tell us before disclosing it elsewhere, and give us enough detail to reproduce it. We will acknowledge your report and keep you informed of the outcome. Please do not access, alter or retain data that is not yours while testing.
Contact us through the enquiry formCustomer & procurement assurance
Additional security, privacy and architecture information is provided under customer and procurement due diligence, including:
- Security and architecture questionnaire responses
- Subprocessor register with processing locations
- Data processing terms and residency detail
- Retention, deletion and audit-history detail
- Regulatory catalogue governance and release-gate evidence
Shared responsibility
Auregis 2 Comply operates the platform and its controls. Customer organisations remain responsible for their own user administration, role assignment, data accuracy, evidence quality and internal policies.
- Version
- 1.3
- Last reviewed
- 22 August 2026
- Basis
- Verified against the deployed Auregis 2 Comply platform on 22 August 2026
- Next review
- At least annually, and on any material legal, product, data-flow, AI, hosting or security change
Privacy enquiries: Contact us through the enquiry form.