Incident Response Plan

1. Purpose

This document outlines the procedures Lex Protocol follows to detect, respond to, and recover from security incidents. As a platform serving legal professionals, we handle data subject to attorney-client privilege and maintain the highest standards of incident response.

Company: Avci Technologies Pty Ltd (ABN: 69 688 146 581), Melbourne, VIC, Australia.

2. Incident Classification

• Critical — Active data breach, unauthorized access to encrypted data, compromised encryption keys, or exposure of attorney-client privileged information. Response: Immediate (within 1 hour).
• High — Unauthorized access attempt detected, authentication bypass, API credential compromise, or third-party provider breach affecting our data. Response: Within 4 hours.
• Medium — Unusual access patterns, failed authentication spikes, rate limit abuse, or non-critical vulnerability discovered. Response: Within 24 hours.
• Low — Minor configuration issues, non-exploitable vulnerabilities, or policy compliance gaps. Response: Within 7 days.

3. Detection

How we detect incidents:

• Real-time error monitoring via Sentry with automated alerting
• Discord webhook alerts for critical backend errors and anomalies
• Firebase Cloud Logging for all Cloud Function executions and authentication events
• Rate limit monitoring to detect brute-force or credential stuffing attempts
• Firestore Security Rules that block and log unauthorized access attempts
• User reports submitted to security@lex-protocol.com

4. Response Procedures

Phase 1: Identification & Triage (0–1 hour)

• Confirm the incident is genuine (not a false positive)
• Assign severity classification
• Designate incident lead
• Begin documentation in incident log

Phase 2: Containment (1–4 hours)

• Revoke compromised credentials and temporary tokens (Deepgram, Stripe)
• Rotate affected API keys and secrets via Firebase Secret Manager
• Disable affected Cloud Functions if necessary
• Block suspicious IP addresses or user accounts
• Isolate affected data to prevent further exposure

Phase 3: Investigation (4–24 hours)

• Analyze Cloud Logging and Sentry traces to determine scope
• Identify attack vector and affected users/data
• Assess whether encrypted data was exposed (note: AES-256-GCM encrypted data is unreadable without the encryption key)
• Determine if third-party providers were involved
• Document timeline of events

Phase 4: Notification (within regulatory timeframes)

• Affected users: Notified via email as soon as practicable after we determine an eligible data breach has occurred (NDB scheme, Privacy Act 1988) and, for EU users, without undue delay (GDPR Art 34). We aim to notify within 72 hours of confirming a breach
• Australian Information Commissioner (OAIC): Notified as soon as practicable after we determine an eligible data breach under the Notifiable Data Breaches (NDB) scheme; our assessment of a suspected breach is completed within 30 days as the Privacy Act requires
• EU supervisory authority: Where the GDPR applies, notified within 72 hours of becoming aware of the breach (GDPR Art 33)
• Third-party providers: Notified if the breach originated from or affects their systems

Notification includes: what happened, what data was affected, what we're doing about it, and what the user should do.

Phase 5: Recovery (24–72 hours)

• Rotate encryption keys if compromised
• Re-encrypt affected data with new keys
• Restore from backups if data integrity is compromised
• Deploy patches for identified vulnerabilities
• Re-enable disabled services after verification

Phase 6: Post-Incident Review (within 7 days)

• Conduct root cause analysis
• Document lessons learned
• Update security controls and monitoring
• Update this incident response plan if needed
• Publish incident report (for Critical/High severity incidents)

5. Data Backup & Recovery

• Firestore data backed up via Google Cloud automated backups
• Point-in-time recovery available
• Encryption keys stored in Secret Manager with version history
• Account data soft-deleted with 30-day recovery window before permanent deletion

6. Communication Channels

7. Regulatory Obligations

• Australian Privacy Act 1988: Eligible data breaches must be reported to the Office of the Australian Information Commissioner (OAIC) and affected individuals as soon as practicable; suspected breaches are assessed within 30 days
• GDPR (EU users): Data breach notification to supervisory authority within 72 hours; affected individuals notified without undue delay

8. Plan Maintenance

This incident response plan is:

• Reviewed quarterly
• Updated after every Critical or High severity incident
• Tested annually through tabletop exercises
• Version controlled alongside application code