1.            Purpose

This ISMS Policy aims to specify the security requirements for the Organization's proper and secure usage of Information Technology services. Its purpose is to protect the Organization and its users against security threats that could threaten their integrity, privacy, reputation, and commercial outcomes to the greatest extent possible by setting up an ISMS (Information Security Management System).

2.            Scope

This document applies to all users in the Organization, including temporary users, visitors with limited or unlimited access to services, and partners with limited or unlimited access to services. Therefore, this document's policies must be strictly followed. The detailed scope of the ISMS including the controls will be defined in SOA (Statement of applicability).

3.            Objectives

The Organization will retain documented information on the information security objectives. The objectives of an ISMS policy include the following:

• Confidentiality: Protect sensitive information from unauthorized access, disclosure, or theft.
• Integrity: Ensure that information is accurate, reliable, and not tampered with or modified inappropriately.
• Availability: Ensure that information is accessible to authorized users when needed and not lost or destroyed due to system failures or other events.
• Compliance: Ensure that the Organization complies with relevant laws, regulations, and standards related to information security.
• Risk Management: Identify and manage risks related to the Organization's information assets and take appropriate steps to mitigate those risks.
• Continual Improvement: Continuously monitor and improve the Organization's information security posture, including its policies, procedures, and technical controls.
• Communication: Ensure that employees, contractors, and other stakeholders are aware of their responsibilities related to information security and that they receive regular training and education on best practices.

When planning how to achieve its information security objectives, the Organization shall determine:

3.1          Understanding the needs and Expectations of interested parties.

The organization shall determine:

1. Interested parties that are relevant to the information security management system.
2. The relevant requirements of these interested parties.
3. Which of these requirements will be addressed through the information security management system?

• Internal issues - Understanding the external context can be facilitated by considering issues arising from legal, technological, competitive, market, cultural, social and economic environments, whether international, national, regional or local.
• External issues - Understanding the internal context can be facilitated by considering issues related to the organization's values, culture, knowledge and performance.

As with internal and external issues stakeholders and their requirements and expectations were identified, Organization had also identified the needs and expectations of interested parties and identified the opportunities and threats and the degree of risk attached to each. The results of these risk assessments are contained in [Risk Register]

Note: The details of needs and expectations described in Organization İSMS Scope document.

4.            ISMS Policy

The Policy's goal is to safeguard the Organization's information assets from any risks, whether internal or external, intentional or unintentional.

The Organization's Policy is to ensure that:

• As the business process requires, information should be made available with minimal disturbance to staff and the general public.
• The confidentiality of this data will be protected. Information confidentiality will be ensured, including but not limited to research, third parties, and personal and electronic communications data.
• All legal and regulatory standards will be met.
• Employees should get information security education, awareness, and training.
• All actual or suspected information security breaches must be reported to and investigated by the appropriate authorities, including System Administration and Incident Response.
• Appropriate access control will be maintained, and data will be kept safe from unwanted access. To complement the ISMS Policy, policies, procedures, and guidelines for AzeriCard LLC will be available in print and online forms through an intranet system.

4.1           Information Security Requirements

With the internal business a precise definition of information security requirements will be agreed upon and maintained. All ISMS work will be focused on meeting those criteria. Legislative, regulatory, and contractual agreements will also be documented and included in the planning process. As part of each project's design, specific security needs for new or altered systems or services will be captured.

The AzeriCard LLC ISMS's key idea is that controls are implemented in response to business needs, which will be conveyed to all employees via team meetings and briefing documents regularly.

4.2          Risk Management

The ISMS policy defines risk management as a core component of the organization's approach to information security. It outlines the objectives and principles guiding the risk management process, as well as the roles and responsibilities of individuals involved. It involves understanding potential threats, vulnerabilities, and the potential impact of incidents on the confidentiality, integrity, and availability of information. The organization establishes a framework that promotes a proactive and systematic approach to identifying, assessing, and managing risks to their information assets.

4.3          Change Management

The ISMS policy defines change management as a critical component of the organization's overall information security strategy and provides guidance on how changes should be managed to minimize risks to information assets. It involves assessing the potential impact of changes on information security, implementing appropriate controls, and ensuring that changes are effectively planned, tested, and documented.

4.4          Human Resources

