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 (ABN: 69688146581), 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@lexprotocol.co

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 OAuth tokens (Clio, 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 within 72 hours of confirmed breach (GDPR requirement)
• Australian Information Commissioner: Notified within 30 days if eligible data breach under the Notifiable Data Breaches (NDB) scheme (Privacy Act 1988)
• Clio: Notified if the breach involves Clio integration tokens or synced data
• 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
• GDPR (EU users): Data breach notification to supervisory authority within 72 hours; affected individuals notified without undue delay
• Clio Developer Terms: Security incidents affecting Clio integration data reported to Clio's developer support

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