Information Security Policy


Information is one of Deal Engine’s most valuable and critical assets. As such, we operate under the fundamental principle that it should be effectively protected at all times. Effective information security assures that Deal Engine’s assets are safe and protected against harm, and thereby act as a business enabler.

Information security is defined as the protection of information and its critical elements, including the systems and hardware that use, store and transmit that information. To ensure effective Information security we have implemented set of controls, including policies, processes, procedures, Company structures and software and hardware functions that ensure information integrity and confidentiality across our operation.

This Information Security Policy (“The Policy”) has the objective to set the guidelines to establish, implement, monitor, review and improve, where necessary, the set of controls that ensure the specific security and business objectives are achieved.

2. Asset Management

2.1 Asset responsibility

OBJECTIVE - Identify information assets and define appropriate protection responsibilities.

2.1.1 Asset Inventory

All assets associated with information and information processing facilities should be identified and an inventory of these assets should be drawn up and maintained.

  • Identify information assets at their relevant information lifecycle. The lifecycle of information should include creation, processing, storage, transmission, deletion, and destruction.
  • Document assets. Assets should be documented in dedicated or existing inventories. The asset inventory should be accurate, up to date, consistent, and aligned with other inventories.
  • Assign ownership of assets. For each of the identified assets, ownership of the asset should be assigned and classified.

2.1.2 Asset ownership

Ownership should be assigned when assets are created or when assets are transferred to the Company. The asset owner is responsible for the proper management of an asset over the whole asset lifecycle. The asset owner has to:

A) Ensure that assets are inventoried.

B) Ensure that assets are appropriately classified and protected.

C) Define and periodically review access restrictions and classifications to important assets, taking into account applicable access control policies.

D) Ensure proper handling when the asset is deleted or destroyed.

The asset owner can be either an individual or an entity who has approved management responsibility for controlling the whole lifecycle of an asset. The identified owner does not necessarily have any property rights to the asset.

Routine tasks may be delegated, e.g. to a custodian looking after the assets on a daily basis, but the responsibility remains with the owner.

2.1.3 Acceptable asset use

Rules for the acceptable use of information and of assets associated with information and information processing facilities should be identified, documented and implemented.

Employees and external party users using or having access to the Company’s assets should be made aware of the information security requirements of the Company’s assets associated with information and information processing facilities and resources. They should be responsible for their use of any information processing resources and of any such use carried out under their responsibility.

2.1.4 Asset return

All employees and external party users should return all of the Company assets in their possession upon termination of their employment, contract or agreement. The termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the Company.

In cases where an employee or external party user has knowledge that is important to ongoing operations, that information should be documented and transferred to the Company.

2.2 Information Classification

OBJECTIVE - Ensure that information receives an appropriate level of protection in accordance with its relevance.

2.2.1 Classification of information

Information should be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification. Owners of information assets are accountable for their classification.

Classifications and associated protective controls for information should take account of business needs for sharing or restricting information, as well as legal requirements. Assets other than information should be classified in conformance with classification of information which is stored in, processed by, or otherwise handled or protected by the asset.

The level of protection in the scheme should be assessed by analyzing confidentiality, integrity and availability and any other requirements for the information considered. The scheme should be aligned to the access control policy.

Classification should be included in the Company’s processes, and be consistent and coherent across the Company. Results of classification should indicate value of assets depending on their sensitivity and criticality to the Company, e.g. in terms of confidentiality, integrity and availability.

Deal Engine’s information confidentiality classification scheme is defined in the 3 following categories:

  • Highly Confidential - An unauthorized disclosure, compromise or destruction would result in severe damage to Deal Engine or its employees. Violation of statutes, regulations, or other legal obligations, financial loss, damage to Deal Engine’s reputation, and possible legal action could occur.
  • Confidential - An unauthorized disclosure, compromise or destruction would directly or indirectly have an adverse impact on Deal Engine or its employees. Financial loss, damage to Deal Engine’s reputation, and possible legal action could occur.
  • Publicly available - Knowledge of this information does not expose Deal Engine to financial loss, or jeopardize the security of Deal Engine’s information assets.

3. Access Control

3.1 Business requirements of access control

OBJECTIVE - Limit access to information and information processing facilities.

3.1.1 Access Control Policy

Deal Engine’s Access Control Policy operates under the premise that “access is generally forbidden unless expressly permitted” and under the “Need-to-know” and “Need-to use” principles.

A) Need-to-know: access is only granted to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profile).

B) Need-to-use: access is only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role.

Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks.

Access controls are both logical and physical and these should be considered together. Users and service providers should be given a clear statement of the business requirements to be met by access controls.

