Skip to content
Networks

Overview

Segmentation Standard Overview

At a corporate event, registration, payments, production, streaming, contractors, and venue infrastructure all collide on one network. Our documented segmentation standard keeps them in their own lanes — isolating payment, production, registration, attendee, contractor, and management traffic — and the pre-opening acceptance test proves it holds before go-live.

Why segmentation matters at events

An event is the hardest possible environment for a flat network. Thousands of attendee devices, a payment system that cannot stutter, encoders that cannot drop frames, contractors plugging in unknown hardware, and a production-control system that treats latency as a safety issue — all standing up in a day and tearing down the same night. On a single shared network, an attendee’s behavior can affect a payment terminal, and a contractor’s laptop can reach a production switch. Segmentation removes that possibility by design.

Segmentation does three things at once: it contains failure so a problem in one zone cannot cascade into another, it contains risk so sensitive systems are not reachable from public or contractor space, and it contains scope so payment systems are isolated enough to keep what can touch payment data tightly bounded. It is the structural reason we can be one accountable operator instead of finger-pointing across venue, AV, payment, registration and carriers.

Transport-only posture: we operate at the transport layer. By default we do not store or process cardholder or attendee data — we move it, segmented and monitored, between the systems that own it. Segmentation is how we keep those systems separated, not how we inspect their contents.

The security zones

Every deployment isolates traffic into documented zones. The specific zones in play depend on the event, but the standard covers the following. Each zone has its own boundary, its own access rules, and its own place in the responsibility matrix.

ZoneWhat it carriesWhy it is isolatedWired-first
PaymentPayment devices and payment-adjacent systems.Keeps payment-data paths separated from all other traffic to keep what touches payment data isolated under a clear shared-responsibility model.
RegistrationBadge scanning, check-in desks, and entry systems.Protects check-in and entry flow from attendee congestion and from unrelated production traffic.
ProductionProduction control, encoders, broadcast/streaming contribution, media servers.Low-latency, high-reliability paths must not contend with public or office traffic; a dropped frame is a visible, on-stage failure.
AttendeePublic or guest access, where in scope as an add-on.The least-trusted zone; fully isolated so public devices can never reach payment, production, or management systems.Wireless
ContractorThird-party vendors, sponsors, and activation hardware.Unknown devices are kept off critical zones; access is scoped to what each contractor actually needs.Mixed
ManagementNetwork device administration and monitoring.The control plane is isolated so the network managing the event is never exposed to event traffic.

Wired-first for critical paths

Wireless is shared, contended, and subject to interference from a room full of radios — fine for general attendee access, wrong for anything the event depends on. Our standard is wired-first for the systems that cannot tolerate a retransmit: payments, registration, encoders, and production control. Wireless is engineered deliberately where it belongs, with RF coordination so the zones that must use it do so without stepping on production radios.

  • Payment systems — wired drops
  • Registration & check-in — wired drops
  • Encoders & broadcast contribution — wired drops
  • Production control — wired drops
  • Attendee access — coordinated wireless
  • Contractor access — scoped, mixed media

Resilience underneath the zones

Segmentation defines how traffic is separated; resilience defines what happens when a path fails. Underneath the zones we run dual-WAN where the venue permits, or an approved single underlay with a defined failover plan where it does not. Critical-system redundancy and monitoring sit across the zones so that a failure is detected, contained, and — where designed — failed over inside its target window.

How it is verified before go-live

A segmentation design only counts if it is proven on the actual deployment. That is the job of the pre-opening acceptance test, run before go-live. It is documented, repeatable, and has a clear go/no-go owner.

Segmentation holds

Confirm zones are isolated and that traffic cannot cross boundaries it should not.

Failover lands

Verify WAN failover completes inside its target window on critical paths.

Redundancy is live

Confirm critical-system redundancy is active, not just configured.

Monitoring reports

Verify the NOC is receiving telemetry and alerting before the first attendee arrives.

The first-run pass rate of that test is one of the metrics we hold ourselves to. For how data responsibility maps onto these zones, read the Data Responsibility & Segmentation Guide, and see our Security & assurance posture for the full picture.

See the standard applied to your event

An Event Network Risk Assessment returns a segmentation design scoped to your venue and critical systems — a written scope before any spend.