Trust Center
How CADRE handles your data, who we rely on to run it, and what we commit to on availability.
This page describes the hosted CADRE service — the multi-tenant SaaS operated by Eduworks. It is written to be read by a security reviewer, so it states what we do not have as plainly as what we do.
We do not hold a SOC 2 attestation. If your review requires one, tell us early. It is on our roadmap and we begin it when a customer needs it, but we will not imply we hold something we do not.
CADRE holds a production Authority to Operate at IL5 on US Air Force networks (Platform One), with authorization in progress at IL4 in the US Navy ADE environment. That authorization covers those government deployments, not this commercial hosted service. We mention it because the engineering practice behind it informs how we build, not as a claim of accreditation for the SaaS.
Last updated September 2026.
Data handling
Where your data lives
Customer data is stored in Google Cloud Platform regions in the United States, in the region where the instance is provisioned. We do not replicate customer data outside the United States.
Tenant isolation
Every subscription gets its own instance rather than a row in a shared database:
- A dedicated Kubernetes namespace per subscription.
- Its own application and search workloads — no datastore is shared between customers.
- Its own persistent storage volumes.
- Network policies permitting traffic only from the ingress controller, so one tenant's workloads cannot reach another's.
- Per-tenant resource quotas, so no instance can exhaust capacity another depends on.
These controls are implemented and covered by our automated tests. They have not yet been examined by an independent penetration test; one is planned, and tenant isolation is in its scope.
Encryption
- In transit: HTTPS on every instance, with certificates issued and renewed automatically.
- At rest: storage volumes and backups are encrypted by Google Cloud Platform, which encrypts customer content at rest by default.
Who can reach your instance
- Nobody, until you say so. A new instance has an empty user list. Access is granted by adding a person on your account page, and changes take up to five minutes to reach the instance.
- Single sign-on. Sign-in is federated to Microsoft Entra ID or Google Workspace, so no password ever reaches Eduworks. You may point your instance at your own identity provider instead.
- Optional network restriction. You can limit your instance to specific IP addresses or ranges from the account page. Sign-in is still required — this is an additional layer, not a replacement for it.
Eduworks access to your account
Named Eduworks staff can access customer accounts for support. Every such access is logged, and access is limited to named individuals authenticating through Eduworks-controlled identity providers. We are enabling an automatic notification to the account owner and administrators whenever it happens, so that support access is never invisible to you.
Backups
Instance data is backed up to a private cloud storage bucket under a prefix scoped to your subscription. You can create, download and delete backups yourself from the account page. We do not delete your backups on a schedule — they are kept until you remove them.
What happens when you cancel
When a subscription stops being active we shut the running instance down and it stops being reachable. Your data is not deleted. The storage volumes are kept as they are, and reactivating the subscription brings the instance back with your data in place. Backups remain downloadable while the subscription is in this state, deliberately, so that cancelling never traps your data.
You can choose disposal instead. On the account page, next to your backups, you can elect to have everything permanently deleted when the subscription ends, or delete it immediately once the subscription has been cancelled. Both destroy the instance storage and every stored backup, and neither can be undone. Retention stays the default: a destructive option should take a deliberate action to reach, never the absence of one.
Eduworks support cannot delete your data on your behalf. That control belongs to the account owner and administrators alone, and staff access is explicitly refused on it — being able to help with an account is not the same as being able to destroy one.
This is how we meet NIST 800-53 MP-6 and 800-171 03.08.03 (media sanitization), SOC 2 C1.2 (disposal of confidential information) and CSA CCM DSP-16 (a verifiable deletion process) while keeping the safer default.
Subprocessors
These are the third parties that may process customer data as part of running the hosted service. All are located in the United States.
| Subprocessor | Purpose | Data it can see |
|---|---|---|
| Google Cloud Platform | Hosting, compute, storage and backup storage for the service. | All customer content stored in the service. |
| Stripe | Subscription billing and payment processing. | Account contact and billing details. Eduworks does not store card numbers. |
| Microsoft Entra ID and Google Workspace | Identity providers for single sign-on. | Sign-in identity: name and email address. No passwords reach Eduworks. |
| Google Workspace (SMTP relay) | Delivering account notification email. | Account owner and administrator email addresses, and the content of those notifications. |
| Slack | Internal operational alerting for the Eduworks team. | Subscription identifiers and account owner email addresses. No instance content. |
Changes to this list will be published here. If you need advance notice of subprocessor changes as a contractual term, raise it during contracting.
Uptime
Our current commitment is best-effort availability, not a contractual uptime percentage. We would rather say that than publish a number we are not yet measuring well enough to stand behind. Customers on sales-supported and enterprise agreements can negotiate a written SLA with defined availability targets and response times.
What best-effort means concretely, today:
- Every instance is health-checked continuously from outside the cluster, through its public hostname — so the check exercises DNS, TLS, the ingress and the application, the same path your users take.
- Failures alert our team automatically. We alert on a confirmed failure rather than a single missed check, so that alerts stay worth reading.
- Instances are restored automatically wherever the platform can do so.
- Maintenance that requires downtime is deferred to a weekly window rather than applied the moment it is discovered.
- Backups and restores take an instance offline for their duration. You choose when those run.
A public status page and published historical uptime are in progress. See the Service Level Agreement for the current written terms.
Security reviews and vulnerability reports
If you are evaluating CADRE and need more than this page — a completed security questionnaire, a data processing agreement, architecture detail, or answers on your own template — email security@eduworks.com and we will work through it with you.
To report a suspected vulnerability, use the same address. Please include a way to reach you and enough detail to reproduce the issue. We will not pursue anyone who reports a genuine issue in good faith.