I'm Marcus, Arcline's lead engineer. Before joining, I spent six years building data infrastructure — three at a healthcare SaaS company where HIPAA compliance shaped everything we built, and three at a fintech startup where we learned the hard way what happens when you treat security as a phase-two feature. (Short version: there is no phase two. There's phase one and then there's a breach.)
When Alex asked me to join Arcline, my first question wasn't about the product roadmap. It was: how seriously are we taking FERPA? His answer — "it's the first thing we build" — is why I'm here.
Why FERPA Isn't a Checkbox
The Family Educational Rights and Privacy Act protects student education records. That sounds simple. In practice, it's a constraint that touches every layer of a data platform: how data is stored, who can access it, how queries are processed, how results are returned, and how every access is logged.
Most EdTech companies treat FERPA compliance as a policy document and an annual training. They add a Terms of Service page, sign a Data Privacy Agreement with each district, and call it done. That handles the legal surface. It doesn't handle the engineering surface.
If your database schema allows a query from District A to accidentally return rows belonging to District B, your DPA doesn't matter. If a natural language query about "students with low attendance" returns PII in the response that gets cached in a shared layer, your training module doesn't matter. FERPA compliance is an architecture problem, not a paperwork problem.
Tenant Isolation from Day One
The most fundamental decision we made was tenant isolation. Every district's data is logically and physically separated. We don't use row-level filtering on a shared database and hope the WHERE clause never fails. Each district gets its own isolated data store.
This is more expensive to operate. It's harder to manage at scale. It means we can't do the easy thing that most multi-tenant SaaS platforms do, which is throw everything into one database and filter by a tenant ID column. We made that tradeoff deliberately.
The reason is simple: in a shared-database architecture, a single bug in a query filter — one missing WHERE clause, one malformed join — can leak data across district boundaries. In an isolated architecture, that bug can't cross the boundary because the boundary is infrastructure, not logic. A query running against District A's data store physically cannot return District B's records, because District B's records aren't there.
Is this belt-and-suspenders? Yes. When you're handling the education records of minors, belt-and-suspenders is the minimum.
Encryption: At Rest and In Transit
All data at rest is encrypted with AES-256. All data in transit is encrypted with TLS 1.3. These are table stakes in 2025, but they're worth mentioning because the implementation details matter.
Encryption at rest means that if someone gains access to the underlying storage — a compromised disk, a misconfigured backup, a cloud provider incident — they get ciphertext, not student records. Each district's data store uses its own encryption key, managed through a hardware security module. Rotating a key for one district doesn't affect any other district.
TLS 1.3 for data in transit means that the connection between a district user's browser and our servers, and the connections between our internal services, are encrypted with the latest transport protocol. We don't support TLS 1.2 fallback. If a client can't negotiate TLS 1.3, the connection is refused. This is a deliberate choice — backward compatibility is not worth the downgrade risk.
Role-Based Access Control at the Field Level
This is where things get genuinely hard.
RBAC in most SaaS products means: admins can see everything, regular users can see most things, read-only users can see some things. In a school district, the access model is far more granular than that.
A superintendent needs to see aggregate data across all schools. A principal needs to see student-level data, but only for their building. A school counselor needs to see sensitive fields — disciplinary records, IEP status, mental health referrals — but only for students on their caseload. A classroom teacher needs to see assessment scores and attendance for their own students, but not disciplinary details or special education records.
We built RBAC directly into the query layer. It's not a filter that runs after the query returns results. It's a constraint that shapes the query before it executes. When a principal at Jefferson Elementary asks "show me chronic absence rates by grade," the system doesn't fetch all students and then filter to Jefferson. It constructs a query that only touches Jefferson's data in the first place. The principal never sees — and the system never retrieves — records from other buildings.
Field-level RBAC is the harder version of this. A counselor and a principal looking at the same student might see different fields. The counselor sees IEP accommodation details. The principal sees IEP status (yes/no) but not the specifics. A teacher sees neither. This isn't cosmetic — hiding a column in the UI while the data sits in the API response. The restricted fields are excluded from the query results at the database level. They never leave the data store.
The Natural Language Problem
Arcline lets district staff ask questions in plain English instead of writing SQL. That's the product. It's also the hardest security problem we've had to solve.
When a user types "which eighth graders at Lincoln Middle School have missed more than 15 days this year," we translate that into a database query. The security challenge is that the natural language input might reference students, schools, or data fields that the user doesn't have permission to access. The query translation layer has to enforce RBAC before the query runs, not after.
We handle this with a permission-aware query planner. Before a natural language query is translated into SQL, the system resolves the user's role, determines their accessible scope (which schools, which students, which fields), and constrains the query generation to that scope. If a teacher at Lincoln Middle School asks about students at Washington High School, the system doesn't return an access denied error on the results — it never generates the query in the first place.
The other challenge is PII in query responses. If a superintendent asks "what's the average attendance rate for students receiving special education services," the answer should be a number, not a list of names. Our response layer strips PII from aggregate queries automatically. When a query is classified as aggregate, the system enforces minimum group sizes (we default to n=10 to prevent re-identification) and returns only the statistical result.
Audit Logging: Every Access, Every Time
Every data access in Arcline is logged. Every query, every result set, every export, every report view. The audit log captures who accessed what data, when, from where, and what the query returned. These logs are immutable — they're written to an append-only store that can't be modified or deleted, even by our own engineering team.
This isn't just for compliance. It's for the districts. When a parent files a FERPA request asking who has accessed their child's records, the district needs to be able to answer that question completely and accurately. Our audit system makes that a query, not a research project.
The "School Official" Question
Under FERPA, a third party — like Arcline — can access student education records without parental consent if the district designates that party as a "school official" with a "legitimate educational interest." This designation happens through the Data Privacy Agreement each district signs with us.
But the designation isn't a blank check. It means we can access data only to perform the service the district has contracted us for. We can't use student data for product development on unrelated features. We can't share data across districts. We can't retain data after a district ends their contract. These aren't just policy commitments — they're enforced architecturally. Our systems literally cannot query across tenant boundaries. Data retention is automated: when a contract ends, the district's isolated data store is wiped on a defined schedule, with cryptographic verification that the deletion is complete.
SOC 2 Type II: Starting Early
We started the SOC 2 Type II audit process in our fourth month. For a startup with five people and no revenue, that's an unusual choice. The audit costs real money. The preparation takes real time. The process requires documenting controls, implementing monitoring, and maintaining evidence over a sustained observation period.
We did it anyway because districts are increasingly requiring SOC 2 Type II as a procurement condition. Waiting until a district asks for it means waiting 6-12 months after the ask before you can produce the report. Starting early means we'll have the certification when districts need to see it, not months after.
It also forces discipline. Writing security controls on paper is easy. Implementing them in code is harder. Proving to an independent auditor that they've been operating correctly for six months is the real test. We wanted that test early, while our architecture is still young enough to change without major rework.
Security Is the Foundation
I've worked in enough startups to know the default playbook: ship fast, get users, figure out compliance when a customer asks for it. In consumer software, that can work. In EdTech, it's reckless.
The data we're handling belongs to children. The families who entrusted that data to their school district did so for educational purposes, under legal protections that exist for good reason. When a district gives us access to that data, they're extending that trust to us. We don't get to be casual about it.
Security in EdTech isn't a feature. It's the foundation everything else sits on. If you get it wrong, nothing else matters.