Trust Centre

Scolah Compass Platform (“Platform”) installs and operates Scolah Compass and other software on servers you own. This page is written for the IT, security and data-protection teams who need to approve that. It explains what stays on your servers, what reaches us, and how we protect both.

Page	What it covers
Architecture & Data Flow	The components, the connections between them, and a diagram of every data flow
Threat Model	What we defend against, how, and the risks that remain
Security Practices	Encryption, key management, staff access, audit logging, software supply chain
Incident Response	How we detect, handle and tell you about security incidents
Vulnerability Disclosure	How to report a security issue to us
Data Processing Addendum · Subprocessors	Our contractual commitments as processor

---

Data Residency

That statement is precise, and so are its limits. Below is everything that crosses between your servers and ours.

What never leaves your servers

• The contents of your applications’ databases and object stores
• Files and documents users upload to your applications
• Your applications’ own logs
• User accounts and passwords of your applications’ end users

The exceptions are the notifications your applications send, which go through Scolah (below), and integrations that you choose to enable, listed under “What leaves only if you turn it on”.

What the agent always sends to the Platform

The agent on each server connects out to the Platform over HTTPS. It sends operational information only:

Information	Examples	Why
Server capabilities	Runtime and version, CPU, memory, disk, architecture, public IP address, Kubernetes version and node count, detected database engines	To check an application will fit and run before installing it
Installation status	State, revision, each service’s health, whether each domain is routed	To show health in the portal and calculate installation-days
Deployment progress	Phase, service name and messages, including the last lines of deployment output; values whose names look like secrets are redacted	So you and our support team can see why a deployment failed
Precheck results	Pass or fail per check, with a message	To block changes that would fail
Connection details	Host, port, database name and username of a read-only connection between two installations. Never the password.	To show the connection in the portal
Backup metadata	Snapshot identifiers, database sizes and versions, replication lag	To manage disaster recovery. The backups themselves never pass through the Platform.
Agent telemetry (when enabled)	The agent’s own logs and metrics: heartbeats, apply and pull timings, errors	To detect failing agents and support you. These are logs of the agent, not of your applications.

What the Platform sends to your servers

• Signed bundles: deployment files and pinned container image references, signed with our release key
• Desired state: which installations should run, at what version and size
• Sealed secrets: passwords and keys encrypted to that one server’s key, which only that server can decrypt
• Lifecycle and backup instructions: deploy, upgrade, scale, suspend, remove, snapshot, verify, restore

Container images are pulled by your server directly from the registries the bundle names: Scolah’s own container registry for Scolah software, and the publisher’s public registry for third-party catalog applications.

What Scolah holds about your installations

To deploy and manage your installations, the Platform stores:

• Your organisation, portal users (name, email address, role) and the activity log
• Each server’s capabilities and heartbeats, and each installation’s configuration values, status and history
• The credentials your installations use: database passwords, administrator passwords, encryption keys, TLS keys you upload, and credentials for external services you register. They are encrypted at rest. The Platform can decrypt them, because it needs to re-seal them for a server when an installation is moved, restored or re-sealed.

We hold those credentials but have no network path to use them. Your servers accept no inbound connection from the Platform. You can rotate them at any time, and we recommend rotating them if you end your subscription.

What goes through Scolah for notifications

Scolah Compass and Scolah Compass Resources send text messages and push notifications through Scolah, and email too unless you set your own mail server. Scolah receives the recipient and the message to deliver it, does not keep message content, and uses the providers listed under Subprocessors.

What leaves only if you turn it on

Integration	Off by default?	Where data goes	What is sent
Compass AI module — “Self-hosted LiteLLM” (the default when the module is on) or “Bring your own key”	AI module is off by default	Your own LiteLLM installation, and the model providers you configure in it; or the provider whose key you enter	The text of AI requests, and document text indexed for search, under your own provider contracts. Nothing passes through Scolah.
Compass AI module — “Scolah-managed” provider	Yes — you must choose it	Scolah’s AI service (ai.scolah.com), which runs models Scolah hosts itself. No third-party model provider (see Subprocessors)	The text of AI requests: questions, the case or knowledge-base content needed to answer them, and the responses
Your own mail server for outbound email	Yes	The SMTP server you configure	Recipient addresses and message contents
Disaster-recovery backups	Yes	The object store you designate	Encrypted database and file backups. Scolah does not operate this store.
Public domain with HTTPS	Yes	A public certificate authority, contacted from your server over ACME	Domain names, to issue certificates
Catalog applications’ own features	Depends on the application	Wherever that application sends data	Whatever that application’s own documentation describes; for example, a catalog AI gateway forwarding to providers you configure

---

Questions