This Control states that the rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented. There must be a  clear guidelines of how users should behave when working with information assets, to ensure confidentiality, integrity and availability of the organisation’s information security assets.Acceptable use of information and other associated assets means using information assets in ways that do not put at risk the availability, reliability, or integrity of data, services or resources. It also means using them in ways that do not violate laws or the organisation’s policies The Acceptable Use of Information Assets applies to all members of an organisation and assets owned or operated by the organisation. It applies to all uses of Information Assets for any purpose, including commercial. The following are examples of Information Assets:

• Hardware: computers, mobile devices, phones and fax machines.
• Software: operating systems, applications (including Web-based apps), utilities, firmware and programming languages.
• Data: structured data in relational databases, flat files and No SQL data; unstructured data such as text documents, spreadsheets, images, video and audio files; records in any format.
• Networks: wired and wireless networks; telecommunications systems; voice over IP services.
• Services: cloud services, email accounts and other hosted services.

Control

Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented.

Purpose

To ensure information and other associated assets are appropriately protected, used and handled.

ISO 27002 Implementation Guidance

Personnel and external party users using or having access to the organization’s information and other associated assets should be made aware of the information security requirements for protecting and handling the organization’s information and other associated assets. They should be responsible for their use of any information processing facilities.
The organization should establish a topic-specific policy on the acceptable use of information and other associated assets and communicate it to anyone who uses or handles information and other associated assets. The topic-specific policy on acceptable use should provide clear direction on how individuals are expected to use information and other associated assets. The topic-specific policy should state:

1. expected and unacceptable behaviors of individuals from an information security perspective;
2. permitted and prohibited use of information and other associated assets;
3. monitoring activities being performed by the organization.

Acceptable use procedures should be drawn up for the full information life cycle in accordance with its classification and determined risks. The following items should be considered:

1. access restrictions supporting the protection requirements for each level of classification;
2. maintenance of a record of the authorized users of information and other associated assets;c) protection of temporary or permanent copies of information to a level consistent with the protection of the original information;
3. storage of assets associated with information in accordance with manufacturers’ specifications;
4. clear marking of all copies of storage media (electronic or physical) for the attention of the authorized recipient ;
5. authorization of disposal of information and other associated assets and supported deletion method.

Other information

It can be the case that the assets concerned do not directly belong to the organization, such as public cloud services. The use of such third-party assets and any assets of the organization associated with such external assets (e.g. information, software) should be identified as applicable and controlled, for example, through agreements with cloud service providers. Care should also be taken when a collaborative working environment is used.

After going through the asset inventory, categorization, and ownership identification, ensure there are documented policies regarding the acceptable use of assets. Define, and document, the rules that clarify the acceptable uses of assets associated with information and information processing facilities. It is important, once the rules are clarified, that appropriate controls are implemented and the security requirements are communicated. Target the communication of security requirements to employees and, if appropriate, third parties who may use these assets. Accountability is key. Asset owners should be responsible and accountable, even if the owner has delegated responsibility, for their use of facilities and resources. The Control was designed to ensure that policies, procedures and technical controls are in place to prevent users from inappropriately accessing, using or disclosing information assets.This control aims to provide a framework for organisations to ensure that information and other assets are appropriately protected, used and handled. This includes ensuring that the policies and procedures exist at all levels within the organisation, as well as ensuring that those policies and procedures are consistently enforced. You have put in place the various requirements related to how your company protects IT assets including:

• The protection of information in storage, processing and transit.
• The protection and appropriate use of IT equipment.
• The use of appropriate authentication services to control access to information systems.
• The processing of information within an organisation only by users with appropriate authorisation.
• The allocation of information-related responsibilities to specific individuals or roles.
• The education and training of users regarding their security responsibilities.

You will need to develop procedures for handling assets associated with your information and information processing facilities. It is important that your asset handling procedures respect and reflect how you classified it. Ensure that

• Information is handled and protected according to its classification. This includes sharing with external entities.
• There are procedures to control classified information. Clarify how yours, and perhaps others’, classifications should be interpreted.
• Information is stored, processed, transmitted and copied according to its classification. Copies should get the same protections.
• Access restrictions are designed for each level of classification. Restrictions must meet protection requirements.
• There is a formal record of the authorized recipients of the assets. Specify who the authorized recipient should be. Label media copies appropriately.

All of the above bullet points can be incorporated into one procedural access handling document. Remember, keep it simple so others will be able to understand and comply with the requirements. Hold a session with your information and physical asset owners so they can help you define the requirements. It’s important everyone feels ownership of this process.

An example of an Acceptable Use Rules

1.0 General Use and Ownership

1. proprietary information stored on electronic and computing devices whether owned or leased by , the employee or a third party, remains the sole property of. You must ensure through legal or technical means that proprietary information is protected in accordance with the Data Protection Standard.
2. You have a responsibility to promptly report the theft, loss or unauthorized disclosure of proprietary information.
3. You may access, use or share proprietary information only to the extent it is authorized and necessary to fulfill your assigned job duties.
4. Employees are responsible for exercising good judgment regarding the reasonableness of personal use. Individual departments are responsible for creating guidelines concerning personal use of Internet/Intranet/Extranet systems. In the absence of such policies, employees should be guided by departmental policies on personal use, and if there is any uncertainty, employees should consult their supervisor or manager.
5. For security and network maintenance purposes, authorized individuals within may monitor equipment, systems, and network traffic at any time, per the organization’s Audit Policy.
6. reserves the right to audit networks and systems on a periodic basis to ensure compliance with this policy.

2.0 Security and Proprietary Information

1. All mobile and computing devices that connect to the internal network must comply with the Minimum Access Policy.
2. System-level and user-level passwords must comply with the Password Policy. Providing access to another individual, either deliberately or through failure to secure its access, is prohibited.
3. All computing devices must be secured with a password-protected screensaver with the automatic activation feature set to 10 minutes or less. You must lock the screen or log off when the device is unattended.
4. Postings by employees from an email address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of unless posting is in the course of business duties.
5. Employees must use extreme caution when opening e-mail attachments received from unknown senders, which may contain malware.

3.0 Unacceptable Use

The following activities are, in general, prohibited. Employees may be exempted from these restrictions during the course of their legitimate job responsibilities (e.g., systems administration staff may have a need to disable the network access of a host if that host is disrupting production services).
Under no circumstances is an employee of authorized to engage in any activity that is illegal under local, state, federal, or international law while utilizing -owned resources.
The lists below are by no means exhaustive, but attempt to provide a framework for activities that fall into the category of unacceptable use.
3.1  System and Network Activities
The following activities are strictly prohibited, with no exceptions:

1. Violations of the rights of any person or company protected by copyright, trade secret, patent or other intellectual property, or similar laws or regulations, including, but not limited to, the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by.
2. Unauthorized copying of copyrighted material including, but not limited to, digitization and distribution of photographs from magazines, books or other copyrighted sources, copyrighted music, and the installation of any copyrighted software for which or the end-user does not have an active license is strictly prohibited.
3. Accessing data, a server or an account for any purpose other than conducting business, even if you have authorized access, is prohibited.
4. Exporting software, technical information, encryption software or technology, in violation of international or regional export control laws, is illegal. The appropriate management should be consulted prior to the export of any material that is in question.
5. Introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.).
6. Revealing your account password to others or allowing the use of your account by others. This includes family and other household members when work is being done at home.
7. Using a computing asset to actively engage in procuring or transmitting material that is in violation of sexual harassment or hostile workplace laws in the user’s local jurisdiction.
8. Making fraudulent offers of products, items, or services originating from any account.
9. Making statements about warranty, expressly or implied, unless it is a part of normal job duties.
10. Effecting security breaches or disruptions of network communication. Security breaches include, but are not limited to, accessing data of which the employee is not an intended recipient or logging into a server or account that the employee is not expressly authorized to access unless these duties are within the scope of regular duties. For purposes of this section, “disruption” includes, but is not limited to, network sniffing, pinged floods, packet spoofing, denial of service, and forged routing information for malicious purposes.
11. Port scanning or security scanning is expressly prohibited unless prior notification to Information Security is made.
12. Executing any form of network monitoring which will intercept data not intended for the employee’s host, unless this activity is a part of the employee’s normal job/duty.
13. Circumventing user authentication or security of any host, network or account.
14. Introducing honeypots, honeynets, or similar technology on the network.
15. Interfering with or denying service to any user other than the employee’s host (for example, denial of service attack).
16. Using any program/script/command, or sending messages of any kind, with the intent to interfere with, or disable, a user’s terminal session, via any means, locally or via the Internet/Intranet/Extranet.
17. Providing information about, or lists of, employees to parties outside.

3.2 Email and Communication Activities

When using company resources to access and use the Internet, users must realize they represent the company. Whenever employees state an affiliation to the company, they must also clearly indicate that “the opinions expressed are my own and not necessarily those of the company”. Questions may be addressed to the IT Department

1. Sending unsolicited email messages, including the sending of “junk mail” or other advertising material to individuals who did not specifically request such material (email spam).
2. Any form of harassment via email, telephone or paging, whether through language, frequency, or size of messages.
3. Unauthorized use, or forging, of email header information.
4. Solicitation of email for any other email address, other than that of the poster’s account, with the intent to harass or to collect replies.
5. Creating or forwarding “chain letters”, “Ponzi” or other “pyramid” schemes of any type.
6. Use of unsolicited email originating from within ‘s networks of other Internet/Intranet/Extranet service providers on behalf of, or to advertise, any service hosted by or connected via ‘s network.
7. Posting the same or similar non-business-related messages to large numbers of Usenet newsgroups (newsgroup spam).

3.3 Blogging and Social Media

1. Blogging by employees, whether using ’s property and systems or personal computer systems, is also subject to the terms and restrictions set forth in this Policy. Limited and occasional use of ’s systems to engage in blogging is acceptable, provided that it is done in a professional and responsible manner, does not otherwise violate company’s policy, is not detrimental to ’s best interests, and does not interfere with an employee’s regular work duties. Blogging from ’s systems is also subject to monitoring.
2. Company’s Confidential Information policy also applies to the blog. As such, Employees are prohibited from revealing any confidential or proprietary information, trade secrets or any other material covered by ’s Confidential Information policy when engaged in blogging.
3. Employees shall not engage in any blogging that may harm or tarnish the image, reputation and/or goodwill of and/or any of its employees. Employees are also prohibited from making any discriminatory, disparaging, defamatory or harassing comments when blogging or otherwise engaging in any conduct prohibited by Company’s Non-Discrimination and Anti-Harassment policy.
4. Employees may also not attribute personal statements, opinions or beliefs to when engaged in blogging. If an employee is expressing his or her beliefs and/or opinions in blogs, the employee may not, expressly or implicitly, represent themselves as an employee or representative of . Employees assume any and all risks associated with blogging.
5. Apart from following all laws pertaining to the handling and disclosure of copyrighted or export controlled materials, ’s trademarks, logos and any other intellectual property may also not be used in connection with any blogging activity

4.0 Policy Compliance

1. Compliance Measurement: The IT team will verify compliance with this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.
2. Exceptions: Any exception to the policy must be approved by the II team in advance.
3. Non-Compliance: An employee found to have violated this Rules may be subject to disciplinary action, up to and including termination of employment.

—————————End of example—————————————

