Written for the reviewer, not the brochure.

This section states controls, not a compliance determination. It is written so that your counsel, privacy officer, or IT reviewer can reach their own conclusion rather than accept ours.

No identifiable student or guardian data at rest. Every field that names a student or a guardian, or that could be traced to one, is AES-256-GCM ciphertext under a key unique to that district: student name and student ID, the five address fields, guardian email and phone, homeroom, the IEP or 504 support-plan marker, the family-context note, the contact log's notes, its written prevention plan and the field recording which family member was spoken with, the destination number and body of every text message, the recipient address and rendered subject of every email, and every address on the bounce and complaint suppression list.

The lookups that need an exact match run on a keyed hash. The student reference on every contact-log row, the name-prefix index behind district-wide search, and the address index behind the email log are HMAC-SHA256 under keys derived from that district's master key. Keyed rather than a bare digest on purpose: an unkeyed hash of a student ID or an email address can be confirmed against a guess in milliseconds. A database copy yields neither a readable value nor a hash anyone can reverse.

Attendance counts and grade stay readable, by design. They are what the tier model, the dashboards, and the threshold flags compute on, in SQL, across roughly 281,000 rows a week at the largest scale supported. Sealing them would mean decrypting an entire district into memory to render one page. A stolen row reads “student reference 4471, week 12, 14 absences of 60 possible.” Attaching a name to that requires the district's key.

Each district is a separate database with its own key. There is no shared student table and no district column to filter on, so a query cannot cross districts even in principle. One district's ciphertext is meaningless to the holder of another district's key, and a stolen key opens one district.

The district's student information system stays the system of record. MoveableIQ keeps the weekly attendance history it needs to show a trend and the sealed identity record it needs to put a name on a worklist. We do not duplicate the SIS, and we do not ask the district to give up custody of its own data.

Everything sealed at rest uses AES-256-GCM, an authenticated cipher that detects tampering as well as preventing reads, with a fresh random nonce for every value, so the same name encrypts differently every time. Three categories:

• The student and guardian fields in the district's database, listed in the section above. The key is derived from a server-side district master key held outside the district's database and not present in any backup of it.
• The uploaded attendance file, sealed the moment the request carrying it arrives and deleted once its week is processed. It is a whole district's roster, so it is the largest single concentration of student data the system ever holds, and it is never written anywhere in the clear.
• The credentials table, holding the small set of operational secrets the application needs to talk to external services (mail providers, integration endpoints). Stored with PBKDF2 key derivation and AES-GCM under the same district master key.

The practical consequence: a database backup file, a disk image, or a stolen drive does not contain a readable student name, address, or guardian contact, and does not contain readable operational credentials. The server-held key is the second factor, and it does not travel with the data.

Every request is HTTPS. HTTP Strict Transport Security (HSTS) is enabled with a 365-day max-age and includeSubDomains, which means a browser that has visited the site even once will refuse to make a plaintext connection to it or any subdomain for the next year, even if a user types http:// by hand or follows an old bookmark.

There is no opt-out, no mixed-content fallback, no plaintext path through the application. A man-in-the-middle on a guest Wi-Fi network at a conference cannot downgrade the connection because the browser will not allow the downgrade.

Schools have a wide range of sign-in habits. MoveableIQ supports several methods, but every method is gated on the same foundation: a confirmed email, a strong credential, and a lockout policy that defeats brute force.

• Passkey (WebAuthn), the recommended primary method. Phishing-resistant by design, bound to the staff member's device. Works on most current laptops, phones, and tablets.
• Password, minimum 12 characters; must contain a digit, an uppercase letter, a lowercase letter, and a non-alphanumeric character; minimum 4 unique characters. These are enforced at creation, not suggested.
• Two-factor (TOTP), standard authenticator-app codes, compatible with the authenticator the district already uses.
• Google sign-in, available, enabled per district via its own Google credentials, for districts whose staff already live in Google Workspace.

The Admin role is held to a higher bar. A plain password is not sufficient for an Admin to sign in. The system requires a passkey, TOTP-protected password, or OAuth from a Google account that itself has 2FA enabled. The role that can change the system requires the strongest credentials, by policy, not by convention.

Five failed login attempts on any account trigger a 15-minute lockout. The lockout applies from the moment an account is created. There is no “new account” exemption that credential-stuffing attacks could exploit. An attacker working from a leaked password list gets five tries per account per 15 minutes, not unlimited.

No account can sign in until its email address is confirmed through a link the system sent to that address. An unconfirmed registration is not trusted, cannot authenticate, and is cleaned up automatically on a schedule. Terms-of-service consent is captured explicitly at registration and enforced server-side, not just in the UI.

Combined with per-IP rate limiting on registration and the failed-login lockout, this is a high bar for automated abuse. A script that registers a thousand accounts to use as a beachhead does not get a thousand sign-in-capable accounts. It gets a thousand pending records that will time out before anyone confirms them.

The endpoints that an outside attacker would actually target are rate-limited per IP. When a limit is exceeded the server returns HTTP 429 with a Retry-After header, the standard mechanism well-behaved clients respect and badly-behaved clients trip over.

• Registration, 5 requests per 60 minutes per IP.
• Login, 10 requests per 5 minutes per IP, in addition to the per-account lockout described above.
• Contact form, 5 requests per 60 minutes per IP, so the inbox does not become a spam target.

Four operational roles, with deliberate separation between operational work and system administration:

• Member, the base role assigned on registration, before a tenant Admin promotes the account. A Member can sign in but cannot see any district data.
• Principal / Counselor / Staff, school-scoped. Sees only the schools assigned to that user. This is the frontline tier that actually makes the calls and sends the messages.
• Manager, district-wide. Sees every school in the district, with cross-school rollups for leadership reporting.
• Admin, tenant configuration, user accounts, school assignments, integration settings. Intentionally small. The Admin role does not do operational outreach work; it manages the system that operational staff use.