The policy should take account of the following:

  • Security requirements of business applications
  • Policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information
  • Consistency between the access rights and information classification policies of systems and networks;
  • Relevant legislation and any contractual obligations regarding limitation of access to data or services;
  • Management of access rights in a distributed and networked environment which recognizes all types of connections available;
  • Segregation of access control roles, e.g. access request, access authorization, access administration;
  • Requirements for formal authorization of access requests;
  • periodic review of access rights
  • Removal of access rights;
  • Archiving of records of all significant events concerning the use and management of user identities and secret authentication information;
  • roles with privileged access

3.1.2 Access to networks and network services

Users should only be provided with access to the network and network services that they have been specifically authorized to use. A policy should be formulated concerning the use of networks and network services. This policy should cover:

  • the networks and network services which are allowed to be accessed;
  • Authorization procedures for determining who is allowed to access which networks and networked services;
  • management controls and procedures to protect access to network connections and network services;
  • the means used to access networks and network services (e.g. use of VPN or wireless network);
  • user authentication requirements for accessing various network services;
  • monitoring of the use of network services.

Unauthorized and insecure connections to network services can affect the whole Company. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the Company’s information security management and control.

3.2 User access management

OBJECTIVE - Ensure authorized user access and prevent unauthorized access to systems and services.

3.2.1 User registration and de-registration

A formal user registration and de-registration process should be implemented to enable assignment of access rights. Providing or revoking access to information or information processing facilities is a two-step procedure:

  • Step 1 – Assign and enable (or revoke) a user ID
  • Step 2 – Provide (or revoke) access rights to such user ID

The process for managing user IDs should include:

  • using unique user IDs to enable users to be linked to and held responsible for their actions; the use of shared IDs should only be permitted where they are necessary for business or operational reasons and should be approved and documented;
  • immediately disabling or removing user IDs of users who have left the Company
  • periodically identifying and removing or disabling redundant user IDs;
  • ensuring that redundant user IDs are not issued to other users.

3.2.2 User access provisioning

A formal user access provisioning process should be implemented to assign or revoke access rights for all user types to all systems and services.

The provisioning process for assigning or revoking access rights granted to user IDs includes:

  • Obtain authorization from the asset owner of the information system or service for the use of the information system or service
  • Verify that the level of access granted is appropriate to the access policies and is consistent with other requirements such as segregation of duties
  • Ensuring that access rights are not activated before authorization procedures are completed;
  • Maintain a central record of access rights granted to a user ID to access information systems and services
  • Adapt access rights of users who have changed roles or jobs and immediately remove access rights of users who have left the Company
  • Periodically review access rights with owners of the information systems or services

3.2.3 Secret authentication information of users

The allocation of secret authentication information should be controlled through a formal management process. The beforementioned process includes the following requirements:

  • users are required to sign a statement to keep personal secret authentication information confidential and to keep group (i.e. shared) secret authentication information solely within the members of the group;
  • Users are provided with an initial secure temporary secret authentication information, the use of unprotected (clear text) electronic mail messages to share them is strictly forbidden.
  • Temporary secret authentication information is unique to an individual and should not be guessable
  • Users are forced to change the initial secure temporary secret authentication information on first use and are required to maintain their own secret authentication information.
  • Users should acknowledge receipt of secret authentication information;
  • Verify the identity of a user prior to providing new, replacement or temporary secret authentication information;
  • Default vendor secret authentication information should be altered following installation of systems or software.

3.3 User responsibilities

OBJECTIVE - Make users accountable for safeguarding their authentication information.

3.3.1 Use of secret authentication information

Users are required to follow the Company’s practices in the use of secret authentication information. To achieve this all users are required to:

  • keep secret authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority
  • Avoid keeping a record (e.g. on paper, software file or hand-held device) of secret authentication information, unless this can be stored securely and the method of storing has been approved (e.g. password vault);
  • change secret authentication information whenever there is any indication of its possible compromise;
  • when passwords are used as secret authentication information, select quality passwords with sufficient minimum length which are:
  • easy to remember;
  • not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers and dates of birth etc.;
  • not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);
  • free of consecutive identical, all-numeric or all-alphabetic characters;
  • if temporary, changed at the first log-on;
  • not share individual user’s secret authentication information;
  • ensure proper protection of passwords when passwords are used as secret authentication information in automated log-on procedures and are stored;
  • not use the same secret authentication information for business and non-business purposes.

3.4 System and application access control

OBJECTIVE - Prevent unauthorized access to systems and applications.

3.4.1 Information access restriction

