Incident Response Plan

This document defines severity levels, response procedures, communication protocols, and post-incident review processes for Conduit security incidents.

Severity levels

LevelDefinitionExampleResponse time
P1Active data breach or unauthorized access to MLS dataAPI key compromise, RLS bypass, unauthorized listing data exposureImmediate (within 1 hour)
P2Vulnerability discovered that could lead to breachMissing RLS policy, auth bypass in staging, credential exposure in logsWithin 4 hours
P3Security degradation without immediate exploit riskRate limiting failure, audit log gap, billing miscalculationWithin 24 hours
P4Minor security improvement or hardening opportunityDependency update, header hardening, logging improvementNext development cycle

Immediate response procedures

P1: Active breach response

01.Activate kill switch — Suspend the affected vendor's access immediately (see Kill Switch Procedure below).
02.Revoke compromised credentials — Rotate or revoke any API keys, OAuth tokens, or service credentials that may be compromised.
03.Preserve evidence — Export audit logs for the affected time window. Do not modify or delete any records.
04.Assess blast radius — Determine which MLSs, vendors, and data were affected using the audit log.
05.Notify affected parties — Contact affected MLS administrators and vendors within 4 hours (see Communication below).
06.Remediate — Patch the vulnerability, deploy the fix, and verify the fix prevents recurrence.

P2: Vulnerability response

01.Assess exploitability — Determine if the vulnerability is being actively exploited. If yes, escalate to P1.
02.Implement temporary mitigation — Apply WAF rules, tighten rate limits, or restrict access as needed.
03.Develop and test fix — Patch the vulnerability and verify in staging.
04.Deploy — Push the fix to production and verify.
05.Audit for similar issues — Check for the same class of vulnerability elsewhere in the codebase.

Kill switch procedure

[!!]Emergency use only

The kill switch immediately terminates a vendor's ability to query MLS data. Use only when vendor access poses an active threat to MLS data integrity.

Path A: Dashboard (preferred)

Navigate to MLS Dashboard → Vendor Management → select vendor → click "Suspend Access". Takes effect within 300 seconds (KV cache TTL).

Path B: Direct database (emergency)

If dashboard is unavailable or immediate effect is required:

sql
-- Suspend specific vendor access to specific MLS
UPDATE mls_vendor_access
SET status = 'suspended', updated_at = now()
WHERE vendor_id = '<vendor_profile_id>'
  AND mls_id = '<mls_profile_id>';

-- Nuclear option: suspend ALL vendor access to an MLS
UPDATE mls_vendor_access
SET status = 'suspended', updated_at = now()
WHERE mls_id = '<mls_profile_id>';

Direct database updates bypass KV cache and take effect on the next governance context lookup (cache miss or TTL expiry). To force immediate effect, manually evict the affected governance context keys from Cloudflare KV.

Communication

MLS administrators — Notified within 4 hours of P1 incidents affecting their data. Email with incident summary, affected data scope, and remediation steps. Follow-up within 24 hours with root cause analysis.

Vendors — Notified if their credentials were compromised or if their access was suspended. Include clear next steps for credential rotation.

Board/stakeholder reports — P1 and P2 incidents produce a formal incident report within 7 days. Report includes: timeline, root cause, blast radius, remediation actions, and controls added to prevent recurrence.

Post-incident review

Root cause analysis — Every P1 and P2 incident receives a formal RCA within 7 days. Blameless format focused on system improvements, not individual fault.

Controls update — Identified gaps are addressed with new controls, tests, or monitoring. Changes are tracked as security work orders with verification evidence.

Publication — Material incidents are documented in a public security advisory (after remediation is complete) to maintain transparency with MLS partners.