Guide
Data Responsibility & Network Segmentation
When payments and registration ride an event network, the question is not just “is it secure?” — it is “who is responsible for what, and what data touches whom?” Here is how we approach it: transport-only by default, the segmentation boundary defined before contract, and responsibility allocated explicitly across the venue, partner, organizer, payment vendor, and LGL.
Transport-only by default
Our default posture is unambiguous: we operate at the transport layer. We carry and isolate payment traffic across a segmented, monitored network between the systems that own it — the payment devices and the payment provider. By default we do not store, process, or transmit payment data as a data processor, and we do not log or retain attendee or cardholder data unless that is explicitly contracted, which is not our standard model.
This matters. Because we provide connectivity rather than handling payment data, our role is to deliver and segment the network that payment systems use — not to sit inside the payment application’s data path beyond carrying it. We do not run the client’s payment, registration, or production applications, and we do not stand behind their uptime; we stand behind the network and transport we operate.
Defining the boundary before contract
Where payment traffic flows on the network is not something to discover after deployment. We define the boundary up front — during the Event Network Risk Assessment and before any deployment contract — so every party knows which segments carry payment traffic, how they are isolated, and what is out of scope.
- Identify the payment path on the network — which devices and segments carry or connect to payment traffic for this event.
- Draw the segmentation boundary — how the payment zone is isolated from production, registration, attendee, contractor, and management zones.
- State what LGL operates vs. does not — transport and segmentation in; payment-data storage and processing out, by default.
- Document assumptions — the payment vendor’s architecture, encryption at the device, and where the payment provider’s responsibility starts.
- Record it in the responsibility matrix — so the boundary is contractual, not verbal.
Who is responsible for what
No single party owns payment responsibility for an event end to end. The honest model is shared responsibility, written down before the event. The table below shows the typical allocation; specifics are confirmed per engagement and depend on the payment vendor’s architecture and the merchant relationship.
| Area | Typically owned by | LGL's role |
|---|---|---|
| Merchant account & payment compliance obligation | Organizer / merchant of record | Not LGL |
| Payment application & cardholder-data handling | Payment vendor | Not LGL |
| Payment processing & settlement | Payment provider / acquirer | Not LGL |
| Network transport for payment traffic | LGL | Operated by LGL |
| Segmentation isolating the payment zone | LGL | Operated by LGL |
| Pre-opening acceptance test of segmentation | LGL | Operated by LGL |
| Venue circuit & demarc | Venue / house provider | Coordinated, not owned |
| Engagement integration & client relationship | Production / AV partner (white-label) | Delivered behind partner |
The point of writing this down is the same point as our whole model: one accountable operator for the network, with every other responsibility named and owned — instead of finger-pointing across venue, AV, payment, registration and carrier vendors when something goes wrong.
How segmentation isolates payment data
Effective network segmentation is one of the most direct ways to keep the set of systems that can touch payment data small. When the payment zone is genuinely isolated — no path from attendee, contractor, or general production traffic into it — systems outside that boundary stay out of the payment path. That is exactly what our segmentation standard is built to do, and it is precisely what the pre-opening acceptance test verifies before go-live.
Prerequisites before a paying payment engagement
Carrying payment traffic raises the bar, and we hold ourselves to it. Before the first paying engagement that touches payment traffic, we expect the segmentation approach and the data-responsibility boundary to be settled, the responsibility matrix to be signed, and cyber-liability and E&O insurance to be in place for the parties operating the network. These are preconditions, not afterthoughts.
For the broader picture of how we handle security across every zone, see Security & assurance.
Settle data responsibility before you deploy
An Event Network Risk Assessment defines the segmentation boundary and the responsibility matrix before contract — a written scope before any spend.