Anonymous in the room. Accountable afterwards.
What we store, for how long, who can see it, and what we have not done yet.
What we keep about this delegate
- Who
9f3c…a71ea random code, hashed- Answer
- Start a biologic now
- Name
- None, unless the delegate asks a question under their name
- None, unless your feedback form asks for one and says so
- Phone number
- Never collected
- Network
- A keyed hash, never the address
An illustration. The table below lists everything, and for how long.
- A random codeNo name, no email, no phone number to join.
- Deleted after 90 daysBy default, after the event’s last day, or all at once.
- Roles, and wallsEach agency is walled off. Reviewers see slides only.
- What is not doneNo penetration test or certification yet. Said plainly.
Everything we keep about a delegate, and for how long
A delegate is a random code, not a person. No name, no email, no phone number to join.
| What | Why | For how long |
|---|---|---|
| A random device code, kept in a cookie on the phone. We store only a one-way hash of it. | So an answer counts once per phone, and a phone can pick up where it left off. | Until the retention period after the event ends, or until the delegate deletes it. |
| Answers to polls, quizzes and games | The service itself, and your results. | Deleted with the delegate data. Aggregate results can be kept. |
| Audience questions, and a name only if the delegate chooses to ask under theirs | The service itself. | Questions you never approved are deleted at the end of the period; shown ones are kept without the name. |
| Feedback forms: answers, and an email address only if your form asks for one and says so | Feedback. | Email addresses and free text are deleted at the end of the period. |
| A keyed hash of the network, never the address | To stop one source creating thousands of fake identities. | Two days after it was made. |
Not collected: names, email addresses (except a feedback form you set up to ask), phone numbers, advertising identifiers, analytics, third-party scripts. Our fonts are served from the product itself, so a phone does not contact a font provider. Every phone page links to “Privacy and your data”, which says who is responsible for the data and lets a delegate delete their own answers.
Delegate data has an end date, and you control it.
By default, 90 days after the event’s last day, a nightly job deletes it. Or delete it all at once, with the event’s name typed to confirm.
- Find and delete one person’s data
- A delegate deletes their own answers
- Delete an event or an agency
- Erase a staff account
Roles with only what they need.
Each role, and the walls between agencies
Agency administrator
Everything in the agency: events, clients, brand, passes, the team, the data and the activity log.
Session owner
Builds and runs one client’s sessions, or one session. Cannot see the rest of the agency.
Speaker and AV technician
Runs one session from the Presenter console. The AV technician does not edit content.
Moderator
Sees the audience questions of one session. Not the slides, not the answers, not unopened questions.
Each agency is walled off
A person with no role in an agency is told “not found” for everything in it. As a second line of defence, every table has row-level security on, checked by a script.
Preview links see slides only
A reviewer’s private link is read-only: no speaker notes, nothing delegates wrote. It can be switched off.
The activity log, and the approval trail
Administrators can read what was done to delegates’ data, what was downloaded, who joined or left, which passes were bought, and when content was approved or unlocked. It holds kinds and counts, never what delegates wrote, and is kept 24 months.
- Approved versions are locked. Editing is refused until someone unlocks with a reason that is kept.
- Who approved is as they gave it. A reviewer who approves through a private link types their own name and role; SympoSync does not verify who they are.
- A log of what was shown on the audience display, with a fingerprint of each slide. It is written on a best-effort basis: if a line cannot be written the presentation carries on without it, so a line can be missing.
- Reports can be frozen with a fingerprint, so a copy sent to a client can be checked.
- Sign-in links work once and invitations only for the address they were sent to.
Where it runs is named in your agreement
The regions our database and hosting providers use are written into your data processing agreement, with the list of sub-processors. We use no analytics, advertising or third-party scripts.
Said plainly, so you do not have to ask.
A pharma security review will ask for each of these. Here is where we stand today.
- No independent penetration test and no ISO 27001 or SOC 2 certification. Our own checks, including over two thousand automated tests and AI-assisted code review, do not replace an independent audit.
- Staff sign in with an emailed link only. There is no multi-factor authentication or single sign-on yet.
- Our own staff can reach customer data through the product’s operator role. There is no technical separation beyond the role.
- Free text is not scanned for patient information or adverse events. Delegates are told not to enter either; audience questions can wait in a moderator queue, and a word cloud holds back entries that look like personal details until the presenter decides.
- No uptime monitoring or alerting service is connected yet, and the hosting measures (encryption at rest, backups, log retention) are those of the host we name in your agreement.
We keep this list current. The security overview we send under your agreement lists what exists and what does not, in the same way.
Ask for the security pack.
The security overview, the record of processing, the draft data processing agreement and the list of sub-processors. Tell us where to send it, and the questionnaire your team uses if you have one.