An asset is an item of value. An asset is defined as “Any item of economic value owned by an individual or corporation”. An information asset management has a long history in business continuity planning (BCP), disaster recovery (DR), and incident response planning. The first step in any of those processes involves identifying critical systems, networks, databases, applications, data flows and other components that need protection. If you do not know what needs protecting or where it resides, then you cannot plan for how to protect it. Asset and data management is based on the idea that it is important to identify, track, classify, and assign ownership for the most important assets in the organization to ensure they are adequately protected. Tracking inventory of IT hardware is the simplest example of asset management.The purpose of this control is to identify the organisation’s information and other associated assets in order to preserve their information security and assign appropriate ownership. The control requires taking an inventory of all information and other associated assets, classifying them into distinct categories, identifying their owners, and documenting the controls that are or should be in place. This is a crucial step toward ensuring that all information assets are adequately protected.

.An inventory of information and other associated assets is a list of everything an organisation stores, processes, or transmits. It also includes the location and security controls for each item. The goal is to identify every single piece of data. This is a list of information assets that an organisation owns, including fixed assets such as property and equipment, as well as intangible assets such as personal data. Creating such an inventory is essential for managing assets and, by extension, mitigating against information security risks. This can be used to identify gaps in the Information security program and identify vulnerabilities during the risk assessments that could lead to a breach. It can also be used as evidence during compliance audits that you’ve done due diligence in identifying your sensitive data, which helps you avoid fines and penalties. The inventory of information assets should also include details of who owns each asset and who manages it. It should also include information about the value of each item in the inventory and how critical it is to the success of the organisation’s business operations. It is important that inventories are kept up-to-date so that they reflect changes within the organisation.

Control

An inventory of information and other associated assets, including owners, should be developed and maintained.

Purpose

To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership.

ISO 27002 Implementation Guidance

Inventory

The organization should identify its information and other associated assets and determine their importance in terms of information security. Documentation should be maintained in dedicated or existing inventories as appropriate. The inventory of information and other associated assets should be accurate, up to date, consistent and aligned with other inventories. Options for ensuring accuracy of an inventory of information and other associated assets include:

1. conducting regular reviews of identified information and other associated assets against the asset inventory.
2. automatically enforcing an inventory update in the process of installing, changing or removing an asset.

The location of an asset should be included in the inventory as appropriate. The inventory does not need to be a single list of information and other associated assets. Considering that the inventory should be maintained by the relevant functions, it can be seen as a set of dynamic inventories, such as inventories for information assets, hardware, software, virtual machines (VMs), facilities, personnel, competence, capabilities and records. Each asset should be classified in accordance with the classification of the information associated to that asset. The granularity of the inventory of information and other associated assets should be at a level appropriate for the needs of the organization. Sometimes specific instances of assets in the information life cycle are not feasible to be documented due to the nature of the asset. An example of a short-lived asset is a VM instance whose life cycle can be of short duration.

Ownership

For the identified information and other associated assets, ownership of the asset should be assigned to an individual or a group and the classification should be identified . A process to ensure timely assignment of asset ownership should be implemented. Ownership should be assigned when assets are created or when assets are transferred to the organization. Asset ownership should be reassigned as necessary when current asset owners leave or change job roles.

Owner duties

The asset owner should be responsible for the proper management of an asset over the whole asset life cycle, ensuring that:

1. information and other associated assets are inventoried;
2. information and other associated assets are appropriately classified and protected;
3. the classification is reviewed periodically;
4. components supporting technology assets are listed and linked, such as database, storage, software
   components and sub-components;
5. requirements for the acceptable use of information and other associated assets are established;
6. access restrictions correspond with the classification and that they are effective and are reviewed periodically;
7. information and other associated assets, when deleted or disposed, are handled in a secure manner and removed from the inventory;
8. they are involved in the identification and management of risks associated with their asset;
9. they support personnel who have the roles and responsibilities of managing their information.

Other information

Inventories of information and other associated assets are often necessary to ensure the effective protection of information and can be required for other purposes, such as health and safety, insurance or financial reasons. Inventories of information and other associated assets also support risk management, audit activities, vulnerability management, incident response and recovery planning. Tasks and responsibilities can be delegated (e.g. to a custodian looking after the assets on a daily basis), but the person or group who delegated them remains accountable. It can be useful to designate groups of information and other associated assets which act together to provide a particular service. In this case, the owner of this service is accountable for the delivery of the service, including the operation of its assets. See ISO/IEC 19770-1 for additional information on information technology (IT) asset management. See ISO 55001 for additional information on asset management.

An organization should identify assets relevant in the life cycle of information and document their importance. The life cycle of information should include creation, processing, storage, transmission. deletion and destruction. Documentation should be maintained in dedicated or existing inventories as appropriate. The asset inventory should be accurate, up to date, consistent and aligned with other inventories. For each of the identified assets, ownership of the asset should be assigned and the classification should be identified. Inventories of assets help to ensure that effective protection takes place, and may also be required for other purposes. such as health and safety. insurance or financial (asset management) reasons. ISO provides examples of assets that might need to be considered by the organization when identifying assets. The process of compiling an inventory of assets is an important prerequisite of risk management.Individuals, as well as other entities having approved management responsibility for the asset life cycle, qualify to be assigned as asset owners. A process to ensure timely assignment of asset ownership is usually implemented. Ownership should be assigned when assets are created or when assets are transferred to the organization. The asset owner should be responsible for the proper management of an asset over the whole asset life cycle. The asset owner should:

1. ensure that assets are inventoried.
2. ensure that assets are appropriately classified and protected.
3. define and periodically review access restrictions and classifications to important assets, taking into account applicable access control policies.
4. ensure proper handling when the asset is deleted or destroyed.

The identified owner can be either an individual or an entity who has approved management responsibility for controlling the whole life cycle 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. In complex information systems, it may be useful to designate groups of assets that act together to provide a particular service. In this case, the owner of this service is accountable for the delivery of the service, including the operation of its assets.

You need to identify the information and other associated assets within your organisation. Then you should determine the importance of these items in terms of information security. If appropriate, documentation should be maintained in dedicated or existing inventories. The approach to developing an inventory will vary depending on an organisation’s size and complexity, its existing controls and policies, and the types of information and other associated assets that it uses. The inventory of information and other associated assets should be accurate, up to date, consistent and aligned with other inventories. Options for ensuring accuracy of an inventory of information and other associated assets include:

• conducting regular reviews of identified information and other associated assets against the asset inventory;
• automatically enforcing an inventory update in the process of installing, changing or removing an asset.

The location of an asset should be included in the inventory as appropriate. Some organisations may need to maintain several inventories for different purposes. For example, some organisations have dedicated inventories for software licences or for physical equipment such as laptops and tablets. Others may have a single inventory that includes all physical equipment, including network devices such as routers and switches. It is important that any such inventories are regularly reviewed to ensure that they are kept up-to-date so that they can be used to assist with risk management activities.

In order to effectively manage an organization’s assets, you must first understand what assets you have and where your organization keeps them. Some asset examples are IT hardware, software, data, system documentation, and storage media. Supporting assets such as data center air systems, UPS’s, and services should be included in the inventory. All assets should be accounted for and have an owner. If improperly managed, assets can become liabilities.

• Categorize your assets. Begin by defining distinct categories of the types of assets in the organization. Each category should have its own inventory or classification structure based on the assets that category may contain. (Category: Data Center Hardware)
• Create a list of assets for each category. Creating a list of an institution’s assets and their corresponding locations is the beginning of your inventory. Often, the process of doing so helps identify additional assets that previously had not been considered.(Category: Data Center Hardware; Asset: Core Network Switches)
• Add a location for each asset. The location could be a brick and mortar physical location such as a classroom, data center or office. It could also be collaborative research materials on a file share or financial information stored in a database. (Category: Data Center Hardware; Asset: Core Network Switches; Location: Room no 001)

Because assets can be many things and serve multiple functions, there will likely be more than one inventory process or system used to capture the range of assets that exist in an organization. Make sure you connect with other areas to see what form of hardware inventory already exists. Don’t start from zero. Each inventory system should not unnecessarily duplicate other inventories that may exist.

Asset Responsibility/Ownership
Once you have begun to capture an inventory of the potential assets and their locations, start identifying the responsible person for each asset. An owner is a person, or persons or department, that has been given formal responsibility for the security of an asset. The owner is responsible for securing the asset during the life cycle of the asset. At this juncture in the exercise, it is important to understand the distinction between the terms “owner” and “custodian” of assets. The custodian is responsible for ensuring that the asset is managed appropriately over its life cycle, in accordance with rules set by the asset owner. The custodian is often a subject matter expert (SME) or “owner” of the business process for a particular information asset. An owner of an information asset, Data Owners if you will have direct operational responsibility for the management of one or more types of data. Think of it in terms of an information security department. You have the “owner”, the person responsible for interpreting and assuring compliance. That would be the Director or CISO. Then there is the custodian, the person responsible for the day-to-day operations and management of the tools and processes that protect the information assets. Identifying the owners will help determine who will be responsible for carrying out protective measures, and responding to situations where assets may have been compromised. You will also quickly realize when it isn’t clear who the appropriate responsible party is or when shared responsibility may be an issue. (Category: Data Center Hardware; Asset: Core Network Switches; Location: Room no 01; Owner: Director XYZ) The owner of the assets should be able to identify acceptable uses or provide information on which policy governs its acceptable use. Work with the responsible owner, if need be, on acceptable uses. The acceptable uses should include items such as who assumes the risk of loss, gives access to the asset and how a critical asset is kept functional during or after a loss. Policies governing the use, preservation, and destruction of hardware may originate from your asset management office. Many organizations also find it helpful to document expectations for the acceptable and responsible use of information technology assets in an Acceptable and Responsible Use Policies.The asset owner should be responsible for the proper management of an asset over the whole asset life cycle, ensuring that:

1. information and other associated assets are inventoried;
2. information and other associated assets are appropriately classified and protected;
3. the classification is reviewed periodically;
4. components supporting technology assets are listed and linked, such as database, storage, software components and sub-components;
5. requirements for the acceptable use of information and other associated assets (see 5.10) are established;
6. access restrictions correspond with the classification and that they are effective and are reviewed periodically;
7. information and other associated assets, when deleted or disposed, are handled in a secure manner and removed from the inventory;
8. they are involved in the identification and management of risks associated with their asset(s);
9. they support personnel who have the roles and responsibilities of managing their information.

Physical and Environmental Asset Importance
All assets add value to an organization. However, not all assets are created equal. Gaining a clear understanding of the relative importance of each asset when compared to other organizational assets is an essential step if you are to adequately protect your assets. The importance of an asset can be measured by its business value and security classification or label. Create a rating system for the asset. It can be as simple as (highest to lowest)

1 – critical is always available and protected
2 – very important this asset is available and protected
3 – important if this asset is available and protected
4 – good if this asset is available with minimal protection
Building on the previous example and adding a rating system, it would look like. (Category: Data Center Hardware; Asset: Core Network Switches; Location: Room no 01; Owner: Director XYZ; Rate: 1 (Critical)) A computer kept in a cafeteria for the purpose of recreation may have a lower score given it is good that the asset is available. The computer kept in the finance dept may be protected with anti-virus and firewall.

