Security & data handling
How CampusMind stores and processes your documents on Azure, and what procurement will ask for.
In short
Your documents can contain student records. Most institutions run CampusMind in their own Azure subscription, which means the documents, the database and the model endpoint never leave infrastructure they already govern.
- Runs on
- Microsoft Azure — usually inside your own subscription
- Encryption
- TLS 1.2 minimum in transit, AES-256 at rest
- Model training
- Your documents are never used to train any model
- SOC 2
- Audit in progress. Report expected September 2026
Where CampusMind runs
| Self-hosted in your Azure subscription | CampusMind-hosted | |
|---|---|---|
| Subscription owner | You | CampusMind |
| Where documents live | Your Azure Storage account | CampusMind's Azure Storage |
| Region | Any Azure region you deploy to | All US Azure regions; other regions on request |
| Model endpoint | Your Azure OpenAI resource, your quota, your keys | CampusMind's Azure OpenAI resource |
| Who can reach the data | Your administrators, under your Entra ID and RBAC. CampusMind staff cannot reach data in your tenant | CampusMind operations staff, limited to what is needed to run the service |
| Retention and deletion | Your lifecycle policy, defined with you at deployment | 3 months by default, then deleted |
| Compliance evidence | Your existing Azure attestations, plus CampusMind's | CampusMind's |
Everything below describes the self-hosted deployment unless it says otherwise.
What happens to a document
CampusMind receives a file, rebuilds its structure, and returns the corrected version. The original is kept and never overwritten.
| Stage | How it is handled |
|---|---|
| In transit | TLS 1.2 minimum on every Azure endpoint — storage, database, and the model call; TLS 1.3 where both ends support it |
| At rest | AES-256. Azure Storage encryption is on by default and cannot be switched off; databases and managed disks use the same 256-bit encryption |
| Processing | In the Azure region or regions you deploy to. Nothing is processed outside your subscription |
| Model calls | Your own Azure OpenAI resource, reached over your network path |
| Model training | Never. Microsoft does not use prompts, completions or uploaded content to train or improve any Microsoft or OpenAI model, and does not share them with OpenAI |
| Retention | Yours to set. Documents and versions stay until your lifecycle policy or an administrator removes them |
| Deletion | Deleting the storage objects or the resource group destroys the data, subject to any soft-delete or backup window you configured |
Two Azure settings decide your data residency
Azure OpenAI deployment type. A Global Standard deployment may route the inference request to Azure capacity in any region, worldwide. Choose Data Zone to keep processing within a geography, or Regional / Standard to keep it in the resource's own region. Data at rest stays in your chosen region either way — it is the inference hop that moves.
Abuse monitoring. By default Azure OpenAI retains prompts and completions for up to 30 days so Microsoft can detect misuse. They are stored in the resource's geography and readable only by authorized Microsoft reviewers on a confirmed signal.
Institutions handling education records can apply to Microsoft for modified abuse monitoring, after which nothing is stored or human-reviewed.
What else is stored
Every record below lives in your own database. Nothing beyond this is collected.
| Record | What it holds |
|---|---|
| Accounts | Name, email address, role and group membership, created in-product |
| Document and batch metadata | File names, uploader, status, scores, version history |
| Model usage | Per file: the model called, input and output tokens, and cost, with batch, user and pipeline context. This is what drives cost reporting. |
Azure controls you keep
You own the subscription, so the standard Azure hardening controls are yours to apply. CampusMind does not need its own version of any of them.
| Control | What it gives you |
|---|---|
| Customer-managed keys | Hold the encryption keys in your Key Vault or Managed HSM, and revoke them |
| Private Endpoints | Keep storage, database, and the Azure OpenAI resource off the public internet |
| Managed identity | No connection strings or API keys in application configuration |
| Network rules and NSGs | Restrict traffic to your VNet and known ranges |
| Microsoft Defender for Cloud, Azure Policy | Continuous posture checks against your own baseline |
| Diagnostic settings and Activity Log | Infrastructure telemetry in your Log Analytics workspace — a record of actions on Azure resources, not of edits inside a document |
FERPA
Documents from a school or university may contain education records protected by FERPA. Those records never leave your Azure subscription, so the institution remains the custodian and CampusMind is a software vendor rather than a recipient of the data.
Microsoft's Products and Services Data Protection Addendum covers Azure, and states that Microsoft acts as a school official with legitimate educational interests — FERPA's own term — for the education records it processes on your behalf.
FERPA-aligned, without a separate addendum
CampusMind's data handling is built to FERPA: documents are processed solely to perform remediation and for no other purpose. A signed FERPA addendum is handled case by case rather than shipped as a standard document, so if your institution's counsel requires one, raise it with your CampusMind contact rather than assuming it is already on file.
Access control
Access to documents is scoped by group. Administrators decide which groups exist and who belongs to them; a user sees the batches and documents belonging to their groups.
Single sign-on is configured with you, not inherited from Azure
Deploying into your own Azure subscription does not by itself federate sign-in. CampusMind can sign users in against your institution's Entra ID — other OIDC or SAML providers on request — and CampusMind performs that setup during onboarding; your IT team maintains it afterwards, granting and revoking access in your own directory. It covers authentication, so a CampusMind Admin still places each person in the groups that scope document access. Without SSO, the application manages its own accounts.
Per-document change records are covered in Version history, which sets out what that record captures and how to use it as evidence.
Hosting and subprocessors
Microsoft Azure is the only infrastructure provider involved, and self-hosted it is your relationship with Microsoft, not ours.
- Self-hosted — Azure, in your subscription, in the regions you choose. No CampusMind-operated service handles document content.
- CampusMind-hosted — Azure is the subprocessor for hosting, storage and model inference. Email delivery, error monitoring and analytics also run on Azure services, so there are no further subprocessors beyond Microsoft.
What procurement will ask for
Some of this is Microsoft's to evidence, not CampusMind's.
| Artifact | Where it stands |
|---|---|
| Azure attestations | SOC 1, 2 and 3, ISO/IEC 27001, 27017 and 27018, and FedRAMP High cover the platform layer. Reports download from the Microsoft Service Trust Portal. |
| CampusMind SOC 2 | Covers the application layer, which Azure's reports do not. An audit is in progress and the report is expected in September 2026 — we will name it as available on the day it is issued, and not before. |
| HECVAT | The higher-ed vendor assessment questionnaire. A completed HECVAT is available from your CampusMind contact on request. Self-hosting also lets you answer the hosting, residency and data-handling sections from your own Azure posture. |
| VPAT / ACR | The accessibility conformance report for the CampusMind application itself, on request. A PDF/UA validation report for a remediated document is a different artifact — see Accessibility standards. |
Reporting a security concern
Report anything you find in CampusMind itself to info@campusmind.ai, or directly to the CampusMind solutions architect at ammar.ali@royalcyber.com. Suspected vulnerabilities in Azure itself go to the Microsoft Security Response Center, which runs Microsoft's own disclosure process.