SELLAI LLC

SafeLaw Service (safelaw.ai)

TIN 312530703, Nukus, Republic of Karakalpakstan, Uzbekistan

INFORMATION SECURITY INCIDENT RESPONSE PLAN

Document IRP-01

Version 1.0

Effective date: 15 May 2026

Compliance: PCI DSS v4.0.1, SAQ A

Master language: Russian. In case of any discrepancy between the English translation and the Russian master, the Russian version shall prevail.

1. Purpose

This Information Security Incident Response Plan (the «Plan») defines the actions of SELLAI LLC (the «Company») in the event of information security incidents, including incidents affecting payment data processed in connection with the SafeLaw service (safelaw.ai). The Plan is developed in accordance with PCI DSS v4.0.1 Requirement 12.10.

Objectives of the Plan:

to ensure a prompt and effective response to information security incidents;
to minimise damage and contain the consequences of an incident;
to notify relevant parties in a timely manner (acquiring bank, payment systems, regulators, users);
to restore normal operations of information systems;
to learn lessons and improve protective measures based on incident outcomes.

2. Scope

The Plan applies to all information security incidents affecting:

the Company's information systems;
data of SafeLaw service users;
the infrastructure supporting payment operations;
the Company's business reputation.

The Plan is mandatory for all employees and contractors of the Company.

3. Definitions

Information security event — an identified state of a system, service or network indicating a possible breach of information security.

Information security incident — one or more unwanted or unforeseen information security events with a significant probability of compromising business operations and threatening information security.

Data compromise — actual or suspected unauthorised access, disclosure, modification or destruction of data.

Incident Response Team (IRT) — the group of individuals responsible for responding to information security incidents.

4. Incident Classification

Incidents are classified by severity level:

Level

Name

Description

Critical

Compromise of payment cardholder data; compromise of accounts with administrative privileges; major service unavailability (>4 hours); suspected malware in production infrastructure.

High

Leak of personal data; compromise of user accounts; targeted attacks (phishing of executives, intrusion attempts); serious vulnerabilities in public services.

Medium

Suspicious activity not resulting in compromise; isolated phishing incidents; unauthorised login attempts without consequences.

Low

Information security policy violations without material consequences; technical failures without indicators of attack.

5. Example Incident Types

unauthorised access to servers, databases or administrative consoles;
account compromise (password disclosure, token theft);
malware on devices or servers;
leak of personal data or other confidential information;
suspected compromise of payment cardholder data;
DDoS attacks and service unavailability;
phishing attacks against employees or users;
exposure of keys, passwords or credentials in source code or configuration;
detection of tampering with payment pages (unauthorised JavaScript, form changes);
incidents at service providers (TPSPs) affecting the Company's infrastructure.

6. Response Team

The Incident Response Team (IRT) is maintained on a standing basis:

Role

Responsibilities

Assigned

Incident Response Team Lead

Overall response coordination; decision-making; communication with management; notifications to external parties.

Director of the Company (R. Jumamuratov)

Information Security Officer

Technical analysis of the incident; containment and eradication; maintaining the incident log.

Appointed by the Director's order (until appointment, performed by the Director)

Technical Specialist

Working with infrastructure, servers, databases and networks; system recovery.

Appointed based on the specifics of the incident

Legal Representative

Assessing legal implications; engagement with regulators; preparing notifications.

Appointed based on the specifics of the incident (an external advisor may be engaged)

Team contact details (internal data):

Internal incident hotline: safelawinfo@gmail.com;
Director direct line: [доступно по запросу];
Alternative communication channel: the Company's internal messenger.

The Response Team operates 24/7. Responsible persons ensure availability through the specified channels around the clock or designate substitutes during their absence.

7. Incident Response Phases

7.1. Preparation

Preparation is an ongoing phase that includes:

keeping this Plan up to date;
training employees and Response Team members;
providing technical means for monitoring, logging and response;
maintaining a register of external contacts (acquiring bank, service providers, legal advisors);
testing the Plan at least every 12 months.

7.2. Detection and Analysis

Sources of incident detection:

reports from employees and users;
monitoring, logging and anti-malware systems, Cloudflare WAF;
notifications from service providers (acquiring bank, hosting provider);
notifications from payment systems and regulators;
media publications and vulnerability databases.

Actions during this phase:

The person identifying an event immediately (within 30 minutes of detection) notifies the Response Team via safelawinfo@gmail.com
The Information Security Officer opens an incident record in the incident log noting date, time, source, description and preliminary classification.
Initial analysis is performed: incident confirmation, scope assessment, severity classification.
For P1 and P2 incidents, the Response Team Lead is notified within 1 hour of incident confirmation.