Information and Communications Technology (ICT) is integral for the daily operations and functionality of the organization. From cell phones to cloud storage to satellite connectivity, the ICT supply chain encompasses the entire life cycle of hardware, software, and services and a diverse array of entities—including third-party vendors, suppliers, service providers, and end users. However, the globally-distributed and interconnected nature of ICT also means that compromise of vulnerabilities in the supply chain can have cascading impacts on Organization Information security. Vulnerabilities in supply chains either developed intentionally for malicious intent or unintentionally through poor security practices can enable data and intellectual property theft, loss of confidence in the integrity of the system, or exploitation to cause system or network failure. Compounding the risk associated with supply chains is that vulnerabilities may be introduced during any phase of the ICT life cycle: design, development and production, distribution, acquisition, deployment, maintenance, and disposal. These vulnerabilities include malicious software and hardware; counterfeit components; and poor product designs, manufacturing processes, and maintenance procedures.

Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

Control

Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

Purpose

To maintain an agreed level of information security in supplier relationships.

Guidance

The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships:
a) defining information security requirements to apply to ICT product or service acquisition;
b) requiring that ICT services suppliers propagate the organization’s security requirements throughout the supply chain if they sub-contract for parts of the ICT service provided to the organization;
c) requiring that ICT products suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased or acquired from other suppliers or other entities (e.g. sub-contracted software developers and hardware component providers);
d) requesting that ICT products suppliers provide information describing the software components used in products;
e) requesting that ICT products suppliers provide information describing the implemented security functions of their product and the configuration required for its secure operation;
f) implementing a monitoring process and acceptable methods for validating that delivered ICT products and services comply with stated security requirements. Examples of such supplier review methods can include penetration testing and proof or validation of third-party attestations for the supplier’s information security operations;
g) implementing a process for identifying and documenting product or service components that are critical for maintaining functionality and therefore require increased attention, scrutiny and further follow up required when built outside of the organization especially if the supplier outsources aspects of product or service components to other suppliers;
h) obtaining assurance that critical components and their origin can be traced throughout the supply chain;
i) obtaining assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features;
j) implementing processes to ensure that components from suppliers are genuine and unaltered from their specification. Example measures include anti-tamper labels, cryptographic hash verification or digital signatures. Monitoring for out of specification performance can be an indicator of tampering or counterfeits. Prevention and detection of tampering should be implemented during multiple stages in the system development life cycle, including design, development, integration, operations and maintenance;
k) obtaining assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement;
l) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers;
m) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered.

Other information

The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. Organizations are advised to work with suppliers to understand the ICT supply chain and any matters that have an important effect on the products and services being provided. The organization can influence ICT supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the ICT supply chain. ICT should be acquired from reputable sources. The reliability of software and hardware is a matter of quality control. While it is generally not possible for an organization to inspect the quality control systems of its vendors, it can make reliable judgments based on the reputation of the vendor. ICT supply chain as addressed here includes cloud services. Examples of ICT supply chains are:

1. cloud services provisioning, where the cloud service provider relies on the software developers, telecommunication service providers, hardware providers;
2. IoT, where the service involves the device manufacturers, the cloud service providers (e.g. the IoT platform operators), the developers for mobile and web applications, the vendor of software libraries;
3. hosting services, where the provider relies on external service desks including first, second and third support levels.

See ISO 27036-3 for more details including risk assessment guidance. Software identification (SWID) tags can also help to achieve better information security in the supply chain, by providing information about software provenance. See ISO 19770-2 for more details.

This control is focused on the Information and communication technology supply chain that may need something in addition or instead of the standard approach. ISO advocates numerous areas for implementation and whilst these are all good, some pragmatism is needed as well. The organization should again recognize its size compared to some of the very large providers that it will sometimes be working with e.g. data centers & hosting services, banks, etc., therefore potentially limiting its ability to influence practices further into the supply chain. The organization should consider carefully what risks there may be based upon the type of information and communication technology services that are being provided. For example, if the supplier is a provider of infrastructure critical services, and has access to sensitive information e.g. source code for the flagship software service, it should ensure there is greater protection than if the supplier is simply exposed to publicly available information e.g. a simple website. Agreements with suppliers should include requirements to address the information security risks associated with information and communications technology services and product supply chains. This section is largely physical in nature and defines additional points to include in supplier agreements, specifically related to their use of technology, both hardware, and software. There should be a process to identify a product or service that is a critical capability and require increased scrutiny. This is especially true for components built outside the supplier organization. The ability to trace origins and compliance with security requirements is integral in ensuring both integrity and availability. Finally, the organization should address the risks of a component or service becoming unavailable or no longer supported.Supplier agreements include requirements to reduce the security risks connected with the IT services and the product supply chain. This means that if there’s a possibility of a data breach, the supplier and contractor will have to get in touch. Suppliers are required to describe how they dealt with minor risks, as well as how they assured the risk was eradicated, even if it is a small risk. Controlling supplier relations effectively requires using crucial services to track the supply chain’s history and its point of origin.

Given the expansion of cross-platform on-premise and cloud services over the last decade, it deals with the supply of both hardware and software-related components and services (both on-premise and cloud-based), and rarely draws a distinction between the two. As well as the relationship between the supplier and the organisation, several controls also deal with a supplier’s obligations when sub-contracting elements of the supply chain to third-party organisations. Organisations should draft a clear set of information security standards that apply to their individual needs, to set clear expectations on how suppliers should conduct themselves when delivering ICT products and services. If the ICT supplier sub-contracts any element of the supply chain, the supplier should take measures to ensure that contractors and their personnel are fully conversant with the organisation’s unique information security standards. If the need arises to acquire components (physical or virtual) purchased from a third party, the supplier should disseminate the organisation’s security requirements to any vendors or suppliers they themselves use. Suppliers should be asked to provide information on the nature and function of the software components they use to deliver a service to the organisation. Organisations should identify the underlying security functions of any product or service supplied, and how to operate said product or service in a way that doesn’t compromise on information security. Organisations shouldn’t take risk levels for granted, and draft procedures that ensure any products or services that a supplier delivers are of a secure nature and compliant with accepted industry standards. Methods may include certification checks, internal testing and supporting compliance documentation. When receiving a product or service, organisations should adhere to a process of first identifying then recording any elements that are deemed to be essential to maintaining core functionality – especially if those components have originated from a sub-contractor/outsourced agreement. Suppliers should be able to provide concrete assurances that “critical components” benefit from a thorough audit log that traces their movement throughout the ICT supply chain, from creation through to delivery. As ICT products and services are delivered, organisations should seek categorical assurance that said products and services are not only operating within scope, but do not contain any additional features which may present a collateral security risk. Component specifications are key to ensuring that an organisation understands the hardware and software components it’s introducing onto its network. Suppliers should consider anti-tampering measures throughout the development life cycle, and organisations should require stipulations which verify components as legitimate upon delivery. Assurances should be sought to confirm that ICT products are in alignment with industry-standard and/or sector-specific security requirements, as relevant to each product. Common methods for achieving this include achieving a minimum level of formal security certification, or adhering to a set of internationally recognized information standards (such as the Common Criteria Recognition Arrangement) per product. Organisations should take steps to ensure that suppliers are aware of their obligations when sharing information and/or data concerning the mutual supply chain operation, including acknowledging any potential conflicts or problems that may arise between both parties, and how to deal with them at source. Organisations need to draft procedures that manage risk when operating with unavailable, unsupported or legacy components, wherever they reside. Where components have fallen into one of these categories, organisations should be able to adapt accordingly and identify alternatives.

Protecting organization’s information in a digitally-connected world requires understanding not only organization’s immediate supply chain, but also the extended supply chains of third-party vendors, service providers, and customers. These essential steps will assist your organization in managing supply chain risks.

1. Identify the people: Build a team of representatives from various roles and functions of the company (e.g., cyber security, information technology, physical security, procurement/acquisition, legal, logistics, marketing, and product development). Ensure personnel at all levels are well-trained in the security procedures of their role or function.
2. Manage the security and compliance: Document the set of policies and procedures that address security, integrity, resilience, and quality. Ensure they are based on industry standards and best practices
3. Assess the components: Build a list of ICT components (e.g., hardware, software, and services) that your organization procures to enable your business. Know which internal systems are relied upon for critical information or functions, and which systems have remote access capability that must be protected to prevent unauthorized access.
4. Know the supply chain and suppliers: Identify your suppliers and, when possible, the suppliers’ sources. In today’s world of increased outsourcing, it is important to understand your upstream suppliers as part of the larger supply chain ecosystem.
5. Verify assurance of third-parties: Verify that your suppliers maintain an adequate security culture to appropriately address the risks that concern your organization. Establish the protocols your organization will use to assess the supply chain practices of your suppliers.
6. Evaluate risk associated with ITC supply: Determine the frequency with which to review your risk, incorporate feedback, and make changes to your risk assessment. This may also include auditing suppliers against practices and protocols established by your organization

Any suppliers that view, process, store, communicate or provide IT infrastructure component information for the organization should be defined and agreed with all applicable information security requirements. This control governs how an organization forms a contractual relationship with a supplier, based on their security requirements and the type of suppliers they deal with. Supplier agreements should be defined and recorded so that the organization and the supplier do not misinterpret the obligations of the two parties to meet the applicable information security requirements. This clause explains about defining and accepting the obligations as well as record them securely under a relevant documented policy. This policy may consist of all the roles and responsibility and limit of accessing the information security of the supplier. It also gives exclusive right to the organization to audit the supplier and its sub contractors. In the ISO 27001 supplier register we record whether we have a contract that covers the products or services that we are buying. To implement this we would also have a local copy of the contract that we could get access to and we would check that the contract the contract includes information security requirements. We always want to have an in date contract that meets the requirements of this clause before we go for ISO 27001 certification audit.

Control

Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship.

Purpose

To maintain an agreed level of information security in supplier relationships.

ISO 27002 Implementation Guidance

Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfill relevant information security requirements. The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements:

1. description of the information to be provided or accessed and methods of providing or accessing the information.
2. classification of information according to the organization’s classification scheme.
3. mapping between the organization’s own classification scheme and the classification scheme of the supplier.
4. legal, statutory, regulatory and contractual requirements, including data protection, handling of personally identifiable information (PII), intellectual property rights and copyright and a description of how it will be ensured that they are met.
5. obligation of each contractual party to implement an agreed set of controls, including access control, performance review, monitoring, reporting and auditing, and the supplier’s obligations to comply with the organization’s information security requirements.
6. rules of acceptable use of information and other associated assets, including unacceptable use if necessary.
7. procedures or conditions for authorization and removal of the authorization for the use of the organization’s information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organization’s information and other associated assets).
8. information security requirements regarding the supplier’s ICT infrastructure; in particular, 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 organization’s business needs and risk criteria.
9. indemnities and remediation for failure of contractor to meet requirements.
10. incident management requirements and procedures (especially notification and collaboration during incident remediation).
11. training and awareness requirements for specific procedures and information security requirements (e.g. for incident response, authorization procedures).
12. relevant provisions for sub-contracting, including the controls that need to be implemented, such as agreement on the use of sub-suppliers (e.g. requiring to have them under the same obligations of the supplier, requiring to have a list of sub-suppliers and notification before any change).
13. relevant contacts, including a contact person for information security issues.
14. any screening requirements, where legally permissible, for the supplier’s personnel, including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern.
15. the evidence and assurance mechanisms of third-party attestations for relevant information security requirements related to the supplier processes and an independent report on effectiveness of controls.
16. right to audit the supplier processes and controls related to the agreement.
17. supplier’s obligation to periodically deliver a report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report.
18. defect resolution and conflict resolution processes.
19. providing backup aligned with the organization’s needs (in terms of frequency and type and storage location).
20. ensuring the availability of an alternate facility (i.e. disaster recovery site) not subject to the same threats as the primary facility and considerations for fall back controls (alternate controls) in the event primary controls fail.
21. having a change management process that ensures advance notification to the organization and the possibility for the organization of not accepting changes.
22. physical security controls commensurate with the information classification.
23. information transfer controls to protect the information during physical transfer or logical transmission.
24. termination clauses upon conclusion of the agreement including records management, return of assets, secure disposal of information and other associated assets, and any ongoing confidentiality obligations.
25. provision of a method of securely destroying the organization’s information stored by the supplier as soon as it is no longer required.
26. ensuring, at the end of the contract, handover support to another supplier or to the organization itself.

