Security & Data

Built for monitoring centres
that take security seriously.

DAIOS handles sensitive alarm and contact data on behalf of your monitoring centre. Here is exactly how that data is protected, isolated, audited, and deleted when you need it.

Core Architecture

Security at every layer.

Encrypted in Transit & at Rest

Every connection to DAIOS uses TLS, so no personal data travels unencrypted. Disk-level encryption is enabled on all servers. Passwords and verification PINs are stored as one-way cryptographic hashes, never in plain text.

Per-Customer Database Isolation

Each monitoring centre's data lives in its own isolated database. There is no SQL query path that joins one customer's data to another's. The application enforces company context on every single request. Dedicated servers available.

Tamper-Evident Audit Log

Every meaningful action is recorded in a hash-chained audit log: logins, configuration changes, activations processed, manual overrides, and plan edits. Admins can search, filter, and export at any time from the admin panel.

Minimum Data in Transit

When an alarm triggers, only the ticket ID is sent to DAIOS. DAIOS fetches what it needs from your CMS via a secure, token-based REST API. Sensitive details are never pushed to us unsolicited.

Role-Based Access Controls

Staff can only access what their role permits. All staff access to customer data is logged in the audit trail. You authorise every user on your side, scoped by role, and nobody outside your organisation sees your data.

Hardened Infrastructure

Dedicated Linux servers with firewalled access, signed inter-service communication, regular security updates, and containerised deployment. Hosted in Sydney, Australia, with alternative regions available on request.

Contact Verification

Nobody hears alarm details without verifying first.

DAIOS supports per-contact PINs or verification codes that the contact must confirm before any activation details are disclosed. This protects your alarm data even if the wrong person answers a call.

The PIN is derived from the contact's data already held in your CMS, so you don't need to maintain a second credential set. Failed verification is logged, the channel attempt is treated as unanswered, and DAIOS falls through to the next contact per your plan.

→ Voice (IVR & AI): PIN confirmed before alarm details are read out, either by DTMF or spoken
→ SMS & chatbot: code challenge required before the conversation reveals site or alarm details
→ Maximum attempts configurable per company, defaulting to 2 consistently across all channels
→ Contacts with no PIN on file: downgrade, skip, or escalate, configurable per company
OK Password

A standard alternate verification that lets a contact confirm they are safe. It is accepted on all channels exactly like a normal PIN, with no visible difference to anyone observing.

Duress (Hold-Up) Password

A covert alternate that looks identical to a successful verification, so the contact sees no behavioural difference. Behind the scenes DAIOS silently logs an AUDIT_SECURITY event, posts a DURESS note to the CMS, and escalates to the operator queue. No log or transcript ever names which credential matched.

High-Security Profile

Zero contact data retained after an activation closes.

For customers with strict data-minimisation requirements, DAIOS offers a per-company High-Security data-handling profile. Standard customers are unaffected. When enabled, DAIOS automatically pseudonymises all identifying data shortly after each activation closes.

What gets removed
✕ Contact names → anonymised labels ("Contact 1")
✕ Phone numbers and email addresses → masked
✕ Addresses and free-text notes → removed
✕ Verification secrets (PINs, OK & duress passwords) → cleared
✕ Conversation transcripts → not retained
✕ Call recordings → deleted (after CMS upload if enabled)
✕ Business/account name from audit log → removed
What is kept (non-identifying)
✓ Ticket number & account number
✓ Site city and state
✓ Resolution and outcome
✓ Engagement timings
✓ Channel and outcome summary

Your CMS remains the authoritative record. Because DAIOS re-fetches account data from the CMS on each new alarm, de-identification does not affect service quality. Pseudonymisation is one-way: once applied, original values cannot be recovered from DAIOS.

Data Retention

Your data, your terms.

Retention periods are configurable per company. You can set data to be retained for years, months, or weeks, or deleted immediately after each activation closes. You can request deletion of specific data at any time.

Live operational data Your retention period
Audit logs 90 days online, 2 years archived
Backups 30 days rolling
On offboarding Full export + purge within 30 days

Administrators can permanently purge all completed activation history within a chosen date range, across both the decision platform and engagement engine, including call recordings. This is a deliberate, type-to-confirm action recorded in the audit log.

Data Location

Hosted in your region.

DAIOS is hosted on professionally managed cloud infrastructure. Your operational database, isolated per customer, and the application run on servers in your chosen region. We can deploy in the region that suits your compliance and data residency requirements.

To place calls and send messages, content passes through the relevant carriers for your region. We can discuss specific carrier and provider arrangements during onboarding to ensure they meet your requirements.

Flexible hosting options
→ Your region, deployed where your operation runs
→ Dedicated server per company
→ Per-company database isolation (standard)

Have specific security or compliance requirements?

We work with monitoring centres across Australia and New Zealand. If you have specific data handling, residency, or SLA requirements, get in touch and we'll walk through exactly how DAIOS can meet them.

Privacy Policy →