Checklist for Standard ISO/IEC 27018:2014

Overview of the base standard ISO/IEC 27018:2014

ISO/IEC 27018 establishes commonly accepted control objectives, controls and guidelines for implementing measures to protect Personally Identifiable Information (PII) in accordance with the privacy principles in ISO/IEC 29100 for the public cloud computing environment.

ISO/IEC 27018 specifies guidelines based on ISO/IEC 27002, taking into consideration the regulatory requirements for the protection of PII which might be applicable within the context of the information security risk environment(s) of a provider of public cloud services.

ISO/IEC 27018 is applicable to all types and sizes of organizations, including public and private companies, government entities, and not-for-profit organizations, which provide information processing services as PII processors via cloud computing under contract to other organizations.

The guidelines in ISO/IEC 27018 might also be relevant to organizations acting as PII controllers; however, PII controllers can be subject to additional PII protection legislation, regulations and obligations, not applying to PII processors. ISO/IEC 27018 is not intended to cover such additional obligations.

Annex A to ISO/IEC 27018:2014 specifies new controls and associated implementation guidance which, in combination with the augmented controls and guidance in ISO/IEC 27002, make up an extended control set to meet the requirements for PII protection which apply to public cloud service providers acting as PII processors. These additional controls are classified according to the 11 privacy principles of ISO/IEC 29100.

Purpose of this standard

More companies are going to the Cloud each day. The “cloud” offers organizations a variety of benefits: cost savings, flexibility and mobile access to information. However, it also raises concerns about data protection and privacy; particularly around personally identifiable information (PII). PII includes any piece of information that can identify a specific user. The more obvious examples include names and contact details or your mother’s maiden name. The cloud processor also has high risk. Security must be extremely high especially if you have a subcontractor doing part of the work. If this data is compromised it could cost a company, customers, money and reputation

Relationship to other 27000 Standards

If a PII processor wants to become certified to ISO/IEC 27001 – Information Security – Requirements then it should assess its practices using ISO/IEC 27002 – Information Security – Code of Practice. In addition, there are specific controls specified in ISO/IEC 27018 that need to be addressed. If a PII processor is not interested in certification the requirements and guidelines in these three standards should be an important part of business considerations.

SEPT provides checklists for all three standards to assist in understanding the requirements and related practices.

Purpose of the SEPT checklist

The task of getting information security under control is daunting. The last thing an organization wants in its security management operation is to call in a Notified Body for certification and to find out that the organization is lacking the correct records or documents for the auditor to examine. If you do not read the standard correctly it could cause a security problem or could increase the cost to become certified. That is why we believe a checklist is important.

For 20 + years (SEPT) Software Engineering Process Technology has been producing checklists for standards that address software issues. To reduce this fog surrounding these types of standards SEPT has been producing checklists for standards since 1994. This is another checklist software related standard for the IT industry that will aid an organization’s compliance with an international information security code of practice. The first step that an organization has in meeting the guidance of an information security management standard such as Standard ISO/IEC 27018:2014 is to determine what is required and what is suggested. Often these systems and technical standards are confusing and laborious because the directions contained in the standards are unclear to a lay person. The checklists lift this fog around a standard and state what is required and suggested by the standard in a clear and concise manner. To aid in determining what is “required” by the document in the way of physical evidence of compliance, the experts at SEPT have produced this checklist. The SEPT checklists are constructed around a classification scheme of physical evidence comprised of policies, procedures, plans, records, documents, audits, and reviews. There must be an accompanying record of some type when an audit or review has been accomplished. This record would define the findings of the review or audit and any corrective action to be taken. For the sake of brevity this checklist does not call out a separate record for each review or audit. All procedures should be reviewed but the checklist does not call out a review for each procedure, unless the standard calls out the procedure review. In this checklist, “manuals, reports, scripts and specifications” are included in the document category. In the procedure category guidelines are included when the subject standard references another standard for physical evidence, the checklist does not call out the requirements of the referenced standard.

Since ISO/IEC 27018 is a guidance standard we have departed from our usual practice by making “should” a requirement (R) of the guidelines (no “shall” is specified) and “may” a suggested (S) item. This enables a distinction to be made regarding the more important considerations (“should”).

The authors have carefully reviewed the Standard ISO/IEC 27018:2014 and defined the physical evidence required based upon this classification scheme. SEPT’s engineering department has conducted a second review of the complete list to ensure that the documents’ producers did not leave out a physical piece of evidence that a “reasonable person” would expect to find. It could certainly be argued that if the document did not call it out then it is not required; however, if the standard was used by an organization to improve its process, then it would make sense to recognize missing documents. Therefore, there are documents specified in this checklist that are implied by the standard, though not specifically called out by it, and they are designated by an asterisk (*) throughout this checklist. If a document is called out more than one time, only the first reference is stipulated.

There are occasional situations in which a procedure or document is not necessarily separate and could be contained within another document. For example, the "Security Monitoring Log Information Record" could be a part of the "Security Monitoring and Operational Diagnostics Log Information Record." The authors have called out these individual items separately to ensure that the organization does not overlook any facet of physical evidence. If the organization does not require a separate document, and an item can be a subset of another document or record, then this fact should be denoted in the detail section of the checklist for that item. This should be done in the form of a statement reflecting that the information for this document may be found in section XX of Document XYZ. If the organizational requirements do not call for this physical evidence for a project, this should also be denoted with a statement reflecting that this physical evidence is not required and why. The reasons for the evidence not being required should be clearly presented in this statement. Further details on this step are provided in the Detail Steps section of the introduction. The size of these documents could vary from paragraphs to volumes depending upon the size and complexity of the project or business requirements.

Note: “International Standards (ISO) define the best of practices for Medical Device and Software firms in producing a quality product. This checklist that SEPT produces will ensure that all of the best of practices are adhered to.”