Access to information and application system functions should be restricted in accordance with the access control policy. Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy. The following should be considered in order to support access restriction requirements:

  • Provide menus to control access to application system functions;
  • Control which data can be accessed by a particular user;
  • Control access rights of users, e.g. read, write, delete and execute;
  • Control access rights of other applications;
  • Limit the information contained in outputs;
  • Provide physical or logical access controls for the isolation of sensitive applications, application data, or systems.

3.4.2 Secure log-on procedures

Where required by the access control policy, access to systems and applications should be controlled by a secure log-on procedure. A suitable authentication technique should be chosen to substantiate the claimed identity of a user.

Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used.

The procedure for logging into a system or application should be designed to minimize the opportunity for unauthorized access. The log-on procedure should therefore disclose the minimum of information about the system or application, in order to avoid providing an unauthorized user with any unnecessary assistance. A good log-on procedure should:

  • not display system or application identifiers until the log-on process has been successfully completed;
  • display a general notice warning that the computer should only be accessed by authorized users;
  • not provide help messages during the log-on procedure that would aid an unauthorized user;
  • validate the log-on information only on completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect;
  • protect against brute force log-on attempts;
  • log unsuccessful and successful attempts;
  • raise a security event if a potential attempted or successful breach of log-on controls is detected;
  • not display a password being entered;
  • never transmit passwords in clear text over a network;
  • terminate inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the Company’s security management or on mobile devices;

4. Cryptographic Control

4.1 Cryptographic controls

OBJECTIVE - Ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information.

Cryptographic controls are used to achieve different information security objectives:

1) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted;

2) integrity/authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information;

3) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources.

The Company’s cryptographic policy includes:

  • the management approach towards the use of cryptographic controls across the Company, including the general principles under which business information should be protected;

b) based on a risk assessment, the required level of protection should be identified taking into account the type, strength and quality of the encryption algorithm required;

c) the use of encryption for protection of information transported by mobile or removable media devices or across communication lines;

d) the approach to key management, including methods to deal with the protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys;

e) roles and responsibilities, e.g. who is responsible for:

1) the implementation of the policy;

2) the key management, including key generation;


5.1 Operational procedures and responsibilities

OBJECTIVE - Ensure correct and secure operations of information assets.

5.1.1 Documented operating procedures

Operating procedures and the documented procedures for system activities should be treated as formal documents and changes authorized by management.

Operating procedures associated with information processing and communication facilities, such as computer start-up and close-down procedures, backup, equipment maintenance, media handling, computer room and mail handling management and safety are documented and made available to users who need them

The operating procedures should specify the operational instructions, including:

  • Installation and configuration of systems;
  • Processing and handling of information both automated and manual
  • Backup;
  • Scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times;
  • Instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities
  • Support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties;
  • Special output and media handling instructions, such as the use of special stationery or the management of confidential output including procedures for secure disposal of output from failed jobs
  • System restart and recovery procedures for use in the event of system failure;
  • Management of audit-trail and system log information;
  • Monitoring procedures.

5.1.2 Change management

Changes to the Company, business processes, information processing facilities and systems that affect information security should be controlled. In particular, the following items should be considered:

  • identification and recording of significant changes;
  • planning and testing of changes;
  • assessment of the potential impacts, including information security impacts, of such changes;
  • formal approval procedure for proposed changes;
  • verification that information security requirements have been met;
  • communication of change details to all relevant persons;
  • fall-back procedures, including procedures and responsibilities for aborting and recovering from unsuccessful changes and unforeseen events;
  • provision of an emergency change process to enable quick and controlled implementation of changes needed to resolve an incident

Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes. When changes are made, an audit log containing all relevant information should be retained.

5.1.3 Separation of development, testing and operational environments

Development, testing, and operational environments are separated to reduce the risks of unauthorized access or changes to the operational environment. The level of separation between operational, testing, and development environments that is necessary to prevent operational problems should be identified and implemented, considering:

  • rules for the transfer of software from development to operational status should be defined and documented;
  • development and operational software should run on different systems or computer processors and in different domains or directories;
  • changes to operational systems and applications should be tested in a testing or staging environment prior to being applied to operational systems;
  • other than in exceptional circumstances, testing should not be done on operational systems;
  • compilers, editors and other development tools or system utilities should not be accessible from operational systems when not required;
  • users should use different user profiles for operational and testing systems, and menus should display appropriate identification messages to reduce the risk of error;
  • sensitive data should not be copied into the testing system environment unless equivalent controls are provided for the testing system

5.2 Protection from malware

OBJECTIVE - Ensure that information and information assets and information processing facilities are protected against malware.

5.2.1 Controls against malware

