Security, Privacy & Compliance

Overview

ThouShaltNotClick is a cybersecurity awareness and phishing simulation platform built for schools, dioceses, synagogues, mosques, and faith-based organizations of every tradition. 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 using TLS 1.3. We enforce HTTPS on all endpoints with HSTS headers. API communication uses certificate-pinned connections where supported.

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.

Backup — and the Limits of What We Will Claim About Restore

Backups are the automated ones our managed database provider takes. Application data and password-vault data live in two separate database projects, so each is backed up independently of the other.

What we are not going to tell you is that recovery is a proven capability. An earlier version of this page and our Trust Center advertised “point-in-time recovery available”. We have removed that claim. We have never performed a restore drill, we publish no recovery point objective and no recovery time objective, and until we have restored a real backup to a scratch environment and timed it, any number we gave you would be a guess dressed up as a commitment. Our one tested recovery control is code rollback, which re-points production at the previous build; our own rollback runbook states plainly that it does not undo a database change.

A restore drill and a written RPO/RTO are prerequisites we have set for ourselves before onboarding a school that depends on them. If your evaluation turns on recovery guarantees, ask us at security@thoushaltnotclick.com for the current status before you sign rather than reading a capability into this paragraph.

Platform Architecture

ThouShaltNotClick is built on a modern, security-first technology stack. All infrastructure components are hosted in the United States.

Browser Extension Permissions — Including the All-Sites One

If you are evaluating this for a district-wide deployment you will open the extension’s manifest before you approve it, and the first thing you will see is that ThouShaltNotClick requests access to every website. We would rather you read that here first, from us, than discover it in the manifest and wonder what else we did not mention. This section lists every permission the extension actually declares and what each one is for.

API Permissions

Host Permissions

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.

The Toolbar Badge — a Transmission Worth Naming

The toolbar icon shows a risk indicator for the site you are on. To do that, when a signed-in user navigates to a site that is not on the extension’s built-in list of well-known domains, the extension sends that site’s hostname — not the full URL, not the page, not its content — to our API for a live reputation lookup, and caches the answer. We are naming it because “the extension does not track browsing” is the kind of sentence that should be tested against what the code does, and a hostname leaving the device is the closest thing to an exception. The lookup is a pass-through to the threat sources listed under Threat Intelligence; it returns a verdict and is not written to our database as a browsing record. We do not build, store, or sell a browsing profile.

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.

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.

We want to correct something this page previously claimed. An earlier version said trust was also scoped to the network address, so that changing networks would force re-verification. That is not what the code does. We do record the IP address on the trust record when the device is first trusted, and it is available for audit, but no login path compares it — moving from school Wi-Fi to a home connection inside the 7-day window will not re-prompt. Binding trust to IP is a change we are considering rather than one we have shipped, and we would rather correct the claim than leave a control described that does not exist.

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

Phishing simulation data is retained for the duration of the school's active subscription plus 30 days. Offboarding a school stops every form of product activity at once — simulations, campaigns, staff access, seats and billing — and marks the organization inactive. We want to be exact about what it does not do, because the distinction matters for a FERPA assessment: offboarding preserves stored records rather than deleting them, deliberately, so that a school can still obtain an export or fulfill a records request afterwards. Permanent deletion of an offboarded school's data is carried out by our team when the school asks for it, at privacy@thoushaltnotclick.com, and we will do it as part of the offboard if you tell us that is what you want. There is no automatic job that erases an offboarded school's data on a 30-day clock, and we would rather say so than describe one that does not exist.

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 that belongs to the school's administrator and is OFF by default for every organization — and in this release there is no control in the admin interface to turn it on, so it ships in the off position. When a school enables it in a later release, students receive their own campaigns on a send volume set independently of the staff cadence, drawn from a separate pool of templates an admin has marked age-appropriate; that pool starts empty, and adult-financial lures (payroll and direct-deposit changes, wire transfers, vendor and invoice fraud, tax, benefits, banking, W-2) are refused for student recipients even if a template carrying one is tagged age-appropriate
• The gap we have not finished closing, stated rather than glossed: a student could historically be enrolled in a STAFF campaign by accident, simply by being on the roster that campaign was built from. The check that classifies students and holds them out — and that refuses to launch at all rather than guess when it cannot tell who on a roster is a student — is in place on the main campaign-launch path and is being extended to the remaining automatic campaign-generation paths. Until that is finished we do not claim accidental enrollment is impossible. Schools wanting certainty today should keep student accounts off the campaign target roster
• 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
• There are two such paths and we name both. 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, and we would rather list it than imply otherwise: 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. A 3,000-character body excerpt is email content, not metadata, and we describe it that way deliberately. 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.

Where We Retain Free Text From, or About, an Email — the Complete List

Elsewhere on this site we say email content is not stored. That is true of the routine paths and false as an absolute, so here is the complete enumeration.

An earlier version of this page listed four stores and said “and no others”. That was wrong, and the correction matters more than the wording: the four we listed are the ones that hold text lifted from an email body, but they are not the only places free text about an email comes to rest. A user filing a report can type a note in their own words, and that note is stored — nobody had written it down. It is rows five and six below. We are stating the miss rather than quietly widening the list, because a store we had not disclosed is exactly the failure this section exists to catch, and it is the second time it has happened here.

