Compliance answers
Admin, Compliance (/admin/compliance).
Every answer on a departmental vendor assessment was already knowable from somewhere in Plugboard and not answerable from anywhere in it. A school filling in the form had to email and ask, which is slow for them and unnecessary for us, because the deployment already knows.
This screen states it.
What it tells you
Section titled “What it tells you”Where the data is held. The region, its location and its residency statement. Read from local configuration, not by calling home, so it still answers while cut off from everything, including during the incident where somebody is most likely to ask.
What each connector sends, and where. Stated per category, because the question is about the kind of data leaving, and a school swapping Jamf for Intune has not changed the answer.
| Category | What leaves |
|---|---|
| MDM | Device serial numbers, models, assignment and compliance state |
| SIS | Student and staff names, year levels, identifiers and email addresses |
| Directory | Names, usernames, email addresses and group membership |
| Message content and recipient addresses | |
| SMS | Phone numbers and message content |
| Ticketing | Ticket subject, body and requester details |
| Warranty | Serial numbers |
| Repair vendor | Serial numbers, fault descriptions and contact details |
| Security | Device identifiers and application approval requests |
| CRM | Account and contact details |
| Printing | Usernames, card numbers and print balances |
| AI | Ticket text and what you ask the assistant. Where it goes depends on which of the three AI connectors you configured |
Only the connectors you have enabled are listed, so the answer describes your deployment.
Which connectors are in demo mode. A connector in demo mode sends nothing anywhere, and one you thought was in demo mode and is not becomes a finding.
Retention settings. How long the audit log is kept, and what your erasure policy is set to.
Whether vendor access is enabled.
Sending us bug reports
Section titled “Sending us bug reports”Separate from vendor access, and pointing the other way. Vendor access is a door we might open into your server. This sends your words and your name outwards.
So the two default differently. The support API is available when the operator configures its deployment key, unless an administrator switches it off. Feedback defaults to nothing leaving, and somebody has to turn it on.
With it on, staff can send a bug report or a request from the feedback button in the top bar. You see what was sent and where each one got to: not sent yet, received, planned, being worked on, fixed and released, or not planned.
With it off, the button does not appear and nothing leaves. Nothing else about the product changes.
Vendor access
Section titled “Vendor access”The product support API requires an operator-configured deployment key. When configured, it is enabled unless an administrator switches it off; access does not expire automatically. Standard self-hosted configuration does not include this key.
Its authority includes deployment and administrator metadata, backup lists, restores and administrator setup links. A setup link can reset its named account’s password. Restore and setup-link operations record support audit entries; read requests are not all audited. See audit coverage.
Switch off support access blocks this API. It does not revoke hosting, database or remote access granted separately to an infrastructure administrator. Keep an administrator account available to change the setting. The beta candidate checks the opt-out for every school on the deployment, including inactive schools; confirm its deployment status.
Using it for an assessment
Section titled “Using it for an assessment”Screenshot this page. It answers, in the assessment’s own terms:
- Where is the data held
- Is it transferred outside that jurisdiction
- Which sub-processors receive what
- How long is data retained
- Can the vendor access our data
- What is the deletion process
The parts an assessment asks that this page cannot answer are the ones about your own configuration: who at your school has which permissions, and whether you have restored a backup. Those are roles and backups.
Erasure and retention
Section titled “Erasure and retention”Two different clocks.
Audit retention is operational and set by you. Longer is better for investigation and worse for disk and for privacy. See audit and retention.
Erasure removes a person’s records on request. It is built into the product rather than a manual database edit, which is what an assessment asking “how does deletion work” wants to hear.
The AI row
Section titled “The AI row”Where ticket text goes depends on which AI connector you configured, and the three answers differ:
- The bundled model, which runs inside your own deployment. Inference stays on that configured endpoint; enabled connectors, notifications and external clients have their own data flows.
- Your own key, through Anthropic or an OpenAI-compatible endpoint. Ticket text goes to that provider under your agreement with them, or to your own GPU box if that is what you pointed it at.
- Vendor-hosted AI, on managed plans that include it. Ticket text goes to our inference provider.
This page names the one you have. With no AI connector at all, the assistant still works using a built-in offline command engine and nothing goes anywhere.
None of that extends to a third-party MCP client you choose to connect, because that client hands tool results to whatever model it uses.
If that distinction matters to your assessment, and it usually does, state it this way: which AI connector is configured decides where ticket text goes, this page names it, and connecting an external MCP client is a separate decision you make. Scope API keys accordingly.