Based on proper education, training, abilities, and experience, AzeriCard LLC will ensure that all personnel involved in information security are competent. The required skills will be determined and assessed regularly, as well as an assessment of current skill levels within AzeriCard LLC. Training requirements will be identified, and a strategy will be implemented to guarantee that the appropriate skills are in place. The HR department will keep track of training, education, and other necessary data to document individual skill levels.

4.5          Business Continuity

Business continuity, within the context of an Information Security Management System (ISMS) policy, refers to the strategies, plans, and procedures put in place to ensure the organization can continue its critical operations and minimize the impact of disruptions or incidents that may threaten the availability of its information assets. It involves proactive measures to identify potential risks, develop resilience capabilities, and establish effective response and recovery mechanisms.

AzeriCard LLC defines business continuity as a fundamental aspect of the organization's information security strategy, highlighting the commitment to maintaining the continuity of business operations, safeguarding critical assets, and minimizing the impact of incidents.

4.6          Improvement of ISMS

AzeriCard LLC policy about continual improvement is to:

• Increase the level of proactivity (and stakeholder perception of proactivity) about information security, according to the AzeriCard LLC Policy on continuous improvement.
• Make information security processes and controls more measurable so that informed decisions may be made
• Evaluate important metrics yearly to see if they should be changed based on historical data.
• Collect ideas for continuous improvement through regular meetings and communication with stakeholders.
• In evaluating improvement recommendations, the following criteria must be used:

o    Cost

o    Business Benefit

o    Risk

o    Timeline for Implementation

o    Resources required

5.            Confidentiality

All rights are reserved in this document, which is copyrighted. Without the previous written consent of an authorized representative of AzeriCard LLC, this document may not be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form, in whole or in part. This document is for internal use only and may be given to anybody outside the firm, including customers, clients, or prospects, after receiving consent from an authorized representative of AzeriCard LLC in whole or in part.

6.            Legal, statutory, regulatory and contractual requirements

6.1          Identify requirement.

AzeriCard LLC relies upon the following internal teams and external bodies to identify legal, regulatory and contractual requirements that are relevant to its information security:

Table 1: Source of requirements

In general, AzeriCard LLC will rely on the right group or outside organisation to offer an interpretation of the pertinent sections of the object under review. Briefing papers, presentation materials, or other media may be used for this.

For reference purposes, the IS Manager must, if needed, procure complete copies of any pertinent source documents (such as laws or regulatory notices). These could be printed materials or digital files.

6.2          Assess implications.

The ISMS Manager is responsible for ensuring that a full assessment of the implications of the relevant items for the ISMS is carried out. 

The assessment will include the following aspects:

• The extent of the necessary modifications to the ISMS's associated policies, procedures, forms, and plans.
• Urgency of meeting the requirement
• The effects of failing to comply with the obligation.
• Available options for meeting the requirement.

6.3          Document requirements

Once assessed, the relevant requirements will be documented at a high level as part of the ISMS within the document Information Security Context, Requirements and Scope. According to the ISMS documentation procedures, any changes to this document will be tracked.

Details of the requirements will be documented in the SLA register, Contract register, and External Documented Information register where the details will include at least:

• Identification code
• Regulation name
• Type of requirement – legislative, regulatory, contractual, other
• Details of the requirement, at an appropriate level
• The reason of applicability
• Compliance level
• Dates the requirement applies from and to
• Tracking Frequency

Where needed, confirmation of the interpretation of the requirement will be obtained from a relevant source, for example AzeriCard LLC legal department.

6.4          Define approach to meeting requirements.

If an instant update to the ISMS is required due to a new or modified requirement, this shall be done as quickly as feasible, and all recipients of the pertinent policies and procedures will be informed of the revisions. If not, the modification will be taken into account at the following ISMS yearly review.

The External Documented Information register will be updated with specifics of the strategy to be used and, where necessary, links to pertinent papers.

6.5          Review and update

At routine review meetings with internal departments, new requirements and modifications to existing requirements will be covered, especially:

• Legal department
• ISMS team
• RISK Management Team
• Supplier Management

As part of the ISMS yearly assessment, all pertinent requirements will be revaluated at least annually. At this time, appropriate counsel will be sought to guarantee that all modifications have been noted.

