Incident Response and Business Continuity Policy

1. Purpose

This policy sets out how Lever AI responds to information security incidents and how it keeps its services running and restores them during and after a disruption. Its aim is to limit harm, meet the company's obligations, and return to normal operation quickly.

2. Scope

This policy applies to all Lever AI personnel and to any contractor or third party acting on the company's behalf. It covers all information, systems, and services the company operates, and any event or disruption that affects, or could affect, their confidentiality, integrity, or availability.

3. Incident classification

A security incident is any event that compromises, or threatens to compromise, the security of information or systems. Examples include unauthorised access to a system or account, exposure or loss of data, malware, denial of service, loss or theft of a device holding company or customer data, misuse of access, and any confirmed weakness being actively exploited. A suspected event is treated as an incident until shown otherwise.

4. Severity levels

5. Roles and escalation

The Security Owner leads incident response and decides on severity, containment, and escalation. The Engineering owner carries out technical containment and recovery. The Data Protection lead is engaged whenever personal data may be affected and manages any notification. The Founder is informed of Critical and High incidents and approves external communication. Every member of staff is responsible for reporting a suspected incident without delay. Escalation follows severity: Critical and High incidents are escalated to the Founder immediately; Medium and Low are handled by the Security Owner and reported in the periodic review.

6. Response process

Report. Anyone who suspects an incident reports it immediately to the Security Owner through the designated channel. Reporting is prompt and blame-free.

Triage and assess. The Security Owner confirms whether an incident has occurred, assigns a severity level, and opens an incident record.

Contain. Immediate action is taken to limit the impact, which may include isolating affected systems, disabling accounts, revoking access or sessions, and rotating credentials.

Eradicate and recover. The underlying cause is removed, affected systems are restored to a known-good state, and normal operation is confirmed before the incident is closed.

7. Notification

Where an incident affects personal data, the company follows the Data Protection and Privacy Policy. Acting as a processor, Lever AI notifies the affected customer without undue delay and assists with any regulatory notification, including notification to a supervisory authority within 72 hours where the GDPR applies, and to the Data Protection Board and affected persons as required under the DPDP Act, 2023. External communication is approved by the Founder.

8. Records and post-incident review

Each incident is recorded with its timeline, severity, actions taken, people involved, and outcome, and evidence is preserved where it may be needed. After every Critical or High incident a review is held to establish the root cause and agree improvements, and the resulting actions are tracked to completion.

9. Continuity of service

The company maintains arrangements to keep its services available and to continue essential operations during a disruption. Where a service cannot be maintained, the priority is to restore it within the recovery objectives below and to keep affected customers informed.

The company commits to a monthly service availability target of 99% for its production service, offered to customers as a service level agreement. Availability is measured monthly against the production service endpoint; scheduled maintenance announced to customers in advance is excluded from the measurement. The continuity arrangements in this policy, and the recovery objectives below, exist to meet that commitment; measurement detail and any service-credit terms are set in the customer agreement.

10. Recovery objectives

The company sets recovery objectives for its services. It aims to restore service within a Recovery Time Objective (RTO) of 8 hours and to limit data loss to a Recovery Point Objective (RPO) of 24 hours for the data it retains.

11. Resilience and backups

Production runs on Microsoft Azure using managed, redundant services, and the company relies on the provider's regional redundancy and platform resilience. Configuration and operational data are backed up on a daily basis and retained for at least 30 days, stored within the provider's managed infrastructure separately from the primary systems. The ability to restore from backup is verified periodically.

12. Testing and exercises

The incident response, continuity, and recovery arrangements are exercised at least once a year, for example through a tabletop walkthrough of a realistic scenario or a restore test. The results are recorded, and any actions arising are tracked to completion. Contact points and escalation paths are kept current.

13. Review

This policy is reviewed at least annually and after any significant incident, disruption, or change to the business.