Where your data lives, who can see it, and how you keep it.
What a business manager or IT committee asks before signing, answered from our published control inventory. We list the controls we run and name the certifications we do not hold.
Where it runs
Australia or your own server. A database of your own. Tenant isolation, encryption and backups.
Who can see what
SSO, MFA, passkeys, SCIM, roles by campus, the audit log, and privacy tooling for export and erasure.
Continuity
Full export, the self-hosting fallback and source escrow on request. Plus what we do not claim yet.
Where it runs.
Managed hosting is one server per school in Australia. Self-hosting is the same software on hardware or cloud you control.
Australia, or your own server
Managed deployments run in Australia. Your application database and its backups stay in that region. Or run Plugboard on your own infrastructure and choose its external connections yourself.
A server of your own
Each managed school gets its own server, its own database, its own disk and its own backups. No other school's deployment is on the machine.
Every record belongs to one school
Tenant-aware queries and PostgreSQL row-level security enforce the boundary in the database as well as in the application. Self-hosted deployments run with the same restricted application role.
In transit, and for every secret
TLS encrypts traffic in transit. Connector credentials are envelope-encrypted in the vault with key rotation and redacted from normal responses and logs. Disk encryption on a self-hosted server is yours to configure.
Scheduled, encrypted, restorable
Scheduled encrypted backups with export and restore tooling and a documented restore procedure. On managed hosting, backups stay in the same region as the deployment.
Hosted and pseudonymised, or local
Managed AI runs on open models that DigitalOcean serves in the United States, not in your hosting region. Names, emails, phone numbers and IDs are pseudonymised before every call, and DigitalOcean stores no inputs or outputs. Self-hosted, a local model keeps it on your server; with no AI, nothing is sent. Email, SMS and other connectors are processed by their providers. Where AI runs
Who can see what.
Staff sign in with the identity provider you already run. Students tap cards and parents follow links; neither ever sees the technician console.
Your identity provider, your policy
Staff sign in with Entra, Google, custom OIDC or SAML. Require MFA across the team, and offer or require passkeys. A sensitive action, such as a wipe or an MFA reset, needs fresh verification there and then.
Deprovisioned from your directory
Provision and deprovision technician accounts from your identity provider. When someone leaves the school, you remove them once, in the directory.
Built-in roles, or your own
Start from the built-in roles or write your own, and grant a role on one campus rather than across the whole school. Every guarded action has its own permission.
Audit row first, command second
Plugboard records covered operations, and writes the audit row for a privileged command before sending it. Export records and set retention. Authentication events and some configuration changes still have gaps, and the documentation says which.
Export and erasure, per person
Per-person export and erasure workflows and configurable retention. We are your processor: the data is the school's, we do not train models on it, and the sub-processor list is published.
Scanned, signed, with an SBOM
Every release image is scanned for vulnerabilities, published with an SPDX software bill of materials attestation, and signed with cosign. Your team can verify what it is running.
Vulnerability disclosure.
Report a security issue to security@plugboard.app. Say if you want to encrypt the report and we will send a key. The hosted demo is in scope and a reasonable place to test; customer deployments are not, without the customer's written permission.
We ask for 90 days before public disclosure, or until a fix has shipped and schools have had a fair chance to apply it, whichever comes first, and we credit reporters in the release notes unless they prefer not to be named.
Three commitments in every agreement.
A school should not depend on one supplier to keep running. These three commitments are part of every agreement and hold regardless of what happens to Plugboard.
- Your data exports in full, any time, in a machine-readable format. On exit we keep it for the window in your order so you can migrate, then delete it, including from backups.
- The same software runs self-hosted. If managed hosting ever stopped, your export runs on your own server with the same features.
- Source escrow is available on request, so a school can hold the code against a defined release event.
What we don't claim yet.
No SOC 2 or ISO 27001 certification, no ST4S assessment, and no independent penetration test. If any of these is a condition of purchase, tell us and we will say where each one stands.
What we do have is the control inventory above, sourced from the platform and reviewed against the code, and the operational evidence for your deployment on request.
Request our security pack
A two-page security summary, questionnaire answers and the continuity statement, for your business manager or IT committee.
Sent by email, usually the same working day.