Skip to content
Sympozio

Security & privacy

Built for institutions that are accountable for their data.

An academic congress holds personal data belonging to scholars, students, and public officials from many countries at once. The organising body — usually a university, a learned society, or a public institution — remains accountable for that data long after the closing session.

Sympozio is built on that assumption. This page sets out how the platform is designed, in enough detail to be assessed by the person at your institution whose job it is to ask.

Privacy by design

Privacy is treated as an architectural property rather than a policy document. The decisions below are made in the data model and the interface, where an attendee can act on them.

  • Data minimisation: the platform asks for what running the event genuinely requires, and does not accumulate personal data on the chance it may later prove useful.
  • Contact sharing is consent-gated. An attendee’s email address and telephone number leave the server only when that attendee has chosen to share them — registering does not disclose them as a side effect.
  • Every participant governs their own directory visibility, contact card, messaging availability and openness to meetings, and can change any of it at any time.
  • Account deletion is genuine. The account is removed and the records that must remain for the integrity of the event are anonymised, rather than merely flagged as inactive.

Account security

Congress accounts belong to scholars and officials who often reuse credentials across many systems. The authentication design assumes that and limits the consequences.

  • Passwords are hashed with argon2, a memory-hard function designed to resist offline attack.
  • Sessions use httpOnly cookies with token-versioned revocation: changing a password invalidates sessions held elsewhere, which is what makes a compromised device recoverable.
  • Authentication endpoints are rate-limited against credential-stuffing and brute-force attempts.
  • Hardened HTTP response headers, secure cookies and HSTS in production.
  • Administrative interfaces are additionally restricted by IP allow-list, so the console is not merely password-protected but unreachable from the open internet.

Architecture and hosting

The three applications are separated by role, which keeps the blast radius of any single surface small, while a shared data model keeps the event coherent.

  • Three role-separated applications over one API and one PostgreSQL data model.
  • Cloud-native and deployable on AWS: compute, managed PostgreSQL and nginx.
  • Installable as a Progressive Web App with Web Push over VAPID — no app-store dependency, and no delay between publishing a fix and attendees receiving it.
  • Persistent storage for uploaded files, with regular database backups.

GDPR alignment

Attendees at an international congress arrive from many jurisdictions, and the organising institution is accountable for their data in all of them.

  • Data-subject rights are honoured inside the product rather than only in a written policy: an attendee exercises them by using the application.
  • Access and rectification are self-service — an attendee can see and correct what is held about them.
  • Erasure is available directly, through account deletion with anonymisation of remaining records.
  • Purpose limitation: data gathered for the event serves the event.

A note on certification

Everything above describes how the platform is designed and built. These are engineering commitments, not third-party certifications, and we claim no certifications we do not hold. We would rather state plainly what the system does than gesture at a badge.

Where your institution’s procurement or ethics process requires a specific assurance, tell us what it asks for and we will answer it precisely, in writing.

Ask a security questionPrivacy policy for this website