This approach will be followed for any new or modified requirements that are found during the review process, and the necessary adjustments will be made.

7.            Configuration management

AzeriCard LLC should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services and networks, for newly installed systems as well as for operational systems over their lifetime.

Roles, responsibilities and procedures should be in place to ensure satisfactory control of all configuration changes.

Standard templates:

• Standard templates for the secure configuration of hardware, software, services, and networks should be defined:
• using publicly available guidance (e.g., pre-defined templates from vendors and from independent security organizations).
• considering the level of protection needed to determine a sufficient level of security.
• supporting AzeriCard LLC’s information security policy, topic-specific policies, standards, and other security requirements.
• considering the feasibility and applicability of security configurations in AzeriCard LLC’s context.

The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced.

The following should be considered for establishing standard templates for the secure configuration of hardware, software, services, and networks:

• minimizing the number of identities with privileged or administrator-level access rights.
• disabling unnecessary, unused, or insecure identities.
• disabling or restricting unnecessary functions and services.
• restricting access to powerful utility programs and host parameter settings.
• synchronizing clocks.
• changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters.
• invoking time-out facilities that automatically log off computing devices after a predetermined period of inactivity.
• verifying that license requirements have been met.

Managing configurations:

Established configurations of hardware, software, services, and networks should be recorded and a log should be maintained for all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates.

Changes to configurations should follow the change management process.

Configuration records can contain as relevant:

• up-to-date owner or point of contact information for the asset.
• date of the last change of configuration.
• version of configuration template.
• relation to configurations of other assets.

Monitoring configurations:

Configurations should be monitored with a comprehensive set of system management tools (e.g., maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths, and assess activities performed.

Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions.

Other information:

Documentation for systems often records details about the configuration of both hardware and software. System hardening is a typical part of configuration management. Configuration management can be integrated with asset management processes and associated tooling.

Automation is usually more effective in managing security configuration (e.g., using infrastructure as code). Configuration templates and targets can be confidential information and should be protected from unauthorized access accordingly.

8.            Intellectual property rights

Copyright for software or documents, design rights, trademarks, patents, products and source code licences are all examples of intellectual property rights.

To safeguard any content that could be regarded as intellectual property, the following principles should be taken into account:

1. establishing and disseminating a topic-specific intellectual property rights protection policy.
2. Providing guidelines for using software and information items in conformity with intellectual property rights.
3. purchasing only from reliable and well-known sources when purchasing software to prevent copyright infringement.
4. keeping suitable asset registrations up to date and identifying any assets that need to be protected by intellectual property rights.
5. preserving proof of ownership for documents like manuals and licences, etc.
6. guaranteeing that no upper limit on the number of users or resources [such CPUs] set forth in the licence is exceeded.
7. ensuring that only licenced products and authorised software are installed by conducting reviews.
8. establishing mechanisms for maintaining suitable licence restrictions.
9. establishing protocols for software disposal or software transfer.
10. respecting the terms and conditions for any software or data downloaded from the internet or other sources.
11. not making copies, converting to another format, or removing content from audio or video commercial recordings unless it is legal or has the necessary licences.
12. not reproducing in whole or in part, unless expressly permitted by copyright law or the applicable licences, standards (such as ISO/IEC International Standards), books, articles, reports, or other works.

Accountable for this process is Chief Information Officer of Azericard LLC. All intellectual property rights regulation correlate with the process of Information classification policy.

Other information:

Typically, proprietary software products are provided with a licence agreement that outlines the terms and conditions of the licence, such as restricting use to a set of machines or allowing only backup copies to be made.

Information can be obtained from external sources.

Typically, such data is acquired in accordance with the provisions of a data sharing agreement or other equivalent legal document. Such data sharing agreements should specify what processing of the acquired data is allowed.

The source of the data should also be mentioned properly.

Copying of proprietary content may be constrained by legal, statutory, regulatory, and contractual obligations.

In particular, they can stipulate that only content created by AzeriCard LLC, licenced to AzeriCard LLC, or provided to AzeriCard LLC may be used.

Legal action for copyright violations may result in penalties and criminal charges.

AzeriCard LLC must manage the risks of its employees and third parties violating its own intellectual property rights in addition to its responsibility to respect the intellectual property rights of others