7.3. Containment

Purpose: to limit the spread of the incident and minimise damage. Actions:

isolation of compromised systems from the network (where necessary);
blocking of compromised accounts;
rotation of passwords, API keys and access tokens;
enabling additional protective rules in Cloudflare WAF;
if a compromise of payment data is suspected, suspending the relevant payment operations in coordination with the acquiring bank.

Evidence is preserved during containment for subsequent analysis: memory images, log copies, file system artefacts.

7.4. Eradication

Actions to eradicate the cause of the incident:

removal of malware;
remediation of vulnerabilities exploited by the attacker (patching, configuration changes);
hardening of security controls in affected systems;
rebuilding compromised systems from scratch where necessary.

7.5. Recovery

Actions to restore normal operations:

restoration of systems from trusted backups or master images;
staged return of restored systems to production with enhanced monitoring;
verification that systems operate correctly and show no signs of re-compromise;
notifying users and partners of the restoration of service, as necessary.

7.6. Post-Incident Analysis and Lessons Learned

Within 10 business days following closure of a P1 or P2 incident, a post-mortem is performed by the Response Team and management. The outcomes are documented and include:

incident timeline;
root cause of the incident;
assessment of the response effectiveness;
gaps identified in defences and in the Plan;
specific measures to prevent recurrence, with assigned owners and deadlines;
updates to the Plan and related policies.

8. External Notifications

8.1. Notification to the Acquiring Bank

Upon detection of P1-level incidents involving a potential compromise of payment cardholder data, or incidents affecting payment operations, the Company shall notify the acquiring bank (Ipak Yuli Bank) within 24 hours of incident confirmation. Notifications are sent through the official channels agreed in the acquiring contract and shall include:

incident date and time;
description of the incident and its potential impact;
containment and eradication actions taken;
expected timelines for remediation and recovery;
the Company's contact person.

8.2. Notification to Payment Systems

Upon confirmed compromise of payment cardholder data, the acquiring bank together with the Company notifies the relevant payment systems (Visa, Mastercard, Uzcard, Humo) in accordance with the rules of those payment systems.

8.3. Notifications to Regulators

In the event of a leak of personal data, the Company notifies the competent authority for personal data of the Republic of Uzbekistan in the manner and within the deadlines set out in Law No. ZRU-547 «On Personal Data».

8.4. Notifications to Affected Users

In the event of a personal data leak affecting SafeLaw users, the Company notifies the affected users no later than 72 hours after the leak is confirmed. The notification includes:

a description of the nature of the leak;
categories and approximate volume of affected data;
likely consequences for the user;
steps taken by the Company to address the leak;
recommendations for the user on account protection;
contact details for inquiries (safelawinfo@gmail.com).

8.5. Notifications to Service Providers

Incidents affecting or potentially affecting service providers' infrastructure (Cloudflare, Netcup, Google Workspace, AI providers etc.) are reported to those providers within their notification timelines.

9. Incident Log

All information security events and incidents are recorded in the incident log. For each incident the following details are recorded:

unique incident identifier;
date and time of detection; date and time of incident start (if known);
source of detection;
severity level;
incident description;
affected systems, data and users;
actions taken, with dates, times and owners;
external parties notified (with date and channel of notification);
post-mortem outcomes and recurrence-prevention measures;
incident closure date.

The incident log is retained for at least 3 years after the incident closure.

10. Plan Testing

The Plan is tested at least every 12 months. Forms of testing:

tabletop exercises — team discussions of action in hypothetical scenarios;
alert drills — verification of team availability through notification channels;
full simulated incident response.

A test report is produced; deficiencies are remediated and the Plan updated as needed.

11. Training

Response Team members are trained to act in accordance with this Plan at least every 12 months. All Company employees receive training on reporting suspicious activity and incidents upon hiring and annually thereafter.

12. Plan Review

This Plan is reviewed at least every 12 months and also:

after each P1 or P2 incident;
upon material changes to the Company's information infrastructure;
upon changes to key service providers (TPSPs);
upon changes to regulatory requirements or standards (PCI DSS, Uzbek legislation).

13. Document Information

Version

Date

Changes

Approved by

1.0

15 May 2026

Initial approval of the document

R. Jumamuratov

Document Approval

This document is approved by the Director of SELLAI LLC and becomes effective from the signing date. All personnel, contractors, and other persons with access to SELLAI LLC information assets are required to acquaint themselves with this document.

Director of SELLAI LLC:

_________________________ / R. Jumamuratov

(signature) (name)

Date: «_____» _____________ 2026

Company seal.