Detection, prevention and recovery controls to protect against malware are implemented and combined with appropriate user awareness. Use of malware detection and repair software alone as a malware control is not usually adequate and needs to be accompanied by operating procedures that prevent introduction of malware.

Protection against malware should be based on malware detection and repair software, information security awareness and appropriate system access and change management controls, considering:

  • A formal policy prohibiting the use of unauthorized software
  • Controls that prevent or detect the use of unauthorized software
  • Controls that prevent or detect the use of known or suspected malicious websites (e.g. blacklisting)
  • A formal policy to protect against risks associated with obtaining files and software either from or via external networks or on any other medium, indicating what protective measures should be taken;
  • Regular reviews of the software and data content of systems supporting critical business processes; the presence of any unapproved files or unauthorized amendments should be formally investigated;
  • Installation and regular update of malware detection and repair software to scan computers and media as a precautionary control, or on a routine basis; the scan carried out should include:
  • scan any files received over networks or via any form of storage medium, for malware before use;
  • scan electronic mail attachments and downloads for malware before use; this scan should be carried out at different places, e.g. at electronic mail servers, desk top computers and when entering the network of the Company;
  • scan web pages for malware;
  • defining procedures and responsibilities to deal with malware protection on systems, training in their use, reporting and recovering from malware attacks;
  • preparing appropriate business continuity plans for recovering from malware attacks, including all necessary data and software backup and recovery arrangements (see 12.3);
  • implementing procedures to regularly collect information, such as subscribing to mailing lists or verifying websites giving information about new malware;
  • implementing procedures to verify information relating to malware, and ensure that warning bulletins are accurate and informative; managers should ensure that qualified sources, e.g. reputable journals, reliable Internet sites or suppliers producing software protecting against malware, are used to differentiate between hoaxes and real malware; all users should be made aware of the problem of hoaxes and what to do on receipt of them;
  • isolating environments where catastrophic impacts may result.

5.3 Backup

OBJECTIVE - Protect against loss of data.

5.3.1 Information backup Control

Operational procedures should monitor the execution of backups and address failures of scheduled backups to ensure completeness of backups according to the backup policy.

Backup arrangements for individual systems and services should be regularly tested to ensure that they meet the requirements of business continuity plans. In the case of critical systems and services, backup arrangements should cover all systems information, applications and data necessary to recover the complete system in the event of a disaster.

The retention period for essential business information should be determined, taking into account any requirement for archive copies to be permanently retained.

Backup copies of information, software and system images should be taken and tested regularly in accordance with an agreed backup policy. Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following a disaster or media failure The backup policy should define the retention and protection requirements, considering:

  • Accurate and complete records of the backup copies and documented restoration procedures should be produced;
  • the extent (e.g. full or differential backup) and frequency of backups should reflect the business requirements of the Company, the security requirements of the information involved and the criticality of the information to the continued operation of the Company;
  • the backups should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site;
  • backup information should be given an appropriate level of physical and environmental protection (see Clause 11) consistent with the standards applied at the main site;
  • backup media should be regularly tested to ensure that they can be relied upon for emergency use when necessary; this should be combined with a test of the restoration procedures and checked against the restoration time required. Testing the ability to restore backed-up data should be performed onto dedicated test media, not by overwriting the original media in case the backup or restoration process fails and causes irreparable data damage or loss;
  • in situations where confidentiality is of importance, backups should be protected by means of encryption.

5.4 Logging and monitoring

OBJECTIVE - Record events and generate evidence.

5.4.1 Event logging

Event logging sets the foundation for automated monitoring systems which are capable of generating consolidated reports and alerts on system security. Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed, considering:

  • user IDs;
  • system activities;
  • dates, times and details of key events, e.g. log-on and log-off;
  • device identity or location if possible and system identifier;
  • records of successful and rejected system access attempts;
  • records of successful and rejected data and other resource access attempts;
  • changes to system configuration;
  • use of privileges;
  • use of system utilities and applications;
  • files accessed and the kind of access;
  • network addresses and protocols;
  • alarms raised by the access control system;
  • activation and de-activation of protection systems, such as antivirus systems and intrusion detection systems;
  • records of transactions executed by users in applications.

Logging facilities and log information should be protected against tampering and unauthorized access. Implementation guidance. Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including:

  • alterations to the message types that are recorded;
  • log files being edited or deleted;
  • storage capacity of the log file media being exceeded, resulting in either the failure to record events or over-writing of past recorded events.

5.5 Control of operational software

OBJECTIVE - Ensure the integrity of operational systems.

