Lighthouse Incident Response Plan

This is the public summary of Lighthouse's internal incident response plan. It describes how we detect, contain, recover from and communicate about security incidents, privacy breaches and AI incidents. It is suitable for sharing with customers, auditors and security reviewers.

Incidents this plan covers

The plan covers:

• Security incidents: unauthorized access to Lighthouse systems or accounts, exposed credentials, malware, or attacks on availability.
• Privacy breaches: personal information accessed, disclosed, lost or altered without authorization, including exposure of one customer's data to another.
• AI incidents: harmful or wrong output from an AI feature reaching platform users, customer systems or candidates; compromise or outage of a model provider; candidate data reaching a model provider outside our rules; and prompt injection.
• Incidents at our service providers: an outage or breach at a provider such as Supabase, Google Cloud or Railway that affects Lighthouse systems or data.

How to report an incident to Lighthouse

Anyone, including customers and candidates, can report a suspected security incident, privacy breach, AI incident or vulnerability to security@lighthousehiring.ca. Customers can also report through support@lighthousehiring.ca. Reports reach the CEO and the CTO.

Roles and responsibilities

• The CTO leads every incident and runs the technical response; other staff support as the CTO directs.
• The CEO is the single point of contact for affected customers.
• If the CTO is unavailable, the CEO leads the incident, limited to containment steps that need no code change and to customer communication.
• The CEO and the CTO together decide whether an incident must be notified to regulators or individuals.

Severity levels and response targets

The plan uses the four support severity levels of our customer agreements, with their initial response targets.

Security incidents involving personal information are always Severity 1, whatever the number of customers affected. When the level is unclear, we use the higher one. Escalation beyond the standard support channels may be directed to the CEO or the CTO.

Preparation

We keep this plan, the credential register, the AI system inventory and the vendor register current, and exercise the plan once a year (see Testing this plan).

Backup and recovery

Production data is backed up daily, and backups are kept for 30 days. Our recovery targets are to restore service within 24 hours and to lose no more than 24 hours of data.

Incident response steps

1. Detect and report: whoever notices an incident records what they saw and when, before changing anything, and reports it to the CTO, who declares the incident.
2. Triage: the CTO sets the severity level and establishes which systems, customers and data are affected.
3. Contain: stop the harm first. Exposed credentials are rotated under our key management policy, high-privilege credentials within 24 hours of discovery.
4. Eradicate and recover: fix the cause through our normal reviewed change process, repair affected data with reversible changes, and verify the fix end to end.
5. Notify: tell affected customers and assess our notification duties, as set out under Notifying customers, individuals and regulators.
6. Review: for every Severity 1 or Severity 2 incident, record the cause and the changes that follow, each with an owner and a date.

These steps align with the incident handling lifecycle of NIST SP 800-61.

Handling incidents at our service providers

An outage or breach at a service provider is handled under this plan like any other incident, with its severity set by its effect on customers and candidates. Provider status pages and breach notices are among the ways we detect these incidents.

Handling AI incidents

AI incidents follow the same roles, severity levels and response steps as every other incident. This section adds what is specific to AI features.

Candidate scores are computed by a deterministic rules engine; language models parse resumes and help draft scorecards, but do not score candidates. Parsed fields feed the scoring rules, so an incident that damages parsed profiles can change candidates' scores.

Kinds of AI incident and the first question we answer

Severity examples for AI incidents

Other AI incidents, including prompt injection, are rated by their effect against the severity levels above.

What keeps working during a model provider outage

Scoring needs no model provider: the rules engine scores from profiles already stored in our database. A model provider outage therefore stops parsing of new resumes and the AI assistance features, but applications already parsed keep their scores and can still be scored. An outage that stops resume parsing is Severity 2.

Containment, repair and customer communication

• Each AI feature has a documented containment option: reverting to the previous model version, pausing new parses, disabling the feature, or disabling the provider credential.
• Data affected by a wrong output is repaired and re-scored, and affected customers are told the date range and number of applications so they can re-review candidates.
• A provider that has not been reviewed for data protection is never used as a workaround during an outage.

Notifying customers, individuals and regulators

For candidate data, Lighthouse acts as a service provider to the customer, who controls the information.

Telling customers about an incident. Whether a customer reports an incident to us or we detect it ourselves, we tell the affected customers within the initial response target for its severity level, measured from when Lighthouse becomes aware of the incident: within 1 hour for Severity 1 and within 4 hours for Severity 2, 24 hours a day, 7 days a week, within 1 business day for Severity 3, and within 2 to 3 business days for Severity 4. Near misses with no customer impact are recorded but not notified. Customers are also informed through our status page, https://status.lighthousehiring.ai/, and by email during an outage.

Written notice of a confirmed breach. Lighthouse notifies affected customers in writing of a confirmed breach of their data without undue delay, and no later than 72 hours after becoming aware of it, or sooner where their contract requires. With that notice, we give them the facts they need for their own notices, cooperate in reasonable investigations and keep them informed of remediation.

Notices to candidates and regulators. The customer, as controller, decides on and sends notices to candidates and regulators unless the contract assigns that to Lighthouse, and Lighthouse assists; where Lighthouse controls the information itself, it notifies directly.

The breach notification rules we work within include, among others:

• Canadian federal and provincial privacy law: PIPEDA's breach of security safeguards rules, Quebec's private-sector privacy act and Alberta's Personal Information Protection Act, under which the organization in control of the information reports qualifying breaches to the regulator and the individuals concerned and keeps a breach record.
• United States state data breach notification laws: which generally require a service provider to notify the business it holds data for, and that business to notify affected residents and, in some states, regulators.
• GDPR and UK GDPR: where they apply, a processor notifies the controller without undue delay.

Incident records

Every incident, whatever its severity, is recorded with its timeline, scope, actions taken, notification assessment and outcome. Records do not contain candidate names, contact details or resume content, and are kept for at least 24 months.

Testing this plan

The CEO and the CTO run a tabletop exercise of this plan once a year and record the results.

Standards this plan aligns with

This plan is aligned with NIST SP 800-61, Canadian federal and provincial privacy law, applicable US state data breach notification laws, and our customer agreements.