Skip to content

What we process

The answers a privacy assessment asks for. Your own deployment states most of this for itself under Admin, Compliance, which is the version to screenshot because it reflects your actual configuration.

CategoryExamplesWhere it comes from
PeopleNames, year levels, tutor groups, usernames, email addresses, student numbers, card numbersYour SIS and directory
DevicesSerials, models, assignment, lifecycle fieldsYour MDM, and records created here
WorkSubmissions, tickets, notes, statuses, outcomes, costsCreated in Plugboard
LoansWhich device, to whom, whenCreated in Plugboard
MoneyPurchases, damage chargesCreated in Plugboard
Staff accountsNames, emails, roles, MFA enrolmentCreated here, or SCIM
AuditWho did what, whenGenerated
ConfigurationModules, workflow, templates, encrypted connector credentialsCreated in Plugboard

Plugboard does not ask for and does not hold health data, ethnicity, or anything else in a special category under GDPR and equivalents.

The one thing worth flagging: free-text notes on submissions and tickets can contain anything a staff member types. A note explaining why a family cannot pay for a repair might touch on circumstances that are sensitive.

That is a training point, not a product one, and it is why ticket.internal exists as a separate permission.

Only where you send it, through connectors you enable.

CategoryWhat leaves
MDMDevice serial numbers, models, assignment and compliance state
SISStudent and staff names, year levels, identifiers and email addresses
DirectoryNames, usernames, email addresses and group membership
EmailMessage content and recipient addresses
SMSPhone numbers and message content
TicketingTicket subject, body and requester details
WarrantySerial numbers
Repair vendorSerial numbers, fault descriptions and contact details
SecurityDevice identifiers and application approval requests
CRMAccount and contact details
PrintingUsernames, card numbers and print balances
AIWhatever you ask the assistant, to a model you host

Stated per category rather than per connector, because the question is about the kind of data leaving, and swapping Jamf for Intune does not change the answer.

Your compliance page lists only the connectors you have actually enabled, which makes it a statement about your deployment rather than about the product.

Self-hosted: there are none. Nothing leaves your infrastructure except through connectors you configured, to vendors you already have a relationship with.

Managed: the hosting provider in your region, and the services listed in your agreement. Customer data stays in the region; backups replicate within it and nowhere else.

The control plane is global and holds counts, versions and billing records only. No names, no records, no content. See the control plane.

A deployment reports count-only usage: technician accounts, managed devices, enabled modules, version, deployment id.

No names, no records, no serials, no credentials, no content of any kind.

Self-hosted deployments can disable it entirely with USAGE_REPORTER_DISABLED=1, and export local snapshots instead. See licence and plan.

The in-product assistant runs against a model you host through the Ollama connector. Nothing is sent to an external AI provider. Without a model configured it uses a built-in offline command engine.

That guarantee is about the assistant. It does not extend to a third-party MCP client you choose to connect, because that client hands results to whatever model it uses.

If your assessment asks, state it this way: the product sends nothing to an external AI service; connecting an external MCP client is your decision, and API keys should be scoped accordingly.

Covered in audit and retention. Retention is configurable and erasure is a first-class operation rather than a manual database edit.

Admin, Backups exports a portable per-tenant copy at any time, without asking anybody. See backups in the app.