Procedures should be implemented to control the installation of software on operational systems.The following guidelines should be considered to control changes of software on operational systems:

  • updating of the operational software, applications and program libraries should only be performed by trained administrators upon appropriate management authorization
  • operational systems should only hold approved executable code and not development code or compilers;
  • applications and operating system software should only be implemented after extensive and successful testing; the tests should cover usability, security, effects on other systems and user-friendliness and should be carried out on separate systems it should be ensured that all corresponding program source libraries have been updated;
  • a configuration control system should be used to keep control of all implemented software as well as the system documentation;
  • a rollback strategy should be in place before changes are implemented;
  • an audit log should be maintained of all updates to operational program libraries;
  • previous versions of application software should be retained as a contingency measure;
  • old versions of software should be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive.

5.6 Technical vulnerability management

OBJECTIVE - Prevent exploitation of technical vulnerabilities.

Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the Company’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.

Firstly, a current and complete inventory of assets is a prerequisite for effective technical vulnerability management. Specific information needed to support technical vulnerability management includes the software vendor, version numbers, current state of deployment within the Company responsible for the software.

Appropriate and timely action should be taken in response to the identification of potential technical vulnerabilities. The following guidance should be followed to establish an effective management process for technical vulnerabilities:

  • the Company should define and establish the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, patching, asset tracking and any coordination responsibilities required;
  • information resources that will be used to identify relevant technical vulnerabilities and to maintain awareness about them should be identified for software and other technology (based on the asset inventory list, see 8.1.1); these information resources should be updated based on changes in the inventory or when other new or useful resources are found;
  • a timeline should be defined to react to notifications of potentially relevant technical vulnerabilities;
  • once a potential technical vulnerability has been identified, the Company should identify the associated risks and the actions to be taken; such action could involve patching of vulnerable systems or applying other controls;
  • depending on how urgently a technical vulnerability needs to be addressed, the action taken should be carried out according to the controls related to change management (see 12.1.2) or by following information security incident response procedures (see 16.1.5);
  • if a patch is available from a legitimate source, the risks associated with installing the patch should be assessed (the risks posed by the vulnerability should be compared with the risk of installing the patch);
  • patches should be tested and evaluated before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated; if no patch is available, other controls should be considered, such as:
  • turning off services or capabilities related to the vulnerability;
  • adapting or adding access controls, e.g. firewalls, at network borders (see 13.1);
  • increased monitoring to detect actual attacks;
  • raising awareness of the vulnerability;
  • an audit log should be kept for all procedures undertaken;
  • the technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency;
  • systems at high risk should be addressed first;
  • an effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out should an incident occur;
  • define a procedure to address the situation where a vulnerability has been identified but there is no suitable countermeasure. In this situation, the Company should evaluate risks relating to the known vulnerability and define appropriate detective and corrective actions.

5.7 Information systems audit considerations

OBJECTIVE - Minimize the impact of audit activities on operational systems.

Audit requirements and activities involving verification of operational systems should be carefully planned and agreed to minimize disruptions to business processes. The following guidelines should be observed:

  • audit requirements for access to systems and data should be agreed with appropriate management;
  • the scope of technical audit tests should be agreed and controlled;
  • audit tests should be limited to read-only access to software and data;
  • access other than read-only should only be allowed for isolated copies of system files, which should be erased when the audit is completed, or given appropriate protection if there is an obligation to keep such files under audit documentation requirements;
  • requirements for special or additional processing should be identified and agreed;
  • audit tests that could affect system availability should be run outside business hours;
  • all access should be monitored and logged to produce a reference trail.

6. Communications Security

6.1 Network security management

OBJECTIVE - Ensure the protection of information in networks and its supporting information processing facilities.

6.1.1 Network controls

Networks should be managed and controlled to protect information in systems and applications. Implementation guidance. Controls should be implemented to ensure the security of information in networks and the protection of connected services from unauthorized access. In particular, the following items should be considered:

  • responsibilities and procedures for the management of networking equipment should be established;
  • operational responsibility for networks should be separated from computer operations where appropriate
  • special controls should be established to safeguard the confidentiality and integrity of data passing over public networks or over wireless networks and to protect the connected systems and applications
  • appropriate logging and monitoring should be applied to enable recording and detection of actions that may affect, or are relevant to, information security;
  • management activities should be closely coordinated both to optimize the service to the Company and to ensure that controls are consistently applied across the information processing infrastructure;
  • systems on the network should be authenticated;
  • systems connection to the network should be restricted.

6.1.2 Security of network services

Security mechanisms, service levels and management requirements of all network services should be identified and included in network services agreements, whether these services are provided in-house or outsourced. The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored, and the right to audit should be agreed.

The security arrangements necessary for particular services, such as security features, service levels and management requirements, should be identified. The Company should ensure that network service providers implement these measures.