User management is Admin-only. A Manager who runs the district's attendance program cannot promote or demote other users, and an Admin who manages the system does not automatically have a worklist of students to contact. The separation is structural, not policy.

Deactivation is a soft delete. When a staff member leaves the district, their account is disabled but the contact history they created is preserved with their identity intact. The institutional memory does not vanish when a person does.

Sensitive administrative actions are logged independently in an Audit Logs table, separate from the operational tables they describe. That includes credential reveal events, role changes, and key rotation events, the activities a security reviewer needs to see precisely because they are the activities a misbehaving admin would most want to hide.

On the operational side, contact log entries track LastEditedBy and LastEditedAt on every change. Deletes are soft, with DeletedBy and DeletedAt preserved. Nothing in the contact history is silently overwritten or silently removed; the record of what happened survives the record of what was changed.

State-reporting posture. The contact-log schema is structured to satisfy your state's attendance-conference documentation requirements without an additional reporting tool: each row carries a timestamp, the staff member who recorded it, the family member contacted, the channel (phone, text, email, in-person), and, for an attendance conference triggered by an early unexcused-absence threshold, the written prevention plan in its own dedicated field. The dashboard's documentation-gap panel flags any student past that threshold without a matching conference logged, so a compliance review and a worklist are the same artifact. State chronic-absence reporting itself still flows through the district's SIS. MoveableIQ is documentation infrastructure, not a reporting channel.

The authentication cookie is configured with the full set of modern protections:

• HttpOnly, not accessible to JavaScript. Defeats session theft via XSS, even if a script were ever to execute in a user's browser.
• Secure (always), only transmitted over HTTPS. Defeats interception on a compromised network path.
• SameSite=Lax, not sent on cross-site sub-requests. Mitigates CSRF without breaking normal navigation.
• 8-hour sliding window, an idle session expires after 8 hours of inactivity, which fits a school day. Re-authentication is required if a staff member returns the next morning.

A workstation left unlocked at 4pm does not have an active session at 7am.

Family outreach often travels by email, so the mail path is engineered as carefully as the data path. A multi-provider failover chain runs every send: a transactional email provider as the primary route, Azure Communication Services as the backup, and SMTP as a last-resort fallback. If one provider has an outage, the next picks up automatically and the staff member never sees the difference.

Each tenant sends from its own per-subdomain envelope. One district's deliverability reputation cannot affect another's, and an aggressive spam complaint against one district does not pull every other district down with it.

There is no bulk-mailer infrastructure. MoveableIQ does one-to-many personalized sends: every email is rendered against one specific recipient's data before it leaves the system. Parents never receive a message that reads “Dear Parent of [Student Name]” because the substitution happens inside MoveableIQ, not in a downstream mail-merge tool that might fail open.

This marketing site does not run analytics scripts, advertising pixels, or external session-recording tools. It is static HTML, CSS, and JavaScript served from a Windows IIS host. A district IT reviewer who opens DevTools and watches the network tab will see requests to the site itself and to Bootstrap's CDN, and nothing else. No third party knows that a particular district visited.

MoveableIQ is currently US-hosted, in a single region. The specific provider and region details are appropriate to discuss inside an NDA during a procurement conversation, and we are happy to put them on the table when the conversation gets to that point.

Multi-region hosting is a future capability if the customer base demands it; today, the simpler single-region posture is what is in operation, and we would rather be honest about that than describe an architecture we have not built.

K-12 public-school districts are Title II entities under the Americans with Disabilities Act. The Department of Justice's final rule, published April 2024, requires Title II entities to make their web content and mobile apps conform to WCAG 2.1 Level AA. The compliance deadline is April 2026 for districts serving a population of 50,000 or more, and April 2027 for smaller districts.

The tools a district provides to its own staff fall inside that scope. MoveableIQ is built to WCAG 2.1 AA so that it is not the reason a district fails its own accessibility audit. That includes keyboard operability on every interactive element, visible focus indicators, semantic heading structure, descriptive labels and ARIA where appropriate, color contrast that meets AA, and skip-to-content links on every page.

The same standard applies to this marketing site. If you want to verify, an automated scanner is a fine starting point, but a tab-through with a screen reader is the test that actually matters, and that is the test we run.

We would rather state a few things plainly than let a reviewer discover them by inference:

• We do not claim SOC 2, ISO 27001, or any other third-party audit certification. We are building toward the controls a future audit would expect; we have not been audited.
• We do not claim StateRAMP or FedRAMP authorization.
• We do not claim a published bug-bounty program. We do welcome responsible disclosure, and the contact form reaches a human.
• We do not claim multi-region high availability today. The current posture is single-region, with a documented backup strategy.
• We do not claim FERPA compliance or a FERPA certification. That determination belongs to your district's counsel, and no such certification exists for any vendor to hold. What we publish are the controls, described specifically enough to check.
• The at-rest claim covers student and guardian data, and says so deliberately. Staff identity is held by the application's authentication system in the normal way, which is the correct arrangement for an authenticated application rather than a gap, and it is stated here so a reviewer is not left guessing.
• Free text is a bounded exception. Bug-report text and administrator notes about staff members are readable, because an operator can paste anything into either. Staff are asked to keep what they type quantitative and procedural, which is a request rather than an enforcement, and we would rather name that than round it off.
• A column-by-column inventory of every table, including the classification of each field and the known gaps in the current build, is provided during a security review. An inventory that lists only strengths is the same failure as an overstated claim.