Security — Absentry

The short version

Absentry is a SaaS application that lets Texas school districts upload PEIMS attendance data and receive chronic-absenteeism risk scores per student. We hold student data on behalf of the district, encrypted, in a multi-tenant database where each district's data is isolated by foreign-key constraint and additionally filtered server-side by every API request.

We treat your data as the district's data, not ours. We don't sell it, share it across districts, train models on it across districts, or use it for any purpose other than running the service you signed up for.

What student data Absentry collects

Districts upload PEIMS-shaped attendance rosters. The fields we use are the ones already required by TEA for the official PEIMS submission your district already files. Specifically:

Identity: student_id (your local identifier), name, grade level, campus assignment.
Attendance: year-to-date and prior-year days absent and days enrolled; recent (last-20-day) absences; tardies.
Academic: failing course count and GPA (when provided).
Behavioral: discipline incidents and suspensions count (when provided).
Context flags: economically disadvantaged, English learner, special education, homeless, mobility count (when provided). These exist because PEIMS already tracks them and they have small explanatory weight in the model.

We do not collect: social security numbers, addresses, parent contact information, health records, disciplinary narratives, free-text counselor notes, or any data not used by the algorithm.

We do not collect any data classified as Protected Health Information (PHI). Where attendance patterns suggest a health-related root cause, Absentry flags this descriptively for the school nurse and 504 coordinator to review against the General Education Homebound program (SAAH §3.7) — Absentry never receives or stores medical records.

Where your data lives

Application: Hosted on Railway.com infrastructure in US-region data centers (primary: US-West).
Database: PostgreSQL managed by Railway, with encryption at rest enabled by the provider.
Static site: The marketing site (this page) is served by Netlify CDN.
Source code: Stored in a private GitHub repository accessible only to FORMA Group personnel.

All data in transit between district browsers and Absentry servers is encrypted using TLS 1.2 or higher (HTTPS). All data at rest in the database is encrypted using AES-256 at the storage layer (a feature of the Railway-managed Postgres service).

How districts are isolated from each other

Absentry is a multi-tenant SaaS, meaning multiple districts use the same application code and database — but their data is segregated by design.

Database tenancy: Every row of student, cohort, user, invite, audit, and upload data is tagged with a district_id foreign key referencing the owning district. There is no shared student data across districts.
Application tenancy: Every authenticated API request is scoped to the requesting user's district_id before any query is run. A district admin at District A cannot, by URL manipulation or any other means, request data belonging to District B.
Campus tenancy within a district: Within a district, users assigned to specific campuses (counselors, nurses, attendance officers) see only data for their assigned campuses. This is enforced server-side, not just hidden in the UI.
No cross-district analytics: Aggregate statistics (statewide chronic rate, calibration baselines) are derived from public TEA data, not from customer data.

Who can access your data

Your users: The district admin who signs up controls who else gets access. Invites are scoped to specific roles (district admin, campus user) and specific campuses. Magic-link invites expire in 14 days.
FORMA personnel: A small number of FORMA Group employees and contractors have administrative access to the production database for the purpose of operating the service. Today that is one person (the founder). As FORMA grows, access will be limited to personnel with a need-to-know and tracked via an internal access log. We will publish the count of personnel with production access on this page as it changes.
Sub-processors: See the list below.
Law enforcement: If we receive a valid legal request for district data, we will notify the affected district before disclosure unless legally prohibited from doing so.

Sub-processors

A sub-processor is a third-party service that touches customer data on our behalf. We list ours here:

Vendor	Purpose	Data touched	Region
Railway.com	Application hosting, managed Postgres database	All customer data at rest	US
Netlify	Static-site hosting for marketing pages	None — no customer data ever served from Netlify	US
GitHub	Source code repository (private)	Source code only — no customer data ever stored	US
Google Fonts	Web font delivery (Inter)	Page-load metadata only — no customer data	US

We will update this list whenever a new sub-processor is added. Districts on annual paid plans will be notified in advance of changes via email.

