Incident Response Policy
Version 1.0 · Effective 3 September 2026
On this page
1. Purpose 2. Scope 3. Definitions 4. Responsibilities 5. How to Report an Incident 6. Severity Classification 7. Response Procedure 8. Notification Obligations 9. Evidence Handling and Forensics 10. Post-Incident Review 11. Testing and Training 12. Policy Compliance1. Purpose
The goal of this policy is to clearly identify the IT roles and responsibilities of Xpert Group FZE-LLC ("the Company") for the investigation of and response to computer security incidents and data breaches affecting the Company and the SignSyncer platform.
The policy exists so that when something goes wrong, everyone knows who leads, who decides, who communicates, and what happens in which order — without needing to work it out under pressure.
2. Scope
This policy applies to all personnel, including employees, temporary workers, contractors, those employed by contracted entities, and others authorised to access Company information resources, regardless of the ownership or location of the information systems used to store, process, transmit, or access Company data.
It covers all incidents affecting signsyncer.com, app.signsyncer.com, the supporting APIs and infrastructure, Company corporate systems, and any data processed on behalf of customers.
3. Definitions
| Term | Meaning |
|---|---|
| Security event | Any observable occurrence relevant to security, such as a failed login or an alert. Most events are not incidents. |
| Security incident | An event, or series of events, that compromises or threatens the confidentiality, integrity, or availability of Company or customer information or systems. |
| Personal data breach | A security incident leading to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data. |
| Incident Response Team (IRT) | The group convened by the Security Officer to manage an incident through to closure. |
| Containment | Action taken to limit the scope and impact of an incident before the root cause is fully resolved. |
4. Responsibilities
| Role | Named individual | Responsibility |
|---|---|---|
| Security Officer & Incident Response Team Lead | Shahid Rasool +971 50 433 4829 developer@xpertgroup.me | Primarily responsible for all procedures involved in the reporting, identification, investigation, and resolution of security incidents. Declares an incident, sets severity, convenes the IRT, and approves closure. |
| External communications | Shahid Rasool developer@xpertgroup.me | Responsible for external communication on significant security-related issues, covering both the event itself and its resolution. No other person may make an external statement about an incident. |
| Legal & Human Resources | Ammad Sajid +971 50 849 7302 | Advises on regulatory notification obligations, contractual commitments, evidence preservation, insurance notification, and any employment matters arising from the incident. |
| Communications | Sonia Nisar +971 54 382 9536 | Prepares and delivers internal messaging to staff, and supports customer-facing and media messaging drafted with the Security Officer. |
| All personnel | — | Responsible for promptly reporting any suspected or confirmed security incident involving Company data or an associated information system, even if they have contributed in some way to the event or incident. |
No-blame reporting. Anyone who reports an incident in good faith — including one they caused themselves — will not face disciplinary action for reporting it. Failing to report a known incident, or concealing one, is a disciplinary matter.
5. How to Report an Incident
A suspected or confirmed security incident must be reported immediately, and in any case within one hour of discovery, using one of the following channels:
| Channel | Detail |
|---|---|
| Email (primary) | developer@xpertgroup.me — Security Officer |
| Email (customers and public) | support@signsyncer.com |
| Telephone (urgent) | +971 50 433 4829 — Security Officer |
| Verbally or via chat | Directly to the security responsible person, followed up in writing the same day |
The report should describe what happened, when it was noticed, which systems or data appear to be affected, and what the reporter has already done. Reporters must not attempt to investigate, remediate, or delete evidence themselves unless instructed by the Security Officer.
External security researchers should report through the Vulnerability Disclosure Policy.
6. Severity Classification
The Security Officer assigns a severity at triage. Severity may be revised as more is learned.
| Level | Definition | Response target |
|---|---|---|
| P1 CRITICAL | Confirmed unauthorised access to customer data, OAuth tokens, or production credentials; ransomware; full platform outage; active exploitation in progress. | Immediate response, 24/7. IRT convened within 1 hour. Updates every 2 hours. |
| P2 HIGH | Suspected but unconfirmed data exposure; exploitable vulnerability in production; partial outage affecting many customers; loss of a device holding customer data. | Response within 4 hours. IRT convened same business day. Daily updates. |
| P3 MEDIUM | Contained incident with no data exposure; malware on a single endpoint; policy violation with security impact; single-customer service issue. | Response within 1 business day. Updates every 3 business days. |
| P4 LOW | Minor policy deviation, false positive requiring documentation, or a finding with no realistic exploit path. | Response within 5 business days. Tracked to closure in the normal cycle. |
7. Response Procedure
In the case of a security incident, the following steps are taken by the security responsible person towards resolution. Each step is recorded in the incident log with a timestamp and the name of the person who performed it.
1Investigate and reproduce
Confirm that the report is genuine. Reproduce the issue in a controlled way where safe to do so. Preserve logs and evidence before changing anything. Open an incident record and start the timeline.
2Determine the size and type of the breach
Establish which systems, accounts, records, and data categories are affected; whether personal data is involved; how many individuals and organisations are impacted; and whether the incident is ongoing or historic.
3Contain
Take immediate action to limit the damage — revoke sessions and OAuth tokens, rotate credentials and keys, disable affected accounts, block source addresses, isolate hosts, or take a component offline. Containment takes priority over root-cause analysis.
4Define the communication plan — the issue
Agree with Legal and Communications what will be said internally and externally about the incident, to whom, and when. The Security Officer is the single external voice. Nothing is published without their approval.
5Classify
Classify the incident as front-end, back-end, infrastructure, third-party, or other, and confirm the severity level from Section 6.
6Assign technical ownership
Name the individual technically responsible for the resolution. That person owns the fix through to verified deployment and reports progress to the Security Officer at the cadence set by the severity level.
7Eradicate, resolve, and deploy to all environments
Remove the root cause, apply the fix, and deploy it consistently across every environment. Verify the fix independently. Confirm that no attacker persistence remains before restoring normal service.
8Recover and verify
Restore affected services from clean sources, re-enable accounts, confirm data integrity, and monitor closely for recurrence for at least 14 days after closure.
9Identify automatic detection and notification
Identify how this and similar security issues could be detected and alerted on automatically in future, and raise the work to implement it. An incident that could recur undetected is not fully closed.
10Review all relevant policies for updates
Review this policy set and any related standard for changes needed as a result of the incident, and update them where required.
11Define the communication plan — the resolution
Communicate the resolution internally and externally: what happened, what was affected, what was done, and what has changed to prevent recurrence.
8. Notification Obligations
Where an incident involves personal data or customer data, the following notification timelines apply. Legal advises on which apply in each case; the Security Officer executes them.
| Recipient | Timeline |
|---|---|
| Supervisory authority under GDPR | Without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach likely to result in a risk to individuals |
| UAE Data Office under Federal Decree-Law No. 45 of 2021 | Without undue delay upon becoming aware, in the form required by the regulator |
| Affected business customers (where we act as processor) | Without undue delay, and in any event within 48 hours of confirming that their data is affected, so they can meet their own obligations |
| Affected individuals | Without undue delay where the breach is likely to result in a high risk to their rights and freedoms |
| Google, where Google User Data is affected | Promptly, in line with the Google API Services User Data Policy and any applicable assessment or partner obligations |
| Microsoft, where Microsoft user data is affected | Promptly, in line with applicable Microsoft partner and publisher obligations |
| Cyber insurer | As required by the policy, typically immediately on declaring a P1 or P2 incident |
Notifications describe the nature of the incident, the categories and approximate number of individuals and records concerned, the likely consequences, the measures taken or proposed, and a contact point for further information.
9. Evidence Handling and Forensics
- Preserve before you fix. Take copies of logs, memory, and disk images where practical before remediating, and record who took them and when.
- Do not power off a compromised system unless instructed; volatile evidence may be lost.
- Maintain a chain of custody for any evidence collected, recording each person who handled it and the date and time.
- Store evidence encrypted, with access limited to the IRT and any appointed forensic investigator.
- Where cyber insurance is in place, the insurer's appointed forensic investigators will determine how the breach occurred, the types of data involved, the number of individuals and organisations impacted, and the root cause.
- Retain incident records for a minimum of 3 years.
10. Post-Incident Review
A post-incident review is held within 10 business days of closing any P1 or P2 incident, and at the Security Officer's discretion for P3 and P4.
The review is blameless and covers: the timeline of events, how the incident was detected and how long detection took, what worked, what did not, the root cause, contributing factors, and the corrective actions required. Each corrective action is given an owner and a due date, and is tracked to closure by the Security Officer. Findings feed back into the Information Security Policy and the risk register.
11. Testing and Training
- The Incident Response Team conducts a table-top exercise at least annually, simulating a realistic scenario such as a leaked OAuth token or a compromised administrator account.
- The exercise tests the contact tree, the decision path, the containment steps, and the notification timelines. Findings are documented and used to update this policy.
- Contact details in Section 4 are verified at least quarterly and updated immediately on any personnel change.
- All personnel receive incident reporting training on joining and annually thereafter, so that everyone knows how to raise an incident and what not to do.
12. Policy Compliance
Compliance measurement
The Security Officer verifies compliance with this policy through incident record review, exercise results, response-time metrics, and internal and external audit.
Exceptions
Any exception to this policy must be approved by the Security Officer in advance and documented with a business justification and an expiry date.
Non-compliance
An employee found to have violated this policy — including by failing to report or by concealing a known incident — may be subject to disciplinary action, up to and including termination of employment.
Review and version history
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | 3 September 2026 | Shahid Rasool, Security Officer | Initial issue for Xpert Group FZE-LLC and the SignSyncer platform |