6.1.3 Network segregation

Groups of information services, users and information systems should be segregated on networks.

One method of managing the security of large networks is to divide them into separate network domains. The domains can be chosen based on trust levels (e.g. public access domain, desktop domain, server domain), along Company units (e.g. human resources, finance, marketing) or some combination (e.g. server domain connecting to multiple Company units). The segregation can be done using either physically different networks or by using different logical networks (e.g.virtual private networking).

The perimeter of each domain should be well defined. Access between network domains is allowed, but should be controlled at the perimeter using a gateway (e.g. firewall, filtering router). The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the access control policy, access requirements, value and classification of information processed and also take account of the relative cost and performance impact of incorporating suitable gateway technology.

Wireless networks require special treatment due to the poorly defined network perimeter. For sensitive environments, consideration should be made to treat all wireless access as external connections and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls policy before granting access to internal systems.

The authentication, encryption and user level network access control technologies of modern, standards based wireless networks may be sufficient for direct connection to the Company’s internal network when properly implemented.

6.2 Information transfer

OBJECTIVE - Maintain the security of information transferred within an Company and with any external entity.

6.2.1 Information transfer policies and procedures

Information transfer may occur through the use of a number of different types of communication facilities, including electronic mail, voice, facsimile and video. Software transfer may occur through a number of different mediums, including downloading from the Internet and acquisition from vendors selling off-the-shelf products.

Formal transfer policies, procedures and controls are in place to protect the transfer of information through the use of all types of communication facilities. The procedures and controls to be followed when using communication facilities for information transfer consider the following items:

  • procedures designed to protect transferred information from interception, copying, modification, mis-routing and destruction
  • procedures for the detection of and protection against malware that may be transmitted through the use of electronic communications;
  • procedures for protecting communicated sensitive electronic information that is in the form of an attachment;
  • policy or guidelines outlining acceptable use of communication facilities;
  • personnel, external party and any other user’s responsibilities not to compromise the Company, through defamation, harassment, impersonation, forwarding of chain letters, unauthorized purchasing, etc.;
  • use of cryptographic techniques e.g. to protect the confidentiality, integrity and authenticity of information ;
  • retention and disposal guidelines for all business correspondence, including messages, in accordance with relevant national and local legislation and regulations;
  • controls and restrictions associated with using communication facilities, e.g. automatic forwarding of electronic mail to external mail addresses;
  • advising personnel to take appropriate precautions not to reveal confidential information;
  • not leaving messages containing confidential information on answering machines since these may be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialling;
  • advising personnel about the problems of using facsimile machines or services, namely:
  • unauthorized access to built-in message stores to retrieve messages;
  • deliberate or accidental programming of machines to send messages to specific numbers;
  • sending documents and messages to the wrong number either by misdialing or using the wrong stored number.

In addition, personnel are required to avoid having confidential conversations in public places or over insecure communication channels, open offices and meeting places.

6.2.2 Confidentiality or non-disclosure agreements

Confidentiality and non-disclosure agreements protect Company information and inform signatories of their responsibility to protect, use and disclose information in a responsible and authorized manner. Requirements for confidentiality or non-disclosure agreements reflecting the Company’s needs for the protection of information should be identified, regularly reviewed and documented.

Confidentiality or non-disclosure agreements should address the requirement to protect confidential information using legally enforceable terms. Confidentiality or non-disclosure agreements are applicable to external parties or employees of the Company. Elements should be selected or added in consideration of the type of the other party and its permissible access or handling of confidential information. To identify requirements for confidentiality or non-disclosure agreements, the following elements should be considered:

  • a definition of the information to be protected (e.g. confidential information);
  • expected duration of an agreement, including cases where confidentiality might need to be maintained indefinitely;
  • required actions when an agreement is terminated;
  • responsibilities and actions of signatories to avoid unauthorized information disclosure;
  • ownership of information, trade secrets and intellectual property, and how this relates to the protection of confidential information;
  • the permitted use of confidential information and rights of the signatory to use information;
  • the right to audit and monitor activities that involve confidential information;
  • process for notification and reporting of unauthorized disclosure or confidential information leakage;
  • terms for information to be returned or destroyed at agreement cessation;
  • expected actions to be taken in case of a breach of the agreement.
  • Requirements for confidentiality and non-disclosure agreements should be reviewed periodically and when changes occur that influence these requirements.

7. Systems Acquisition, Development & Maintenance

7.1 Security requirements of information systems

Objective - Ensure that information security is an integral part of information systems across the entire lifecycle.

7.1.1 Information security requirements analysis and specification

