Information Security Policy

1. About This Document

This document contains the set of IT and security policies which together comprise the Information Security Policy of Xpert Group FZE-LLC ("the Company") in respect of its business operations and the SignSyncer platform, delivered at https://signsyncer.com and https://app.signsyncer.com.

It applies to all employees, contractors, consultants, temporary workers, interns, and other personnel affiliated with third parties who access Company information resources, regardless of the ownership or location of the systems used to store, process, transmit, or access Company data.

The Security Officer owns this document. It is reviewed at least annually, and additionally whenever there is a material change to the platform, the threat landscape, or applicable law. Every member of personnel is required to read and acknowledge this policy on joining and at each annual review.

2. Roles and Responsibilities

2.1 Responsibilities in summary

• Security Officer: owns this policy set, approves exceptions, verifies compliance, leads incident response, maintains the risk register, and reports security posture to management.
• Legal & Human Resources: owns contractual and regulatory obligations, breach notification requirements, employment screening, confidentiality agreements, and disciplinary process.
• Communications: owns all internal and external messaging during an incident, including customer notification and any statement to the media or regulators.
• All personnel: are responsible for complying with these policies, protecting the information they handle, and promptly reporting any suspected or confirmed security incident.

3. Data Classification

All Company information is classified into one of four levels. The handling requirements for each level are set out below.

4. Data Breach Response Policy

Purpose

The purpose of this policy is to establish the goals and the vision for the breach response process. This policy defines to whom it applies and under what circumstances; it includes the definition of a breach, staff roles and responsibilities, standards and metrics enabling prioritisation of incidents, and reporting, remediation, and feedback mechanisms. This policy is publicised and made easily available to all personnel whose duties involve data privacy and security protection.

The Company's intention in publishing a Data Breach Response Policy is to focus significant attention on data security and data security breaches, and on how the Company's established culture of openness, trust, and integrity should respond to such activity. The Company is committed to protecting its employees, partners, customers, and the business itself from illegal or damaging actions by individuals, whether knowing or unknowing.

Background

This policy mandates that any individual who suspects that a theft, breach, or exposure of Company Protected data or Company Sensitive data has occurred must immediately provide a description of what occurred by email to the Company's Security Officer at developer@xpertgroup.me, or by calling +971 50 433 4829. This mailbox is monitored by the Security Officer. The Security Officer and the incident response team will investigate all reported thefts, data breaches, and exposures to confirm whether a theft, breach, or exposure has occurred. If one has, the Security Officer will follow the procedure set out in the Incident Response Policy.

Scope

This policy applies to all who collect, access, maintain, distribute, process, protect, store, use, transmit, dispose of, or otherwise handle personally identifiable information belonging to the Company's customers, their end users, or the Company's own personnel. Any agreement with a vendor will contain language that provides equivalent protection.

Policy

As soon as a theft, data breach, or exposure containing Company Protected data or Company Sensitive data is identified, the process of removing all access to that resource will begin.

The Security Officer will chair an incident response team to handle the breach or exposure. The team will include members from:

• IT Infrastructure and Applications
• Legal
• Communications
• Human Resources
• The affected unit or department that uses the involved system or output, or whose data may have been breached or exposed
• Additional departments based on the data type involved, and additional individuals as deemed necessary by the Security Officer

Confirmed theft, breach, or exposure of Company data

The Security Officer will be notified of the theft, breach, or exposure. IT, along with a designated forensic team, will analyse the breach or exposure to determine the root cause.

Work with forensic investigators

Where cyber insurance is in place, the insurer will provide access to forensic investigators and experts who will determine how the breach or exposure occurred, the types of data involved, the number of internal and external individuals or organisations impacted, and the root cause.

Develop a communication plan

The Security Officer will work with the Communications, Legal, and Human Resources leads to decide how to communicate the breach to (a) internal employees, (b) the public and the relevant authorities, and (c) those directly affected. Where the breach involves personal data subject to the GDPR, notification to the supervisory authority will be made without undue delay and, where feasible, within 72 hours of becoming aware of it.

5. Disaster Recovery Plan Policy

Overview

Because disasters happen rarely, management often neglects the disaster recovery planning process. Having a contingency plan in the event of a disaster gives the Company a competitive advantage. This policy requires management to financially support and diligently attend to disaster contingency planning efforts. Disasters are not limited to adverse weather conditions; any event that could cause an extended delay of service should be considered. The Disaster Recovery Plan is part of the wider Business Continuity Plan.