The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses.

Other information

The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks.

All relevant information security requirements must be in place with each supplier that has access to or can impact the organisation’s information or assets that process it. Again this should not be a one size fits all – take a risk based approach around the different types of suppliers involved and work they do. Working with suppliers that already meet the majority of your organisations information security needs for the services they provide to you and have a good track record of addressing information security concerns responsibly is a very good idea – as it will make all of these processes much easier. In simple terms, look for suppliers that already have achieved an independent ISO 27001 certification or equivalent themselves. It is also important to ensure that the suppliers are being kept informed and engaged with any changes to the ISMS or specifically engaged around the parts that affect their services. Your auditor will want to see this evidenced – so, by keeping a record of this in your supplier on-boarding projects or annual reviews it will be easy to do so. Things to include in the supply scope and agreements generally include: the work and its scope; information at risk and classification; legal and regulatory requirements ; reporting and reviews; non disclosure; IPR; incident management; specific policies to comply with if important to the agreement; obligations on subcontractors; screening on staff etc. A good standard contract will deal with these points but as above, sometimes it might not be required, and could be way over the top for the type of supply, or it might not be possible to force a supplier to follow your idea of good practice. Be pragmatic and risk centred in the approach.An organization may want suppliers to access and contribute to certain high-value information assets (e.g. software code development, accounting payroll information). They would therefore need to have clear agreements of exactly what access they are allowing them, so they can control the security around it. This is especially important with more and more information management, processing, and technology services being outsourced.  That means having a place to show management of the relationship is happening; contracts, contacts, incidents, relationship activity, and risk management, etc. Where the supplier is also intimately involved in the organization, but may not have its own certified ISMS, then ensuring the supplier staff is educated and aware of security, trained on your policies, etc. is also worth demonstrating compliance around. Working with suppliers that already meet the majority of your organization’s information security needs for the services they provide to you and have a good track record of addressing information security concerns responsibly is a very good idea – as it will make all of these processes much easier. In simple terms, look for suppliers that already have achieved an independent ISO 27001 certification or equivalent themselves.  It is also important to ensure that the suppliers are being kept informed and engaged with any changes to the ISMS or specifically engaged around the parts that affect their services. Your auditor will want to see this evidenced – so, by keeping a record of this in your supplier on-boarding projects or annual reviews it will be easy to do so. Things to include in the supply scope and agreements generally include the work and its scope; information at risk and classification; legal and regulatory requirements e.g. adherence to GDPR and or other applicable legislation; reporting and reviews; non-disclosure; IPR; incident management; specific policies to comply with if important to the agreement; obligations on subcontractors; screening on staff, etc.  A good standard contract will deal with these points but as above, sometimes it might not be required and could be way over the top for the type of supply, or it might not be possible to force a supplier to follow your idea of good practice.  Be pragmatic and risk-centered in the approach.

Supplier agreements should be established and documented to ensure there is no misunderstanding regarding both parties’ obligations to fulfill relevant security, legal, and/or regulatory requirements. Organizations are increasingly using outsourced services. While sensitive data processes and services might be outsourced, responsibility for the associated risk remains with the organization. Supplier agreements should include (as appropriate) clear and concise information regarding:

• The types of data being accessed and methods of access
• Definitions of data ownership and disposition throughout the service lifecycle
• The organization’s data classification requirements as it applies to the supplier
• Definition of acceptable uses for the data handled by the supplier
• Establishment of security incident notification requirements
• Processes and procedures for monitoring compliance with the contract requirements
• A “right to audit” the supplier or regular access to external assessments
• Conflict and defect resolution
• The required screening, training or other obligations of the suppliers’ staff
• The use of subcontractors to provide services and the extension of security requirements to them.

It is important to address the risk early in the procurement phase of the relationship with external parties so that roles, responsibilities, and expectations can be clearly defined in agreements or contracts. This Control explicitly states that both parties should exit the process with a “clear understanding” of their information security obligations to one another. A clear description should be provided detailing the information that needs to be accessed in any way, and how that information is going to be accessed. The organisation should classify the information to be accessed in accordance with its published classification scheme . Adequate consideration should be given to the supplier-side classification scheme, and how that relates to the organisation’s classification of information. Both parties’ rights should be categorized into four main areas – legal, statutory, regulatory and contractual. Within these four areas, various obligations should be clearly outlined, as is standard in commercial agreements, including accessing PII, intellectual property rights and copyright stipulations. The agreement should also cover how each of these key areas will be addressed in turn. Each party should be obligated to enact a series of concurrent controls that monitor, assess and manage information security risk levels such as access control policies, contractual reviews, systems monitoring, reporting and periodic auditing. In addition, the agreement should clearly outline the need for supplier personnel to adhere to an organisation’s information security standards. There should be a clear understanding of what constitutes both acceptable and unacceptable use of information, and physical and virtual assets from either party. Procedures should be put in place that deal with the levels of authorization required for supplier-side personnel to access or view an organisation’s information e.g. authorized user lists, supplier-side audits, server access controls. Information security should be considered alongside the supplier’s own ICT infrastructure, and how that relates to the type of information that the organisation has provided access to, the risk criteria and the organisation’s base set of business requirements. Consideration should be given to what courses of action the organisation is able to take in the event of a breach of contract on the part of the supplier, or failure to comply with individual stipulations. The agreement should clearly outline a mutual Incident Management procedure that clearly stipulates what needs to happen when problems arise, particularly concerning how the incident is communicated between both parties. Personnel from both parties should be given adequate awareness training on key areas of the agreement, specifically concerning key risk areas such as Incident Management and the provision of access to information. Adequate attention should be given to the use of subcontractors. If the supplier is permitted to use subcontractors, the organisations should take steps to ensure that any such individuals or companies are aligned with the same set of information security requirements as the supplier. Where it’s legally possible and operationally relevant, organisations should consider how supplier personnel are screened prior to interacting with their information, and how screening is recorded and reported to the organisation, including non-screened personnel and areas for concern. Organisations should stipulate the need for third-party attestations that verify the supplier’s ability to fulfill organisational information security requirements, including independent reports and third-party audits. Organisations should have the contractual right to assess and audit a supplier’s procedures. Suppliers should have an obligation to deliver reports (at varying intervals) that cover the effectiveness of their own processes and procedures, and how they intend to address any issues raised in such a report. The agreement should take steps to ensure the timely and thorough resolution of any defects or conflicts that take place during the course of the relationship. Where relevant, the supplier should operate with an robust BUDR policy, in line with the organisation’s needs, that covers off three main considerations:

• Backup type (full server, file and folder etc, incremental etc.)
• Backup frequency (daily, weekly etc.)
• Backup location and source media (onsite, offsite)

Data resilience should be achieved by operating with a disaster recovery location that is separate from the supplier’s main ICT site, and is not subject to the same level of risk. The supplier should operate with a comprehensive change management policy that gives advance notification to the organisation of any changes that may affect information security, and provide the organisation with the ability to reject such changes. Physical security controls (building access, visitor access, room access, desk security) should be enacted that are relevant to the kind of information they are permitted to access. When the need arises to transfer information between assets, sites, servers or storage locations, the supplier should ensure that data and assets are protected from loss, damage or corruption throughout the process. The agreement should outline a comprehensive list of actions to be taken by either party in the event of termination , including but not limited to:

• Asset disposal and/or relocation
• Information deletion
• Return of IP
• Removal of access rights
• Ongoing confidentiality obligations

The supplier should outline precisely how it intends to destroy/permanently delete the organisation’s information the moment it is no longer required i.e. in the event of a termination. If, at the end of a contract, the need arises to handover support and/or services to another provider not listed on the agreement, steps are taken to ensure that the process results in zero business interruption. To ensure that the benefits of outsourcing operations outweigh the risks of including providers in the scenario, contracts should be written properly, and ISO 27001 requires an organization to consider security clauses in contracts. Some examples of security clauses are:

• Right to audit: clause ensuring the organization has the right to audit and test the security controls periodically, or upon significant changes to the relationship.
• Notification about security breaches: clause requiring the provider to inform the organization in a timely manner regarding any security breaches that may impact the organization’s business. Generally, this clause is related to data breach notification laws that affect either the organization or the provider, or both.
• Adherence to security practices: clause requiring the provider to adhere to the organization’s security practices, and to communicate any situations where this adherence is not achievable, helping to prevent security gaps or conflicts that could impair security performance.
• Response time to vulnerabilities: clause requiring the provider to provide, in a timely manner, proper treatment for known vulnerabilities that may impact the organization’s business.
• Demonstration of compliance: clause requiring the provider to provide independent evidence that its operations and controls comply with contractual requirements. This can be achieved, for example, by a third-party audit agreed upon by the provider and the organization.
• Management of supplier’s supply chain risks: clause requiring the provider to ensure, within its own supply chain, the fulfillment of the same security clauses applied to the provider.
• Communication of changes: clause requiring the provider to inform the organization in a timely manner regarding changes in its environment that may impact the organization’s business.
• Maintenance of service levels: clause requiring the provider to inform the organization regarding its plans to ensure service levels in normal conditions and during disruptive events, on either the organization’s or the provider’s premises.

You should note this is not a definitive list and other clauses may arise from risk assessments, and that all contractual clauses should be reviewed by legal personnel to ensure proper wording and application. To define which clauses to apply, you should focus on each supplier’s risks, by means of surveys, questionnaires, and gathering of controls documentation during supplier selection. To help you manage information on multiple suppliers, you can use criteria like:

• categorizing suppliers based on what they do for you
• prioritizing suppliers based on information you share with them, or information they may have access to.

External suppliers are a vital component of business operations. Suppliers may have access to a wide range of information from the supported organization. Once shared with a supplier, direct control of this information is lost, regardless of sensitivity or value. As a result, appropriate technical and contractual controls and mitigation processes must be established with all external suppliers. One essential control would be to ensure the existence of a data-sharing agreement that clearly delineates roles and responsibilities. Some data privacy regulations may have specific data sharing requirements that must be met. The contracting organization should understand that the management of external providers is a life cycle. Part of this cycle is a process to monitor and continuously assess provider performance and compliance. A variety of tools may be used to assess and validate external supplier data protection practices. In almost all cases, some mitigation will be contractual and requires extensive documentation. In addition to protecting information handled and used by external suppliers, the organization must also assess service availability. If business-critical data or functions are supported by an external entity, then the provider’s disaster recovery processes are integral to the recovery processes of the hiring entity. Agreements regarding the return of data in the event of contract termination or unexpected closure should also be considered within the life cycle.
This control is about information security in supplier relationships. The objective here is the protection of the organization’s valuable assets that are accessible to or affected by suppliers. The organization must also consider other key relationships here too, for example, partners if they are not suppliers but also have an impact on your assets that might not simply be covered by a contract alone. This is an important part of the information security management system (ISMS) especially. Let’s understand those requirements and what they mean in a bit more depth now. The contracting organization should understand that the management of external providers is a life cycle. Part of this cycle is a process to monitor and continuously assess provider performance and compliance. A variety of tools may be used to assess and validate external supplier data protection practices. In almost all cases, some mitigation will be contractual and requires extensive documentation. In addition to protecting information handled and used by external suppliers, the organization must also assess service availability. If business-critical data or functions are supported by an external entity, then the provider’s disaster recovery processes are integral to the recovery processes of the hiring entity. Agreements regarding the return of data in the event of contract termination or unexpected closure should also be considered within the life cycle.

