Monitoring, DLP & incident response

This page covers Fanzava’s operational security: how the platform detects security events, what catches sensitive data written into the platform by mistake, and how Fanzava responds when an incident is confirmed.

For a summary you can forward to your IT team, see security at Fanzava.

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 runs a two-tier DLP system that checks content written to the platform for accidental disclosure of sensitive data. Which tiers run depends on the hub’s plan:

Plan	Tier 1: edge scanning	Tier 2: deep scanning
Free, Starter, Growth	✗	✗
Pro, Scale	✓	✗
Enterprise	✓	✓

Tier 1: Edge scanning

Every request that creates or changes content (POST, PUT and PATCH with a JSON, form or plain-text body) is scanned at the Worker layer before it reaches the application. Sign-in requests, public endpoints and file uploads are not scanned.

Tier 1 looks for high-confidence secret formats:

• AWS access keys and secret keys
• Stripe secret and restricted keys
• GitHub personal access and OAuth tokens
• Google and OpenAI API keys
• PostgreSQL, MySQL, MongoDB and Redis connection strings that carry a password
• Private keys (PEM and OpenSSH)

What happens on a match depends on its severity. A confirmed secret, such as a Stripe secret key or a connection string with a password, blocks the request with a 403. Other matches are masked (replaced with [REDACTED]) before the content is stored, and the request carries on. Either way a finding is recorded for the security team. For a body larger than 128 KB, the first 128 KB is scanned before the request continues.

False positives are rare because the patterns target specific, well-known formats.

Tier 2: Deep scanning (Enterprise)

On Enterprise hubs, every request Tier 1 scans is also passed to a queue for deep scanning, whether or not Tier 1 found anything. Secrets Tier 1 recognises are masked before the copy is queued. Tier 2 looks for lower-confidence personal and payment data:

• Payment card numbers, validated with the Luhn check
• US Social Security numbers
• Email addresses, phone numbers and postal addresses

Tier 2 runs after the request has completed, so it detects rather than blocks: a match records a finding for the security team to review. A high-confidence card number is quarantined for priority review, and if nobody reviews it within 24 hours the finding’s copy of the content is permanently redacted.

A finding keeps the pattern that matched, the hub, the request and a copy of the content with recognised secrets masked, so the security team can judge whether the match is real.

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.