Purpose

This policy defines the requirement for a baseline disaster recovery plan to be developed and implemented by the Company, describing the process to recover IT systems, applications, and data from any type of disaster that causes a major outage.

Scope

This policy is directed at IT management staff, who are accountable for ensuring the plan is developed, tested, and kept up to date. This policy states the requirement to have a disaster recovery plan; it does not prescribe what goes into the plan or its sub-plans.

Policy — contingency plans

The following contingency plans must be created and maintained:

• Computer Emergency Response Plan: who is to be contacted, when, and how; what immediate actions must be taken in the event of certain occurrences.
• Succession Plan: the flow of responsibility when normal staff are unavailable to perform their duties.
• Data Study: the data stored on the systems, its criticality, and its confidentiality.
• Criticality of Service List: all services provided and their order of importance, and the order of recovery over both short-term and long-term timeframes.
• Data Backup and Restoration Plan: which data is backed up, the media it is saved to, where that media is stored, how often the backup is taken, and how the data can be recovered.
• Equipment Replacement Plan: what equipment is required to begin providing services, the order in which it is needed, and where to purchase it.
• Mass Media Management: who oversees giving information to the media, and guidance on what information is appropriate to release.

Recovery objectives

After creating the plans, it is important to practise them to the extent possible. Management should set aside time to test implementation of the disaster recovery plan. Table-top exercises should be conducted annually. During these tests, issues that may cause the plan to fail can be discovered and corrected in an environment with few consequences. The plan must, at a minimum, be reviewed and updated annually.

6. Access Control Policy

Purpose

To ensure that access to Company systems and customer data is granted only to authorised individuals, limited to what their role requires, and removed promptly when no longer needed.

Policy

• Access is granted on the principle of least privilege and on a documented business need. Default access for a new joiner is the minimum required for their role.
• All access is role-based. Individual permissions are not granted ad hoc outside a defined role without Security Officer approval.
• Multi-factor authentication is mandatory for all administrative accounts, all cloud console access, all source-code repository access, and all remote access to production.
• Access to production systems and customer data requires separate credentials from those used for development or general corporate access.
• Shared or generic accounts are prohibited. Every action must be attributable to a named individual.
• Access reviews are performed at least quarterly by the Security Officer. Any access no longer required is revoked and the review is recorded.
• Joiner, mover, leaver: access is provisioned on the first day of employment, adjusted within 3 business days of a role change, and fully revoked within 24 hours of termination. Departing personnel return all Company equipment and have all tokens and sessions revoked.
• Third-party and contractor access is time-limited, approved in writing by the Security Officer, and reviewed monthly.
• Remote administrative access is permitted only over an encrypted channel from a Company-managed device.

7. Encryption and Data Protection Standard

Purpose

To define the minimum cryptographic controls applied to Company and customer data.

Standard

8. Secure Development Policy

Purpose

To ensure that security is designed into the SignSyncer platform rather than added afterwards.

Policy

• Development, staging, and production environments are logically separated. Production customer data is never copied into development or staging environments. Test data is synthetic or anonymised.
• All code changes require review and approval by at least one person other than the author before merge to the main branch.
• Applications are developed against the OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS). Input validation, output encoding, parameterised queries, and safe deserialisation are mandatory.
• Applications must authenticate individual users, not groups, and must provide role management such that one user can assume another's functions without knowing the other's password.
• Applications must not store passwords in clear text or in any easily reversible form, and must not transmit passwords in clear text over the network.
• Automated dependency scanning and static application security testing run on every build. Builds with known critical or high-severity vulnerabilities are blocked from release.
• Secrets are injected at runtime from the secrets manager. Hard-coded credentials in source code are prohibited and are treated as a security incident if discovered.
• Vulnerability remediation targets: Critical 7 days, High 30 days, Medium 90 days, Low next release cycle.
• An independent penetration test of the SignSyncer web application is commissioned at least annually and after any major architectural change. Findings are tracked to closure.
• Externally reported vulnerabilities are handled under the Vulnerability Disclosure Policy.

9. Change Management Policy

• All changes to production systems are recorded, reviewed, and approved before deployment.
• Each change record identifies the requester, the reason, the risk assessment, the test evidence, the approver, and the rollback plan.
• Deployments to production are performed through an automated pipeline. Manual changes directly on production servers are prohibited except during a declared incident, and must be documented retrospectively within 24 hours.
• Emergency changes may bypass the standard approval sequence but require Security Officer notification at the time and full documentation within 24 hours.
• No developer deploys their own change to production without a second person's approval.