Control

Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.

Purpose

To maintain an agreed level of information security in supplier relationships.

ISO 27002 Implementation Guidance

The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties. The organization should identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers. This should also apply to the organization’s use of resources of cloud service providers. These processes and procedures should include those to be implemented by the organization, as well as those the organization requires the supplier to implement for the commencement of use of a supplier’s products or services or for the termination of use of a supplier’s products and services, such as:
a) identifying and documenting the types of suppliers (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the organization’s information;
b) establishing how to evaluate and select suppliers according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, on- site assessments, certifications);
c) evaluating and selecting supplier’s products or services that have adequate information security controls and reviewing them; in particular, accuracy and completeness of controls implemented by the supplier that ensure integrity of the supplier’s information and information processing and hence the organization’s information security;
d) defining the organization’s information, ICT services and the physical infrastructure that suppliers can access, monitor, control or use;
e) defining the types of ICT infrastructure components and services provided by suppliers which can affect the confidentiality, integrity and availability of the organization’s information;
f) assessing and managing the information security risks associated with:

1. the suppliers’ use of the organization’s information and other associated assets, including risks originating from potential malicious supplier personnel;
2. malfunctioning or vulnerabilities of the products (including software components and sub- components used in these products) or services provided by the suppliers;

g) monitoring compliance with established information security requirements for each type of supplier and type of access, including third-party review and product validation;
h) mitigating non-compliance of a supplier, whether this was detected through monitoring or by other means;
i) handling incidents and contingencies associated with supplier products and services including responsibilities of both the organization and suppliers;
j) resilience and, if necessary, recovery and contingency measures to ensure the availability of the supplier’s information and information processing and hence the availability of the organization’s information;
k) awareness and training for the organization’s personnel interacting with supplier personnel regarding appropriate rules of engagement, topic-specific policies, processes and procedures and behavior based on the type of supplier and the level of supplier access to the organization’s systems and information;
l) managing the necessary transfer of information, other associated assets and anything else that needs to be changed and ensuring that information security is maintained throughout the transfer period;
m) requirements to ensure a secure termination of the supplier relationship, including:

1. de-provisioning of access rights;
2. information handling;
3. determining ownership of intellectual property developed during the engagement;
4. information portability in case of change of supplier or in sourcing;
5. records management;
6. return of assets;
7. secure disposal of information and other associated assets;
8. ongoing confidentiality requirements;

n) level of personnel security and physical security expected from supplier’s personnel and facilities.

The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers).

Other information

In cases where it is not possible for an organization to place requirements on a supplier, the organization should:
a) consider the guidance given in this control in making decisions about choosing a supplier and its product or service;
b) implement compensating controls as necessary based on a risk assessment.
Information can be put at risk by suppliers with inadequate information security management. Controls should be determined and applied to manage the supplier’s access to information and other associated assets. For example, if there is a special need for confidentiality of the information, non-disclosure agreements or cryptographic techniques can be used. Another example is personal data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization. Risks can also be caused by inadequate controls of ICT infrastructure components or services provided by suppliers. Malfunctioning or vulnerable components or services can cause information security breaches in the organization or to another entity (e.g. they can cause malware infection, attacks or other harm on entities other than the organization). See ISO 27036-2 for more detail.

Suppliers are used for two main reasons; you want them to do work that you have chosen not to do internally yourself, or you can’t easily do the work as well or as cost-effectively as the suppliers. The organization should identify and require information security controls that specifically address external parties (contractors, service providers) gaining authorized access to the organization’s information in the policy. The controls should also specify processes and procedures that should be followed, either when third-party contractors work within the organization or when there are service provider/hosting arrangements. Suppliers should be managed throughout the life cycle of a relationship with them–from initially reviewing their contracts and security methods to monitoring their SLAs and performance agreements once they are engaged to perform services and/or provide solutions.  Access control, especially for sensitive information must be accurately defined, managed, and monitored. Awareness training for both the organization’s staff and supplier staff that handle or interact with this data must be addressed. Finally, service transitions should be documented and include procedures for secure data transfers and availability as the relationship changes during the lifecycle. Many (but not all) supplier relationships will involve cloud computing services and processes, which should be carefully considered as a part of Supplier Relationship Management. One essential control that the organization can implement is the development of a checklist to assess contractual cloud service providers. If regulated and/or sensitive data is being put out in the cloud, then the organization should consider obtaining formal written assurances from cloud service providers, including the regular submission of independent assessments and/or audits. The organization should always consider asking these cloud service providers for a copy of a report which focuses strictly on reviewing controls related to the confidentiality, integrity, and availability of information and systems. The organization has seen a move from consumer-level adoption of cloud services to enterprise deployment of full-scale cloud storage and collaboration platforms. Enterprise services can now offer the convenience of cloud storage and collaboration services with single sign-on through the organization’s identity management system, integration with other services, and contractual assurances of privacy, security, and uptime. The deployment of enterprise cloud storage and collaboration services has introduced new opportunities for how documents are conceived, completed, and submitted. This technology provides the opportunity for employees to bring their work wherever they go, access it instantly, and collaborate with colleagues in a private and secure digital environment.

The supplier should be agreed with the and documented information security requirements relates to the the risk of access by suppliers to organisation assets. If any organisation wants to provide access to its supplier, the risk assessment should be done. The organisation must identify and involve required security information controls. These could include the following:

• Identification and reporting of supplier forms, e.g. IT services, financial services etc. which are accessible to the organisation;
• Controls over the accuracy and completeness of information transmitted by either party;
• Resilience and, if necessary, recovery and contingency plans to ensure the availability by all parties of information or processing;
• Training in awareness of applicable policies, processes and procedures for the organization staff involved in acquisitions;
• Training in awareness of how the organization’s staff interacts with supplier staff on appropriate rules of engagement and behavior based on provider type and level of supplier access to the system and information of the organization;
• A legal contract must be signed by both parties to maintain the integrity of the relationship.

There are many important things to consider in the approach to supplier selection and management but one size does not fit all and some suppliers will be more important than others.  As such your controls and policies should reflect that too and segmentation of the supply chain is sensible; we advocate four categories of the supplier based on the value and risk in the relationship.  These range from those who are business-critical to other vendors who have no material impact on your organization. Some suppliers are also more powerful than their customers (imagine telling Amazon what to do if you are using their AWS services for hosting) so it’s pointless having controls in place that the suppliers will not adhere to.  Therefore reliance on their standard policies, controls, and agreements is more likely – meaning the supplier selection and risk management becomes even more important. In order to take a more forward approach to information security in the supply chain with the more strategic (high value / higher risk) suppliers, organizations should also avoid binary ‘comply or die’ risk transferring practices e.g. awful contracts preventing good collaboration. Instead, we recommend they develop more close working relationships with those suppliers where thigh value information and assets are at risk, or they are adding to your information assets in some (positive) way. This is likely to lead to improved working relationships, and therefore deliver better business results too. A good policy describes the supplier segmentation, selection, management, exit, how information assets around suppliers are controlled in order to mitigate the associated risks, yet still enable the business goals and objectives to be achieved. Smart organizations will wrap their information security policy for suppliers into a broader relationship framework and avoid just concentrating on security per se, looking to the other aspects as well. An organization may want suppliers to access and contribute to certain high-value information assets (e.g. software code development, accounting payroll information). They would therefore need to have clear agreements of exactly what access they are allowing them, so they can control the security around it. This is especially important with more and more information management, processing, and technology services being outsourced.  That means having a place to show management of the relationship is happening; contracts, contacts, incidents, relationship activity, and risk management, etc. Where the supplier is also intimately involved in the organization, but may not have its own certified ISMS, then ensuring the supplier staff is educated and aware of security, trained on your policies, etc. is also worth demonstrating compliance around.

Compliance with this Control involves adhering to what’s known as a ‘topic-specific’ approach to information security in supplier relationships. Topic-specific approaches encourage organisations to create supplier-related policies that are tailored towards individual business functions, rather than adhering to a blanket supplier management policy that applies to any and all third party relationships across an organisation’s commercial operation. The organisation must implement policies and procedures that not only govern the organisation’s use of supplier resources and cloud platforms, but also form the basis of how they expect their suppliers to conduct themselves prior to and throughout the term of the commercial relationship. It can be viewed as the essential qualifying document that dictates how information security governance is handled over the course of a supplier contract. It contains following points to be adhered to:

1) Maintain an accurate record of supplier types (e.g. financial services, ICT hardware, telephony) that have the potential to affect information security integrity. Maintain a list of all suppliers categorizing them according to their business function and add categories to said supplier types as and when required.

2) Evaluate your suppliers,based on the level of risk inherent for their supplier type such as industry references, financial statements, onsite assessments, sector-specific certifications such as Microsoft Partnerships . Different supplier types will require different due diligence checks. Consider evaluation methods on a supplier-by-supplier basis

3) Identify suppliers that have pre-existing information security controls in place based on their relevant information security governance procedures.

4) Identify and define the specific areas of organisation’s ICT infrastructure that suppliers will be able to either access, monitor or make use of themselves. It’s important to establish from the outset precisely how suppliers are going to interact with ICT assets be it physical or virtual and what levels of access they’re granted in accordance with their contractual obligations.

5) Define how the suppliers’ ICT infrastructure can impact organizations or its customers data, and that of your customers. Supplier ICT assets need to be reviewed in accordance with their potential to affect uptime and integrity throughout the organisation.

6) Identify and manage the various information security risks attached to:

• Supplier use of confidential information or protected assets (e.g. limited to malicious use and/or criminal intent).
• Faulty supplier hardware or malfunctioning software platform associated with on-premise or cloud based services.

Organisations must lookout for information security risks associated with catastrophic events, such as nefarious supplier-side user activity or major unforeseen software incidents, and their impact on organisational information security.

7) Monitor information security compliance on supplier type based on the information security implications inherent within each supplier type, and adjust their monitoring activity to accommodate varying levels of risk.

8) Limit the amount of damage and/or disruption caused through non-compliance.Supplier activity should be monitored in an appropriate manner, and to varying degrees, in accordance with its risk level. Where non-compliance is discovered, either proactively or reactively, immediate action should be taken.

9) Maintain a robust incident management procedure that addresses a reasonable amount of contingencies. Organisations should understand precisely how to react when faced with a broad range of events relating to the supply of third party products and services, and outline remedial actions that include both the supplier and the organisation.

10) Enact measures that cater to the availability and processing of the supplier’s information, wherever it’s used, thereby ensuring the integrity of the organisation’s own information. Steps should be taken to ensure that supplier systems and data are handled in a way that doesn’t compromise on the availability and security of the organisation’s own systems and information.

