Security, privacy & compliance (FERPA, NY §2-d)

How AskElira protects student and guardian data — FERPA processor role, NY Education Law §2-d, encryption, and the agreements you can review before signing.

AskElira is built for student-data privacy. Your school stays the data controller and owner; AskElira is a FERPA processor / “school official” acting only on your instructions.

The agreements (review before you sign)

Read the full documents at schools.askelira.com/legal:

• [Master SaaS & Services Agreement](/legal/master-saas-agreement) — the overall contract, tiers, and security commitments.
• [Data Processing Agreement (FERPA)](/legal/data-processing-agreement) — controller/processor roles, exactly what data is processed, subprocessors, breach notice, retention & deletion.
• [NY Education Law §2-d Addendum](/legal/nys-ed-law-2d-addendum) — New York student-data privacy (8 NYCRR Part 121); controls on any conflict.
• [Parents' Bill of Rights — Supplemental Information](/legal/parents-bill-of-rights) — the standalone §121.3 supplemental-information document (a published copy of the Addendum's Exhibit B), ready for your school to append to its own Parents' Bill of Rights.
• [Subprocessor schedule](/legal/subprocessors) — the live list of every provider that can reach your families' data, incorporated into the DPA at §5.3.

What we protect — and what we never touch

• We process only what’s needed for enrollment outreach: guardian name/phone/email/language; student name; seat and application status, including your school system’s own record identifiers; grade level and campus; waitlist position; registration-paperwork checklist status (which documents are in or missing — never the documents themselves); an IEP yes/no flag only; enrollment notes your staff share; and the outcome/summary of each enrollment call and message.
• We never store IEP document content, disability category, service plans, evaluations, PHI, academic records, report-card grades, or SSNs — SSN-shaped text in any note, question, or call summary is automatically redacted before it is ever stored.
• We never sell student data, use it for marketing, or use it to train or improve AI models beyond delivering your service.

Pausing the AI

Three things use AI. Two of them touch your families and your records: the family question-and-answer assistant, and the send-or-hold review of staff enrollment notes. The third is this help assistant — the chat on these support pages, which answers your staff's questions about using AskElira from these articles. Nothing else does: your enrollment and attendance sequences are ordinary scheduled calls, texts and emails, and they never call a model.

You can pause all three, at any time, for any reason. Email akerremans@askelira.com. No fee, no notice period, no reason required; we action it and confirm in writing. Resume the same way. It is your right under DPA §3.7(c) and it shows in Settings so you can see the current state at a glance.

While paused, every family question goes straight to your staff instead of being answered, no staff note is released automatically, and the help chat on these pages stops answering. Your outreach keeps running — pausing the AI does not pause your enrollment season. These articles and the contact form keep working: pausing the AI never costs you a way to reach a person.

Who else touches your data (subprocessors)

A short, disclosed list, each bound in writing to confidentiality, security, breach notification, and deletion on our instruction: Twilio (texts and calls), Meta Platforms (the WhatsApp network), Google Cloud (Vertex AI — our AI model provider, on a US Processing Endpoint — plus Sheets), Turso (database), Vercel (hosting), AgentMail / Amazon SES (email), and SchoolMint (where you authorize the integration). A second AI model provider, Amazon Web Services (Amazon Bedrock), is named there too — see below. The whole schedule is published at [schools.askelira.com/legal/subprocessors](/legal/subprocessors) — every provider, what it does, what it can reach, and where it processes — and you get at least 30 days’ notice before we add or replace any of them.

From the v2.7 packet that published page *is* the schedule: DPA §5.3 incorporates it into your agreement, and the tables printed inside your signed packet are that same list as of the version you signed. It cannot be changed quietly. A change takes at least 30 days’ advance written notice to your authorized representative and your data-privacy contact, published at the same time, plus a real chance to object — and if we cannot accommodate your objection you can end the agreement without penalty. The published page governs only for changes you were actually given notice of; for anything else, the table printed in your executed copy is the one that counts.

That schedule is also the only place an AI model provider is named — the body of the contract no longer names one. Two things follow for you. Any provider that runs an AI model on your families’ questions or your staff notes is marked in the schedule as an AI model provider, so you can see who it is without reading the whole DPA. And changing it is a scheduled change with notice and your right to object — not a quiet swap. Two are in force today — Google Cloud (Vertex AI) and Amazon Web Services (Amazon Bedrock) — each for the functions its row states, and all inference runs on US Processing Endpoints.