10. Logging and Monitoring Policy

• Security-relevant events are logged centrally, including authentication successes and failures, privilege changes, administrative actions, access to customer data, configuration changes, and deployments.
• Logs are protected against tampering and deletion, and access to logs is itself logged.
• Logs are retained for a minimum of 12 months.
• Logs must not contain passwords, OAuth tokens, full payment card numbers, or the content of customer emails.
• Automated alerting is configured for repeated authentication failures, privilege escalation, unusual data export volumes, and changes to security configuration. Alerts are routed to the Security Officer.
• Alerts are reviewed on each business day. Anything meeting the definition of an incident is escalated under the Incident Response Policy.

11. Third-Party and Vendor Management

• Any vendor or sub-processor that will store, process, or transmit Company or customer data must be assessed for security and data protection before onboarding, and the assessment must be approved by the Security Officer.
• Contracts with such vendors must include confidentiality obligations, data protection terms, breach notification obligations, and a right to audit or to receive audit reports.
• Where personal data is transferred internationally, an appropriate transfer mechanism must be in place before the transfer begins.
• A register of sub-processors is maintained and reviewed at least annually.
• Vendor access to Company systems is time-limited, least-privilege, and revoked at the end of the engagement.
• Customers are given notice of any new sub-processor that will process their data.

12. Asset and Endpoint Security

• An inventory of hardware, software, cloud services, and data stores is maintained and reviewed at least annually. Each entry has a named owner.
• All endpoints used to access Company systems must have full-disk encryption enabled, an automatic screen lock of no more than 10 minutes, an active endpoint protection agent, and a supported operating system.
• Operating system and application security patches are applied within 30 days of release, and within 7 days for critical vulnerabilities under active exploitation.
• Personal devices may be used for Company work only with Security Officer approval and only where the controls above are met.
• Lost or stolen devices must be reported to the Security Officer immediately so that access can be revoked and, where possible, the device wiped remotely.
• Unauthorised software, unlicensed software, and unapproved cloud services must not be installed or used for Company work.

13. Email Policy

Overview

Electronic email is used pervasively and is often the primary communication method within an organisation. At the same time, misuse of email can create legal, privacy, and security risks, so it is important that users understand the appropriate use of electronic communications.

Purpose

To ensure the proper use of the Company's email system and to make users aware of what the Company deems acceptable and unacceptable use of it. This policy outlines the minimum requirements for use of email within the Company network.

Scope

This policy covers appropriate use of any email sent from a Company email address and applies to all employees, vendors, and agents operating on behalf of the Company.

Policy

1. All use of email must be consistent with Company policies and procedures of ethical conduct, safety, compliance with applicable laws, and proper business practices.
2. Company email accounts should be used primarily for Company business purposes. Personal communication is permitted on a limited basis, but non-Company related commercial use is prohibited.
3. Email should be retained only if it qualifies as a Company business record — that is, where there is a legitimate and ongoing business reason to preserve the information it contains.
4. The Company email system must not be used to create or distribute any disruptive or offensive messages, including offensive comments about race, gender, disability, age, sexual orientation, pornography, religious belief and practice, political belief, or national origin. Employees who receive such an email from any Company employee should report the matter to their supervisor immediately.
5. Users are prohibited from automatically forwarding Company email to a third-party email system. Individual messages forwarded by the user must not contain Company Confidential or above information.
6. Users are prohibited from using third-party email systems and storage services to conduct Company business, to create or memorialise binding transactions, or to store or retain email on behalf of the Company. Such communications must be conducted through approved Company channels.
7. Using a reasonable amount of Company resources for personal email is acceptable, but non-work-related email must be saved in a folder separate from work-related email. Sending chain letters or joke emails from a Company email account is prohibited.
8. Credentials, OAuth tokens, API keys, and other secrets must never be sent by email.
9. Employees shall have no expectation of privacy in anything they store, send, or receive on the Company email system.
10. The Company may monitor messages without prior notice. The Company is not obliged to monitor email messages.

14. Password Construction Guidelines

Overview

Passwords are a critical component of information security. They protect user accounts, but a poorly constructed password may result in the compromise of individual systems, data, or the Company network. These guidelines provide best practice for creating secure passwords.

Scope

