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 a reportable data breach has occurred under applicable data-breach notification laws and, for EU users, without undue delay (GDPR Art 34). We aim to notify within 72 hours of confirming a breach
• Relevant supervisory authority: Notified as soon as practicable after we determine a reportable data breach under applicable data-breach notification laws; our assessment of a suspected breach is completed within 30 days
• 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

• Applicable data-breach notification laws: Reportable data breaches must be reported to the relevant supervisory authority 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