Agents that touch student records answer to a human and a ledger.
Risely's agents read one governed student record, draft the move, and stop at a gate. A named person approves before anything is written. The write lands on the SIS as the system of record, and a sealed ledger keeps the receipt. Underneath every workflow, student data is encrypted under a key that is the institution's alone, and it is masked before it ever reaches a model.
risely governance · one action, end to end
Financial Aid
perceive
a verification document posts to the aid file
draft
A plain-language note on the one open signature
drafted by Risely's agents · queued and going nowhere on its own
approve· the gate
nothing passes this line without a person
act
writes to the SIS
log
#48112 sealed · actor, approver, diff, record ID, timestamp
Append-only. Names attached. Auditable any time.
SOC 2 Type 2
Independently audited
FERPA
School official
HECVAT
Completed
GDPR
EU-ready
Per-tenant encryption
A dedicated key
72-hour breach notice
Committed
Risely is SOC 2 Type 2 compliant.
SOC 2 Type 2 means an independent auditor tested Risely's security controls over a period of time rather than in a single snapshot.
- An independent third-party auditor performs the examination.
- The report covers security, with confidentiality and availability addressed where they apply.
- The report period runs from October 2025 through February 2026.
- The full report is available under NDA.
- Risely's controls are validated continuously between audits.
Independent third-party audit
SOC 2 Type 2
Report period · October 2025 through February 2026
Under FERPA, Risely operates as a school official under your control.
This is the standard, correct framing for an education technology provider. Risely does the work the institution hired it to do, under the institution's own policies, and nothing more.
A school official under the institution's control
Risely acts under the institution's direct control, holding the same standing FERPA gives its own staff and authorized vendors.
The institution owns and controls the record
The institution stays the owner of its student education records, and Risely processes them only to deliver the contracted service.
No redisclosure of student data
Risely never rediscloses student data or moves it to any party outside the data processing terms.
Zero retention and no training on public models
Student data never trains public or foundation models, and nothing about a student is kept after a call returns.
Rights preserved and access logged
Students' FERPA rights stay intact, and every access is least-privilege and recorded on the append-only ledger.
Existing systems stay exactly where they are.
Risely connects to the systems already in place and resolves what they hold into one student record. No migration, no rip and replace, no second system of record competing with the SIS.
Scoped, read-only connectors
Each connector reads the fields its workflows need and nothing more. Revoke the key and the reads stop with it.
The SIS keeps the write of record
The only writes are approved ones, and they land on the SIS through the same gate every workflow runs. Existing systems keep serving existing processes.
Deprovisioning is one motion
Access lives in the institution's identity provider and connector keys. Turning Risely off is the institution's decision to execute, with its keys, on its schedule.
The stack in cross-section.
Risely's agents
Eight intelligences read the record and draft the work, one office at a time.
The gate
Every write waits for a named approval, and lands as one sealed ledger entry.
Your systems stay where they are
The SIS keeps the write of record. Approved writes land there. Every read stays within its connector's scope, and everything else keeps its job.
Encrypted end to end, under a key that is the institution's alone.
Student data is encrypted both while it moves and while it sits at rest. No plaintext student record is ever stored, and no connection to the platform runs unencrypted.
At rest
- AES-256 across every production database, backup, and file store.
- No plaintext student record is ever stored.
- Keys live in a managed key service, reachable only through brokered access.
- Backups carry the same encryption on a fixed retention schedule.
In transit
- HTTPS everywhere, with TLS 1.2 as the floor and TLS 1.3 where the client supports it.
- Plain HTTP is redirected at the edge, with strict transport security enforced.
- No unencrypted fallback exists, and internal production traffic is encrypted too.
In transit
No connection runs unencrypted in either direction.
At rest
No plaintext record is ever stored.
A dedicated key per institution
Institution A
its own key
Institution B
its own key
Institution C
its own key
Isolation is enforced by cryptography. One institution's data cannot be read with another's key.
A dedicated key for every institution
- Each institution's data is encrypted under its own customer-managed key.
- That key never touches another institution's data.
- Connector credentials are stored encrypted under the same key.
- Isolation is enforced by cryptography at the key level.
Student identity is masked before it ever reaches a model.
Sensitive fields are stripped before a prompt leaves the platform, and every call is filtered, validated, and traced. Here is the path every model call takes.
One model call, start to finish.
A request enters the platform
a governed workflow needs to act on a record
PII is masked
names and identifiers are redacted before the call
The guardrail filters
prompt-injection and PII-leakage checks run first
The model reasons
over the task, never the student's identity
it retains nothing and never trains public models
The response is validated
checked before it reaches the application
A person approves every write
a named human clears it before anything lands
The append-only ledger seals it
actor, approver, diff, record, and timestamp
Inline guardrails on every call
One gateway filters prompt-injection patterns, validates every response, and rate-limits per institution. No service calls a model provider directly.
Tested against real attacks
Risely continuously red-teams its own calls for PII leakage, prompt injection, and jailbreaks. The guardrails are proven under real attack.
Only the minimum data
Each workflow is scoped to the exact fields it needs. Anything outside that scope is never requested and never ingested.
Every institution runs inside its own boundary.
Isolation is not a setting to be toggled. It is built from the encryption key up, and access is governed by the institution's own identity provider.
One boundary per institution
Each institution's data lives in its own store under its own key, never commingled with another's.
Data stays in one US region
All production infrastructure and data reside in a single United States region, across multiple availability zones.
Identity governs access
Staff sign in through your single sign-on with multi-factor enforced. Access follows least privilege and is reviewed on a set cadence.
Production is not on the open internet
Databases are never exposed to the public internet. Engineering access is brokered, limited to authorized personnel, and fully logged.
Institution A
Institution B
Institution C
Nothing crosses a boundary. Turn Risely off, and the reads stop with the key.
The evidence is ready before the review asks.
SOC 2 Type 2 and FERPA are covered in full above. Everything below is the rest of the packet Risely brings to a procurement review, and the security office can request any of it directly. The controls are backed by the architecture described on this page.
Also completed for higher-education review
HECVAT
The Higher Education Community Vendor Assessment Toolkit is completed, and shared with your security office on request.
GDPR
Risely is prepared for institutions serving students in the European Union, with data processing terms to match.
Continuous validation
Automated checks run every day against CIS, NIST, and SOC 2 benchmarks, so the posture is proven continuously.
Vulnerability management
Critical fixes ship within 7 days, high within 30, and the rest within 90. Dependencies scan continuously, and infrastructure scans weekly.
Independent penetration testing
Third-party pen tests run on an annual cadence, with findings remediated within 60 days.
72-hour breach notification
If a breach affects your data, Risely notifies you within 72 hours of confirming it.
You always know who else touches the data
- The current list is published to every institution in the data processing addendum, and shared on request.
- It falls into three categories: the model providers that power the agents, the cloud the platform runs on, and the services that govern sign-in.
- Every subprocessor with data access is reviewed before onboarding and re-reviewed each year.
- Any new subprocessor comes with at least 30 days of advance written notice, and reasonable objections are accommodated.
Every action passes through the same three gates.
The gates are structural. Every write carries a human approval, whether granted per act or as a standing rule. Every act lands on the ledger. Autonomy moves only when staff move it.
Every action starts as a draft, and the draft waits.
Risely's agents read the record, cross-check the offices it touches, and draft the move. Then they stop. The draft sits in a queue staff own until a named human approves it, edits it, or declines it. Only then does the write land.
Financial aid · drafted for a student
Your verification file is complete. One signature is still open on the master promissory note, and the link below goes straight to it. Sign it, and your loans can disburse within about ten minutes.
Risely's aid agents drafted this and stopped. It goes nowhere until the aid officer approves it, edits it, or declines it.
Every act lands on a ledger counsel can read.
Each draft, approval, and write produces a sealed ledger entry: which agent moved, which human approved, what changed, and which record carried the change. The trail reads end to end, exportable for audit, records requests, and accreditation review.
Signed, logged, and never rewritten.
The aid officer approved the draft with no edits. Risely's aid agents sent the message and wrote the ContactNote to the SIS. The ledger sealed one entry behind it.
aid outreach → approved by the aid officer → wrote ContactNote to the SIS
entry sealed → actor, approver, diff, record ID, and timestamp
Autonomy starts at zero and is earned per workflow.
Every workflow begins in draft-only mode. When a queue builds a history of clean approvals, the team can grant a standing approval for that workflow alone, and turn the dial back down at any point. The ledger records every act, and every move of the dial, at every level.
Transcript receipt confirmation
act, review the logacts under a standing approval the team granted, and staff review the log
Financial aid outreach
approve each acta human approves every send
Registration hold release
draft onlydraft only, by policy
One transcript moves four offices. Every move that reaches a student or the SIS clears its own gate.
The moment a move reaches a student or the SIS, the owning office approves it.
Registrar
ledger #48231
A transfer transcript posts to the record.
Risely's registrar agents draft the articulation: 9 of 12 credits map to degree requirements, with the catalog citations attached.
Degree plan
ledger #48232
Earned credits change, so the plan recomputes.
Three planned courses come off: one clears from spring, dropping the load from 16 units to 13, and the last two empty the final term, so graduation moves up a semester.
Advising
ledger #48233
The shorter path changes the next conversation.
Risely's advising agents draft the outreach that walks the student through the new graduation term and the lighter spring.
Financial Aid
ledger #48234
One fewer term changes the aid math.
Thirteen units keeps full-time status, so spring aid holds. Risely's aid agents draft a repackaging note for the term the student no longer needs.
Retention
ledger #48235
The risk model reads the same record every office just wrote.
The stall flag set while the transfer credits sat unposted clears against the new plan. The watchlist drops by one, no outreach fires, and the ledger says why.
One transcript. Four offices moved, one flag cleared, five ledger entries. Every move that reached the student or the SIS cleared a human gate, and every hop left its own receipt on the same record.
The institution owns its records.
The institution's · Customer Data
The institution owns the raw Customer Data.
- Every record brought in or generated on the platform stays the institution's property: applications, enrollment records, aid files, notes, messages, outcomes.
- Export runs in open formats on request, on the institution's schedule.
- At termination, the raw Customer Data leaves with the institution, complete and in open formats.
The platform · Derived Data
The platform is licensed for the term.
- The resolved knowledge graph, the schema mappings, the entity-resolution logic, and the models are the platform working on the institution's records.
- All of it is licensed to the institution for the term of the agreement.
- At termination, the raw records return to the institution as its Customer Data export, complete and in open formats.
so, lock-in?
Your exit is your raw data, complete, in open formats, ready for whatever system you choose next.
- Any platform that reads a standard export can receive everything you brought and everything your teams created on the record.
- The knowledge graph is how Risely serves you during the term; your portability lives in the raw data itself.
Walk the guardrails with your CIO and your counsel.
One session, end to end: encryption and the per-tenant key, PII masking, the approval gate, the ledger, the connector scopes, the data line, and the exit terms, answered in the room.
Schedule a demo