These guidelines apply to employees, contractors, consultants, temporary and other workers at the Company, including all personnel affiliated with third parties. They apply to all passwords, including user-level accounts, system-level accounts, web accounts, email accounts, screensaver protection, voicemail, and local router logins.

Statement of guidelines

Strong passwords have the following characteristics:

• Contain at least 12 alphanumeric characters (8 is the absolute minimum; 12 or more is required for any account with access to customer data)
• Contain both upper and lower case letters
• Contain at least one number (0–9)
• Contain at least one special character (for example $ % ^ & * ( ) _ + | ~ - = ` { } [ ] : " ; ' < > ? , /)
• Are unique to the account and are not reused anywhere else

Poor, or weak, passwords have the following characteristics:

• Contain fewer than eight characters
• Can be found in a dictionary, including a foreign language dictionary, or exist in slang, dialect, or jargon
• Contain personal information such as birthdates, addresses, phone numbers, or the names of family members, pets, friends, or fictional characters
• Contain work-related information such as building names, system commands, sites, companies, hardware, or software
• Contain number patterns such as aaabbb, qwerty, zyxwvuts, or 123321
• Contain common words spelled backward, or preceded or followed by a number (for example terces, secret1, or 1secret)
• Are some version of Welcome123, Password123, or Changeme123

Passphrases

Passphrases are generally used for public/private key authentication. A public/private key system defines a mathematical relationship between the public key, which is known to all, and the private key, which is known only to the user. Without the passphrase to unlock the private key, the user cannot gain access.

A passphrase is used like a password but is relatively long and constructed of multiple words, which provides greater security against dictionary attacks. Strong passphrases should follow the general password construction guidelines and include upper and lower case letters, numbers, and special characters — for example, TheTrafficOnThe101Was*&!$ThisMorning!.

15. Password Protection Policy

Overview

Passwords are an important aspect of computer security. A poorly chosen password may result in unauthorised access to or exploitation of Company resources. All users, including contractors and vendors with access to Company systems, are responsible for taking the appropriate steps set out below to select and secure their passwords.

Purpose

To establish a standard for the creation of strong passwords, the protection of those passwords, and the frequency of change.

Scope

This policy includes all personnel who have, or are responsible for, an account (or any form of access that supports or requires a password) on any system that resides at a Company facility, has access to the Company network, or stores any non-public Company information.

Password creation

1. All user-level and system-level passwords must conform to the Password Construction Guidelines.
2. Users must not use the same password for Company accounts as for other non-Company access, such as a personal ISP account or personal banking.
3. Where possible, users must not use the same password for different Company access needs.
4. User accounts that have system-level privileges granted through group memberships or through programs such as sudo must have a password unique from all other accounts held by that user.
5. Where SNMP is used, community strings must be defined as something other than the standard defaults of public, private, and system, must differ from interactive login passwords, and must meet the Password Construction Guidelines.
6. Users must use multi-factor authentication to protect all accounts that support it, and it is mandatory for all administrative and production access.

Password change

1. All system-level passwords (for example root, enable, administrator, and application administration accounts) must be changed at least quarterly.
2. All user-level passwords (for example email, web, and desktop computer) must be changed at least every six months; the recommended interval is every four months.
3. All passwords must be changed immediately upon any suspicion of compromise, and upon the departure of anyone who knew a shared system credential.
4. Password cracking or guessing may be performed on a periodic or random basis by the Security Officer or their delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it to comply with the Password Construction Guidelines.

Password protection

1. Passwords must not be shared with anyone. All passwords are to be treated as sensitive, Confidential Company information.
2. Passwords must not be inserted into email messages, support tickets, or other forms of electronic communication.
3. Passwords must not be revealed over the phone to anyone.
4. Do not reveal a password on questionnaires or security forms.
5. Do not hint at the format of a password (for example, "my family name").
6. Do not share Company passwords with anyone, including administrative assistants, managers, co-workers while on vacation, or family members.
7. Do not write passwords down and store them anywhere in your office. Do not store passwords in a file on a computer system or mobile device without encryption.
8. Do not use the "Remember Password" feature of applications such as web browsers.
9. Any user who suspects that their password may have been compromised must report the incident immediately and change all affected passwords.

Application development

Application developers must ensure that their programs contain the following security precautions:

1. Applications must support authentication of individual users, not groups.
2. Applications must not store passwords in clear text or in any easily reversible form.
3. Applications must not transmit passwords in clear text over the network.
4. Applications must provide for role management, such that one user can take over the functions of another without having to know the other's password.

16. Wireless Communication Policy

Overview

With the mass adoption of smartphones and tablets, pervasive wireless connectivity is a given at almost any organisation. Insecure wireless configuration can provide an easy open door for malicious threat actors.

Purpose

To secure and protect the information assets owned by the Company. The Company provides computer devices, networks, and other electronic information systems to meet its missions, goals, and initiatives, and grants access to these resources as a privilege that must be managed responsibly to maintain the confidentiality, integrity, and availability of all information assets. This policy specifies the conditions that wireless infrastructure devices must satisfy to connect to the Company network. Only wireless infrastructure devices that meet the standards specified in this policy, or that are granted an exception by the Security Officer, are approved for connectivity.

Scope

All employees, contractors, consultants, temporary and other workers at the Company, including all personnel affiliated with third parties who maintain a wireless infrastructure device on behalf of the Company, must adhere to this policy. It applies to all wireless infrastructure devices that connect to a Company network or reside on a Company site and provide wireless connectivity to endpoint devices including, but not limited to, laptops, desktops, mobile phones, and tablets. This includes any form of wireless communication device capable of transmitting packet data.

General requirements

All wireless infrastructure devices that reside at a Company site and connect to a Company network, or that provide access to information classified as Company Confidential or above, must:

• Abide by the standards specified in the Wireless Communication Standard below
• Be installed, supported, and maintained by an approved support team
• Use Company-approved authentication protocols and infrastructure
• Use Company-approved encryption protocols
• Maintain a hardware address (MAC address) that can be registered and tracked
• Not interfere with wireless access deployments maintained by other support organisations

Home wireless device requirements

• Wireless infrastructure devices that provide direct access to the Company corporate network must conform to the Home Wireless Device Requirements detailed in the Wireless Communication Standard.
• Wireless infrastructure devices that fail to conform must be installed in a manner that prohibits direct access to the Company corporate network. Access through such a device must use standard remote access authentication.

17. Wireless Communication Standard

Purpose

This standard specifies the technical requirements that wireless infrastructure devices must satisfy to connect to a Company network. Only devices meeting these requirements, or granted an exception by the Security Officer, are approved for connectivity. Network devices including hubs, routers, switches, firewalls, remote access devices, modems, and wireless access points must be installed, supported, and maintained under the authority of the Security Officer.

Scope

All employees, contractors, consultants, temporary and other workers at the Company and its subsidiaries, including all personnel who maintain a wireless infrastructure device on behalf of the Company, must comply with this standard. It applies to wireless devices that make a connection to the network and to all wireless infrastructure devices that provide wireless connectivity to the network. The Security Officer must approve exceptions in advance.

General requirements

All wireless infrastructure devices that connect to a Company network or provide access to Company Confidential, Highly Confidential, or Restricted information must:

• Use EAP-FAST, PEAP, or EAP-TLS as the authentication protocol
• Use WPA2 or WPA3 with AES (CCMP) encryption, with a minimum key length of 128 bits. TKIP and WEP are deprecated and must not be used on any new deployment
• Ensure all Bluetooth devices use Secure Simple Pairing with encryption enabled
• Separate guest wireless access from the corporate network by VLAN or physical segregation

Home wireless device requirements

All home wireless infrastructure devices that provide direct access to a Company network, such as those behind an enterprise teleworker device or hardware VPN, must:

• Enable WPA2-PSK or WPA3-SAE, EAP-FAST, PEAP, or EAP-TLS
• When enabling a pre-shared key, configure a complex shared secret of at least 20 characters on both the wireless client and the access point
• Disable broadcast of the SSID
• Change the default SSID name
• Change the default administrative login and password
• Keep firmware up to date and apply security updates within 30 days of release

18. Security Awareness and Training

• All personnel complete security awareness training on joining, before being granted access to production systems, and at least annually thereafter.
• Training covers phishing and social engineering, password and credential hygiene, data classification and handling, incident reporting, and the requirements of this policy set.
• Personnel with development responsibilities complete additional secure coding training annually, covering the OWASP Top 10.
• Simulated phishing exercises are conducted periodically; results inform further training rather than disciplinary action in the first instance.
• All personnel sign a confidentiality agreement and acknowledge this policy set on joining and at each annual review. Acknowledgements are retained as evidence.
• Background verification is conducted for personnel with access to production customer data, to the extent permitted by applicable law.