One of our sales representatives will contact you shortly.
GDPR is not a checkbox. It is an operational system. InEvent is built to make GDPR compliance routine: self-service data rights, granular consent, auditable logs, EU/UK transfer safeguards, and controllable data residency choices for global events. (InEvent)
Event teams do not get fined for “bad intent.” They get fined for weak processes: missing consent records, slow DSAR handling, uncontrolled exports, and unclear roles for controllers vs processors. InEvent is designed to remove those failure modes by moving privacy controls into the platform. (InEvent)Most GDPR failures in events are not caused by missing features. They come from using the wrong lawful basis for the wrong purpose. A clean GDPR posture starts with a simple map: what data is collected, why it is collected, and which lawful basis you rely on. Consent is only one option, and it is often the wrong one for core event operations.
For example, registration and access commonly sit under “contract” (or steps prior to entering a contract) because the attendee is requesting participation in the event and you need data to deliver it. Security logging and fraud prevention often sit under legitimate interests (or legal obligations, depending on context), because you must protect the platform and demonstrate integrity. Marketing often requires consent when it is not essential to deliver the event itself, especially for ongoing newsletters or sponsor outreach.
A practical lawful-basis map for event workflows usually looks like this:
Service delivery (registration, access, event operations): contract / legitimate interest
Operational communications (changes, reminders, entry instructions): contract / legitimate interest
Networking visibility and 1:1 meeting features: typically consent (because it’s optional and profile sharing is not required to attend)
Sponsor lead sharing: consent (explicit, unbundled, and revocable)
Analytics and conversion tracking on EU event sites: consent (cookie categories), with necessary cookies as strictly required
Security monitoring, anti-abuse, audit logging: legitimate interest / legal obligation (where applicable)
Your platform needs to support this separation in the UI and in the data model. If “Attend the event” is bundled with “Receive marketing from sponsors,” you create compliance debt immediately. You also create DSAR complexity later because you cannot tell which downstream processing was “required” versus “optional.” The safer design pattern is: required fields for delivery, optional fields for enrichment, and separate opt-ins for each optional purpose.
This is why “granular consent management” matters beyond checkboxes. It is how you keep your lawful basis defensible under scrutiny: you can show which data was collected to run the event, which data was collected for optional experiences, and which optional experiences were turned on by the attendee knowingly. It is also how you reduce risk in the most common event scenario: a mixed audience of customers, prospects, partners, and employees where internal policy may be stricter than the law.
Under GDPR Article 17, a data subject can request erasure of personal data in defined circumstances, and controllers must erase “without undue delay.” (GDPR). Operationally, your risk is not the concept of erasure. It is the workflow: identity verification, scope finding, cross-system deletion, and proof that it happened.
The fastest way to fail GDPR is to treat deletion as a manual scavenger hunt across:
registration exports in spreadsheets
email marketing tools
badge printing devices and onsite check-in lists
sponsor lead exports
session attendance reports
helpdesk tickets with personal data pasted into text fields
That sprawl is how organizations miss deadlines, lose auditability, and accidentally retain data they promised to erase.
InEvent describes a rights-to-erasure flow where users can request to be forgotten via a public page: the user enters an email address, receives a confirmation, and confirms they want to be forgotten. InEvent also notes that information is logged for administrative and forensic purposes. (InEvent)
For full account-level termination, InEvent documents a termination page where an authenticated user confirms deletion and submits “Delete account.” InEvent states the termination and removal may take up to five days to complete and is permanent. (faq.inevent.com)
This matters because “delete” has to be:
authenticated (to prevent malicious deletion requests)
repeatable (a standard runbook, not an exception)
provable (log evidence for audits, disputes, and incident response)
bounded (clear expectations for completion time and any lawful retention)
The hardest part of GDPR is not the right itself. It is the operations: intake, identity verification, scoping, execution, and proof. Events increase DSAR pressure because you generate many “small” datasets quickly (forms, check-ins, scans, session attendance, lead capture, exports) and they get copied into places that are not built for privacy governance.
A DSAR-safe workflow starts with a predictable intake and verification process. If you accept requests via random inboxes, you create two risks at once: missed deadlines and unauthorized disclosure. A clean approach is to route requests through a dedicated privacy channel or a standardized portal process, then verify identity before action. Verification does not need to be invasive, but it must be consistent. In events, the most common verification signal is the registration email address plus a confirmation step (which aligns with InEvent’s described “enter email → confirm request” approach). The point is to prevent someone from requesting deletion or export for another person.
Next is scope: you must define what “my data” means in an event context. It can include registration data, custom fields, approval status, badge type, check-in logs, attendance history, session Q&A submissions, meeting requests, and consent choices. The platform can automate parts of this. But you also need an internal runbook for what sits outside the platform: sponsor exports, CRM pushes, shared Google Sheets, and CSV files sent to vendors. DSARs fail when the organization deletes the platform record but keeps the “real” record in a spreadsheet that was emailed around.
Execution needs evidence. Even when the platform performs the deletion or export action, your compliance posture depends on whether you can prove what was done, when it was done, and under which request. That is why audit logs and consent logs are not “nice to have.” They are your defense when an attendee asks, “Did you actually delete it?” or when a regulator asks, “How do you know you complied within the timeline?”
Finally, deadlines matter because DSAR timelines are strict and event teams move fast. The operational fix is to reduce DSAR work to a repeatable checklist:
Verify identity
Confirm request type (export, erasure, restriction, objection)
Run platform action (export/erase)
Notify downstream recipients (where applicable and feasible)
Record evidence (timestamps, actions taken, exceptions, lawful retention reasons)
Close the request with a clear response
When this is built into your event operations, DSARs stop being a fire drill. They become routine. That is the real goal: fewer manual hunts, fewer judgment calls under pressure, and a consistent evidence trail you can defend.
A GDPR-safe erasure program is not just “remove a row from a table.” It must address typical event data surfaces:
Identity layer
user profile details
login credentials (if applicable)
authentication artifacts and session metadata (retention may be required for security)
Registration layer
form submissions
custom fields
approval state, ticket class, payment status
Engagement layer
chat messages (if collected)
meeting requests
session Q&A and polling entries (if attributable)
feedback forms
Operations layer
badge print events
check-in and attendance timestamps
onsite device synchronization records
Exports and downstream recipients
sponsor lead exports
CRM pushes
emailed CSV files sitting in inboxes
local copies on staff laptops
A platform can automate deletion in its own systems. You still need governance for the “last mile”: who exported what, where it went, and whether it must also be deleted.
Avoid absolute claims you cannot prove (“deleted everywhere instantly”). InEvent itself frames rights tooling plus logging, and for account termination it states a completion timeline (“up to five days”). (faq.inevent.com)
A defensible organizer policy typically states:
deletion will be actioned without undue delay
some records may be retained where required by law, security, fraud prevention, or dispute handling
third-party recipients will be notified where applicable (and where feasible)
Consent under GDPR must be freely given, specific, informed, and unambiguous. It cannot be bundled into unrelated contract terms; it must be clearly distinguishable. (InEvent). If you treat “registering for an event” as consent to marketing, sponsor outreach, third-party sharing, and cross-event profiling, you are manufacturing enforcement risk.
A GDPR-safe event registration should separate at least:
Contract / service delivery (often required)
Terms of use for event participation
Privacy notice acknowledgement (not consent, but receipt/notice)
Marketing (optional)
organizer marketing emails
post-event newsletters
partner or sponsor marketing (separate purpose)
Third-party sharing (optional and explicit)
“Share my profile with sponsors”
“Allow meeting requests from exhibitors”
“Publish my profile in attendee networking”
InEvent’s GDPR page explicitly calls out “clear opt-in forms” and the requirement that consent not be bundled, aligning the platform’s approach to this structure. (InEvent).
If you cannot prove what a user agreed to, you are not compliant in practice. The EDPB guidance and ICO consent guidance emphasize that valid consent must be demonstrable and withdrawable. (European Data Protection Board)
InEvent describes built-in GDPR tooling including audit logs and consent management. (InEvent)
A procurement-grade consent record should capture:
user identifier (or event registration ID)
checkbox label text and version at time of consent
timestamp (with timezone)
lawful basis and purpose mapping (your internal register)
method (web form, mobile app, kiosk, API integration)
withdrawal timestamp (if withdrawn)
For EU-facing event websites, tracking consent is not optional. InEvent’s FAQ describes an EU cookie consent pop-up that allows toggling categories (analytics, marketing/ads, content personalization) while “necessary cookies” cannot be disabled, and the user can accept all or save settings. (faq.inevent.com).
Do not treat cookie consent as “marketing’s problem.” It is a legal control. It becomes DSAR scope (you may need to export what tracking choices were made if tied to an identifiable account).
The most underrated GDPR control in event operations is not consent. It is data minimization. Every extra field you collect becomes an extra liability: it expands DSAR scope, increases breach impact, and creates justification work you do not want. Many event teams over-collect because they confuse “nice to know” with “need to know.”
A privacy-first event registration form should start with one question: What is the minimum data required to deliver the event safely and effectively? Name and email are common. Organization might be necessary for access rules. Dietary restrictions may be needed for catering. But fields like personal phone numbers, home addresses, or unrelated demographic questions should be optional and purpose-labeled, or removed entirely. If you cannot explain why a field exists in plain language, it should not be required.
Retention is the second part of minimization. GDPR does not require you to delete everything instantly, but it does require you not to keep data longer than necessary for the purpose. Events create a common retention trap: data is retained “just in case” because it might be useful for next year. That is not automatically unlawful, but it must be justified, documented, and limited. A defensible retention approach usually separates:
Operational retention: short window for delivery, support, and dispute handling
Reporting retention: limited window to analyze attendance and performance
Marketing retention: only for those who opted in, with easy unsubscribe and preference controls
Security retention: logs retained as needed for forensic integrity, with access restricted
Exports are where minimization and retention often collapse. The moment a CSV leaves the platform, you lose centralized control. This is why a GDPR-safe event program treats exports as privileged actions:
restrict exports to specific roles
log exports with timestamp and actor identity
standardize export formats so downstream handling is consistent
avoid “full dataset” exports when a filtered export will do
rotate access and remove temporary staff permissions after the event
If sponsors receive leads, minimize what you share and make the sharing purpose explicit. If you push to a CRM, map only what you need. If badge printing devices store local attendee lists, control how those lists are created, who can download them, and how they are deleted after the event.
The payoff is practical: fewer fields reduces abandonment, reduces DSAR work, and reduces breach impact. It also makes your privacy notice clearer. Instead of explaining a complex web of data collection “because we can,” you can explain a focused set of data uses “because we need to deliver the event.”
GDPR does not say “EU data must never leave the EU” in all cases. It says transfers must be lawful and safeguarded, with mechanisms like adequacy decisions or Standard Contractual Clauses (SCCs). (InEvent). That said, many EU/UK legal teams and public-sector buyers impose stricter internal policies: “EU events must be hosted in EU regions.”
InEvent states its servers are located in Virginia, USA and Dublin, Ireland. It also states EU clients are covered by a Dublin, Ireland-based server. (InEvent)
This is the operational starting point for EU residency in procurement conversations:
EU residency: Dublin (Ireland)
US residency: Virginia (US)
Frankfurt is a well-known EU cloud region option (AWS eu-central-1). (AWS Documentation)
InEvent’s public material in the cited pages names Dublin, not Frankfurt. If your requirement is “Germany-only” or “eu-central-1 specifically,” treat that as a contracting requirement:
require the hosting region in your MSA/DPA
require confirmation of where production data is stored and processed
require restrictions on support access locations
require documentation of transfer mechanisms (SCCs, adequacy)
This keeps you legally accurate and avoids the common procurement failure: marketing claims about a region that is not actually your tenant’s region.
Your biggest GDPR risk is not the core platform. It is what sits around it:
cloud hosting provider
email delivery services
analytics tools
payment processing
webinar streaming
captioning/transcription vendors
CRM and marketing automation integrations
Under GDPR, controllers must understand processors and sub-processors, and ensure contractual controls exist.
InEvent’s Privacy Policy is explicit:
InEvent is a Data Processor under GDPR for customer-submitted personal data.
The customer is the Data Controller and determines how and why personal data is used. (InEvent)
That division matters in every DSAR:
The attendee requests rights.
The controller is responsible for responding.
The processor must support the controller within authorization and contract scope.
InEvent states a Data Processing Agreement is available and that it uses DPAs and SCCs with sub-processors. (InEvent)
This is the baseline procurement expectation for EU/UK.
Your legal review should confirm your DPA includes, at minimum:
subject matter and duration of processing
nature and purpose
type of personal data and categories of data subjects
controller obligations and rights
processor obligations (confidentiality, security, assistance, sub-processing controls)
audit rights and evidence artifacts (SOC 2 report, ISO certificate if applicable, pen test summaries where allowed)
breach notification process and timelines
InEvent’s security page says third-party integrations are vetted and it references sub-processor arrangements via SCCs/DPAs. (InEvent)
A procurement-safe approach is to require:
a current sub-processor list
a notice period for changes
the right to object to new sub-processors in defined circumstances
data location per sub-processor (country/region)
transfer mechanism per sub-processor (SCCs, adequacy, etc.)
InEvent’s GDPR page references the GDPR breach notification standard: notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach (where risk exists). (InEvent)
Your DPA should define:
how “awareness” is determined
notification channels
If there is one place event teams get exposed, it is sponsor and exhibitor lead sharing. This is where GDPR becomes real, because the data leaves the organizer’s direct control and enters another company’s sales stack. The common failure mode is assuming badge scans or booth visits automatically equal consent to be contacted. That assumption is risky. A GDPR-safe workflow makes lead sharing explicit, granular, and provable.
A clean sponsor-sharing model starts with purpose-based opt-ins at registration and inside the event experience. Attendees should understand:
whether their profile will be visible in networking
whether exhibitors can message them
whether their contact details can be shared with sponsors
whether “meeting requests” are enabled and from whom
Then you align this with enforcement. Consent is not only something you collect. It is something you apply. If someone opts out of sponsor sharing, your system should prevent them from appearing in sponsor exports or exhibitor lead retrieval datasets. If someone withdraws consent later, you need a process to stop future sharing and, where reasonable, notify recipients who already received the data.
This is where “last-mile governance” matters, because no platform can delete a CSV that was downloaded onto a laptop or imported into a CRM outside your tenant. But you can govern the risk with operational controls:
require exhibitors to accept data terms before access (use limitations, retention, no resale)
restrict what fields sponsors receive (share business email, not personal phone numbers unless explicitly provided for that purpose)
provide “lead sharing” only when the attendee performs a clear action (e.g., consent checkbox, meeting acceptance, explicit badge-scan consent notice)
log when exports happen and who initiated them
define retention expectations for exhibitors and require deletion after a defined period where applicable
A strong organizer policy also addresses the human layer. Staff often share attendee lists with partners over email because it feels convenient. That is how “shadow processing” happens. The fix is to keep sharing inside governed workflows: platform exports with logging, controlled integrations, and documented recipient obligations.
When you treat sponsors as recipients under a controlled privacy model, you protect your attendees and your event brand. You also protect renewals. Sponsors still get value, but it is value delivered in a compliant way: clear opt-in, clean lead data, and fewer disputes about “why did I get contacted?” That reduces complaints, reduces regulator risk, and increases trust in your event as a safe marketplace.
Data portability (GDPR Article 20) gives data subjects the right to receive personal data they provided in a structured, commonly used, machine-readable format, and transmit it to another controller where feasible. (Legislation.gov.uk)
InEvent’s FAQ describes a user export flow:
user goes to My Account
selects Export user data
receives the exported data by email after clicking Export (faq.inevent.com)
InEvent’s GDPR page also frames portability via a public page for users to see events they are enrolled in and request stored information. (InEvent)
Portability is one of the fastest ways to de-escalate DSAR pressure:
the requester receives their data without a bespoke engineering effort
you reduce internal handling errors (wrong person’s file, incomplete extracts)
you shrink the legal review cycle because the data is produced in a consistent format
DPA + SCCs (signed or ready-to-sign) (InEvent)
Data residency statement (tenant region and any cross-region processing) (InEvent)
Security controls summary (encryption at rest/in transit, access control model) (InEvent)
Audit log capabilities (export logging, admin actions, consent logs) (InEvent)
Data rights workflows (export, erasure, controller support process) (InEvent)
Cookie consent behavior (what loads before consent, categories, retention of choices) (faq.inevent.com)
If you want, I can convert this into a procurement-ready checklist (questions + acceptable answers + evidence artifacts) aligned to GDPR Articles 5, 6, 7, 12–17, 20, 28, 32, and UK GDPR equivalents, using only verifiable claims from InEvent documentation.
Q: Who is the Data Controller and who is the Processor?
InEvent is the Processor; the customer is the Controller for customer-submitted personal data in the platform, and the customer determines why and how personal data is used. (InEvent)
Q: What are the DSAR response deadlines in the UK/EU?
Typically one month, with an extension of up to two additional months for complex requests. This is why self-service export and standardized workflows matter. (ICO)
Q: Is consent required for everything?
No. GDPR allows multiple lawful bases. But where you use consent (especially marketing and tracking), it must be valid, granular, and provable. (European Data Protection Board)
Q: Does InEvent use cookies and provide cookie controls?
Yes. InEvent documents an EU cookie consent pop-up with category toggles and accept/save options, with necessary cookies required for functionality. (faq.inevent.com)
Q: Can we implement EU-only hosting and limit transfers?
InEvent publicly states EU hosting via Dublin and describes SCC/DPA safeguards for transfers. If you require stricter controls (EU-only support access, Germany-only region), make those explicit contractual requirements and verify deployment details. (InEvent)
Q: Does InEvent offer a DPA and SCCs for EU/UK transfers?
Yes. InEvent states a Data Processing Agreement is available to define responsibilities, and it states it uses Standard Contractual Clauses with sub-processors and offers EU Model Clauses to support international transfers for EU/UK customers. (InEvent)
Q: What about breach notification obligations?
GDPR requires notification to regulators without undue delay and, where feasible, within 72 hours where risk exists. Your incident plan must align with that standard, and your vendor DPA must define timelines and content of notifications. (InEvent)
