Impersonation

Fanzava platform staff occasionally need to view a hub’s interface from a participant’s or hub admin’s perspective to investigate a support issue or replicate a reported bug. This is implemented as a constrained impersonation flow with strict controls, full auditing, and customer visibility.

When impersonation is used

Impersonation is initiated only in response to:

• An active support ticket where the participant or hub admin has reported a UI issue that requires Fanzava staff to see exactly what they see
• An open incident where investigating an anomaly requires viewing a specific hub’s state
• A documented troubleshooting request from a hub admin

In all cases, the requesting participant or hub admin is informed before the session begins.

Controls

Every impersonation session is constrained by multiple guardrails:

Control	Behaviour
Justification required	Staff member must enter a ticket or incident reference before the session starts. Sessions without a justification are rejected.
View-only by default	Staff cannot submit tips, change settings, send messages, or perform any state-changing action while impersonating. Writes require a separately documented elevation that is itself audited.
30-minute cap	Sessions auto-expire after 30 minutes. Extending requires re-initiating with a new justification.
No chained impersonation	A staff member impersonating User A cannot then impersonate User B from within that session. Chained or nested impersonation is architecturally prevented.
Visible banner	While impersonating, the staff member’s browser displays a persistent orange banner indicating the session is active, the user being impersonated, and the remaining time.
Screenshot watermark Enterprise	All screenshots taken during impersonation of Enterprise hubs are server-side watermarked with the staff member’s identity and timestamp.

Auditing

Every impersonation session is recorded in the hub’s audit log with:

• The staff member’s identity (impersonator_user_id)
• The user being impersonated (actor_user_id)
• The session start and end timestamps
• The justification reference (ticket or incident ID)
• Every API request made during the session
• Every page accessed

For Enterprise hubs, the impersonation history is also surfaced directly to hub admins from Admin → Settings → Security → Impersonation log. They don’t need to filter the general audit log to see it.

Monthly review

Fanzava conducts a monthly internal review of all impersonation activity across the platform:

• Sessions are reviewed for justification adequacy
• Sessions exceeding 15 minutes are flagged for additional review
• Patterns suggestive of unauthorised access (repeat impersonation of a high-value account, off-hours impersonation, impersonation outside the ticket window) are escalated
• Findings are reported to Fanzava’s security lead and, where relevant, to the affected customer

Enterprise customers can request the impersonation review summary for their hub on a quarterly cadence.

User-visible impersonation history

Enterprise

For Enterprise hubs, participants can see their own impersonation history from Profile → Security → Impersonation log. The log shows:

• When a Fanzava staff member impersonated their account
• The justification reference for that session
• The session duration
• A summary of what was accessed

This is in addition to (not a replacement for) the hub-admin view of the audit log.

Disabling impersonation

For high-sensitivity Enterprise hubs, impersonation can be disabled entirely:

• Hub admins set Admin → Settings → Security → Impersonation → Disable to opt out
• With impersonation disabled, Fanzava support cannot replicate UI issues from the customer’s perspective
• Customers requesting support that requires UI replication will need to provide screen recordings or screenshots themselves

This option is rarely chosen (most Enterprise customers prefer the auditability of impersonation over the support cost of disabling it) but it’s available for environments where the trade-off is required.

i

Note

Impersonation is a deliberate, documented capability with strong controls. It is not a back door: every action is logged, every session is bounded, and the architecture prevents misuse from going undetected.