Security, Privacy & Compliance
Last updated: July 28, 2026
Continuously scanned by Intruder
Our infrastructure is monitored around the clock by Intruder, an automated vulnerability scanning service used by thousands of security-conscious companies. New CVEs and emerging threats are checked against our public-facing systems on an ongoing basis, with high-severity findings triaged within 24 hours.
Listed on the CSA STAR Registry
ThouShaltNotClick is publicly listed on the Cloud Security Alliance STAR Registry with a completed Consensus Assessments Initiative Questionnaire (CAIQ v4) — the same self-assessment used by Microsoft Azure, IBM Cloud, and Fortinet. The registry maps our security posture to 197 controls across 17 domains, including encryption, access management, incident response, and supply chain security. View the full assessment at the link above.
Overview
ThouShaltNotClick is a cybersecurity awareness and phishing simulation platform built for K-12 schools and the organizations that serve them — public, private, charter, and faith-based alike. We take the security of your community's data as seriously as we take the security training we provide. This document describes our security architecture, privacy practices, and regulatory compliance posture in technical detail.
We encourage IT directors, diocesan/congregational CIOs, and school administrators to review this document as part of their vendor due diligence process. If you have questions not covered here, contact us at security@thoushaltnotclick.com.
Encryption & Data Protection
Data in Transit
All data transmitted between your browser (or browser extension) and our servers is encrypted in transit using TLS 1.2 or higher (TLS 1.3 where supported). We enforce HTTPS on all endpoints with HSTS headers.
Data at Rest
All data stored in our database is encrypted at rest using AES-256 encryption provided by our infrastructure provider (Supabase, hosted on AWS). Database backups are encrypted using the same standard.
Backups and Recovery
Our databases are backed up automatically. Application data and password-vault data live in separate databases and are backed up independently. We have tested restoring from these backups. Customers can request our recovery details at security@thoushaltnotclick.com.
Platform Architecture
ThouShaltNotClick is built on a modern, security-first technology stack. All infrastructure components are hosted in the United States.
| Component | Technology | Security Feature |
|---|---|---|
| Frontend | Vercel | Edge-deployed, HTTPS-only, CSP headers |
| API Server | Railway | Rate limiting, bot protection, input validation |
| Database | PostgreSQL via Supabase (AWS) | Row-Level Security, encrypted at rest, automated backups |
| Resend (transactional email) | DKIM/SPF/DMARC authenticated, webhook signature verification | |
| Payments | Stripe | PCI DSS Level 1, no card data touches our servers |
| Browser Extension | Manifest V3 | Client-side processing; no browsing data collected (the optional, school-enabled Content Filter records only blocked-site events). Requests all-sites host access — see "Browser Extension Permissions" below |
Browser Extension Permissions
The browser extension requests access to all websites. This section lists every permission it declares and what each one is for.
https://*/* and http://*/* host permissions. In Chrome’s install prompt this reads as “Read and change all your data on all websites”. It is a genuine all-sites grant, and Chrome has no narrower way to express what the on-page features below need. What it is not is a browsing-data collection channel: the features that use it run on the page in front of you, and the general-web ones only run when a user asks for them.API Permissions
| Permission | What it is used for |
|---|---|
| activeTab | Temporary access to the tab the user is currently on, granted at the moment they invoke the extension |
| storage | Settings, cached org domains, the learned-signal list, and the on-device sender-familiarity tally (sending domains and a count each), held on the device |
| contextMenus | The right-click entries: scan a link, open a link in Safe Preview, scan this page or this image for QR codes, check an image for AI generation |
| tabs | Reading the current tab's URL to set the toolbar badge and to notice when a mail tab opens. See the note on the toolbar badge below — this is the one permission with an ongoing network consequence |
| notifications | Desktop notifications: breach alerts, sign-in confirmation, and threat warnings |
| alarms | Periodic background work — the health heartbeat, the daily kindness-stat sync, and refreshing the phishing-signal list |
| declarativeNetRequestWithHostAccess | The optional Content Filter. Blocking is done by the browser's own rule engine rather than by our code inspecting traffic. No rules are installed unless your school turns the filter on and the policy resolves; if anything is missing it installs nothing |
Host Permissions
| Host | Why |
|---|---|
| mail.google.com, outlook.live.com, outlook.office.com, outlook.office365.com, outlook.cloud.microsoft | Where the phishing analyzer runs. This is the core product |
| thoushaltnotclick.com and our API host | Talking to our own backend, and letting the dashboard see whether the extension is installed |
| api.pwnedpasswords.com | The k-anonymity breach check — a 5-character hash prefix, never a password |
| https://*/* and http://*/* (ALL SITES) | Four capabilities need to run on an arbitrary page, and Chrome cannot scope them to "whatever page the user is on later": the QR-code scanner, the AI-generated-image check, password-breach warning on login forms, and password-manager autofill. The Content Filter also needs host access to redirect a blocked navigation to the extension's own block page |
What Actually Runs on a General Website
- QR-code scanner — user-initiated. It runs when someone clicks it in the popup or right-clicks, and it decodes what is already on screen so the user can see where a code points before trusting it. There is an opt-in “Auto-scan pages for QR codes” checkbox on the toolbar icon; it is off unless a user turns it on.
- AI-generated-image check — user-initiated only, via the popup or right-click. It sends the URL of the images being checked, and nothing else about the page.
- Password-breach warning — gated on the password-manager feature being enabled for that user; when it is off the script is a no-op. When it is on, it uses the k-anonymity check described above.
- Password-manager autofill — same gate. The “save this password?” capture banner is disabled outright for everyone.
- Content Filter — only for schools that enable it, and only enforces the policy the school configured.
Toolbar Risk Badge
The toolbar icon shows a risk rating for the site you are on. For sites not on the extension’s built-in list of well-known domains, a signed-in extension sends the site’s hostname (never the full address, the page or its content) to our API for a reputation check and caches the result. The lookup is not stored as a browsing record, and we do not build, store, or sell browsing profiles.
If your deployment cannot accept an all-sites grant, tell us at security@thoushaltnotclick.com. Chrome enterprise policy can restrict an extension’s host permissions at the managed-browser level, and the mail-analysis core keeps working with only the mail hosts granted — the general-web features are the ones that stop.
Access Control & Authentication
Role-Based Access Control (RBAC)
ThouShaltNotClick implements a strict role hierarchy with principle of least privilege. Each role can only access data within their organizational scope.
| Role | Scope | Access Level |
|---|---|---|
| Platform Admin | Entire platform | System management |
| Enterprise Admin | Archdiocese/Diocese | Cross-school reporting, license management |
| Organization Admin | Single school | Staff management, campaign management |
| Staff/Teacher | Own data only | Training modules, phishing reports |
| Parent/Family | Family data only | Family dashboard, student monitoring (if enabled) |
Multi-Factor Authentication (MFA)
ThouShaltNotClick supports both TOTP-based MFA (compatible with Google Authenticator, Authy, Microsoft Authenticator, and any standards-compliant app) and SMS text-message MFA for users who prefer a one-time code sent to their phone. Recovery codes are provided during MFA setup for account recovery.
Device Trust
When MFA is verified, users can optionally trust their device for 7 days. Trust is bound to two things that must both match a live, unexpired record: a device identifier held in that browser’s local storage, and a secret trust token our server issues at the moment of verification and stores alongside it. Presenting the device identifier alone does not work — a stolen or guessed identifier without the matching token re-prompts for MFA. Signing in from a different browser, a different profile, or after clearing site data always requires MFA again.
Impersonation Safeguards
Platform administrators can impersonate school accounts for support purposes. Impersonation tokens cannot carry platform admin privileges. All impersonation sessions are logged with the admin's identity, the target user, timestamps, and IP addresses.
Rogue Admin Prevention (Multi-Admin Co-Approval)
For destructive or sensitive admin actions, ThouShaltNotClick requires independent sign-off from a second administrator at the affected organization before the action can proceed. This prevents a single elevated account from unilaterally destroying or tampering with data across organizations.
- Peer-reviewable activity log: every modifying admin action — staff deactivation, role changes, configuration updates — is recorded with a snapshot of the row state before the change. Any peer admin at the same organization can review recent activity and undo reversible actions. Self-undo is gated to encourage cross-admin review.
The combination of multi-admin co-approval, a peer-reviewable action log, and user-visible notifications means that no single rogue admin — at any tier of the system — can quietly tamper with or destroy another organization's data.
FERPA Compliance
The Family Educational Rights and Privacy Act (FERPA) protects the privacy of student education records. ThouShaltNotClick is designed to operate as a "school official" with "legitimate educational interests" under FERPA.
How We Support FERPA Compliance
- We collect only the minimum data necessary to provide phishing simulation and security awareness training
- Student personally identifiable information (PII) is not required for platform operation — schools control what data they share
- All data access is controlled through RBAC with organization-scoped isolation
- Complete audit trail of all data access, modifications, and administrative actions
- Data export capability (FERPA-compliant format) for schools to fulfill parent/student access requests
- A school offboarding process that stops all product activity immediately, and permanent deletion of organizational data when the school asks for it
- We do not sell, rent, or share student data with third parties for any purpose
- We do not use student data for advertising, marketing, or profiling
Data Retention
We keep a school’s data for as long as the school is a customer. Offboarding a school stops all product activity at once — simulations, campaigns, staff access, seats and billing. Stored records are kept after offboarding so the school can still export them or answer a records request, and our team permanently deletes them when the school asks at privacy@thoushaltnotclick.com, including as part of the offboarding itself.
COPPA Compliance
The Children's Online Privacy Protection Act (COPPA) governs the collection of personal information from children under 13. ThouShaltNotClick's phishing simulation platform is directed at school staff (adults). In its default configuration we hold no student data at all — a school account is created with staff coverage only.
- Simulations are addressed to the staff target list. Student participation is a separate opt-in controlled by the school's administrator, and it is off by default for every organization. When a school turns it on, students receive their own campaigns on a send volume set independently of the staff cadence, drawn only from templates an administrator has marked age-appropriate. Adult-financial lures (payroll and direct-deposit changes, wire transfers, vendor and invoice fraud, tax, benefits, banking, W-2) are never sent to students, even if a template carrying one is tagged age-appropriate
- Students are held out of staff campaigns automatically. The check runs when a campaign is built and again when it launches, and if we cannot tell who on a roster is a student, the campaign does not launch
- Student records exist only if a school holds Student Coverage — purchased seats, or a contracted allocation we have granted the school — AND a principal, IT admin or enterprise admin has separately and explicitly accepted the Student Coverage terms (the FERPA/COPPA authority-and-consent representations) at their current version. That acceptance is its own recorded act, not a checkbox in general signup: we store who accepted, when, from what IP and browser, and which version, as an immutable receipt. Neither condition alone creates a student record
- Both conditions are enforced by one shared gate on every path that could store a minor's name, and the gate fails CLOSED — any error, any unverifiable answer, any un-applied migration means no student data is stored rather than the benefit of the doubt. This is the deliberate opposite of our availability checks, which fail open so schools are never locked out
- Student data can enter in only two ways. A directory sync additionally requires an admin to designate a group as a Student group. A parent invitation is the other: a parent creating their account enters their child's first name, last name and grade so the school can link them. If the gate refuses there, the parent's own account is created normally and the child's name is discarded before it is written anywhere, including our logs
- A directory-synced student ROSTER record holds first name, last name, school email address, and grade level. That is the whole record
- A student ACCOUNT — created only if the school issues students their own logins — holds more: sign-in and MFA data, training progress and quiz scores, breach-monitoring data for a personal address the student enters and verifies themselves, extension install status, and any report the student files from the extension (which carries a 500-character body excerpt, exactly as a staff report does). Schools that do not want that should not issue student logins or deploy the extension to student devices
- If student data is included in training scenarios (e.g., a simulated email referencing student names), schools control this content and obtain appropriate consent
- We do not collect personal information directly from children — student records come from the school's own directory, at the school's direction
- Schools acting as educational agencies may provide consent on behalf of parents under COPPA's school consent mechanism, and are responsible for obtaining it before designating a Student group
- Signed-in student sessions are excluded from our product analytics entirely
CIPA Compliance
The Children's Internet Protection Act (CIPA) requires schools receiving E-Rate funding to implement internet safety policies and content filters. ThouShaltNotClick supports CIPA compliance through cybersecurity awareness training that educates staff about online safety, phishing threats, and responsible internet use.
State Data Privacy Laws
Over 120 state laws protect student privacy beyond FERPA. ThouShaltNotClick's data minimization practices, transparent data handling, and strict purpose limitations are designed to satisfy the requirements of state laws including California's SOPIPA, New York's Education Law §2-d, and similar state-level student privacy statutes.
Schools with specific state compliance requirements should contact us for a tailored assessment.
Threat Intelligence & Email Analysis
Privacy-Preserving Analysis
In the ThouShaltNotClick browser extension — the product a school deploys — your email is analyzed on your device and the content never leaves it. The trust score, the findings and the recommendation are all computed in the browser. Email content reaches our servers only if the user explicitly opts in to AI-enhanced analysis, which is a per-email action taken each time.
When a user opts in to AI analysis, this is transmitted for that one email: the sender address, subject line, visible headers (Date, To, Reply-To), full link URLs with their display text, and up to 3,000 characters of the email body. Before the body is sent, the recipient’s own name and email addresses are stripped out of it. Our AI provider does not retain it or train on it. We never transmit or store the complete body.
Footnote — the Outlook add-in (beta). We also publish a separate Outlook add-in, currently in beta. Microsoft’s add-in platform cannot run our analyzer on the device, so the add-in transmits the sender, subject, link URLs and up to 3,000 characters of the body to our server for scoring every time a user opens the panel on an email — its default path, not an opt-in one. The message is scored in memory and the body is not written to our database on that path. The on-device statement above describes the browser extension; if your assessment depends on “email content never leaves the endpoint”, deploy the extension and not the add-in.
Where Email Text Is Kept
The browser extension analyzes email on your device. Email text is kept on our servers only in the cases below.
| Store | What triggers it | How much | Who can read it | Retention |
|---|---|---|---|---|
| Reported email excerpt | A user presses Report Suspicious | 500 characters (plus headers up to 16 KB and link URLs) | Administrators at that user's own organization | Erased 30 days after the report; sender, subject and verdict are kept |
| Phishing-sample corpus | AI analysis scores an email below 30/100 | Up to 3,000 characters, with the recipient's name and addresses removed. One sample per sender, the worst-scoring example seen | ThouShaltNotClick platform administrators only — not your school's admins, not any other organization | 30 days from the sender's last flag, then erased |
| Missed-phish report | An administrator tells us our score was wrong on a real phish | 500 characters | ThouShaltNotClick engineering only | 90 days, then erased |
| Learned phrase signals | An administrator confirms a report as phishing; we extract detection phrases from its subject and 500-character excerpt. A platform admin can also enter a phrase by hand when reviewing a missed-phish report | 3-to-5-word fragments (not the excerpt itself), stored with the IDs of the source reports and organizations — no sender, recipient or reporter. Names, email addresses, links and phone numbers are removed before any fragment is taken, and a fragment that still carries one is discarded | Pending fragments: ThouShaltNotClick platform administrators. Approved fragments are shared with TSNC browser extensions so they can be matched on the device | Deleted 365 days after the fragment was last seen in a new confirmed report. Removal on request |
| Reporter's optional note | A user reporting a sender can add a note in their own words | Up to 1,000 characters | Administrators at the reporter's own organization, and ThouShaltNotClick platform administrators reviewing the sender | Kept with the report; deleted on request |
Subject lines of reported senders are kept with the sender record. The administrator review-queue entry created when AI analysis scores an email below 30 holds the sender and subject only, and a Community Threat record shares the sender, subject, score and the AI’s explanation — never the body.
Retention jobs run daily. To have anything purged sooner, email privacy@thoushaltnotclick.com.
External Threat Intelligence
To check senders and links, we query commercial and public threat-intelligence services. They receive only a domain, a sender address or a link — never email content. Providers that receive personal data are listed by name under Third-Party Services & Subprocessors.
Password Breach Monitoring
When checking passwords against the Have I Been Pwned database, we use the k-anonymity protocol. Only the first 5 characters of the SHA-1 hash of the password are sent. The full password hash — and certainly the password itself — never leaves your browser. This is the same privacy-preserving method used by 1Password, Firefox, and the NIST 800-63B guidelines.
Audit Logging
All security-sensitive actions are recorded in an immutable audit log with the following fields: actor identity, action type, affected resource, timestamp, IP address, and relevant metadata. Audit logs are available to organization administrators for compliance reporting.
Actions Logged
- All login attempts (success and failure), including MFA verification
- User account creation, modification, and deletion
- Role changes and permission modifications
- Phishing campaign creation, launch, and completion
- External share approvals and denials
- Data export requests
- Organization onboarding and offboarding
- Administrative impersonation sessions
- browser extension installation and heartbeat events
Application Security
Input Validation & Injection Prevention
- All user inputs are validated and sanitized server-side
- HTML output is escaped using context-appropriate encoding to prevent XSS
- Database queries use parameterized statements (Supabase client) — no SQL injection vectors
- URL fetching for sandbox preview blocks private/internal IP addresses to prevent SSRF
- Webhook signatures are verified before processing
Rate Limiting & Abuse Prevention
- Rate limits and lockouts on sign-in and other authentication endpoints
- Bot protection (Cloudflare Turnstile) on public signup forms
- API rate limiting on all authenticated endpoints
- Abuse limits and duplicate detection on phishing reports and rewards
Session Management
- JWT tokens with configurable expiration
- Short-lived MFA challenges
- Session invalidation on password change
- Impersonation tokens cannot carry admin privileges
Third-Party Services & Subprocessors
We use the following third-party services to operate our platform. Each has been evaluated for security practices and data handling. A service appears here only if it receives data from us, and we update this list before a new service receives any.
Infrastructure
| Service | Purpose | Data Shared | Compliance |
|---|---|---|---|
| Supabase (AWS us-east-1) | Database & storage | All platform data (encrypted at rest) | SOC 2 Type II, HIPAA |
| Vercel | Frontend hosting | No user data — static assets only | SOC 2 Type II |
| Railway | API server hosting | API processing (no persistent storage) | SOC 2 Type II |
| Hetzner Cloud | Mobile Coverage mail relay (only for orgs that buy the add-on) | Full inbound email passes through in memory to score it and attach the trust banner. What is stored is the sender, the recipient, the score, and the scoring signals behind it — never the subject, body, or attachments. The scoring signals are derived facts about the shape of a message (whether your organization had heard from the sender before, whether it asked about a payment, what category of attachment it carried) and aggregate norms per sending domain — never its wording, its subject, or a filename | Hetzner DPA / GDPR terms |
| PostHog | Product analytics (cookieless, anonymous) | Anonymous page/click events — no PII, no signed-in student sessions | SOC 2 Type II |
| Stripe | Payment processing | Billing information only | PCI DSS Level 1 |
| Resend | Email delivery | Email addresses, email content of messages we send | SOC 2 Type II |
Email & Threat Analysis
| Service | Purpose | Data Shared | Compliance |
|---|---|---|---|
| Anthropic (Claude API) | Two distinct uses: (1) AI email analysis, opt-in per email; (2) the AI support chat on our website | (1) Sender address, subject, visible headers, full link URLs, and up to 3,000 characters of that email's body. (2) Whatever a website visitor types into the chat, the recent conversation history, and the help articles we matched to it — sent on every message, not opt-in. Not used to train models | SOC 2 Type II |
| Google Safe Browsing | URL threat checking | Link URLs from analyzed emails | Google Privacy Policy |
| EmailRep | Sender reputation & account age | Sender email address | EmailRep Privacy Policy |
| IPQualityScore (IPQS) | Fraud scoring, disposable-email detection | Sender email address, link URLs | IPQS Privacy Policy |
Identity, Directory & Messaging
| Service | Purpose | Data Shared | Compliance |
|---|---|---|---|
| Google (Sign-In / Identity) | Google SSO sign-in | The user's own Google access token, sent to Google to verify it | Google Privacy Policy |
| Google Workspace Admin SDK | Directory sync (only if your school connects it) | Read-only directory access using the token your admin grants. We receive staff — and, only under the Student Coverage rules, student — names, email addresses, and group/OU membership | Google Workspace DPA |
| Microsoft (Graph / Entra ID) | Microsoft SSO sign-in | The user's own Microsoft access token, sent to Microsoft to verify it | Microsoft Online Services DPA |
| Twilio | SMS verification codes (opt-in only) | Phone number and the verification message text. No marketing SMS | Twilio DPA / privacy policy |
| Cloudflare (Turnstile) | Bot protection on public signup forms | Challenge token and the visitor's IP address | Cloudflare DPA / privacy policy |
Breach Monitoring, Payouts & Agreements
| Service | Purpose | Data Shared | Compliance |
|---|---|---|---|
| Have I Been Pwned — password check | Checking a password against known breaches | 5-character SHA-1 hash prefix only (k-anonymity). The password and its full hash never leave your browser | Troy Hunt Privacy Policy |
| Have I Been Pwned — breach monitoring | Account and domain breach monitoring (opt-in) | The full email address or domain being monitored. This is a different feature from the password check above and it is not k-anonymized | Troy Hunt Privacy Policy |
| Tremendous | Referral and reward payouts | Recipient name and email address for the reward being issued | Tremendous DPA / privacy policy |
| BoldSign | E-signature for service agreements | Signer name, signer email address, and the agreement document | BoldSign DPA / privacy policy |
Roster Integrations — Direction of Data
OneRoster works differently. When your school connects a OneRoster SIS (FACTS, PowerSchool, Blackbaud, or another), we connect outbound to your SIS using credentials your school issues us, and roster data flows into TSNC. Your SIS vendor is your vendor, not our subprocessor — we do not send your data to them beyond the credentials needed to authenticate. Threat-intelligence feeds we download are one-way: we pull their published indicator lists and send them nothing about you.
Data We Collect & Why
| Data Type | Purpose | Stored Where | Retention |
|---|---|---|---|
| Staff email addresses | Account identity, phishing simulation delivery | Supabase (encrypted) | Duration of subscription; deleted on the school's request after offboarding |
| Staff names | Personalized training, certificate generation | Supabase (encrypted) | Duration of subscription; deleted on the school's request after offboarding |
| Phishing simulation results | Training analytics, security scoring | Supabase (encrypted) | Duration of subscription; deleted on the school's request after offboarding |
| Training completion records | Compliance tracking, badge awards | Supabase (encrypted) | Duration of subscription; deleted on the school's request after offboarding |
| Reported-email body excerpt (500 chars) | Admin triage of a staff report; phishing phrase-signal learning | Supabase (encrypted) | 30 days |
| Reporter's optional note (up to 1,000 chars) | Context the reporter chose to add to their report | Supabase (encrypted) | Kept with the report; deleted on request |
| Phishing-sample body (up to 3,000 chars, AI score below 30) | Detection research — how attacks are written | Supabase (encrypted); platform admins only | 30 days after that sender was last flagged |
| Missed-phish body excerpt (500 chars) | Diagnosing a phish our scoring let through | Supabase (encrypted); TSNC engineering only | 90 days |
| Learned phrase signals (3–5 word fragments) | Detection — the wording attackers reuse across campaigns | Supabase (encrypted). Pending: platform admins. Approved: shared with TSNC extensions for on-device matching | 365 days after last seen in a confirmed report |
| Website support-chat transcript | Answering the visitor; handing off to a human on request | Supabase (encrypted); TSNC platform admins. Each message is also sent to Anthropic to compose the reply | 90 days, deleted by a daily job. Conversations escalated to a human or flagged for review are retained beyond that until we delete them on request |
| Support-chat visitor contact details | Replying to a visitor who asked for a human | Supabase (encrypted); stored on the conversation — name, email address, free-text note, plus IP address and browser string captured at chat start | Same as the transcript above |
| Audit logs | Compliance, incident investigation | Supabase (encrypted) | 5 years |
| Extension telemetry | Extension health, feature usage | Supabase (encrypted) | 90 days |
Data We Do NOT Collect
- Student grades, test scores, or academic records
- Browsing history. The optional, school-enabled Content Filter records blocked-site attempts only, and the toolbar risk badge checks an unrecognized site's hostname without keeping a browsing record — both described under Browser Extension Permissions
- Complete email bodies. At most 3,000 characters of a message is ever sent for AI analysis or stored, and that limit is enforced on our servers. Attachments are never sent or stored
- Plaintext passwords (zero-knowledge encryption)
- Biometric data
- Social Security numbers or government IDs
- Health or medical information
Incident Response
In the event of a security incident involving unauthorized access to school data, we will notify affected schools within 72 hours of discovery, as required by most state breach notification laws. Our incident response process includes immediate containment, forensic investigation, regulatory notification (if applicable), and a detailed post-incident report shared with affected schools.
To report a security concern, contact security@thoushaltnotclick.com.
Certifications & Trust
Active Certifications & Memberships
| Standard | Status | Details |
|---|---|---|
| SDPC National Data Privacy Agreement | ✅ Signed | Standardized data privacy terms used by thousands of school districts nationwide. Covers data collection, use, retention, deletion, and breach notification. |
| CSA STAR Registry | ✅ Registered | Cloud Security Alliance Security, Trust, Assurance & Risk registry. Self-assessment mapped to 197 controls across 17 domains, covering SOC 2, ISO 27001, NIST, and PCI DSS. |
| BBB A+ Rating | ✅ Accredited | Education Technology Professionals, LLC holds a BBB A+ rating. Verified business practices, complaint resolution, and transparency standards. |
| NCEA Proud Partner | ✅ Active | National Catholic Educational Association partner. Committed to supporting Catholic school communities with purpose-built technology. |
| FERPA | ✅ Compliant by design | RBAC, audit logging, data minimization, data export, school official designation, 72-hour breach notification. |
| COPPA | ✅ Compliant by design | Platform directed at adult staff, not students under 13. Schools provide consent under COPPA's school consent mechanism. |
| CIPA | ✅ Supporting | Cybersecurity awareness training supports school internet safety policies required for E-Rate funding. |
| State Student Privacy Laws | ✅ Designed for compliance | Data minimization + transparent practices satisfy SOPIPA (CA), NY Ed Law §2-d, and 120+ state privacy laws. |
Certification Roadmap
| Standard | Target | Notes |
|---|---|---|
| SOC 2 Type I | 📋 Planned | The technical controls the audit evaluates (encryption, RBAC, MFA, audit logging) are already in place. |
| SOC 2 Type II | 📋 Planned | Follows Type I. Will include the Security and Privacy criteria. |
| ISO 27001 | 📋 Evaluating | Assessing timeline based on international market demand. CSA STAR registration provides foundational mapping. |
Our primary infrastructure providers — Supabase, Vercel, Railway, Stripe, and Resend — are independently SOC 2 Type II certified. The Hetzner Cloud servers that run the optional Mobile Coverage mail relay are operated under Hetzner's own DPA and GDPR terms rather than a SOC 2 report; they are dedicated to that add-on and hold no database. Our application implements the same technical controls these audits evaluate: AES-256 encryption, role-based access control, multi-factor authentication, comprehensive audit logging, rate limiting, input validation, and incident response procedures.
We welcome schools and dioceses to conduct their own security assessment. Contact security@thoushaltnotclick.com to request a completed vendor security questionnaire or schedule a call with our team.
Questions & Contact
For security questions, vendor assessment requests, or compliance documentation, contact our security team at security@thoushaltnotclick.com. For data processing agreements (DPAs), contact legal@thoushaltnotclick.com.
We are happy to provide a completed vendor security questionnaire, sign your school or diocese's data processing agreement, or schedule a call with your IT team to discuss our security architecture.