11) Draft a thorough training plan that offers guidance on how staff should interact with supplier personnel and information on a supplier-by-supplier basis, or on a type-by-type basis. Training should cover the full spectrum of governance between an organisation and its suppliers, including engagement, granular risk management controls and topic-specific procedures.

12) Understand and manage the level of risk inherent when transferring information and physical and virtual assets between the organisation and their suppliers. Organisations should map out each stage of the transfer process and educate staff as to the risks associated with moving assets and information from one source to another.

13) Ensure that supplier relationships are terminated with information security in mind, including removing access rights and the ability to access organisational information. Organization should have a clear understanding of how to revoke a supplier’s access to information, including:

• Granular analysis of any associated domain and/or cloud-based accounts.
• Distribution of intellectual property.
• The porting of information between suppliers, or back to your organisation.
• Records management.
• Returning assets to their original owner.
• Adequate disposal of physical and virtual assets, including information.
• Adherence to any contractual requirements, including confidentiality clauses and/or external agreements.

14) Outline precisely how you expect the supplier to conduct themselves regarding physical and virtual security measures. Organisations should set clear expectations from the outset of any commercial relationship, that specify how supplier-side personnel are expected to conduct themselves when interacting with your staff or any relevant assets.

Modern enterprises have swiftly adopted cloud-based services for their business operations. If they haven’t done so already, they’re rapidly integrating such services. ISO defines Cloud services as “One or more capabilities offered via cloud computing invoked using a defined interface.” and Cloud Computing as ” Paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand. Examples of resources include servers, operating systems, networks, software, applications, and storage equipment.” Organizations place their trust in cloud providers to ensure a secure environment. Unfortunately, that approach has numerous problems — namely that cloud providers don’t always know the risk associated with a customer’s systems and data. They don’t have visibility into other components in the customer’s ecosystem and the security requirements of those components. Failing to take ownership of cloud security is a serious downfall that could lead organizations to suffer data loss, system breaches and devastating attacks. This control provides guidance and references for acquiring, using, managing, and exiting third-party cloud services. This control requires an organization to define the roles and responsibilities of the cloud service provider and understand who is responsible for what. When organizations opt for cloud services, such engagements can involve shared responsibilities for information security. This results in a collaborative effort between the cloud service customer (i.e., organization) and the cloud service provider. The roles and responsibilities of both parties must be defined clearly. A cloud service customer does not have negotiation powers, as cloud service agreements are pre-defined and offered in a ‘take it-or leave it’ manner. For all possible cloud services an organization has availed, it must review relevant contracts to understand the distribution of risks related to cloud services between the service provider and the customer.

Control

Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements.

Purpose

To specify and manage information security for the use of cloud services.

ISO 27002 Implementation Guidance

The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties. The organization should define and communicate how it intends to manage information security risks
associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties. The use of cloud services can involve shared responsibility for information security and collaborative effort between the cloud service provider and the organization acting as the cloud service customer. It is essential that the responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are defined and implemented appropriately. The organization should define:

1. all relevant information security requirements associated with the use of the cloud services;
2. cloud service selection criteria and scope of cloud service usage;
3. roles and responsibilities related to the use and management of cloud services;
4. which information security controls are managed by the cloud service provider and which are managed by the organization as the cloud service customer;
5. how to obtain and utilize information security capabilities provided by the cloud service provider;
6. how to obtain assurance on information security controls implemented by cloud service providers;
7. how to manage controls, interfaces and changes in services when an organization uses multiple cloud services, particularly from different cloud service providers;
8. procedures for handling information security incidents that occur in relation to the use of cloud services;
9. its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage information security risks;
10. how to change or stop the use of cloud services including exit strategies for cloud services.

Cloud service agreements are often pre-defined and not open to negotiation. For all cloud services, the organization should review cloud service agreements with the cloud service provider(s). A cloud service agreement should address the confidentiality, integrity, availability and information handling requirements of the organization, with appropriate cloud service level objectives and cloud service qualitative objectives. The organization should also undertake relevant risk assessments to identify the risks associated with using the cloud service. Any residual risks connected to the use of the cloud service should be clearly identified and accepted by the appropriate management of the organization. An agreement between the cloud service provider and the organization, acting as the cloud service customer, should include the following provisions for the protection of the organization’s data and availability of services:

1. providing solutions based on industry accepted standards for architecture and infrastructure;
2. managing access controls of the cloud service to meet the requirements of the organization;
3. implementing malware monitoring and protection solutions;
4. processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction;
5. providing dedicated support in the event of an information security incident in the cloud service environment;
6. ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted);
7. supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions;
8. providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service;
9. providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer;
10. providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service.

The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including:
a) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering;
b) processing or storing information in a new geographical or legal jurisdiction;
c) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties).
The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements.

Other information

This control considers cloud security from the perspective of the cloud service customer. Additional information relating to cloud services can be found in ISO 17788, ISO 17789 and ISO 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO 19941. Specifics related to information security and public cloud services are described in ISO 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO 27018. Supplier relationships for cloud services are covered by ISO 27036-4 and cloud service agreements and their contents are dealt with in the ISO 19086 series, with security and privacy specifically covered by ISO 19086-4.

This control outlines the processes that are required for the acquisition, use, management of and exit from cloud services, in relation to the organisation’s unique information security requirements.When an organization avails of a cloud service, the service provider signs an agreement with the organization that specifies the nature of service, terms and conditions, and service level agreements, among other important information. This agreement must specify the controls for which the service provider is responsible and the controls for which the organization is responsible. It should also include roles and responsibilities related to the usage of cloud services, along with detailed information on using, changing, or stopping cloud services. It allows organisations to first specify then subsequently manage and administer information security concepts as related to cloud services, in their capacity as a “cloud services customer”.It contains a host of procedures that encompass many distinct elements of an organisation’s operation. Compliance involves adhering to what’s known as a ‘topic-specific’ approach to cloud services and information security. Given the variety of cloud services on offer, topic-specific approaches encourage organisations to create cloud services policies that are tailored towards individual business functions, rather than adhering to a blanket policy that applies to information security and cloud services across the board. Adherence to Control is a collaborative effort between the organisation and their cloud service partner. Control should also be closely aligned with information management in the supply chain and the management of supplier services . However an organisation chooses to operate, this control should not be taken in isolation and should complement existing efforts to manage supplier relationships. With information security at the forefront, the organisation should define:

• Any relevant security requirements or concerns involved in the use of a cloud platform.
• The criteria involved in selecting a cloud services provider, and how their services are to be used.
• Granular description of roles and relevant responsibilities that govern how cloud services areto be used across the organisation.
• Precisely which information security areas are controlled by the cloud service provider, and those that fall under the remit of the organisation themselves.
• The best ways in which to first collate then utilise any information security-related service components provided by the cloud service platform.
• How to obtain categorical assurances on any information security-related controls enacted by the cloud service provider.
• The steps that need to be taken in order to manage changes, communication and controls across multiple distinct cloud platforms, and not always from the same supplier.
• Incident Management procedures that are solely concerned with the provision of cloud services.
• How the organisation expects to manage its ongoing use and/or wholesale adoption of cloud platforms, in-line with their broader information security obligations.
• A strategy for the cessation or amendment of cloud services, either on a supplier-by-supplier basis, or through the process of cloud to on-premise migration.

In addition to the potential for data breaches and lack of visibility,the most common cloud security challenges are:

• misconfigurations and inadequate change controls;
• lack of cloud security architecture and strategy;
• insufficient identity, credential, access and key management;
• account hijacking;
• insecure interfaces and APIs; and
• abuse and nefarious use of cloud services.

The fallout from the cloud attack is often exponential For example, an attack on a single user’s credentials reaches far
beyond the targeted victim, often affecting the entire organization and its customers. To prevent cloud attack the organization can:

• vet and oversee potential providers;
• inspect provider security model
• deploy enhanced authentication, such as multifactor authentication (MFA), where possible;
• encrypt data in motion and at rest in the cloud;
• patch consistently
• utilize manual and automatic methods to discover and inventory cloud assets.
• Manage access

Steps to Create Cloud Security Policy

Step 1: Account for Relevant Laws
If company must adhere to some privacy or compliance regulation,All cloud-based activities must conform to legal obligations.

Step 2: Assess the Security Controls of the Cloud Vendor
Different providers offer different levels of security control. Inspect Provider’s security practices and form solutions that align with the offering.

Step 3: Assign Roles and Access Rights
Specify clear roles for personnel and set their access to applications and data. Give employees access only to the assets they need to perform their tasks. Additionally, define how your company logs and reviews access.

Step 4: Protect Data
Determine how to protect company data. Most businesses choose to encrypt all sensitive data moving through the cloud and the Internet. The policy must document security rules for internal and external data stores. Typically, providers offer Application Program Interfaces (APIs) as part of their services. Consider using an API to enforce encryption and Data Loss Prevention (DLP) policies.

Step 5: Defend the Endpoints
A single infected endpoint can lead to data breaches in multiple clouds. Therefore, there must be a set clear rules surrounding connections with the cloud to avoid this issue. This step includes secure sockets layers (SSLs), network traffic scanning, and monitoring rules.

Step 6: Define Responses
A policy must not only cover prevention. Consider ideal ways for teams to handle data breaches, outline reporting processes, and specify forensic functions. It also helps if you establish protocols for disaster recovery.

Step 7: Ensure Good Integrations
Integrate properly multiple safety solutions. Poorly combined solutions create vulnerabilities, so find a way to integrate and leverage your company’s security devices.

Step 8: Perform Security Audits
Conduct regular reviews and upgrade components to remain ahead of the latest threats. Also, perform routine checks of the vendor’s SLAs .

Information and Communication Technology (ICT) has become an integral part of many of the activities which are elements of the critical infrastructures in all organisational sectors, whether public, private or voluntary. The proliferation of the Internet and other electronic networking services, and today’s capabilities of systems and applications, has also meant that organisations have become ever more reliant on reliable, safe and secure ICT infrastructures. Meanwhile, the need for business continuity , including incident preparedness, disaster recovery planning, and emergency response and management, has been recognized. Failures of ICT services, including the occurrence of security issues such as systems intrusion and malware infections, will impact the continuity of business operations. Thus managing ICT and related continuity and other security aspects form a key part of business continuity requirements. Furthermore, in the majority of cases, the critical business functions that require business continuity are usually dependent upon ICT. This dependence means that disruptions to ICT can constitute strategic risks to the reputation of the organisation and its ability to operate. ICT readiness is an essential component for many organisations in the implementation of business continuity and Information security. It is critical to develop and implement a readiness plan for ICT services to help ensure business continuity. As a result, effective Business Continuity is frequently dependent upon effective ICT readiness to ensure that the organisation’s objectives can continue to be met in times of disruptions. This is particularly important as the consequences of disruptions to ICT often have the added complication of being invisible and/or difficult to detect. In order for an organisation to achieve ICT Readiness for Business Continuity , it needs to put in place a systematic process to prevent, predict and manage ICT disruption and incidents which have the potential to disrupt ICT services.

Control

ICT readiness should be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.

Purpose

To ensure the availability of the organization’s information and other associated assets during disruption.