Two clarifications so this list is not read as broader than it is. The reporter’s note is typed by a person, not extracted from the message — but it sits in this section because a free-text box next to an email is a place email content ends up, and pretending otherwise is how the first four came to be under-counted. Separately, we store the subject line of reported senders alongside these notes; a subject is email content too, it is retained with the sender record rather than on the 30-day excerpt clock, and it is not a body excerpt, which is why it is called out here rather than given its own row.

Two things that are not stores of body text, despite common assumption: the administrator review-queue entry created when the AI scores an email below 30 carries sender and subject only, and the Community Threat record shares the sender, subject, score and the AI’s written explanation — never the body itself.

How Those Erasures Run

The retention column above says what we erase and when. It is worth being equally precise about how, because the honest answer is not “a nightly cron”. The three timed erasures are sweeps hung off the code paths that touch each store — submitting a report sweeps report excerpts, filing or reviewing a phishing sample sweeps the sample corpus, submitting or opening the missed-phish queue sweeps that one — each throttled to at most once per hour per process. In normal operation content past its window is gone within about an hour of the next time that surface is used; on an idle deployment it can persist longer. Every sweep re-counts the rows that should now be empty and raises a persisted alert if any remain, so a retention promise cannot fail quietly the way an unmonitored cron can. Moving these onto the same daily schedule that already drives our log and chat-transcript retention is queued work, and until it ships this paragraph is the accurate description. Immediate purge on request: privacy@thoushaltnotclick.com.

External Threat Intelligence Sources

For enhanced threat detection, we query the following external services. Only sender domains, email addresses, and link URLs are sent — never email content.

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 (Resend via Svix, Stripe via built-in verification)

Rate Limiting & Abuse Prevention

• Authentication endpoints: 10 requests per 15 minutes per IP
• Cloudflare Turnstile CAPTCHA on all public signup forms (6 endpoints)
• API rate limiting on all authenticated endpoints
• Phishing report abuse prevention: 3 point-earning reports per day per user, duplicate detection

Session Management

• JWT tokens with configurable expiration
• MFA tokens expire in 5 minutes
• 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 actually receives data from us today — services we have built support for but have not activated are listed separately below the table.

Infrastructure

Email & Threat Analysis

Why three names that used to appear here are gone. A subprocessor is a party that processes personal data on our behalf. We previously listed RDAP / WHOIS, PhishDestroy and abuse.ch (URLhaus) in this table. Those are public-registry and threat-feed lookups: what we send them is a bare domain name or a link URL, never a person, an account or an email address. Listing them as subprocessors overstated what they receive and blurred the category, so they now appear under Threat Intelligence & Email Analysis, which states exactly what is sent to each. This makes the subprocessor list more accurate, not shorter in substance — nothing we send them has been removed from disclosure.

Identity, Directory & Messaging

Breach Monitoring, Payouts & Agreements

Built But Not Active

We have written integrations for Clever (roster sync), CanIPhish (supplemental training), SheerID and GovX (discount eligibility verification), APWG / eCrimeX (phishing takedown submission), and Vendasta (reseller mailbox provisioning for the consumer Complete Coverage plan). None of these are provisioned in production today — no credentials are configured, so no data is sent to any of them. Each integration is written so that with its credentials unset every call is a no-op. If we activate one, it moves into the tables above before it goes live.

Sightengine (AI-generated image detection) sits in between and we would rather say so than round it off. The feature is user-initiated — a staff member asks us to check one image — and when it runs it sends only the URL of that image: no email content, no subject, no sender, no account identifier. But it only calls Sightengine at all when its API credentials are present in our environment; with them unset the check falls back to our own local provenance analysis and nothing is sent. Because we cannot promise you it is switched off today, we list it here rather than in the active table above. Ask us at security@thoushaltnotclick.com if the current state matters for your assessment and we will tell you exactly.

Roster Integrations — Direction of Data

OneRoster works differently from everything above and is worth stating plainly. 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 consume in bulk (AlienVault OTX, OpenPhish, PhishTank) are download-only: we pull their published indicator lists and send them nothing about you.

Data We Collect & Why

Data We Do NOT Collect

• Student grades, test scores, or academic records
• Browsing history — we do not build, store or sell a record of the sites a user visits. Two precise caveats rather than a flat claim: the optional, school-enabled Content Filter records blocked-site attempts (never general browsing), and the toolbar risk badge sends the hostname of an unrecognized site for a live reputation lookup that is not retained as a browsing record. Both are described under Browser Extension Permissions
• Complete email bodies — on any surface, by any path. 3,000 characters is a hard server-side ceiling on what we forward to the AI provider AND on what we write to our database, and it is enforced at our own API boundary rather than trusted from the client: our scoring endpoint truncates an over-long body before scoring it and tells the caller in the response that it did, and the AI endpoint truncates before both the outbound call and the stored sample. A modified extension, a stale add-in build, or a hand-written curl request cannot raise it. On the server that number comes from one shared constant; our client apps carry their own copy of it — the browser extension is sandboxed and cannot import server code — so they trim before upload as a courtesy, but the ceiling that actually binds is the server one. Attachments are never transmitted or stored at all
• 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

SDPC NDPA Signatory

CSA STAR Registered

FERPA Compliant

BBB A+ Rating

NCEA Proud Partner

Active Certifications & Memberships

Certification Roadmap

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.