SPARC Security & Privacy
SPARC (Student Performance, Achievement & Resource Companion) is a mobile-first web app for students at institutions that license SPARC. Production workloads run on AWS with encrypted storage, edge middleware, and least-privilege access. This page summarizes both product commitments and technical architecture: how we protect accounts, academic data, AI conversations, and operational telemetry. For shared platform practices also described for dissertation management, see the Corvus DM Security page (button above).
Built for educational records, not surveillance
SPARC helps students stay on track with proactive coaching, scheduling, and engagement signals. Data is processed to support retention and success workflows authorized by the institution. SPARC is not a background data collection product: location and attendance features are bounded by design, and students retain visibility into what the product records about them where those features are enabled.
Security overview
SPARC handles FERPA-sensitive educational records (enrollment, courses, grades, goals) and conversational data used to personalize the AI assistant. Security is layered: HTTPS everywhere, encrypted data stores, server-side session validation, role-appropriate access for students and authorized institutional staff tools, and product analytics that avoid unnecessary personal data retention.
- Encryption in transit (TLS) and at rest (managed database encryption)
- HttpOnly session cookies; no long-lived credentials in browser storage for core auth
- Edge middleware: bot and exploit-path blocking plus baseline security headers
- AWS WAF in front of the public load balancer (managed rule sets and custom protections)
- Operational secrets loaded from AWS Secrets Manager in production (not baked into images)
Product signals (location & attendance)
SPARC is built for educational records, not surveillance. When institutions enable location-aware attendance, signals are designed for campus geofences and scheduled class windows, not for continuous off-campus location monitoring. Students retain visibility into what the product records where those features are enabled, consistent with the privacy scope on the SPARC product page.
Campus scope
Attendance-related location is tied to university context, not open-ended monitoring outside institutional use.
Schedule alignment
Signals align with class schedules so the product does not imply 24/7 location collection for attendance.
Safety before the model
Student messages can be pre-screened for crisis and self-harm language before any generative step. When that path triggers, the workflow routes toward resources rather than continuing an open-ended AI conversation on that message. Audit records for those events are kept minimal for continuity and abuse prevention. They do not retain the student's exact words in that audit.
Cloud infrastructure (AWS)
Production is hosted in AWS US-West-2 (Oregon), aligned with SPARC's deployment runbook. The stack inherits AWS physical security and compliance programs (for example SOC and ISO certifications listed at aws.amazon.com/compliance/programs).
| Component | AWS service | Notes |
|---|---|---|
| Compute | Amazon ECS on Fargate | Containerized Next.js app; tasks run in private subnets with least-privilege task roles. |
| Database | Amazon RDS (PostgreSQL) | Managed backups; encryption at rest; access restricted to the application tier (not open to the public internet). |
| Load balancing | Application Load Balancer | TLS termination with ACM certificates; HTTP to HTTPS redirection. |
| Edge protection | AWS WAF | Web ACL attached to the ALB to block common attacks and abusive traffic patterns. |
| Secrets | AWS Secrets Manager | Database URLs, API keys, and signing material referenced at runtime (not committed to source). |
| Amazon SES | Transactional mail (e.g., support notifications) from verified domains with DKIM/SPF alignment. | |
| Observability | Amazon CloudWatch | Logs and alarms for operational health (ALB, ECS, RDS, WAF as configured). |
For shared platform practices across Corvus higher-ed products, see also Corvus DM security architecture.
Encryption
At rest. RDS storage uses AWS-managed encryption. Application data at rest stays inside managed services with encryption enabled per environment configuration.
In transit. Browser traffic uses HTTPS (TLS 1.2+) through the load balancer. Database connections from the application use TLS as required by the connection string and security group design.
Sessions. Primary authentication uses an HttpOnly cookie bound to the student account. Cookies are marked Secure when the deployment URL is HTTPS, and use SameSite=Lax to reduce CSRF risk for typical navigation flows.
Authentication & sessions
Students sign in with institutional credentials managed in SPARC's user store (email and password with server-side verification). Password reset flows use time-limited codes delivered out-of-band.
There is no anonymous access to personalized academic or chat content. API routes validate the session cookie before returning user-specific data.
SPARC does not process MFA inside the web app today; institutional SSO integrations (for example via an identity provider) may be introduced as deployment requirements evolve. When present, they would sit in front of the same session and authorization checks described here.
Access control
Students see their own profile, courses, goals, chat history, notifications, and retention-related insights tied to their account.
Staff and advisor tools (for example VIP or counselor dashboards, where your institution enables them) are separate from the student web app. They use distinct routes and sign-in; only staff accounts your institution authorizes can access those screens.
Provost Dashboard. Leadership views such as the Provost Retention Dashboard show aggregated retention, engagement, and health-and-wellness momentum across cohorts, programs, risk tiers, and institutional trends. Provosts and student success teams can use those views to monitor overall student health in near real time. Individual student identity, private chat content, and identifiable per-student wellness line items are not shared with the institution as exportable student-level reporting; administration sees rollups designed for planning and outreach, per deployment policy.
SPARC is designed so day-to-day student interactions stay oriented to the learner, while leadership views focus on cohort-level trends. Exact access patterns, retention periods, and integrations are set with each institution under their policies and agreements.
Authentication and administrative controls for deployed environments follow the same engineering practices as our other Corvus higher-ed products.
The AI assistant is designed so individualized chat content is not broadcast to other students. Aggregate or de-identified analytics may be used to improve programs, consistent with our privacy policy and product disclosures.
Audit trail & logging
SPARC records product usage and operational events to run the service and understand feature adoption. Examples include session lifecycle signals, feature usage events, and support interactions. IP addresses may be hashed or minimized where feasible to reduce unnecessary personal data retention.
AI safety. Student messages may be pre-screened for crisis and self-harm language before any generative step. Where high-risk scenarios are detected, safety flows may limit what is persisted so that crisis content is not stored as durable chat history. The app can still respond and route users to help resources. Audit records for those events are kept minimal.
Infrastructure logs (ALB, WAF, ECS, RDS) support security investigations and reliability monitoring.
Network security
Middleware runs on every request to block known malicious user agents and common exploit paths, and to add baseline security headers (for example X-Content-Type-Options, X-Frame-Options, and X-XSS-Protection). Additional hardening (CSP, Permissions-Policy, HSTS) may be expanded as the deployment matures.
AWS Shield Standard protects ALB and DNS surfaces from common network-layer denial-of-service patterns at no extra charge for Standard features.
Data isolation
Production data for SPARC is isolated from unrelated development databases and secrets. Each environment should use its own credentials, signing keys, and data stores so a compromise in one environment does not automatically carry to another.
Ownership. Student educational records belong to the institution. Corvus Software Group provides the application; it does not sell student chat content or academic records.
Compliance & regulatory
- FERPA. SPARC is designed to respect FERPA expectations for access, minimization, and institutional control of student records.
- Institutional policies. Universities should align SPARC use with local acceptable-use, records, and AI governance policies.
- AWS inheritance. Operating on AWS allows customers to reference AWS compliance documentation as part of their vendor assessments.
Vendor security questionnaire (summary)
Does SPARC process student or employee information?
Yes. SPARC processes student educational records and limited profile data needed to operate the companion experience (for example courses, goals, chat, notifications). Employee-facing tools, where deployed, process only what is required for those workflows.
Is SPARC cloud-hosted?
Yes. Production runs on AWS (see Infrastructure). There is no requirement to install executables on university-managed desktops beyond a modern web browser for students.
Does SPARC require access to the campus network?
No. Users reach SPARC over HTTPS (for example https://sparc.corvussg.com). Optional DNS aliases (such as a university subdomain) are standard CNAME integrations.
Does SPARC store payment card data?
No. SPARC is not a payment application and does not collect cardholder data.
How are users authenticated?
Application-managed accounts with server-side password verification and HttpOnly session cookies. API routes enforce session checks on protected resources.
Who can answer detailed security questions?
Contact security@corvussg.com for questionnaires, architecture diagrams, or a review with your IT/security team. You can also reach us via the contact page.