ISO 27002 Implementation Guidance

ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption. The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services. The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption. Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes. The organization should ensure that:
a) an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence.
b) ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are:
1) regularly evaluated through exercises and tests.
2) approved by management;
c) ICT continuity plans include the following ICT continuity information:
1) performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA.
2) RTO of each prioritized ICT service and the procedures for restoring those components.
3) RPO of the prioritized ICT resources defined as information and the procedures for restoring the information.

Other information

Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to:
a) respond and recover from disruption to ICT services regardless of the cause.
b) ensure continuity of prioritized activities are supported by the required ICT services.
c) respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services.

Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031. Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317.

“ICT readiness for business continuity” defines the business continuity management requirements for information security in much more specific terms. The control includes the availability requirements based on the results of the Business Impact Analysis (BIA). Two key elements of disaster recovery are addressed. When assessing the Business Impact Analysis, the following points must be considered:

Recovery Time Objective (RTO) – How long can a business process/system be down? The Recovery Time Objective is the time taken from the moment of damage until business processes are fully restored (recovery of: Infrastructure – Data – Reprocessing of data – Resumption of activities) may elapse. The time period can vary from 0 minutes (systems must be available immediately) to several days (in some cases weeks).

Recovery Point Objective (RPO) – How much data loss can be accepted? The Recovery Point Objective is the time period between two backups, i.e. how much data/transactions can be lost between the last backup and the system failure. If no data loss is acceptable, the RPO is 0 seconds.

Based on the results of the BIA, contingency strategies are to be defined for the ICT resources with contingency options before during and after interruptions. Based on these strategies, contingency plans are to be developed, implemented and tested. In doing so, it is required that the organization

• implement an adequate organizational structure to deal with business interruptions,
• have ICT contingency plans that are regularly tested and approved by management,
• have ICT plans that include performance and capacity specifications to meet the requirements from the BIA, as well as RTOs and RPOs.

ICT Readiness for Business Continuity can be achieved by

• Protect—Protecting the ICT environment from environmental failures, hardware failures, operations errors, malicious attack and natural disasters is critical to maintaining the desired levels of system availability for an organization.
• Detect—Detecting incidents at the earliest opportunity minimizes the impact to services, reduces the recovery efforts and preserves the quality of service.
• React—Reacting to an incident in the most appropriate manner leads to a more efficient recovery and minimizes any downtime. Reacting poorly can result in a minor incident escalating into something more serious.
• Recover—Identifying and implementing the appropriate recovery strategy will ensure the timely resumption of services and maintain the integrity of data. Understanding the recovery priorities allows the most critical services to be reinstated first. Services of a less-critical nature may be reinstated at a later time or, in some circumstances, not at all.
• Operate—Operating in disaster recovery mode until return to normal is possible may require some time and necessitate “scaling up” disaster recovery operations to support increasing business volumes that need to be serviced over time.
• Return—Devising a strategy for every IT continuity plan allows an organization to migrate back from disaster recovery mode to a position in which it can support normal business.

ICT Readiness for Business Continuity supports Business Continuity Management by ensuring that the ICT services are as resilient as appropriate and can be recovered to pre-determined levels within timescales required and agreed by the organisation. This control enables an organisation to measure its ICT continuity, security and hence readiness to survive a disaster in a consistent and recognized manner. ICT readiness encompasses preparing the organisation’s ICT (i.e. the IT infrastructure, operations and applications), plus the associated processes and people, against unforeseeable events that could change the risk environment and impact ICT and business continuity. It also helps in leveraging and streamlining resources among business continuity, disaster recovery, emergency response and ICT security incident response and management activities. ICT readiness reduces the impact (meaning the extent, duration and/or consequences) of information security incidents on the organisation. ICT readiness is important for business continuity purposes because:

1. ICT is prevalent and many organisations are highly dependent on ICT supporting critical business processes;
2. ICT also supports incident, business continuity, disaster and emergency response, and related management processes;
3. Business continuity planning is incomplete without adequately considering and protecting ICT availability and continuity.

Processes and procedures created through Control should be drafted following a thorough BIA, that considers how an organisation needs to react when experiencing operational disruption. A BIA should make use of differing impact types and organisation-specific variables to gauge how business continuity will be affected, should any or all products and services be rendered unavailable or inoperable, due to any level of disruption. Organisations should use two key variables to formulate an agreed-upon RTO, that sets clear goals for resumption of normal operations:

1. the magnitude of the disruption
2. the type of disruption experienced

Within their BIA, organisations should be able to specify precisely what ICT services and functions are required to achieve recovery, including individual performance and capacity requirements. Organisations should undergo a risk assessment that evaluates their ICT systems and forms the basis of an ICT continuity strategy (or strategies) that bolsters recovery prior to, during and following a period of disruption. Once a strategy has been agreed, specific processes and plans should be put in place to ensure that ICT services are resilient and adequate enough to contribute towards recovery of critical processes and systems, before, during and after disruption. Within the scope of ICT continuity plans,it outlines three main guidance points:

1. ICT incidents often require quick decisions to be made relating to information security by senior members of staff, in order to expedite recovery.
2. Organisations need to maintain a robust chain of command that includes competent individuals with the ability to make authoritative decisions on technical matters related to business continuity and RTO adherence.
3. Organisational structures need to be up to date and widely communicated, to facilitate adequate communication and speed up recovery times.

ICT continuity plans should be given a great deal of attention, including regular testing and evaluations, and approval by senior management. Organisations should conduct test runs to gauge their effectiveness, and measure key metrics such as response and resolution times. ICT continuity plans should contain the following information:

1. performance and capacity requirements of any systems or processes used in recovery efforts
2. a clear RTO for each ICT service in question, and how the organisation aims to restore them
3. a recovery point objective (RPO) is designated for each ICT resource, and procedures are created that ensure information is able to be restored.

The benefits of ICT readiness for business continuity

• Understands the risks to continuity of ICT services and their vulnerabilities
• Identifies the potential impacts of disruption to ICT services
• Encourages improved collaboration between its business managers and its ICT service providers (internal and external)
• Develops and enhances competence in its ICT staff by demonstrating credible responses through exercising ICT continuity plans and testing IRBC arrangements
• Provides assurance to top management that it can depend upon predetermined levels of ICT services and receive adequate support and communications in the event of a disruption
• Provides assurance to top management that information security (confidentiality, integrity and availability) is properly preserved, ensuring adherence to information security policies
• Provides additional confidence in the business continuity strategy through linking investment in IT solutions to business needs and ensuring that ICT services are protected at an appropriate level given their importance to the organization

Documented procedures for operating information processing and communications facility activities should be prepared including computer start-up and closing down, backup, maintenance of equipment, media handling, computer room and mail management, and safety. Operating procedures must be documented and readily available to the teams for which they have relevance. These procedures should cover methods that reduce the likelihood of introducing or enhancing risks due to accidental or ill-advised changes. Before authoring documentation, it is often very important to identify up-front who the intended audience is. For instance, documentation that is intended to have value for new hires (continuity) often requires a greater degree of detail than steps for staff who regularly perform operations tasks. It is very important that operating procedures be treated as formal documents that are maintained and managed with version and approval processes and controls in place. As technology and our systems infrastructure changes, it is an absolute certainty that operational procedures will become out of date or inaccurate. By adopting formal documentation and review processes, we can help reduce the likelihood of outdated procedures that bring forth their own risks — loss of availability, failure of data integrity, and breaches of confidentiality. This control deals with the concept of information security as an operational activity, with its constituent elements being carried out and/or managed by one or more individuals. and outlines a series of operational procedures that ensure an organisation’s information security facility remains efficient and secure, and in line with their documented requirements.

Control

Operating procedures for information processing facilities should be documented and made available to personnel who need them.

Purpose

To ensure the correct and secure operation of information processing facilities.

ISO 27002 Implementation Guidance

Documented procedures should be prepared for the organization’s operational activities associated with information security, for example:

• when the activity needs to be performed in the same way by many people.
• when the activity is performed rarely and when next performed the procedure is likely to have been forgotten.
• when the activity is new and presents a risk if not performed correctly.
• prior to handing over the activity to new personnel.

The operating procedures should specify:

1. the responsible individuals.
2. the secure installation and configuration of systems.
3. processing and handling of information, both automated and manual.
4. backup and resilience.
5. scheduling requirements, including inter dependencies with other systems.
6. instructions for handling errors or other exceptional conditions (e.g. restrictions on the use of utility programs) which can arise during job execution
7. support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties
8. storage media handling instructions
9. system restart and recovery procedures for use in the event of system failure
10. the management of audit trail and system log information and video monitoring systems
11. monitoring procedures such as capacity, performance and security
12. maintenance instructions.

Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities.

Operating procedures must be documented and then made available to all users who need them. Documented operating procedures help to ensure consistent and effective operation of systems for new staff or changing resources, and can often be critical for disaster recovery, business continuity and for when staff availability is compromised. Where information systems are “cloud-based” traditional operational activities such as system start-up, shut-down, backup etc become less relevant and may often be outsourced to a cloud provider. In more traditional computing environments and architectures operating procedures are much more likely to be required. It is important that documents are maintained in a correct and current state and should therefore be subject to formal change management and periodic review procedures – this is key, as the auditor will be specifically looking to see this. We often get asked about how much detail is needed, and what areas of the business need to have documented procedures. Take a common sense approach. For example, if you have real staff stability, the implicit procedures are very well understood and resilience is in place across that resource pool, simple bullet points may be enough to form a checklist style documented procedure.

Similarly if procedures are evolving or regularly changing e.g. because of fast growth you want to have procedures that can be easily and quickly updated too. Again if lots of new resource is being added and the area has risk and complexity around it, then more depth to the procedures may be needed so it is unambiguous about what, when, how, who etc. The areas of the business that need to be considered for documented procedures should be where your information assets are at risk through incorrect operation, which of course will be identified as part of the risk assessment . That might include software development, IT management, through to financial accounting, customer management, consulting or manufacturing work etc depending on the nature of the business.

What should we document?

The decision on what areas deserve documentation must be informed by an understanding of organizational risks including issues that have previously been observed. However a good list of items to consider include the following items:

• Configuration and build procedures for servers, networking equipment, and desktops.
• Automated and Manual Information Processing
• Backup procedures
• System scheduling dependencies
• Error handling
• Change Management Processes
• Capacity Management & Planning Processes
• Support and escalation procedures
• System Restart and Recovery
• Special Output
• Logging & Monitoring Procedures
• Any individuals responsible – both incumbents and new operators.
• A set of guidelines that maintain security during the installation and subsequent configuration of any related business systems.
• How information is processed throughout the activity.
• BUDR plans and implications, in the event of data loss or a major event
• Linked dependencies with any other systems, including scheduling.
• A clear procedure for dealing with “handling errors” or miscellaneous events that have the potential to occur
• A full list of personnel to be contacted in the event of any disruption, including clear escalation procedures.
• How to operate any relevant storage media associated with the activity.
• How to reboot and recover from a system failure.
• Audit trail logging, including all associated event and system logs.
• Video monitoring systems that monitor onsite activities .
• A robust set of monitoring procedures that cater to the operational capacity, performance potential and security of said activity.
• How the activity should be maintained, in order to be kept at optimal performance levels.

All of the above procedures should be subject to periodic and/or ad-hoc reviews, as and when required, with all changes being ratified by Management in a timely manner to safeguard information security activity across the organisation.ocedures and documented procedures for system operations should be treated as managerial authorized formal documents and alterations. Where technically feasible, IT systems should be consistently administered using the same procedures, tools, and utilities.