Information security requirements should be identified using various methods such as deriving compliance requirements from policies and regulations, threat modelling, incident reviews, or use of vulnerability thresholds. Results of the identification should be documented and reviewed by all stakeholders.

Information security requirements and controls should reflect the business value of the information involved and the potential negative business impact which might result from lack of adequate security. Information security requirements should also consider:

  • the level of confidence required towards the claimed identity of users, in order to derive user authentication requirements;
  • Access provisioning and authorization processes, for business users as well as for privileged or technical users;
  • Informing users and operators of their duties and responsibilities;
  • the required protection needs of the assets involved, in particular regarding availability, confidentiality, integrity;
  • requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements;
  • requirements mandated by other security controls, e.g. interfaces to logging and monitoring or data leakage detection systems.

If products are acquired, a formal testing and acquisition process should be followed. Contracts with the supplier should address the identified security requirements. Where the security functionality in a proposed product does not satisfy the specified requirement, the risk introduced and associated controls should be reconsidered prior to purchasing the product.

Available guidance for security configuration of the product aligned with the final software / service stack of that system should be evaluated and implemented. Criteria for accepting products should be defined e.g. in terms of their functionality, which will give assurance that the identified security requirements are met. Products should be evaluated against these criteria before acquisition. Additional functionality should be reviewed to ensure it does not introduce unacceptable risks.

7.1.2 Securing application services on public networks

Information involved in application services passing over public networks should be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. Information security considerations for application services passing over public networks should include the following:

  • the level of confidence each party requires in each other’s claimed identity, e.g. through authentication;
  • authorization processes associated with who may approve contents of, issue or sign key transactional documents;
  • ensuring that communicating partners are fully informed of their authorizations for provision or use of the service;
  • determining and meeting requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation of contracts, e.g. associated with tendering and contract processes;
  • the level of trust required in the integrity of key documents;
  • the protection requirements of any confidential information;
  • the confidentiality and integrity of any order transactions, payment information, delivery address details and confirmation of receipts;
  • the degree of verification appropriate to verify payment information supplied by a customer;
  • selecting the most appropriate settlement form of payment to guard against fraud;
  • the level of protection required to maintain the confidentiality and integrity of order information;
  • avoidance of loss or duplication of transaction information;


8.1 Information security in supplier relationships

OBJECTIVE - Ensure protection of the Company’s assets that is accessible by suppliers.

8.1.1 Information security policy for supplier relationships

Information security requirements for mitigating the risks associated with supplier’s access to the Company’s assets should be agreed with the supplier and documented. The Company should identify and mandate information security controls to specifically address supplier access to the Company’s information in a policy. These controls should address processes and procedures to be implemented by the Company, as well as those processes and procedures that the Company should require the supplier to implement, including:

  • identifying and documenting the types of suppliers, e.g. IT services, logistics utilities, financial services, IT infrastructure components, whom the Company will allow some access level;
  • standardized process and lifecycle for managing supplier relationships;
  • defining the types of information access that different types of suppliers will be allowed, and monitoring and controlling the access;
  • minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the Company’s business needs and requirements and its risk profile;
  • processes and procedures for monitoring adherence to established information security requirements for each type of supplier and type of access, including third party review and product validation;
  • accuracy and completeness controls to ensure the integrity of the information or information processing provided by either party;
  • types of obligations applicable to suppliers to protect the Company’s information;
  • handling incidents and contingencies associated with supplier access including responsibilities of both the Company and suppliers;
  • resilience and, if necessary, recovery and contingency arrangements to ensure the availability of the information or information processing provided by either party
  • awareness training for the Company’s personnel interacting with supplier personnel regarding appropriate rules of engagement and behavior based on the type of supplier and the level of supplier access to the Company’s systems and information;
  • conditions under which information security requirements and controls will be documented in an agreement signed by both parties;
  • managing the necessary transitions of information, information processing facilities and anything else that needs to be moved, and ensuring that information security is maintained throughout the transition period.


9.1 Management of information security incidents and improvements

OBJECTIVE - Ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.

9.1.1 Responsibilities and procedures

Management responsibilities and procedures should be established to ensure a quick, effective and orderly response to information security incidents. The following guidelines for management responsibilities and procedures with regard to information security incident management should be considered:

  • Management responsibilities should be established to ensure that the following procedures are developed and communicated adequately within the Company:
  • incident response planning and preparation;
  • monitoring, detecting, analyzing and reporting of information security events and incidents;
  • for logging incident management activities;
  • handling of forensic evidence;
  • assessment of and decision on information security events and assessment of information security weaknesses;
  • response including those for escalation, controlled recovery from an incident and communication to internal and external people or Company’s;
  • procedures established should ensure that:

