event67
Open menu

Security, privacy and accessibility

event67 holds an organizer's attendee list and the content attendees post inside an event. This page states what is held, who can reach it, what we deliberately do not record, and which assurances we cannot offer, so that a procurement review can be finished rather than started here.

What data we hold, and why

Categories of data and their purpose
CategoryWhat it isWhy it exists
Account and contactName and email; a password for organizersTo invite an attendee and to sign an organizer in
ProfileTitle, company, bio, interests, links, photoOptional, attendee-authored, editable by them at any time
Event activityFavourites, RSVPs, connections, photos, questions, votes, poll answers, feedbackTo make the features work and to give organizers aggregate insight
Admin messagesDirect and group messages between organizersThe organising team's own channel. Attendees have no chat
IdentifiersFirebase user id, push token, IP address, device model, OS versionAuthentication, notifications and standard technical operation
Usage telemetryWhich screens and features were used, scroll depthProduct improvement and organizer engagement analytics
DiagnosticsServer request and error logs. There is no crash-reporting service in the mobile appOperating the service and investigating faults. Kept for as long as our hosting provider retains them

The full and authoritative statement is the privacy policy, which is deliberately more specific than the category summary above.

Authentication, roles and rate limiting

Identity is Firebase Authentication
Sign-in runs through Firebase Authentication, including Google and Apple sign-in and email with a password. event67 never stores an organizer password; Firebase holds it. Our signup endpoint does receive the password you type in order to pass it to Firebase, and keeps no copy.
Every API request is authenticated
Requests carry a verified identity token, checked on the way in. Four prefixes are deliberately exempt and not all of them are reads: /v1/public (attendee form submission), /v1/webhooks (Stripe and email delivery callbacks), /v1/internal, and /v1/wallet (Apple's PassKit device calls). Each carries its own check in place of a token, such as a signed webhook payload or an opaque single-use link token.
Four levels of access
Platform staff, organisation super-admin, organisation admin, and per-event moderator. A moderator is scoped to one event, which is what makes handing a volunteer the approvals queue a reasonable thing to do.
Console actions are audit-logged
Admin chat and billing actions write an audit record. Moderation decisions do not: hiding a photo or a question records the new status but not who changed it, so we cannot today tell you who removed something.
Rate limiting per client
The API applies a global limit of 100 requests per minute per client. The client address is resolved by counting the proxy hops we actually run behind, rather than by trusting a forwarded header, because trusting that header lets any caller mint themselves a fresh allowance and voids every limit. That is a fixed bug with a regression test on it, not a theoretical control.
Browser origins are allowlisted
Cross-origin requests to the API are accepted only from known origins, and the API applies standard security response headers. On the public websites those headers are currently set on the two functional auth pages rather than site-wide, which is a gap we are naming rather than describing around.

Transport, hosting and location

  • Everything is served over HTTPS. The public sites are hosted on Firebase Hosting, which upgrades HTTP to HTTPS automatically.
  • The API runs on Google Cloud Run; email is delivered through Amazon Simple Email Service; authentication, file storage and push notifications run on Google Firebase.
  • Data is processed primarily in the United States. If you access the service from outside the US, your data is transferred there.
  • Public event imagery is served through signed, expiring read URLs.
  • Payment is processed by Stripe. Card details are handled by Stripe and do not reach event67's servers. Billing is organizer-facing only; the attendee app contains no payment of any kind.

What our telemetry never records

This is the most useful paragraph on the page for a works council, a data protection officer or an internal comms team.

event67's own event telemetry records the fact and the type of an action and never the text inside it. We record that a question was asked, not the question. That a search happened, not the search terms. That a message was sent in the admin chat, not its content.

We do not sell personal data, do not share it for cross-context behavioural advertising, do not share it with ad networks, and do not track anyone across unaffiliated apps or websites.

The honest counterpart: this telemetry is linked to an account rather than anonymous, and third-party analytics are in use — Google Analytics for Firebase in the app and the console, and Mixpanel on the app and our websites, where it also performs autocapture and session recording on our own pages. All of that is named in the privacy policy rather than buried.

What an attendee can do about it

  • Edit or clear their profile at any time from the Me tab.
  • Remove themselves from the attendee directory with a single switch, without leaving the event.
  • Turn off push notifications in device settings; announcements remain readable in the app.
  • Request access, export or deletion by emailing privacy@event67.com, answered within 30 days, including rights under the GDPR and the CCPA/CPRA.
  • Use the delete-account page on this site to start a deletion request.

Stated plainly because it matters: attendees have no in-app deletion button. Attendee deletion is handled by request, through email and the delete-account page, and we consider that a gap rather than a design. Organizers do have a delete control in the console, but it does not erase everything either: the account row holding your name and email remains in our database.

Retention

  • Profile and event participation data: kept until you ask us to delete it. There is no scheduled purge today, so nothing ages out on its own.
  • Server error logs: kept for as long as our hosting provider retains them. There is no crash-reporting service in the mobile app today.
  • Analytics and email-engagement data: kept per person, including which email a named recipient opened and which link they clicked, and not currently deleted on a schedule.
  • The service is intended for attendees aged 13 and over.

Accessibility, stated accurately

Every colour pair in an event's theme is measured against the WCAG AA contrast threshold, and the result is surfaced to the person choosing the colours. The check warns and asks for confirmation. It does not block a save, and describing it as enforced would be untrue.

That is a real, shipped capability and it is the extent of what we can evidence. There is no published VPAT and no third-party accessibility audit of the applications as a whole. If your procurement requires either, ask us directly rather than inferring an answer, and we will tell you the same thing in writing.

Certifications and assurances we do not hold

Publishing this is more useful than omitting it, because a buyer who needs one of these should stop reading now rather than in week three.

  • No SOC 2 report, of any type.
  • No ISO 27001 certification.
  • No HIPAA compliance and no business associate agreement.
  • No FedRAMP authorisation.
  • No published VPAT or third-party accessibility audit.
  • No penetration test report available for distribution.
  • No single sign-on with SAML or SCIM provisioning for organizer accounts.
  • No customer-managed encryption keys and no choice of data residency region.

If a security review is part of your process, write to hello@event67.com and say what you need. We will answer questions specifically and we will not claim a control we do not run.

Last updated

What it costs

Free up to 50
activated attendees, on one live event
$5
per activated attendee beyond 50
$4,750
the most one event can ever cost, whatever happens past 1,000

Activated means the person claimed their invite and opened the app. Not when you import them, not when the invite is delivered, and not if they register and stay home.

See the full pricing

Questions people actually ask

Do you have SOC 2 or ISO 27001?

No, neither, and we would rather say so on this page than in week three of an evaluation. We also hold no HIPAA, FedRAMP or published VPAT. If one of those is a hard requirement for your organisation, event67 will not pass your review.

Where is our attendee data stored?

Data is processed primarily in the United States. The API runs on Google Cloud Run, authentication and file storage on Firebase, and email delivery through Amazon Simple Email Service. There is no choice of data residency region.

Does event67 read what our attendees write?

Our telemetry does not. It records the fact and type of an action and never the text inside it, so questions, chat content and search terms are not analytics data. Staff can access data when needed to operate the service, provide support, investigate abuse or comply with law, which is stated in the privacy policy.

Do you sell or share attendee data?

No. We do not sell personal data, do not share it for cross-context behavioural advertising, do not share it with ad networks and do not track anyone across unaffiliated apps or websites.

How do attendees delete their data?

By emailing privacy@event67.com or using the delete-account page, answered within 30 days. Attendees have no in-app deletion button, which we name as a gap rather than leaving you to discover it. Be aware that a deletion today removes the attendee record but does not yet reach questions, photos or feedback held against the event.

Is event67 accessible?

Every theme colour pair is checked against WCAG AA and the result is shown to the organizer, who is asked to confirm rather than blocked. That is the claim we can evidence. There is no VPAT and no independent audit of the applications as a whole.

Do you support single sign-on for our organizer accounts?

No SAML and no SCIM provisioning. Organizer sign-in runs through Firebase Authentication, which includes Google and Apple sign-in and email with a password.

How do we run a security review?

Write to hello@event67.com and tell us what your process needs. We answer specifically, and we will tell you plainly when the answer is that we do not have the thing you are asking for.

Send us your security questionnaire

We answer specifically, and we will tell you plainly when the answer is that we do not run the control you are asking about.