FERPA alignment

FERPA (Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g) governs the privacy of student education records and applies to your district. Absentry's role under FERPA is that of a school official with a legitimate educational interest performing services that the district would otherwise perform itself — specifically, analysis of attendance data to support intervention decisions.

To meet the FERPA school-official exception:

We use student data only for the purposes the district has authorized (running the Absentry service for that district).
We do not re-disclose student data to any third party except as required to operate the service (see Sub-processors above) or as required by law.
We maintain district control: the district remains the owner of all uploaded data and can request export or deletion at any time.
We sign a Data Processing Agreement (DPA) with the district on request. A standard DPA template is available; districts may also propose their own.

FERPA "compliance" is ultimately a property of the district's overall data-handling practices, not a single vendor. We provide the tools and contractual commitments that let your district treat Absentry as a FERPA-aligned vendor.

Data retention and deletion

Active customers: We retain uploaded student data indefinitely while the district has an active workspace, so that historical trends remain queryable.
Trial / inactive customers: If a district workspace becomes inactive (no logins for 12 months and no paid subscription), we will email the district admin before any deletion and give 60 days' notice.
On request: A district admin can request a full data export at any time. We will provide all uploaded student records, cohort scores, audit logs, and user metadata in CSV form within 30 days.
Right to deletion: A district admin can request full deletion of the workspace and all underlying data. We will confirm completion within 30 days and provide written attestation that the deletion is complete.

Currently: Self-service "Delete my workspace" and "Export all data" buttons are in development and target Q3 2026. In the meantime, contact rick@formagroup.net and we will execute the request manually within the 30-day window.

Authentication and account security

Passwords: Hashed using bcrypt with a cost factor of 12. We never store, log, or transmit passwords in plain text.
Sessions: Server-side session tokens stored in httpOnly cookies, scoped to the application domain. Sessions expire after 30 days of inactivity.
Magic-link invites: 32-byte cryptographically random tokens, single-use, expiring 14 days after issue.
Rate limiting: Authentication endpoints are rate-limited to mitigate brute-force attempts.

Coming in 2026: Multi-factor authentication (MFA), single sign-on (SSO via SAML/OIDC for the Enterprise tier), and IP-allowlisting are on the roadmap.

Incident response

If we become aware of a security incident affecting customer data, we will:

Contain the incident as quickly as possible.
Notify affected districts via email to the district admin on file within 72 hours of discovery, including: what we know about what happened, what data was affected, and what the district should do.
Provide a written post-incident report within 30 days describing root cause and the changes we've made to prevent recurrence.
Cooperate fully with district-led investigations.

To report a suspected security issue with Absentry, email security@formagroup.net. Vulnerability reports from independent researchers are welcome and we will not pursue legal action against good-faith reporters.

What we don't yet have

We believe it's more useful to be honest about what's not yet in place than to over-claim. Here's what we're working toward but haven't completed:

SOC 2 Type II audit. Not started. We will pursue this once the customer base justifies the cost (~$30K and 6+ months) — likely 2026-27.
Independent penetration testing. Not done. Will be commissioned as part of the SOC 2 process.
24/7 security monitoring. We use Railway's built-in monitoring; we don't yet operate a dedicated SOC.
Formal access-review cadence. Production access is small enough today to manage informally. We will document a quarterly review once the team grows.
Documented disaster-recovery runbook. Database backups are taken nightly by Railway; we do not yet have a tested restore-from-backup procedure.
State student-data-privacy attestations. Some states (California, Connecticut, others) require vendor attestations beyond FERPA. Texas does not have such a state-level requirement; we'll add others as customer geography requires.

If any of these items are a hard requirement for your district to do business with us, please tell us when you reach out — we can sometimes accelerate the timeline for committed pilots.

How to reach us

Security issues: security@formagroup.net
Privacy / data requests: privacy@formagroup.net
General inquiries / sales: rick@formagroup.net

FORMA Group · El Paso, Texas