Status: living document. Updated within 24 hours of any change, after which every institution's designated FERPA and/or GDPR point of contact is notified. Institutions have a 30-day notice window for material changes per their Data Processing Agreement (DPA).
About this document. We publish this list so institutions
know exactly which third parties are involved in delivering the
platform. Each provider operates under its own published data-
protection agreement (linked in the last column). This list is
kept current and updated whenever a sub-processor changes.
Purpose: names every third-party service that may process tenant personal data on behalf of DevAcademia, so subscribing institutions can perform their own vendor due diligence.
Legal basis (US, FERPA): 34 CFR § 99.31(a)(1)(i)(B) — the "school official" exception permits sub-processing so long as (a) each sub-processor is under DevAcademia's direct control regarding education records, (b) each is bound by a written agreement, and (c) institutions are informed of who they are.
Legal basis (EU/EEA/UK, GDPR): Article 28(2) and 28(4) — a processor engages sub-processors only with the controller's prior authorisation and imposes on each sub-processor the same data- protection obligations set out in the controller-processor DPA. Articles 44–49 govern any transfer of personal data outside the EU/EEA; each sub-processor row below identifies the Article 46 transfer mechanism relied upon.
#Current sub-processors
| # | Sub-processor | Purpose | Data categories | Jurisdiction | GDPR transfer mechanism (Art. 46) | Sub-processor DPA |
|---|---|---|---|---|---|---|
| 1 | Vercel | Frontend hosting and edge delivery network | Request metadata (URL, user-agent, IP). No education records transit application logic here; session cookies are opaque tokens. | United States (global edge) | EU-US Data Privacy Framework; Standard Contractual Clauses (SCCs) as fallback. | Vercel DPA |
| 2 | DigitalOcean | Managed database, cache, and compute hosting for the application | Full education-record set, encrypted at rest. | United States (EU-region processing available on request for EU institutions) | EU-US Data Privacy Framework; SCCs as fallback. | DigitalOcean DPA |
| 3 | Code-execution sandbox (self-hosted) | Runs student programming submissions in an isolated environment | Submitted source code and input only. Does not receive student name, email, or institution identity. | United States (same region as the primary application; DevAcademia-controlled) | Not an external transfer — runs on DevAcademia-controlled infrastructure covered by row 2's mechanism. | Self-hosted; no external DPA. |
| 4 | Brevo | Transactional email delivery (sign-in codes, notifications, billing) | Recipient email address and message content. Some notification emails contain a student's first name. | European Union (France) | Not required — processing occurs within the EU. | Brevo DPA |
| 5 | Cloudflare Turnstile | Bot-detection challenge on sign-up and sign-in | IP address and browser signal. No account data leaves DevAcademia's origin during the challenge. | United States (EU processing available on request) | EU-US Data Privacy Framework; SCCs as fallback. | Cloudflare DPA |
| 6 | Sentry (error monitoring) | Application error reporting. Receives error diagnostics only, and is configured never to send personal data (email / user ID). | Error diagnostics (stack traces, request context) with personal data suppressed. | United States (EU-region processing available and required for EU-institution deployments) | EU-US Data Privacy Framework; SCCs as fallback. | Sentry DPA |
Sentry (row 6) is configured to suppress personal data; it receives diagnostic error data only. Adding any new sub-processor, or materially changing how an existing one is used, is subject to the 30-day institution notice described below.
#Categories NOT processed by any sub-processor
DevAcademia does not use — and this list will remain empty absent explicit disclosure above:
- Advertising or ad-tech networks (no Google Ads, no Meta pixel,
no advertiser SDK).
- Third-party analytics on student data (no Google Analytics,
Mixpanel, Amplitude, or Segment).
- Data brokers or data-aggregation services.
- Payment-card processors (DevAcademia does not accept card
payments; billing is by institution invoice).
- Public LLM APIs on student personal data (any AI feature runs on
self-hosted infrastructure and is documented separately).
If DevAcademia ever adds a service in any of the above categories, it will first update this document and notify every institution 30 days ahead.
#Data flow — what leaves the DevAcademia network
| Trigger | Destination | Payload |
|---|---|---|
| Sign-up / sign-in | Brevo | One-time sign-in code emailed to the user |
| Password reset | Brevo | Reset-link email |
| Notification delivery | Brevo | Notification body (may contain a first name) |
| Bot challenge | Cloudflare Turnstile | IP and browser signal (challenge round-trip) |
| Code submission | Self-hosted sandbox | Source code and input only |
| Integration webhook | Institution-configured URL | The event payload the institution subscribed to |
Institution-configured integration destinations (for example a Slack channel or a generic HTTPS endpoint the institution sets up) are not counted as DevAcademia sub-processors — they are the institution's own choice under the "direct control" clause of the DPA.
#Contact
FERPA and GDPR compliance point of contact: compliance@devacademia.com. Institutions send sub-processor questions via the same channel they use for DPA queries. Response target: 5 business days.
Change notification: 30 days before enabling any new sub- processor that will process education records.
#Change history
| Date | Change |
|---|---|
| 2026-07-12 | Initial public version. |
| 2026-07-12 | Added the GDPR Article 46 transfer-mechanism column. No sub-processor change. |
Every future change appends a row here. Entries are never deleted — the history stays complete as an audit record.