Skip to content
Kreastel
Opening soon

Security and validation statement

Last updated: 4 October 2026.

What Kreastel is

A planning and oversight aid for the person responsible for pharmacovigilance at a marketing authorisation holder. It holds derived planning data — due dates, owners, statuses, reminders, summary metrics entered by hand — and produces exports used as supporting evidence of oversight. It is not a safety database, not a document repository and not a submission tool. Your quality management system remains the system of record.

It is designed to be used the way a well-controlled spreadsheet is used: as an aid outside the validated system, under the QPPV's own verification. Where a marketing authorisation holder's quality system requires it, the validation kit (below) supports listing and validating Kreastel in about a day.

What is stored

Per workspace: product names and authorisation numbers, active substances, dates and intervals, partner organisations and agreement terms, commitment titles, PSMF version and annex dates, names of people and courses in the training register, monthly KPI figures, and the change log. Nothing about patients, reporters or cases, by design and by the terms of service.

Where it is

  • Database and authentication: Supabase, EU region (Frankfurt).
  • Application: Vercel, EU region (Frankfurt).
  • Transactional e-mail: Resend (sending region not yet confirmed).

Sub-processors are listed here and updated when they change. Data is encrypted in transit (TLS) and at rest by the providers.

Who can see it

  • Every workspace is isolated at the database level by row-level security. A member of one workspace cannot read or write another's data by any request; cross-tenant reads return nothing rather than an error. This is verified by an automated test run as two real users against the production database schema (OQ-13), re-runnable on request.
  • Roles: owner, editor, viewer. Viewers can read, including the change log, and cannot write; enforced by the database, not only by the interface.
  • Sign-in by a single-use link, or the code in the same e-mail, sent to your work address; no passwords are stored. There is no separate multi-factor sign-in: access rests on control of that mailbox, which your organisation's own sign-in protects.
  • Every page is sent with a content security policy: it loads nothing from any other site, cannot be shown inside another site's frame, and tells a site you follow a link to which site you came from, never which page. After signing in you are only ever returned to a page of this site.
  • Kreastel staff do not access workspace contents except for support, at the customer's request, limited to that workspace, and logged.

Integrity

  • Every insert, update and archive on every register is written to an append-only change log by the database itself (trigger), with actor, UTC time, field, old and new value. The log cannot be edited or deleted by anyone, including administrators.
  • Records are archived, never deleted; the database has no delete permission for any user role.
  • A manually overridden due date requires a recorded reason; a "no PSUR required" status requires the legal basis and the EURD list version it rests on. Both are enforced by the database.
  • Exports (CSV and the oversight PDF) are stamped with workspace, UTC time, application version and the exporting user. CSV cells that Excel would interpret as formulas are neutralised.
  • The three date rules that exist in both the application and the database (PSUR due date, agreement reconciliation, PSMF review) are checked against each other by an automated parity test on every release.

EURD list

The list is fetched from the European Medicines Agency, validated, compared with the previous version and published only after review by a named administrator; the review and publication are logged. Changes take effect six months after publication, as the legislation provides, and the application shows both the binding and the pending values with the date the change binds. When a published version changes an entry a product depends on, the product is flagged and the workspace owners are told; nothing on a product changes by itself. A failed comparison blocks publication and is shown to the administrator.

Availability and backups

During the beta the database runs on the provider's free tier, which takes no backups. Every register can be exported as CSV at any time; keep your own copy of anything you rely on. During the beta no service level is offered.

Changes

Every user-visible change is listed in the public changelog with a version number. Changes affecting documented requirements of the validation kit are announced at least 14 days in advance where practicable, naming the requirements affected, so that customers can re-run the corresponding test scripts.

Validation kit

Supplied with every workspace: intended-use statement; GxP impact and risk assessment; user requirements specification with numbered requirements (F-01 …) traced to vendor tests and to customer-executable IQ/OQ scripts; vendor statement on development, testing, hosting and change control; release and acceptance memo template; change-control procedure. Executing the customer scripts takes about one working day. Kreastel does not claim to be "validated": validation is performed by each customer in its own context; the kit makes that fast and documented.

Reporting a security problem

security@kreastel.eu. We acknowledge reports within 2 working days and will not take action against good-faith researchers.