According to ISO, Personally Identifiable Information is defined as “any information that (a) can be used to establish a link between the information and the natural person to whom such information relates, or (b) is or can be directly or indirectly linked to a natural person.” The “natural person” in the definition is the PII principal . To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to establish the link between the set of PII and the natural person. A public cloud PII processor is typically not in a position to know explicitly whether information it processes falls into any specified category unless this is made transparent by the cloud service customer. ISO defines PII principal as “natural person to whom the personally identifiable information (PII) relates”. Depending on the jurisdiction and the particular PII protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”. Personal Identifiable Information (PII) is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. PII directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or identify specific individuals in conjunction with other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors). Additionally, information permitting the physical or online contacting of a specific individual is the same as personally identifiable information. This information can be maintained in either paper, electronic or other media. The loss of PII can result in substantial harm to individuals, including identity theft or other fraudulent use of the information.

Control

The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements.

Purpose

To ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII.

ISO 27002 Implementation Guidance

The organization should establish and communicate a topic-specific policy on privacy and protection of PII to all relevant interested parties. The organization should develop and implement procedures for the preservation of privacy and protection of PII. These procedures should be communicated to all relevant interested parties involved in the processing of personally identifiable information. Compliance with these procedures and all relevant legislation and regulations concerning the preservation of privacy and protection of PII requires appropriate roles, responsibilities and controls. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to personnel, service providers and other interested parties on their individual responsibilities and the specific procedures that should be followed. Responsibility for handling PII should be dealt with taking into consideration relevant legislation and regulations. Appropriate technical and organizational measures to protect PII should be implemented.

Other information

A number of countries have introduced legislation placing controls on the collection, processing, transmission and deletion of PII. Depending on the respective national legislation, such controls can impose duties on those collecting, processing and disseminating PII and can also restrict the authority to transfer PII to other countries. ISO 29100 provides a high-level framework for the protection of PII within ICT systems. Further information on privacy information management systems can be found in ISO 27701. Specific information regarding privacy information management for public clouds acting as PII processors can be found in ISO 27018. ISO 29134 provides guidelines for privacy impact assessment (PIA) and gives an example of the structure and content of a PIA report. Compared with ISO 27005, this is focused on PII processing and relevant to those organizations that process PII. This can help identify privacy risks and possible mitigation to reduce these risks to acceptable levels.

PII forms a key part of an organisation’s data governance strategy, and carries a number of unique regulatory, legislative and contractual risks. A good control describes how privacy and protection of personally identifiable information is assured for relevant legislation and regulation. Any information handled that contains personally identifiable information (PII) is likely to be subject to the obligations of legislation and regulation. PII is especially likely to have high requirements for confidentiality and integrity, and in some cases availability as well (e.g. health information, financial information). This control deals with PII in three distinct ways Preservation, Privacy,Protection. Under some legislation (e.g. the GDPR) some types of PII are defined as additionally “sensitive” and require further controls to ensure compliance. It is important that awareness campaigns are used with staff and stakeholders to ensure a repeated understanding of individual responsibility for protecting PII and privacy. Organisations should treat PII as a topic-specific business function, and develop policies that are unique to their organisation, and the categories of PII that are most common to their day-to-day operation. First and foremost, the organisation should draft, develop and implement a series of policies that cater to the preservation, privacy and protection of PII, and ensure these are communicated to and used by all employees that process PII – not just those who are obligated to deal with it as part of their job roles. PII needs to be managed in a structured, clear and concise manner. To achieve this Control asks organisations to draft policies that consider individual roles, responsibilities and data controls throughout their organisation. The easiest and most efficient way to achieve this is to adopt a top-down approach that features a Privacy Officer, whose job it is to provide guidance to employees and third-party organisations on the subject of PII, and offer advice to senior management on how to remain compliant with the organisation’s obligations. Alongside regulatory, legislative and contractual guidelines, an organisation should also implement technical and operational measures that deal with the practical handling of PII as it’s stored by and flows through the business. The auditor will be looking to see how PII is handled, if the appropriate controls have been implemented, are being monitored, reviewed and where necessary improved. They will also be looking to check that handling requirements are being met and audited suitably. Additional responsibilities exist too, for example, GDPR will expect a regular audit for areas where personal data is at risk. Smart organizations will tie these audits up alongside their ISO 27001 audits and avoid duplication or gaps.

As organizations continuously collect, store and distribute PII and other sensitive data, employees, administrators and third-party contractors need to understand the repercussions of mishandled data and be held accountable.It is the responsibility of the individual employee to protect data to which they have access. Employee having access to personal information must respect the confidentiality of such information, and refrain from any conduct that would indicate a careless or negligent attitude toward such information. They must avoid office gossip and should not permit any unauthorized viewing of records containing PII. Only individuals who have a “need to know” in their official capacity shall have access to such systems of records.Predictive analytics and artificial intelligence (AI) are in use at organizations to sift through large data sets so that any data stored is compliant with all PII rules. Additionally, organizations establishing procedures for access control can prevent inadvertent disclosure of PII. Other best practices include using strong encryption, secure passwords, and two-factor (2FA) and multifactor authentication (MFA). Other recommendations for protecting PII are:

1. encouraging employees to practice good data backup procedures;
2. Safeguard information to which their employees have access at all times
3. Obtain management’s written approval prior to taking any sensitive information away from the office. The manager’s approval must identify the business necessity for removing such information from the facility.
4. safely destroying or removing old media with sensitive data
5. installing software, application and mobile updates
6. using secure wireless networks, rather than public Wi-Fi; and
7. using virtual private networks (VPNs).

According to ISO, Intellectual Property Rights is defined as “legal rights associated with intellectual property” and intellectual property is defined as “result of intellectual activities that is eligible for protection by law“. Intellectual property rights include copyright and related rights , trademarks, geographical indications, industrial design rights , patents, layout-designs (topographies) of integrated circuits and protection of undisclosed information. Intellectual property can include inventions, scientific discoveries, literary, scientific, or artistic works, symbols, designs, names, and images used in commerce, industrial designs, performances, recordings, broadcasts and other creative and industrial works. This control describes describes the steps organisations need to take to ensure compliance with intellectual property (IP) rights, including using proprietary software purchased, subscribed to, or leased from a third party. This control focuses more on obligations towards third parties whose intellectual property rights are covered by licence agreements, data sharing agreements, etc. rather then as an  IP holder. It is a preventive control that maintains risk by enforcing procedures that ensure that the business remains compliant with any prevailing IP or copyright requirements, including mitigating the risk that employees will not adhere to their own obligations. “Legal, statutory, regulatory or contractual” agreements often place restrictions on the use of proprietary software, including restrictions on copying, extracting, or reverse-engineering the source code.

Control

The organization should implement appropriate procedures to protect intellectual property rights.

Purpose

To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products.

ISO 27002 Implementation Guidance

The following guidelines should be considered to protect any material that can be considered intellectual property:
a) defining and communicating a topic-specific policy on protection of intellectual property rights;
b) publishing procedures for intellectual property rights compliance that define compliant use of software and information products;
c) acquiring software only through known and reputable sources, to ensure that copyright is not infringed upon;
d) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights;
e) maintaining proof and evidence of ownership of licences, manuals, etc.;
f) ensuring that any maximum number of users or resources [e.g. central processing units (CPUs)] permitted within the licence is not exceeded;
g) carrying out reviews to ensure that only authorized software and licensed products are installed;
h) providing procedures for maintaining appropriate licence conditions;
i) providing procedures for disposing of or transferring software to others;
j) complying with terms and conditions for software and information obtained from public networks and outside sources;
k) not duplicating, converting to another format or extracting from commercial recordings (video, audio) other than permitted by copyright law or the applicable licences;
l) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences.
Other information
Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licences. Proprietary software products are usually supplied under a licence agreement that specifies licence terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. See the ISO/IEC 19770 series for details about IT asset management.
Data can be acquired from outside sources. It is generally the case that such data is obtained under the terms of a data sharing agreement or similar legal instrument. Such data sharing agreements should make it clear what processing is permitted for the acquired data. It is also advisable that the provenance of the data is clearly stated. See ISO/IEC 23751:—1) for details about data sharing agreements. Legal, statutory, regulatory and contractual requirements can place restrictions on the copying of proprietary material. In particular, they can require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which can involve fines and criminal proceedings. Aside from the organization needing to comply with its obligations towards third party intellectual property rights, the risks of personnel and third parties failing to uphold the organization’s own intellectual property rights should also be managed.

Intellectual Property (IP) rights are a dominant issue at any Organizations. Organizations may have many different types of research and proprietary information that can be protected via these rights. These rights are also attached to the different technologies that the organization might buy or license from others (and the rights are then protected via contract provisions).Copyright and/or IP infringement can lead to severe financial & legal consequences for any organisation that willfully or unwittingly breaches an agreement. This should be given adequate consideration in order to avoid any unnecessary business interruptions or information security incidents. A good control describes how the appropriate procedures ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products. Put into simple terms, the organization should implement appropriate procedures which ensure it complies with all its requirements, whether they are legislative, regulatory or contractual – related to its use of software products or intellectual property rights. Policies, processes and technical controls are likely to be needed for both of these aspects. Within asset registers and acceptable use policies it is likely that IPR considerations will need to be made – e.g. where an asset is or contains IPR protection of this asset must consider the IPR aspect. Controls to ensure that only authorized and licensed software are in use within the organization should include regular inspection and audit. The auditor will want to see that registers of licenses owned by the organization for use of others’ software and other assets are being kept and updated. Of particular interest to them will be ensuring that where licenses include a maximum number of users or installations, that this number is not exceeded and user and installation numbers are audited periodically to check compliance. The auditor will also be looking at how the organization protects its own IPR, which might include; Data loss and prevention controls; Policies and awareness program targeting user education; or Non-disclosure and confidentiality agreements that continue post-termination of employment. Appropriate controls to identify and protect intellectual property include:

• An intellectual property rights compliance policy (which meets copyright policy requirements of certain laws);
• Ensuring proper use of software and other technology licenses;
• Education and awareness on respecting IP rights;
• Keeping track of IP assets.

Organisations should consider the following guidelines when safeguarding data, software, or assets that might be regarded as intellectual property:

• Protecting IP rights on a case-by-case basis, in accordance with their unique operational requirements by implementing a “topic-specific” policy.
• To remain compliant with IP standards, publish and communicate procedures that categorically define how software and ICT products should be operated.
• To avoid any inadvertent copyright breaches, acquire software from reputable sources.
• Identification of ICT assets with IP requirements using an organisational asset register.
• The organisation should be able to provide proof of ownership at any time, including physical and electronic licensing documents, communications, and files.
• Complying with software usage limits, including concurrent users, virtual resources and more.
• Through periodic reviews, ensure the organisation’s ICT estate doesn’t contain any unlicensed or unauthorised software.
• Keep licenses up-to-date through operational and financial procedures.
• Provide safe, responsible, and legally compliant practices for the transfer or disposal of software assets.
• Ensure that any software acquired from the public domain complies with the terms and conditions and fair use guidelines.
• Any commercial recordings used by the organisation may not be extracted, copied, converted, or manipulated in any way that is not specified within the software’s terms and conditions (including licensing) or by prevailing copyright laws.
• Observing and respecting the copyright laws or licensing terms of textual data, such as standards, books, articles, and reports.