The schedule names two AI model providers, and each carries specific functions stated in its row: Google Cloud (Vertex AI) carries the family Q&A assistant, the staff support assistant, and the reading of school-published documents like flyers and calendars; Amazon Web Services (Amazon Bedrock) carries the staff-note send/hold review, at zero data retention with zero operator access — nothing is stored. Both are US Processing Endpoints. The model AWS serves was developed by DeepSeek and is operated entirely by AWS inside AWS's United States infrastructure; the developer receives no content, and no content is used to train any model.

Naming a second source before we use one is the point. DPA §5.3 means the list of who *may* handle your families' information is something you are told in advance and can object to — so if the source ever changes, you read about it here first rather than finding out afterwards. Adding or replacing a provider still takes at least 30 days' written notice and a real chance to object.

One thing in the schedule worth reading rather than skipping: a staff enrollment note is free text your staff typed about a named applicant, so a student’s name is in it whenever your staff wrote one — and that note is what the send-or-hold review sends to the model. SSN-shaped text is removed first; names are not, because there is no dependable way to strip a name from free text and a partial removal would be a promise we could not keep. A family question is different: no name is attached to it at all. Both rows say so plainly.

Registration documents families email your office

A family can email a required document — a birth certificate, immunization record, proof of address — to your office instead of uploading it to your enrollment system. We identify which document it is, forward it to your staff inbox, mark it received so your tracker updates, and text the family what is still outstanding. We never store the document. What persists is the checklist status only: which document is in, which is missing.

No AI ever opens or reads the document. We identify which one it is from the file name and the email around it, never from the contents — so the checklist means "received and forwarded to you", never "verified". Confirming it is the right document for the right child is your staff’s call, in your own system. We tell the family the same thing in their own language, along with how to upload it to your enrollment system themselves, because that is where it ultimately has to land.

We considered having AI check documents and decided against it: a birth certificate carries a government ID number and a place of birth, and an immunization record is a health record — all categories the DPA forbids sending to a model provider. Reading them would have put two clauses of your contract in conflict.

Meta appears on that list because the packet lets a guardian reach the same Q&A assistant over WhatsApp as well as through the widget or a text. That channel is not switched on — nothing changes for your families today, and it would never run for your school without you enabling it. When it does run it is inbound-only: a guardian writes first and gets an answer, and we send no unprompted WhatsApp messages, no sequences, and no attendance alerts there. Unlike our other providers, Meta gives us no United States processing commitment at all, which is why it is named in the DPA’s residency section (§3.7), Exhibit A §5, and Exhibit B (5) rather than folded into the Twilio entry.

Security controls

Encryption at rest (AES-256) and in transit (TLS 1.2+), role-based access, multi-factor sign-in enforced on every dashboard account — including our own administrator accounts, with no exemption, security-event logging, and practices aligned to the NIST Cybersecurity Framework. No live student data connects until the DPA is executed.

Signing in takes two things: a password belonging to that one person, stored only as a salted digest we cannot reverse, and then a single-use link emailed to them. A correct password on its own never opens a dashboard, so neither a stolen mailbox nor a stolen password is enough by itself.

Insurance & liability coverage

AskElira carries General Liability, Professional Liability (Technology E&O), and Cyber Liability insurance — each at a $1,000,000 limit. The Cyber policy (United Specialty Insurance Company, A.M. Best A-rated) includes $1M for privacy, privacy-regulatory, network-security, breach-response, and data-restoration coverage — the exposures a student-data incident creates. So our security and privacy commitments are backed by real coverage. See the [Insurance & Liability Coverage summary](/legal/insurance-coverage), where the Certificate of Insurance (ACORD) is available to download.

Our monitoring record is public

Automated checks run against every record we hold for you, every hour, and alert a monitored inbox on anything they find. Rather than describe that, we publish it: [Security monitoring](/security) shows what each check looks for, how many passes and checks have run, the longest gap between them, and every incident opened and closed. The page generates itself from the monitoring, so it is never a claim we wrote once and left behind.

Two things are deliberately absent. The level at which each check raises an alarm is not published — that would tell someone probing the system how far to go without tripping it. And an incident appears only once closed: while one is open, the schools affected hear from us directly and first, within 48 hours of discovery, so each school decides what its own families are told.