Monitoring, DLP & incident response

This page covers Fanzava’s operational security: how the platform detects security events, what prevents sensitive data from leaving through unintended paths, and how Fanzava responds when an incident is confirmed.

Monitoring

Security-relevant events flow into Fanzava’s monitoring stack on Cloudflare Analytics Engine. The events monitored continuously include:

• Authentication failures and rate-limit triggers
• Authorisation failures (requests rejected for missing role or membership)
• WAF events (blocked requests, threat scores)
• Anomalous traffic patterns (unusual request volumes, unusual geography for known accounts)
• Impersonation sessions
• Production database access requests (Cloudflare Access events)
• Cross-region access attempts

Detection rules trigger alerts to Fanzava’s on-call security responder. Common alert types: spikes in failed sign-in attempts on a single account, unusual access patterns from known admin accounts, WAF events targeting specific hubs.

Data Loss Prevention (DLP)

Fanzava operates a two-tier DLP system that monitors content moving through the platform for unintentional disclosure of sensitive data.

Tier 1 — Edge scanning

A lightweight regex pass runs at the Worker layer on all incoming requests and outbound responses. It targets high-confidence patterns: known secret formats (AWS access keys, Stripe API keys, JWT signing keys, private SSH keys), well-known credential formats, and similar.

When a Tier 1 match occurs, the request is blocked, an audit event is logged, and (for outbound responses) a generic error is returned to the user. False positives are rare because the patterns target highly specific formats.

Tier 2 — Async deep scanning

A queue consumer asynchronously inspects larger payloads (uploads, bulk imports, generated exports) for lower-confidence patterns: credit card numbers validated with the Luhn check, common PII formats (US SSN, Australian TFN, similar), and structured data shapes that could indicate accidental disclosure.

Tier 2 runs detection-only in Phase 1 — matches are logged for review rather than blocking the operation, which keeps false positives from disrupting legitimate use. Once tuning is complete, Tier 2 will move to enforcement.

DLP logs do not include the matched content itself, only the pattern that matched and structured metadata (request ID, hub ID, timestamp). DLP event log retention is 90 days.

Incident detection and triage

A security incident is any event that compromises, or threatens to compromise, the confidentiality, integrity, or availability of customer data or the platform.

Incidents are triaged into four priority tiers:

Priority	Definition	Response time
P1	Active breach of customer data or platform integrity	Immediate response; security lead activated; status page updated
P2	Suspected breach, or active exploitation of a critical vulnerability	Response within 1 hour; full investigation initiated
P3	Confirmed vulnerability of high severity, no active exploitation observed	Response within 4 hours; remediation prioritised
P4	Confirmed vulnerability of medium or low severity	Response within 1 business day; remediation scheduled

P1 and P2 are handled out of hours. P3 and P4 default to business hours unless evidence escalates them.

Response workflow

Confirmed incidents follow a six-phase workflow:

1. Detect — Alerts, customer reports, vulnerability disclosure submissions, or routine review identifies a potential incident.
2. Triage — Security responder confirms or downgrades the incident, assigns priority, and identifies affected scope.
3. Contain — Immediate actions to stop further damage (revoke compromised credentials, block exploited paths via WAF, isolate affected resources).
4. Eradicate — Remove the cause (patch the vulnerability, remove malicious access, fix the misconfiguration).
5. Recover — Restore normal operations, verify the fix works, monitor for recurrence.
6. Post-incident review — Within 5 business days, document timeline, root cause, contributing factors, and corrective actions. Findings feed into engineering and security backlogs.

Customer notification

For incidents affecting customer data, Fanzava notifies affected hub admins within 72 hours of confirming the breach, as required by GDPR Article 33 and the Australian Notifiable Data Breaches scheme. Notification includes:

• What data was affected (categories, approximate volume, hubs impacted)
• When the incident occurred and was discovered
• What Fanzava has done to contain and resolve it
• What hub admins should do (typically: communicate to participants, change credentials, monitor for unusual activity)
• The point of contact for follow-up questions

For severity below the regulatory notification threshold, Fanzava notifies affected hub admins within 5 business days with the same information.

See DPA & GDPR for the full regulatory framework.

Vulnerability disclosure

Report security issues to security@fanzava.com. Fanzava acknowledges reports within 24 hours and provides status updates every 48 hours until resolution.

For confirmed vulnerabilities, Fanzava follows responsible disclosure practice: the reporter is credited (with their permission), and public disclosure is coordinated to give affected customers time to patch where applicable.

Status page

Fanzava maintains a public status page at status.fanzava.com for operational incidents — outages, degraded performance, and similar. Security incidents are posted to the status page when they’re customer-affecting or when sufficient time has passed that disclosure no longer aids ongoing investigation.

i

Note

For the privacy and regulatory framing of how breaches are notified (data controller / processor split, GDPR Article 33, Australian NDB scheme), see DPA & GDPR.