1) competent personnel handle the issues related to information security incidents

2) a point of contact for security incidents’ detection and reporting is implemented;

3) appropriate contacts with authorities, external interest groups or forums that handle the issues related to information security incidents are maintained;

  • reporting procedures should include:
  • preparing information security event reporting forms to support the reporting action and to help the person reporting to remember all necessary actions in case of an information security event;
  • the procedure to be undertaken in case of an information security event, e.g. noting all details immediately, such as type of non-compliance or breach, occurring malfunction, messages on the screen and immediately reporting to the point of contact and taking only coordinated actions;
  • reference to an established formal disciplinary process for dealing with employees who commit security breaches;
  • suitable feedback processes to ensure that those persons reporting information security events are notified of results after the issue has been dealt with and closed.

The objectives for information security incident management should be agreed with management, and it should be ensured that those responsible for information security incident management understand the Company’s priorities for handling information security incidents.

9.1.2 Reporting information security events

Information security events should be reported through appropriate management channels as quickly as possible. All employees and contractors should be made aware of their responsibility to report information security events as quickly as possible. They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported.

Situations to be considered for information security event reporting include:

  • ineffective security control;
  • breach of information integrity, confidentiality or availability expectations;
  • human errors;
  • non-compliances with policies or guidelines;
  • breaches of physical security arrangements;
  • uncontrolled system changes;
  • malfunctions of software or hardware;
  • access violations.

9.1.3 Response to information security incidents

The first goal of incident response is to resume ‘normal security level’ and then initiate the necessary recovery.

Post-incident analysis should take place, as necessary, to identify the source of the incident. Information security incidents should be responded to by a nominated point of contact and other relevant persons of the Company. The response should include the following:

  • collecting evidence as soon as possible after the occurrence;
  • conducting information security forensics analysis, as required;
  • escalation, as required;
  • ensuring that all involved response activities are properly logged for later analysis;
  • communicating the existence of the information security incident or any relevant details thereof to other internal and external people or Companys with a need-to-know;
  • dealing with information security weakness(es) found to cause or contribute to the incident;
  • once the incident has been successfully dealt with, formally closing and recording it.

Information security incidents should be responded to in accordance with the documented procedures.

10. Security & Business Continuity Management

10.1 Redundancies

OBJECTIVE - Ensure availability of information processing facilities.

Information processing facilities are implemented with redundancy sufficient to meet availability requirements.

Company’s should identify business requirements for the availability of information systems. Where the availability cannot be guaranteed using the existing systems architecture, redundant components or architectures should be considered. Where applicable, redundant information systems should be tested to ensure the failover from one component to another component works as intended.

11. Compliance

11.1 Compliance with legal and contractual requirements

OBJECTIVE - Avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements.

11.1.2 Intellectual property rights

Appropriate procedures are implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.

The following guidelines should be considered to protect any material that may be considered intellectual property:

  • publishing an intellectual property rights compliance policy which defines the legal use of software and information products;
  • acquiring software only through known and reputable sources, to ensure that copyright is not violated;
  • maintaining awareness of policies to protect intellectual property rights and giving notice of the intent to take disciplinary action against personnel breaching them;
  • maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights;
  • maintaining proof and evidence of ownership of licenses, master disks, manuals, etc.;
  • implementing controls to ensure that any maximum number of users permitted within the license is not exceeded;
  • carrying out reviews that only authorized software and licensed products are installed;
  • providing a policy for maintaining appropriate license conditions;
  • providing a policy for disposing of or transferring software to others;
  • complying with terms and conditions for software and information obtained from public networks;
  • not duplicating, converting to another format or extracting from commercial recordings (film, audio) other than permitted by copyright law;
  • not copying in full or in part, books, articles, reports or other documents, other than permitted by copyright law.

Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licenses.

Proprietary software products are usually supplied under a license agreement that specifies license terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. The importance and awareness of intellectual property rights should be communicated to all employees dedicated to software developed for the Company.

11.1.2 Privacy and protection of personally identifiable information

Privacy and protection of personally identifiable information is ensured as required in relevant legislation and regulation. A Company’s data policy for privacy and protection of personally identifiable information should be developed and implemented. This policy should be communicated to all persons involved in the processing of personally identifiable information.

Compliance with this policy and all relevant legislation and regulations concerning the protection of the privacy of people and the protection of personally identifiable information requires appropriate management structure and control. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to managers, users and service providers on their individual responsibilities and the specific procedures that should be followed. Responsibility for handling personally identifiable information and ensuring awareness of the privacy principles should be dealt with in accordance with relevant legislation and regulations. Appropriate technical and Company measures to protect personally identifiable information should be implemented.