Privacy Policy

Last updated: August 19, 2026

Who we are

MoveableIQ (also referenced as demo.moveableiq.com) is an internal attendance-intervention tool operated by the school district. Access is limited to authorized district staff.

What student data we store, and how

This section describes the system’s actual data handling. It states no compliance determination, and none should be read into it: that conclusion belongs to the district’s FERPA officer and counsel. Student information IS stored in the database. What follows is how.

• Everything that identifies a student or a guardian is encrypted at rest. Name, student ID, home address, parent email, parent phone, homeroom, the IEP / 504 support-plan marker and the standing family-context note are stored as AES-256-GCM ciphertext under an encryption key that belongs to this district alone and is not held in the database. They are decrypted in memory only for the rows a page is actually displaying to an authorized user. A copy of the database taken without that key does not yield any of them.
• Weekly attendance is stored readable, and deliberately. Each week’s absence total, days possible and unexcused counts are kept per student, as history, along with grade and internal numeric references to school and week. Those counts are what every tier, dashboard figure and statutory trigger is calculated from, in the database, so encrypting them would mean decrypting the whole district for every page. A stored row on its own reads as a number with no name attached to it.
• The contact log identifies a student by a keyed, irreversible hash (HMAC-SHA256 under a key derived from this district’s master key), never by name or raw ID. The key makes it irreversible in practice as well as in principle: a plain hash of a student ID could be worked backwards by trying every plausible ID, and a keyed one cannot be, even by someone with full database access. The hash is the same for a student across school transitions, so their contact history follows them.
• The contact log also records the staff member’s account, the tier at the time of contact, the channel, the outcome, and free text the staff member types: notes on the conversation, the written prevention plan where one applies, and who at the family was spoken with. All three are encrypted at rest under the same district key, because the last of them exists to record a guardian’s name. Encryption is not confidentiality from the school: every one of these fields is part of the student’s record, readable by staff authorized for that school and producible in a compliance review, and staff are asked to keep them quantitative and procedural.
• Outbound messages leave a record, and it is sealed. The email activity log stores each message’s recipient address and rendered subject line, which for a family email means a parent’s address and the student’s first name; both are encrypted under the district key and message bodies are not stored at all. An address that hard-bounces or reports a message as spam is recorded so we stop sending to it, and that list is encrypted too, with the lookup running on a keyed one-way value rather than on the address. Text messages are logged with the phone number and message text encrypted the same way.
• What is not covered by the sentence at the top. Weekly attendance counts, grade and internal reference numbers stay readable, as described above. Text typed into a support ticket is stored as typed, so staff are asked not to paste a student’s details into one. Application error records keep the message an error produced, though they no longer keep the student ID a failing screen was working on. And staff account details are held by the sign-in system, described next.

What staff data we store

For each authorized staff account, we store: name, work email, work phone (optional), staff title, the schools the staff member is permitted to view, the role(s) assigned by an administrator, and standard authentication metadata (last login, lockout state, etc.). This information lives in the application database for the duration of the staff member’s authorization.

Staff account details are held by the application’s sign-in system rather than by the district-key encryption described above, which is the normal arrangement for any application that signs people in: the sign-in system looks an account up by its email address every time someone signs in, resets a password or accepts an invitation. Passwords are never stored, only a one-way hash of them, and a passkey stores only the half of the credential that is meant to be public.

How we use this information

• To authenticate staff members and authorize their access to specific schools.
• To classify each student’s attendance against this state’s rules and present the resulting worklist to the staff assigned to that school.
• To populate the family-communication scripts staff use to reach out.
• To compute district-level and per-school outreach summaries, which are stored as counts and rates with no student-level row of their own.
• To send transactional emails related to the staff member’s account (password reset, two-factor codes, account confirmations).

Text messages to families

A district can turn on text messaging. Where it is on, a staff member can send an individual text message to a student’s parent or guardian from that student’s record, about that student’s attendance. Every message is composed and sent by a named staff member, to one family, about one student. Nothing sends a text on a schedule or without a person deciding to send it, there are no marketing texts, and no messages go to anyone who is not the parent or guardian of an enrolled student.

Email works differently, and the difference is worth stating plainly. A district can send the same message to many families at once by email, and the system then delivers it to each recipient individually and personalized to that family. There is no equivalent path for text messages.

The number is the one the family already gave the district. It arrives in the weekly student information export and is stored encrypted, the same as every other guardian contact detail described above. The district’s student information system stays the system of record, so a family who wants a number changed or removed asks the district, and the change reaches this application on the next weekly export.

A family can reply STOP to any message to stop receiving texts, or HELP for help. Opt-outs are honored automatically by the messaging service that carries them, and this application also marks a number that has opted out so the text channel is no longer offered to staff for that family. Message frequency varies, and message and data rates may apply.

Each send is recorded for audit. The destination number and the message body are encrypted at rest; what stays readable is the delivery outcome, the reason a message failed, and which staff member sent it.

Cookies and session data

We use a single first-party authentication cookie to keep signed-in staff signed in across pages. We do not use advertising, tracking, or third-party analytics cookies.

Third-party services

Outbound email (account confirmations, password resets, family messages, contact-form messages) is delivered through Postmark, Azure Communication Services or an SMTP provider configured by an administrator. Text messages, where a district has enabled them, are delivered through Twilio. Attendance data reaches the system only by an administrator uploading an export from the district’s student information system; there is no automated connection to any external data source. These providers process data on our behalf under their own privacy terms.

Data retention

• Roster and attendance data: retained per student per week as history, for the life of the system, so that year-over-year and week-over-week comparisons are possible.
• Contact-log entries: retained as-is for the life of the system; a deletion is a soft delete that keeps the row for audit. Periodic district-level review may apply.
• The uploaded export file: held encrypted only for the duration of its import, then deleted.
• Email activity log: cleared by an administrator on request; there is no automatic purge.
• Application error logs: automatically deleted after 30 days.
• Staff account records: retained while the staff member is authorized; deactivated when access is revoked.

Security

The application runs on HTTPS only. Every field that identifies a child or a guardian, and the IEP / 504 support-plan marker, is encrypted at rest with AES-256-GCM under a key unique to this district and held outside the database. Where the system has to look a value up by an exact match, such as an email address on the do-not-send list, it stores a keyed one-way value instead of the address, so a copy of the database yields neither the address nor anything that can be worked back to it. This district runs in its own database, so there is no shared pool of student records. Sensitive system credentials (API keys, third-party service passwords) are encrypted at rest the same way. Staff authentication uses standard ASP.NET Identity password hashing. Two-factor authentication is available and may be required by the administrator. Database access is restricted to the application and to a small number of administrators.

One operational limit worth stating plainly: if an administrator rotates the district’s encryption key twice without importing a current week in between, the stored student names and IDs sealed under the original key cannot be recovered. The rotation screen warns about this at the point of use.

Your rights as a staff member

You can review and update your name, contact information, and staff-title fields from the Account Management page after signing in. That includes your own phone number, which you can add, change or remove yourself without going through an administrator. To request changes to your role, school assignments, or to deactivate your account, contact your administrator. To request deletion of contact-log entries you authored, contact your administrator and reference the relevant week.

Questions

Use the Contact form to reach the MoveableIQ team with privacy-related questions, or escalate to your school’s administration or the district’s designated FERPA officer.

Internal district tool. Not licensed for redistribution outside the district.