Security & Where Your Data Lives

This page answers the questions a law firm's risk and IT teams ask before connecting a practice-management system to a cloud service: where is it hosted, where does our data physically reside, what actually leaves our network, and what is — and isn't — protected. The answers below describe how PMS Sync is built and operated today; we've tried to be precise about what we can and cannot claim.

1. The Short Answer

• Your Aderant database never leaves your premises. No cloud component connects to it directly. A small agent inside your network reads it and pushes data outbound — you open no inbound firewall ports.
• Everything we operate runs in Australia. Every Alterspective-hosted component — the portal, the proxy, identity, the relay tunnel, and the metadata store — is hosted in Sydney.
• The cloud keeps pointers, not contents. The only data that rests in our cloud is audit metadata: which matter number was imported, by whom, when, and the resulting work-item reference. Matter descriptions, party names, addresses, and financials are not stored by PMS Sync — they pass through in transit and land in your own Clio Operate tenant.
• Access fails closed. Authentication, tenant resolution, and credential checks all deny by default; a misconfiguration blocks access rather than exposing data.

2. Data Residency — Where Each Piece Lives

All Alterspective-operated infrastructure is hosted in Sydney, Australia:

3. What Data Actually Rests in the Cloud

PMS Sync is a pass-through integration. During an import, matter data travels from your agent, through the proxy, into your Clio Operate tenant — over encrypted connections — and matter content is never written to the PMS Sync metadata store. The only record written there per import is an audit entry, containing:

• The organisation and environment the import targeted
• The Aderant matter number and the resulting Clio Operate work-item reference (identifiers, not contents)
• Who ran it (the staff member's email and ID) and when
• Whether it succeeded, and a short error description if it failed

It does not store matter descriptions, party names or addresses, document content, or financial figures. Per-environment connection settings are also stored — with all secrets (database key, OAuth client secret, relay key) held server-side and never returned to a browser. The managed database platform encrypts data at rest.

4. How the Connection Is Secured

• Outbound-only, read-only at the source. The on-premise agent makes outbound connections only — no inbound firewall rules. It queries Aderant through a read-only database login; the deployment standard grants it db_datareader and nothing more.
• The tunnel requires authentication. The Azure Relay hybrid connection rejects any request that isn't signed with the tenant's shared-access key. The agent listens with one key; the proxy sends with a separate, least-privilege key.
• Every service-to-service call is keyed. The proxy authenticates to the agent with a per-tenant API key (≥32 random characters — the agent refuses to start with a weak or placeholder key). Cross-origin browser access is denied by default unless an origin is explicitly allowlisted.
• Staff sign-in is federated. Authentication is via your identity provider (Microsoft Entra ID / OIDC) through Keystone. Organisation resolution fails closed — if it can't positively confirm a user's organisation, sign-in is denied.
• Encrypted in transit. All public endpoints are served over HTTPS/TLS.

5. Tenant Isolation

Each client organisation has its own connection credentials, its own relay key, and its own configuration — nothing is shared between tenants. The proxy resolves which tenant a request belongs to strictly from the signed-in user's organisation, never from a free parameter, so one tenant cannot address another's data. The metadata store enforces row-level security keyed by organisation, and secret values are redacted from application logs.

6. Auditability

Every import attempt — success or failure — is recorded with the actor, timestamp, target, and outcome. For firms with a SIEM, PMS Sync can additionally emit each event to a webhook (Splunk, Microsoft Sentinel, or any CloudEvents-compatible endpoint) so import activity flows into your own monitoring. A correlation identifier ties a single business operation across the portal, proxy, and agent for traceability.

7. "Is Our Sensitive Data at Risk?"

Answering the question directly, with the trade-offs stated honestly:

• At rest: Your matter content is never stored by PMS Sync. The substantive data lives in your Aderant database (on your premises) and your Clio Operate tenant. Our cloud holds only the audit metadata described above.
• In transit: During an import, matter data passes through the Australian-hosted proxy over encrypted connections and is processed transiently to create the work item. The import pipeline does not persist matter content to the PMS Sync database. (The proxy keeps operational logs; disabling request-body logging in production is a deployment-hardening step we cover in onboarding and recommend your security team confirm.)
• Credentials: The proxy uses your tenant's credentials (to call Clio Operate and the agent) for the duration of a request; the stored copies live in a secrets vault, are never returned to the browser, and are redacted from request logs.
• Blast radius: The agent's HTTP surface is read-only — table/view queries only, with no stored-procedure or write path — and the deployment standard is a read-only Aderant login (db_datareader) as a second line of defence (we recommend your security team verify the login during onboarding). So the cloud side cannot modify or delete data in your practice-management system. Writes only ever occur into your Clio Operate tenant, and only when an administrator explicitly enables imports for an environment.
• Your controls: You can disable imports for any environment instantly, rotate the agent and relay keys at any time, and revoke access by removing a user from the organisation in your identity provider.

8. What We Don't Claim

PMS Sync is in a pilot programme. We do not currently hold a third-party security certification (such as SOC 2 or ISO 27001) for this product, and this page is a plain-language description of the architecture — not a formal compliance attestation. We're happy to walk your risk team through the design, provide the deployment and architecture documentation, and accommodate a security review as part of onboarding.

For the component architecture, see the Technical Overview; for how the on-premise agent and tunnel are deployed, see the Deployment Guide. Your Alterspective contact can arrange a security walkthrough during onboarding.