Trust · security · data
Built for school districts. Documented for the IT review.
This page documents how Blackbox CLC handles accounts, payments, and (eventually) student data. It exists so curriculum directors, IT, and procurement can do their job without scheduling a call. If you need a signed addendum, email security@blackboxintelgroup.com.
Last reviewed: June 27, 2026
At a glance
What we do, in one screen.
Teacher accounts only (today)
v1 of the platform creates accounts for teachers and school administrators only. Students do not create accounts. No student PII is collected, processed, or stored.
Payments off-loaded to Stripe
Card numbers never touch our servers. Stripe is the merchant-of-record for online card payments. Invoices and POs are processed manually or via QuickBooks. We are PCI-DSS SAQ-A scope only.
Encryption in transit + at rest
All public traffic is HTTPS-only (HSTS preload-eligible). Database storage is encrypted at rest at the disk layer. User passwords are stored as bcrypt hashes only (never plaintext).
Audit log of sensitive actions
Account changes, purchases, refunds, role grants, and admin actions are written to a tamper-evident audit log we can produce on request for an in-scope account.
No advertising, no tracking pixels
We do not run third-party ad networks, tracking pixels, or session-replay tools. The site uses first-party analytics only.
Single-tenant deployment available
Districts that require a single-tenant or in-region deployment can request one as part of a District License contract. Contact sales@blackboxintelgroup.com.
Sub-processors
Who else processes your data.
We disclose every third-party service that touches account or payment data. Districts on a written contract receive 30 days' notice before any new sub-processor is added.
| Service | Purpose | Data shared | Region |
|---|---|---|---|
| Stripe | Card payment processing and PCI-DSS scope offload | Buyer name, email, billing address, card details (handled by Stripe; never touches our servers) | USA |
| Resend | Transactional email delivery (sign-in links, receipts, alerts) | Recipient email address, message content | USA |
| PostgreSQL (self-hosted) | Application database (users, purchases, library, audit log) | All application data not handled by another sub-processor | USA — operator-controlled |
| Auth.js (open source) | Authentication library (in-process, no third-party SaaS) | Local session and verification token tables in our database | n/a — runs in our process |
| Google / Microsoft / GitHub OAuth | Optional single-sign-on for teachers who choose it | Profile email + display name returned by the provider | USA |
Authentication
How sign-in works.
- Three sign-in modes: email + password, magic link (one-time email link), and OAuth (Google/Microsoft/GitHub). Districts can request that password-mode be disabled for their tenant.
- Password storage: bcrypt hashes with a per-hash salt. Plaintext passwords are never stored, logged, or transmitted server-side after the initial request.
- Sessions: Auth.js v5 JWT-backed sessions with rolling expiration. Sign-out invalidates the session cookie immediately.
- Brute-force defense:sign-up endpoint is rate-limited per IP. Sign-in attempts are logged in the audit trail.
- Account deletion: a user may delete their account from the dashboard. Deletion removes personal data and anonymizes audit-log entries within 30 days.
Student data (forward-looking)
What changes when student logins arrive.
v2 of the platform will introduce optional student accounts for progress tracking. We will not ship that capability without:
- A signed Student Data Privacy Agreement available for districts (NDPA-compatible framework).
- Data minimization:student records will store only the fields required for classroom use (display name, class enrollment, progress checkpoints). No DOB, no SSN, no demographic data.
- FERPA / COPPA alignment:we will operate as a school official under the FERPA school official exception, and avoid the COPPA verifiable-parental- consent path by collecting student data only at the direction of the school.
- Deletion on request:districts can request bulk deletion or export of their tenant's student data within 30 days.
Until v2 ships, no student data of any kind is collected.
Incident response
What happens if something goes wrong.
- Reporting: security researchers and customers can email security@blackboxintelgroup.com with reports. We acknowledge within 2 business days.
- Containment: on confirmed incidents, we rotate affected credentials, take the affected surface offline if needed, and preserve evidence (audit log, server snapshots).
- Customer notification:customers whose data is implicated are notified within 72 hours of confirmation. District contracts spell out the notification chain in detail.
- Post-mortem: we publish a redacted post-mortem on the changelog for any incident that affected service availability or data confidentiality.
For procurement
Documents we can sign.
- Data Processing Addendum (DPA) — available on request for District License customers.
- Student Data Privacy Agreement (NDPA) — available once v2 student logins ship.
- W-9, certificate of insurance, sub-processor list — available immediately.
- Custom security questionnaires (HECVAT, K-12 SIG, district-specific) — typical turnaround is 5 business days.