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.