Skip to main content
Effective date: 2026-05-01 This document is intended for technical and security teams evaluating Edpire as an integration partner.

​
Infrastructure & Hosting

All production traffic flows through Cloudflare before reaching Edpire infrastructure, providing baseline DDoS protection and TLS termination.

​
Data Residency & Subprocessors

Assessment content, submission results, learner records, and API keys are stored in the European Union, in PostgreSQL on a dedicated VPS. Serverless compute runs in Vercel’s Paris (cdg1) region. Uploaded files are held in Cloudflare R2, which uses automatic placement rather than a pinned jurisdiction. If your organization requires object storage confined to the EU, tell us before onboarding: R2 jurisdiction is fixed when a bucket is created, so an EU-restricted bucket has to be provisioned for you up front. Vercel Edge Network nodes may serve cached responses from edge locations globally, but no personal data or submission content is stored at edge locations. Only static assets and public metadata are eligible for edge caching.

​
Subprocessors

​
AI grading and transfers outside the EU

When an assessment contains an open-ended question configured for AI grading, that learner’s answer text and the question’s rubric are sent to OpenAI for evaluation. This is a transfer of learner-submitted content outside the European Union. This applies only to AI-graded open-ended questions. All deterministic grading — multiple choice, fill-in-the-blank, matching, ordering, and every other auto-graded question type — is performed entirely on Edpire infrastructure, with no third-party transfer. An assessment that contains no AI-graded questions involves no transfer outside the EU at any point. The request sent for grading contains the answer text, its word count, the maximum score, and the rubric. It carries no learner identifier — not learner_ref, not an Edpire user ID, not a name or email — and no other part of the submission. OpenAI therefore receives answer content that is not linked to an identifiable learner by anything Edpire sends.

​
Encryption

HTTPS is enforced on all Edpire domains. HTTP requests are redirected to HTTPS. Webhook endpoints registered by clients must use HTTPS (HTTP is permitted only for localhost during development).

​
Authentication & Authorization

​
API Key Authentication

All REST API requests are authenticated via an Authorization: Bearer edp_live_<key> header. Keys are:
  • Scoped to a single organization (org-isolated by design)
  • Scoped to specific permissions (e.g., read:assessments, write:submissions)
  • Immediately revocable from the dashboard
  • Stored as one-way hashes — Edpire staff cannot read the raw key value

​
Multi-Tenant Isolation

Edpire is a multi-tenant platform. All database queries are scoped by org_id, which is resolved from the authenticated session or API key — never from URL parameters or client-provided input. An API key belonging to Org A cannot access or modify any data belonging to Org B under any condition.

​
Webhook Signature Verification

Outgoing webhooks are signed using HMAC-SHA256 with a per-webhook secret. The signature is sent in the X-Edpire-Signature: sha256=<hex> header. Clients are expected to verify this signature using timingSafeEqual before processing the payload. See the Webhook Security guide for implementation details.

​
Answer Key Protection

Stored answer keys are never returned by any API endpoint. By default the /check endpoint returns only a correctness signal (correct / incorrect / partial / awaiting review), not the correct answer. One documented exception: a caller holding a valid API key may pass include_correct_answers: true to /check, which adds the correct choice IDs, the expected answer text, and correct pairings to the response. This exists so integrations can build review and practice modes that show the learner the right answer after an attempt. It is opt-in per request, it requires a server-side API key, and it is never enabled implicitly. If you do not want correct answers reaching the browser, do not pass the flag and do not proxy it from client input. Answer keys are excluded from client-facing responses by the application layer on each route, not by a schema-level constraint.

​
Learner Data Handling

Edpire stores the minimum learner data required to operate the platform: Edpire does not store learner names, email addresses, or any other PII unless explicitly provided by the client. The learner_ref is treated as an opaque identifier — Edpire does not resolve it to a real identity. Data ownership: All assessment content and submission data belongs to the client organization. Edpire processes it as a data processor, not a data controller, for the purpose of delivering the service.

​
Access Control (Internal)

  • The application connects to the production database through a single pooled service account
  • Database credentials are stored in environment variables, not in source code or version control
  • The codebase is managed in a private repository
  • Edpire is a small team, and named engineers hold direct production database access for migrations, incident response, and operational maintenance. We do not claim that no staff can reach client data. Access is limited to those engineers, used for operating the service, and never for inspecting client content outside a support request or incident.

​
Vulnerability Disclosure

If you discover a security vulnerability in the Edpire platform or API, please report it responsibly:
  • Email: support@edpire.com
  • Subject: [SECURITY] <brief description>
  • Include: A description of the vulnerability, steps to reproduce, and any relevant technical details
Edpire commits to:
  • Acknowledging your report within 48 hours
  • Keeping you informed of the investigation and fix timeline
  • Not taking legal action against researchers who act in good faith
Please do not publicly disclose the vulnerability before a fix has been deployed.

​
Security Testing Policy

​
Standard QA Testing

Use your test organization on the production environment. No approval required. Do not use real learner data during testing.

​
Penetration Testing / Attack Simulation

Clients who need to conduct penetration testing, load testing, or attack simulations can request a planned pen test window:
  1. Submit a request to support@edpire.com at least 5 business days in advance
  2. Provide: testing dates, scope description, test methodology (black-box / gray-box), and source IP ranges
  3. Edpire provisions a temporary isolated environment (separate Vercel deployment + isolated database) for the agreed period
  4. Testing is scoped exclusively to the isolated environment
Scope limitations:
  • Testing against the production environment is not permitted without prior written agreement
  • Testing that targets other clients’ organizations or data is strictly prohibited
  • Denial-of-service attacks against production infrastructure are not permitted under any circumstances
Violations of this policy may result in immediate account suspension.

​
Compliance Posture

Edpire will provide a Data Processing Agreement (DPA) to any client who requires one for compliance purposes.

​
Contact

For security questions, vulnerability reports, DPA requests, or pen test window scheduling: Email: support@edpire.com Subject prefix: [SECURITY] for security matters, [DPA] for data processing agreements
Edpire — support@edpire.com