Security & Data

Built for monitoring centres
that take security seriously.

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

Core Architecture

Security at every layer.

Encrypted in Transit & at Rest

Every connection to OaaS uses TLS — 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 — logins, configuration changes, activations processed, manual overrides, plan edits — is recorded in a hash-chained audit log. 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 OaaS. OaaS 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.

OaaS 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 — you don't need to maintain a second credential set. Failed verification is logged, the channel attempt is treated as unanswered, and OaaS falls through to the next contact per your plan.

Voice (IVR & AI): PIN confirmed before alarm details are read out — DTMF or spoken
SMS & chatbot: code challenge required before the conversation reveals site or alarm details
Maximum attempts configurable per company — default 2 across all channels consistently
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. Accepted on all channels exactly like a normal PIN — no visible difference to anyone observing.

Duress (Hold-Up) Password

A covert alternate that looks identical to a successful verification — the contact sees no behavioural difference. Behind the scenes OaaS 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, OaaS offers a per-company High-Security data-handling profile. Standard customers are unaffected. When enabled, OaaS 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 OaaS 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 OaaS.

Data Retention

Your data, your terms.

Retention periods are configurable per company. You can set data to be retained for years, months, 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.

OaaS 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 OaaS can meet them.

Privacy Policy →