The objective of this control is to prevent unauthorized disclosure, modification, removal or destruction of information stored on media. In computers, a storage media are physical devices that receives and retains electronic data for applications and users and makes data available for retrieval. It might be inside a computer or other device or attached to a system externally, either directly or over a network. The singular form of this term is storage medium.Storage media comes in many different forms, among them:

1. Hard disk drives:It contains metal platters coated with a magnetic layer. The platters usually spin continuously when a computer is on, storing data in different sectors on the magnetic disk.
2. RAID: It works by placing data on multiple disks and balancing input/output (I/O) operations across those disks.
3. Flash memory:Here data is written to microchips, making storage operations much faster than traditional disks.
4. SSD :SSDs is both network-based storage — such as NAS and SAN — and direct-attached storage (DAS)
5. USB flash drives: A USB flash drive is a type of removable storage medium that attaches to a server or other device through a USB port.
6. Optical disc: Optical disc technology uses lasers to write and read data.
7. Tape: Tape was a dominant backup storage medium until the 1990s but was gradually pushed aside by magnetic disk.

Use of storage media devices such as solid-state drives (SSDs), USB sticks, external drives, and mobile phones are vital to many critical information processing operations such as data back-up, data storage, and information transfer. However, the storage of sensitive and critical information on these devices introduces risks to the integrity, confidentiality, and availability of information assets. These risks may include loss or theft of storage media containing sensitive information, propagation of malware into all corporate computing networks via the storage media, and failure and degradation of storage media devices used for data back-up. This Control addresses how organisations can establish appropriate procedures, policies, and controls to maintain the security of storage media throughout its life cycle, from its acquisition to its disposal.

Control

Storage media should be managed through their life cycle of acquisition, use, transportation and disposal in accordance with the organization’s classification scheme and handling requirements.

Purpose

To ensure only authorized disclosure, modification, removal or destruction of information on storage media.

ISO 27002 Implementation Guidance

Removable storage media

The following guidelines for the management of removable storage media should be considered:

1. establishing a topic-specific policy on the management of removable storage media and communicating such topic- specific policy to anyone who uses or handles removable storage media;
2. where necessary and practical, requiring authorization for storage media to be removed from the organization and keeping a record of such removals in order to maintain an audit trail;
3. storing all storage media in a safe, secure environment according to their information classification and protecting them against environmental threats (such as heat, moisture, humidity, electronic field or ageing), in accordance with manufacturers’ specifications;
4. if information confidentiality or integrity are important considerations, using cryptographic techniques to protect information on removable storage media;
5. to mitigate the risk of storage media degrading while stored information is still needed, transferring the information to fresh storage media before becoming unreadable;
6. storing multiple copies of valuable information on separate storage media to further reduce the risk of coincidental information damage or loss;
7. considering the registration of removable storage media to limit the chance for information loss;
8. only enabling removable storage media ports [e.g. secure digital (SD) card slots and universal serial bus (USB) ports] if there is an organizational reason for their use;
9. where there is a need to use removable storage media, monitoring the transfer of information to such storage media;
10. information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending storage media via the postal service or via courier.
11. In this control, media includes paper documents. When transferring physical storage media, apply security measures in control for information transfer

Secure reuse or disposal
Procedures for the secure reuse or disposal of storage media should be established to minimize the risk of confidential information leakage to unauthorized persons. The procedures for secure reuse or disposal of storage media containing confidential information should be proportional to the sensitivity of that information. The following items should be considered:

a) if storage media containing confidential information need to be reused within the organization, securely deleting data or formatting the storage media before reuse;
b) disposing of storage media containing confidential information securely when not needed anymore (e.g. by destroying, shredding or securely deleting the content);
c) having procedures in place to identify the items that can require secure disposal;
d) many organizations offer collection and disposal services for storage media. Care should be taken in selecting a suitable external party supplier with adequate controls and experience;
e) logging the disposal of sensitive items in order to maintain an audit trail;
f) when accumulating storage media for disposal, giving consideration to the aggregation effect, which can cause a large quantity of non-sensitive information to become sensitive.

A risk assessment should be performed on damaged devices containing sensitive data to determine whether the items should be physically destroyed rather than sent for repair or discarded .

Other information

When confidential information on storage media is not encrypted, additional physical protection of the storage media should be considered.

 This control enables organisations to eliminate and mitigate risks of unauthorized access to, use, deletion, modification, and transfer of sensitive information hosted on storage media devices by setting out procedures for the handling of storage media across its entire life cycle. It applies both to digital and physical storage media such as storage of information on physical files. It requires organisations to create and implement appropriate procedures, technical controls, and organisation-wide policies on the use of storage media based on the organisation’s own classification scheme and its data handling requirements such as legal and contractual obligations. Procedures must be put in place for the management of removable media in accordance with the classification scheme. General use of removable media must be risk assessed and it may be necessary to carry out use-specific risk assessments beyond that too. Removable media should only be allowed if there is a justified business reason. If no longer required, the contents of any re-usable media should be made unrecoverable and securely destroyed or erased. All media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications and additional techniques like cryptography considered where appropriate (i.e. as part of the risk assessment). Where necessary and practical, authorization should be required for media removed from the organisation, and a record kept in order to maintain an audit trail.

When no longer required media must be disposed of securely by following documented procedures. These procedures minimize the risk of confidential information leakage to unauthorized parties. The procedures should be proportional to the sensitivity of the information being disposed. Things that should be considered include; whether or not the media contains confidential information; and having procedures in place which help identify the items which might. require secure disposal. Any media containing information needs to be protected against unauthorized access, misuse or corruption during transportation (unless already publicly available). The following should be considered to protect media when being transported; Reliable transport or couriers should be used – perhaps a list of authorized couriers should be agreed with management; Packaging should be sufficient in order to protect the contents from any physical damage during transit; and Logs should be kept, identifying the content of the media and the protection applied.It should also be noted that when confidential information on media is not encrypted, additional physical protection of the media should be considered.

Equipment, information or software taken off-site needs management too. That might be controlled with some form of check in-out process or more simply associated to an employee as part of their role and managed in accordance with their terms and conditions of employment . In the ever mobile working world, some assets such as mobile devices, may be routinely removed from organisational premises to facilitate mobile or home working. Where assets are not designed to be routinely removed from site or if they are of a sensitive, highly classified, valuable or fragile nature then processes should be in place to request and authorize removal and to check return of the assets. Consideration for limiting the length of time assets are allowed to be removed for should be made and should be risk based. The auditor will be looking to see that these risk assessments have been carried out for when non-routine removal of assets occurs and for policies that determine what is and isn’t routine.

Management of Removable Media

Integrate necessary controls to manage media items, whether tapes, disks, flash disks, or removable hard drives, CDs, DVDs, or printed media, to ensure the integrity and confidentiality of university data. Guidelines should be developed and implemented to ensure that media are used, maintained, and transported in a safe and controlled manner. Handling and storage should correspond with the sensitivity of the information on the media. Procedures to erase media if no longer needed, to ensure information is not leaked, are also important. While removable storage media is essential to many business operations and they are commonly used by most personnel, they present the highest degree of risk to the sensitive information.The organisations should adhere to for the management of removable storage media throughout its life cycle:

• Organisations should establish a topic-specific policy on the acquisition, authorization, use, and disposal of removable storage media. This policy should be communicated to all personnel and to all relevant parties.
• If it is practical and necessary, organisations should put in place authorization procedures on how removable storage media can be taken out of corporate premises. Furthermore, organisations should maintain log records of the removal of storage media for audit trail purposes.
• All removable storage media should be stored in a secure area such as a safe, taking into account the information classification level assigned to the information and the environmental and physical threats to storage media.
• If confidentiality and integrity of information contained on removable storage media are of critical importance, cryptographic techniques should be used to protect the storage media against unauthorized access.
• Against the risk of degradation of removable storage media and loss of information stored on the media, the information should be transferred to a new storage media device before such risk occurs.
• Critical and sensitive information should be copied and stored on multiple storage media to minimize the risk of loss of critical information.
• To mitigate the risk of complete loss of information, registration of removable storage media devices can be an option to consider.
• Unless there is a business-related reason to use removable storage media ports such as USB ports or SD card slots, they should not be allowed.
• There needs to be a monitoring mechanism in place for the transfer of information to removable storage media devices.
• When information contained in physical mediums such as papers is transferred via courier or post, there is a high risk of unauthorized access to this information. Therefore, appropriate measures should be applied.

Secure Reuse or Disposal

Procedures for handling classified information should cover the appropriate means of its destruction and disposal. Serious breaches of confidentiality occur when apparently worthless disks, tapes, or paper files are dumped without proper regard to their destruction.Procedures for handling and storage of sensitive information, together with audit trails and records, are important. Accountability should be introduced and data classification and risk assessments performed, to ensure that necessary controls are applied to protect sensitive data. Appropriate access controls should be implemented to protect information from unauthorized disclosure or usage. Systems are also vulnerable to the unauthorized use of system documentation; much of this type of information should be regarded and handled as confidential. Security procedures, operating manuals, and operations records all come into this category.It provides separate guidance on secure reuse and disposal of storage media so that organisations can mitigate and eliminate risks to the compromise of the confidentiality of information. The organisations should define and apply procedures for the reuse and disposal of storage media, taking into account the sensitivity level of information contained in the storage media.

• If a storage media will be reused by an internal party within an organisation, the sensitive information hosted on that storage media should be irreversibly deleted or reformatted before it is authorised for reuse.
• Storage media hosting sensitive information should be destroyed in a secure manner when it is no longer needed. For instance, paper documents can be shredded and digital equipment can be physically destroyed.
• There should be a procedure for the identification of storage media items that need to be disposed of.
• When organisations choose to work with an external party to handle the collection and disposal of storage media, they should conduct due diligence to ensure that chosen vendor is competent and it implements appropriate controls.
• Maintaining a record of all disposed items for audit trail.
• When multiple storage media is to be disposed of together, the accumulation effect should be taken into account: Combining different information pieces from each storage media may transform non-sensitive information into sensitive information.
• Organisations must carry out a risk assessment on damaged equipment storing confidential information to decide if the equipment should be destroyed instead of being repaired.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

This part of the standard is concerned with corrective action requirements. You will need to show how you react to nonconformity, take action, correct them and deal with the consequences. You’ll also need to show whether any similar nonconformity exist or could potentially occur and show how you will eliminate the causes of them so they do not occur elsewhere. There is also a requirement to show continual improvement of the ISMS, including demonstrating the suitability and adequacy of it and how effective it is. However, you do this is up to you.

10.1 Continual improvement

The organization must continually improve the suitability, adequacy, and effectiveness of the information security management system.

Continual improvement is a key aspect of the ISMS in the effort to achieve and maintain the suitability, adequacy, and effectiveness of the information security as it relates to the organizations’ objectives. Organizations with operational ISMS’ must continually strive to improve their management system. This is fundamental to all management systems and an ISMS is no exception.
Improvements can come from a number of sources. These include:
• Internal audits;
• The output from Management reviews;
• External audits;
• Security incidents;
• Security reviews and testing;
• Suggestions, including those from interested parties.
Suggested improvements should be considered but do not need to be implemented. The organization selects those improvements it feels add value to the ISMS. Suggestions from internal and external auditors also do not need to be implemented but should be considered. Time frames for implementing agreed improvements are set by the organization.

10.2 Nonconformity and corrective action

When a nonconformity occurs, the organization must react to this nonconformity by taking action to control and correct it; and deal with the subsequent consequences. The organization must evaluate the need for action to eliminate the causes of nonconformity, in order that it does not recur or occur elsewhere, by reviewing the nonconformity, determining the causes of the nonconformity, and determining if similar nonconformities exist, or could potentially occur. The organization must implement any action needed. It must review the effectiveness of any corrective action taken and make changes to the information security management system, if necessary. The Corrective actions taken should be appropriate to the effects of the nonconformities encountered. The organization must keep a record of the nature of the nonconformities and any subsequent actions taken, and the results of any corrective action taken.

Outputs from management reviews, internal audits, and compliance and performance evaluation should all be used to form the basis for nonconformity and corrective actions. Once identified, a nonconformity or corrective action should trigger, if considered relevant, proper and systematic responses to mitigate its consequences and eliminate root causes, by updating processes and procedures, to avoid recurrence. The effectiveness of actions taken must be evaluated and documented, along with the originally reported information about the nonconformity / corrective action and the results achieved. ISO 27001 requires an organization to continually improve its ISMS. These improvements come from a number of activities. Corrective action is one mechanism to drive improvements and address weaknesses within the system. Corrective action is required by ISO 27001 when a non-conformance or deficiency is identified. The need for corrective action can arise from a number of ISMS activities. These include:

• Internal audits;
•  Management reviews;
•  External audits;
•  Security incidents;
•  Security reviews and testing.

Corrective Actions

• Corrective Action is required to address any deficiencies as per the agreed procedure
• Your agency specifies its timelines for response
• The only exception is issues raised by the certification bodies
• Operate on very specific time frames for correction of defects

The organization’s response to a need for corrective action is documented in some form of corrective action procedure. This procedure includes the requirement for root cause analysis to ensure that the non-conformance does not re-occur. The timeframe for response and implementation of corrective action is the choice of the organization, except for non-conformances raised by certification bodies. There are defined timeframes for the implementation of corrective action for any non-conformances raised during certification or surveillance audits.

One of the main drivers of improvement is to learn from security incidents, issues identified in audits, performance issues identified from monitoring, complaints from interested parties, and ideas generated at management reviews. For each learning opportunity identified you must maintain a record of:

• what occurred;
• if the event had undesirable consequences, what action was taken to contain and mitigate those;
• the root cause of the event (if determined);
• the action is taken to eliminate the root cause (if needed); and
• an assessment of the effectiveness of any action taken.

Root cause analysis
To identify effective corrective action, it is strongly advisable to complete a root cause analysis of the issue that occurred. If you don’t get to the bottom of why or how it happened, then it is likely that whatever fix you implement will not be fully effective. A simple approach such as “5 Whys” is a good root cause analysis tool:
start with the issue, then ask “Why” enough times to reach the root cause. Usually, 5 times of asking are enough, but for more complex problems you may need to dig deeper.
For example:
Problem statement:
The organization was infected by the bogus virus
Why?
Someone clicked on a link in an email and it downloaded the virus and infected their PC
Why?
They had not received any training in clicking on links in emails they are not expecting to receive
Why?
The training manager is on maternity leave and the organization has not implemented cover for them
Why?
The maternity leave process is not covered in the Change Management Procedure and so a risk assessment was not completed to identify any information security risks.

You may not have sufficient resources to undertake root cause analysis for every event. To prioritize your efforts, you should consider first completing a simple risk assessment of an event and then undertake root cause analysis only for those that are medium or high risk.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.

This clause is all about monitoring, measuring, analyzing, and evaluating your ISMS to ensure that it is effective and remains so. This clause helps organizations to continually assess how they are performing in relation to the objectives of the standard to continually improve. You will need to consider what information you need to evaluate the information security effectiveness, the methods employed, and when it should be analyzed and reported. Internal audits will need to be carried out as well as management reviews. Both of these must be performed at planned intervals and the findings will need to be retained as documented information. It should be noted that management reviews are also an opportunity to identify areas for improvement.

This clause of the standard provides the requirements for the assessment of the performance of the ISMS. It includes the requirements for:

9.1 Monitoring, measurement, analysis and evaluation
9.2 Internal audit
9.3 Management review

ISO 27001 does not require you to measure everything. An organization must determine the following:
a) what needs to be monitored and measured, including processes and controls;
b) the methods for monitoring, measurement, analysis, and evaluation, to ensure valid results;
c) when the monitoring will happen;
d) who shall perform the activity;
e) when the results will be analyzed; and
f) who shall do this.
Clause 9.2 of the standard specifies the requirements for ISMS Internal Audit. Key considerations are:

• They occur at planned intervals;
• That the auditor selected will be objective and impartial. Generally, this means the ISMS cannot be audited by persons involved in its implementation or operations.

ISMS internal audits must be conducted to determine the status of the system. The organization needs to plan audits, taking into account the most important aspects of the business, then conduct the audits using the competent staff. The ISMS audit does not need to cover off all elements of the ISMS during the audit. An ISMS audit program is produced which may contain a number of audits. The audit program must ensure that all elements of the system are reviewed.
Clause 9.3 addresses the need for a Management Review. This occurs at planned intervals, generally after the completion of the ISMS Internal Audit. The standard explicitly defines the minimum inputs into the Management Review. These include:
a) the status of actions from previous management reviews;
b) changes in external and internal issues that are relevant to the information security management system;
c) feedback on the information security performance, including trends in:

1. nonconformities and corrective actions;
2. monitoring and measurement results;
3. audit results; and
4. fulfilment of information security objectives;

d) feedback from interested parties;
e) results of risk assessment and status of risk treatment plans; and
f) opportunities for continual improvement.

Outputs include recommendations for improvements and any identified changes to the ISMS. These reviews by management are conducted for the purposes of ensuring the ISMS is operating as expected. These reviews are often performed by the governance forum of the ISMS.

9.1 Monitoring, measurement, analysis and evaluation

The organization must determine what needs to be monitored and measured, including information security processes and controls. It must also determine the methods for monitoring, measurement, analysis, and evaluation, as applicable, to ensure valid results. The methods selected should produce comparable and reproducible results to be considered valid. The organization must determine when the monitoring and measuring should be performed, who shall monitor & measure, when the results from monitoring and measurement shall be analyzed and evaluated, and who will analyze and evaluate these results. The organization must retain appropriate documented information as evidence of the monitoring and measurement results.The organization must evaluate the performance of information security and the effectiveness of the information security management system.

The organization not only has to establish and evaluate performance metrics regarding the effectiveness and efficiency of processes, procedures, and functions that protect the information, but should also consider metrics for the ISMS performance, regarding compliance with the standard, preventive actions in response to adverse trends, and the degree by which the information security policy, objectives, and goals are being achieved. The methods established should take into consideration what needs to be monitored and measured, how to ensure the accuracy of results, and at what frequency to perform the monitoring, measurement, analysis, and evaluation of ISMS data and results. It should also be noted that performance results should be properly retained as evidence of compliance and as a source to facilitate subsequent corrective actions. Your organization will need to decide what needs to be monitored to be assured that your ISMS process and information security controls are operating as intended. It is impractical for an organization to monitor everything all the time; if you attempt to do so, it is likely that the volume of data would be so great that it would be virtually impossible to use it effectively. Therefore, in practice, you will need to make an informed decision about what to monitor. The following considerations will be important:

• Which processes and activities are subject to the most frequent and significant threats?
• Which processes and activities have the most significantly inherent vulnerabilities?
• What is practical to monitor and generate meaningful and timely information from?
• With each monitoring process, you put in place, for it to be effective you must clearly define how the monitoring is undertaken (e.g. is this defined in a procedure);
  • when it is undertaken;
  • who is responsible for undertaking it;
  • how are the results reported, when to whom and what do they do with them; and
  • if the monitoring results identify unacceptable performance,
  • what is the escalation process or procedure to deal with this situation?

To demonstrate to an auditor that you have appropriate monitoring processing in place, you will need to retain records of monitoring results, analysis, evaluation reviews, and any escalation activities.

There are several ways of monitoring an ISMS. Measuring the effectiveness of various components of the ISMS is one of the key mechanisms to assess the performance of the ISMS and drive improvements. ISO 27001 does not require you to measure everything. It is up to the organization to determine what metrics are important and how these will be collected and presented. Measurements can include specific measures of control effectiveness. These could be a bounded range, a trending measure, or an absolute value. Again, it is the organization’s choice. Qualitative assessment of control effectiveness (e.g. marginal, strong, etc) does not in itself provide enough detail in terms of the measurements required to drive improvements. More mature management systems tend to have more metrics available than systems in the early days of operations. An annual Security Calendar assists in ensuring timely collection and reporting of metrics. Agencies should not try to “reinvent the wheel”. Most agencies already accumulate some data or information about information security and how certain controls are functioning. This is a good place to start. The expansion of the measurement regime should be based on the importance or relevance of the control or system component being measured. The more important or sensitive the control area, the more focus should be applied to defining an appropriate metric. One strategy commonly used is to select controls based on the types or levels of risks that they are mitigating. The more risks a control is mitigating, the more likely it that control is important and should be measured. Another approach suggests measuring the effectiveness of the controls managing higher-rated risks. Again, the choice is with the organization. Remember that the Internal Audit and Management Review are also both improvement vehicles.

9.2 Internal audit

The organization must conduct internal audits at planned intervals to provide information on whether the information security management system conforms to the requirements of ISO 27001 standard, the organization’s own requirements for its information security management system and is effectively implemented and maintained. The organization must plan, establish, implement and maintain an audit program, including the frequency, methods, responsibilities, planning requirements, and reporting. The audit program must take into consideration the importance of the processes concerned and the results of previous audits. It must define the audit criteria and scope for each audit. It must select auditors and conduct audits that ensure objectivity and the impartiality of the audit process. It must ensure that the results of the audits are reported to relevant management. The organization must maintain the record of the audit program and the audit results as evidence

Internal audits should be performed at planned intervals, considering the processes’ relevance and results of previous audits, to ensure effective implementation and maintenance, as well as compliance with the standard’s requirements and any requirements defined by the organization itself. The criteria and scope of each audit must be defined.
Auditors should be independent and have no conflict of interest over the audit subject. Auditors also must report the audit results to relevant management and ensure that non-conformity are subject to the responsible managers, who in turn must ensure that any corrective measures needed are implemented in a timely manner. Finally, the auditor must also verify the effectiveness of corrective actions taken. The purpose of internal audits is to test your ISMS processes for weaknesses and identify opportunities for improvement. They are also an opportunity to provide a reality check to Top Management on how strongly the ISMS is performing. When done well, internal audits can ensure that there are no surprises at your external audits. The internal audits you perform should check:

• how consistently processes, procedures, and controls are followed and applied;
• how successful your processes, procedures, and controls are at generating the intended results; and
• whether your ISMS remains compliant with ISO 27001 and the requirements of interested parties.

To ensure that audits are undertaken to a high standard and in a way that is seen to add value, they need to be undertaken by individuals who:

• are respected;
• competent
• understand the requirements of ISO 27001; and
• can quickly interpret your documentation and are well-practised in sound auditing techniques and behaviours.

Most importantly, they need to be allocated sufficient time to do the audit and be assured of cooperation from
relevant employees. You must maintain a plan for carrying out your internal audits. An external auditor will expect this plan to ensure that all of your ISMS processes are audited over a three-year cycle and that processes which:

• have shown evidence of poor performance (i.e. through previous audits, or monitoring results or information security incidents); and/or
• manage the most significant information security risks
• are audited at a higher frequency.

The external auditor will also expect that any actions identified from audits are recorded, reviewed by appropriate employees, and actions implemented in a timely manner to rectify any significant issues. They should make an allowance in the close-out time for any improvement opportunities identified that require significant investment in resources.

The objective of an ISMS Internal Audit is twofold. First, it seeks to assess the conformance of the ISMS with the requirements of the standard, the organization’s own policies and procedures, and the legal and regulatory environment under which the organization operates. The outcome of this element of the ISMS audit includes statements of conformance and non-conformance with those criteria. The second objective of the ISMS Internal Audit is the opportunity to identify improvements to the ISMS. Internal audits are conducted under the banner of the ISMS audit program. This program tends to span a period of several years and outlines the scope of each of the planned audits within the program. Audits need to occur at planned intervals. This does not mean regular intervals. The audit program must address all mandatory clauses and all controls specified within the SoA. Each individual ISMS audit may only be focused on certain clauses and control domains. The auditor for each of these audits cannot audit outside the scope of that specific audit without approval. The focus on any ISMS audit is on the system and NOT the people. If any resource weaknesses are identified it must always be related to a system weakness. It could be mistakes introduced because of a lack of awareness of their responsibilities, a competency gap, or poor supporting policies and procedures. These are the deficiencies that need to be addressed. An ISMS audit is more than a control assessment. The management system is key. Failure of controls usually means a failure in one of the core ISMS components. Fixing the underlying issue will generally address control failures.

ISMS INTERNAL AUDITORS
As with all roles within the ISMS, ISMS Auditors need to be competent and have the necessary skills to conduct an ISMS audit. Whilst the general ICT auditor has the necessary skills to audit the control elements, it is important that the auditor has sufficient skills to audit the management system components. ISMS auditors add value to the ISMS.

ISMS Internal Auditors must:

• be competent to audit the management system
• be non-judgmental, objective
• reference is the ISO 27001, not own opinions
• be able to provide an objective assessment of ISMS effectiveness, focusing on the system, not the people
• be able to report fairly and without bias
• be selected to ensure impartial and objective results

Some of the personal attributes of good ISMS auditors are:

• ethical, fair and truthful;
•  objective and audit against the criteria (ISO 27001) rather than their opinion;
•  diplomatic;
•  observant;
•  culturally sensitive;
•  collaborative.

An ISMS audit should not be adversarial.

9.3 Management review

Top management shall review the organization’s information security management system at planned intervals to ensure its continuing suitability, adequacy and effectiveness.
The management review must take into consideration the status of actions from previous management reviews, changes in external & internal issues relevant to ISMS , feedback from interested parties, opportunities for continual improvement, result of risk assessment& status of risk treatment plan. The input to the management representative must also take into consideration the feedback on the information security performance, including trends in nonconformity & corrective actions, monitoring & measurement results, audit results and audit results fulfillment of information security objectives.
The results of the management review shall include decisions related to continual improvement opportunities and any needs for changes to the information security management system.
The organization shall retain documented information as evidence of the results of management reviews.

The management review exists so that the ISMS can be kept continuously suitable, adequate, and effective to support information security. It must be performed at planned intervals, in a strategic manner, and at the top management level, covering the required aspects all at once or by parts, in a way that is best suitable to business needs. The status of actions defined in previous reviews, significant internal and external factors that may impact the ISMS, information security performance, and opportunities for improvement should be reviewed by top management, so relevant adjustments and improvement opportunities can be implemented. The management review is the most relevant function to the continuity of an ISMS, because of the top management’s direct involvement, and all details and data from the management review must be documented and recorded to ensure that the ISMS can follow the specific requirements and general strategic direction for the organization detailed there. Management Review is an essential element of an ISMS. It is the formal point at which Top Management reviews the effectiveness of the ISMS and ensures its alignment to the organization’s strategic direction. Management Reviews must take place at planned intervals and the overall review program (i.e. one meeting or several meetings) must at a minimum cover a list of core areas specified within clause 9.3 of the standard. It is not essential for one single Management Review meeting to take place covering the full agenda. If you currently hold a range of meetings that cover the inputs between them, there is no specific need to duplicate them.
You will need to retain documented information on your Management Reviews. These would normally be minutes of
meetings or perhaps call recordings if you carry out conference calls. These do not need to be extensive notes, but they must contain a record of any decisions made and actions agreed, ideally with responsibilities and timescales. If you decide to adapt your existing schedule of management meetings and these meetings cover a number of areas, you may want to consider summarizing the areas that these meetings cover in the form of a table or procedure so that it is clear to you and an auditor which meetings cover each of the required review areas.

The objective of the Management Review is to assess the performance of the ISMS, taking into account a number of inputs, and to determine any necessary changes or improvements to the system. Management Reviews are conducted at planned intervals and are performed by senior management. Generally, this is the ISMS governance forum. Management Reviews must consider the following mandatory inputs as defined by ISO 27001:

• the status of actions from previous management reviews;
• changes in external and internal issues that are relevant to the information security management system;
• feedback on the information security performance, including trends in
  1. nonconformity and corrective actions;
  2. monitoring and measurement results;
  3. audit results; and
  4. fulfillment of information security objectives;
  5. feedback from interested parties;
• results of risk assessment and status of the risk treatment plan; and
• opportunities for continual improvement.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

This clause is all about the execution of the plans and processes that are the subject of previous clauses. It deals with the execution of the actions determined and the achievement of the information security objectives. In recognition of the increased use of outsourced functions in today’s business world, these processes also need to be identified and controlled. Any changes, whether planned or unintended need to be considered here and the consequences of these on the ISMS. It also deals with the performance of information security risk assessments at planned intervals and the need for documented information to be retained to record the results of these. Finally, there is a section that deals with the implementation of the risk treatment plan, and again, the need for the results of these to be retained in documented information. This clause of the standard defines the requirements necessary to operate an ISMS. They include the following key elements:

• 8.1 Operational planning and control
• 8.2 Information security risk assessment
• 8.3 Information security risk treatment

Clause 8.1 requires a demonstration of processes controlling critical security-related activities. Some mechanisms to assist with conformance to this subsection include:

• The use of documented security plans or security calendars;
• Monitoring and controlling changes to the environment;
• Implementing controls around third-party outsourcing arrangements.

Clause 8.2 requires the risk assessment to be performed when significant changes occur or are proposed. In addition. this clause requires the review of the risk assessments at planned intervals. In a practical sense. this usually is performed annually and is tracked by activity in the security calendar. Evidence of the output of such planned risk reviews must be available. Clause 8.3 requires risk treatments to be implemented and monitored.

8.1 Operational planning and control

The organization shall plan, implement and control the processes needed to meet information security requirements, and to implement the actions determined in 6.1. This is to be done by establishing the criteria for process and implementing controls of the processes in accordance with the criteria. The organization shall also implement plans to achieve information security objectives determined in 6.2. The organization shall keep documented information to the extent necessary to have confidence that the processes have been carried out as planned. The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary. The organization shall ensure that externally provided products, services or processes related to ISMS are controlled.

To ensure that risks and opportunities are treated properly (clause 6.1), security objectives are achieved (clause 6.2), and information security requirements are met, an ISMS must plan, implement, and control its processes, as well as identify and control any relevant Externally processes including product or services, and retain documented information deemed as necessary to provide confidence that the process is being performed and achieving their results as planned. Being focused on keeping the information secure, the ISMS also should consider in its planning and control the monitoring of planned changes, and impact analysis of unexpected changes, to be able to take actions to mitigate adverse effects if necessary. Managing your information security risks and achieving your objectives require the formalization of your activities into a set of clear and coherent processes. Many of these processes are likely to exist already (e.g. induction, training) and will simply need modifying to include elements relevant to information security. Other processes may happen in an ad-hoc fashion (e.g. supplier approvals), while some may not currently exist at all (e.g. internal audit). To implement effective processes the following practices are crucial:
1 Processes are created by adapting or formalizing an organization’s “business as usual” activities.
2 Systematic identification of the information security risks relevant to each process.
3 Clear definition and communication of the set of activities required to manage the associated information security risks when an event occurs (e.g. a new employee joining
the company).
4 Clear assignment of the responsibilities for carrying out related activities.
5 Adequate allocation of resources to ensure that related activities can take place as and when required.
6 Routine assessment of the consistency with which each process is followed and its effectiveness in managing relevant information security risks.
For each process, designate an individual as accountable for ensuring that steps 2-6 happen. This individual is often referred to as the Process Owner.

Relationship between assets, threats, and vulnerabilities
So, let’s see what this matching of the three components could look like – for example:

1. Asset: paper document:
   threat: fire;
   vulnerability: the document is not stored in a fire-proof cabinet (risk related to the loss of availability of the information)
   threat: fire;
   vulnerability: there is no backup of the document (potential loss of availability)
   threat: unauthorized access;
   vulnerability: the document is not locked in a cabinet (potential loss of confidentiality)
2. Asset: digital document:
   threat: disk failure;
   vulnerability: there is no backup of the document (potential loss of availability)
   threat: virus;
   vulnerability: anti-virus program is not properly updated (potential loss of confidentiality, integrity, and availability)
   threat: unauthorized access;
   vulnerability: access control scheme is not properly defined (potential loss of confidentiality, integrity, and availability)
   threat: unauthorized access;
   vulnerability: the access was given to too many people (potential loss of confidentiality, integrity, and availability)
3. Asset: system administrator:
   threat: unavailability of this person;                                                                        vulnerability: there is no replacement for this position (potential loss of availability)
   threat: frequent errors;
   vulnerability: lack of training (potential loss of integrity and availability) etc.

8.2 Information security risk assessment

The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a). The organization shall retain documented information on the results of the information security risk assessments.

The risk assessment methods and techniques described in Clause 6 must be applied to all processes, assets, information, and activities within the organization’s ISMS scope. Since risks are not static, the results of these assessments must be reviewed at appropriate frequencies. This is usually at least annually, or more frequently if the assessment identifies the presence of one or more significant risks. Risks should also be reviewed whenever:
• any Risk Treatment actions are completed (see below);
• there are changes to the organization’s assets, information, or processes;
• new risks are identified; or
• experience or new information indicates that the likelihood and the consequence of any identified risk have changed.
To ensure your risk assessment process covers the types of events that would require a review, you should also take into consideration the Annex A controls for Technical Vulnerability Management (A.12.6), Security in Development and Support Processes (A.14.2), and Supplier Service Delivery Management (A.15.2).

Given that ISO 27001 is inherently a risk management standard it is no surprise that there are a number of specific clauses addressing this area. The clauses and the expectations outlined in the standard are: – Process must be defined (6.1.2). The standard does not dictate specific methods for risk assessment. It is up to the organization to select a method that aligns with the organizational risk methodology. However, the consequence and likelihood must be considered. ISO 27001 references ISO 31000 as a risk standard.

Management must determine and approve the criteria for accepting the risk. For example, an organization may say “We will accept all risks in the ‘low’ category and treat those rated above this value”. Management must also determine the criteria for performing risk assessments. This may include consideration of risk assessments during projects, significant changes, as a result of incident reviews, or as an outcome of business continuity exercises. Criteria may also be based on the value of the information assets involved. For instance, highly sensitive assets may automatically require a risk assessment around any changes in how those assets are used.

The process of risk assessment should be documented. People undertaking risk assessments must be competent to perform these activities. Training may be required. A general “rule of thumb” regarding “producing consistent, valid and comparable results” should be “if two people of similar competence undertake the same risk assessment the results will be comparable (not necessarily identical)”.Risk assessments should also be performed at planned intervals to address changes in the security requirements and in the risk situation, e.g. in the likelihood or consequences of previously identified risks and also when significant changes occur or are planned.

A question is often posed that if ISO 27001 is about risk management, why do we not do risk assessments against all in-scope assets? This is fundamentally a question of practicality. Few organizations have enough competent resources to undertake such an intensive program. In addition to resources, there is a question of exposure. During the time taken to conduct such risk assessments, the organization is exposed to potentially high risks. The most common approach is to perform detailed risk assessments on “high value” assets and have the risks to those assets of a lower value managed by sets of baseline controls. These controls are the minimum set of controls to provide appropriate protection.

STEPS IN A SAMPLE RISK ASSESSMENT METHOD
1. Identify the critical processes within the scope
2. Identify the information assets required
3. Consider threats (agencies that could cause loss) against the asset
4. Identify vulnerabilities (weaknesses exploited by threat)
5. Assess consequences to the agency if the threat occurs
6. Assess the realistic likelihood of risk eventuating
7. Determine risk rating
8. Compare against acceptance criteria
9. Determine treatment options if required
10. Monitor treatment implementation
11. Repeat from step 1

MEASURES OF LIKELIHOOD
Tables similar to the one below are often seen within risk models. One consideration should be if the timeframes within these types of tables are appropriate for assessing information security risks. One challenge related to the use of a single likelihood table for all types of risk has been the relevance to information security events.

The likelihood should take into account the effectiveness of the current control environment.

MEASURES OF CONSEQUENCE
It is more common to use a single consequence table across the organization. For this to be practical, the consequence (or impact) domains must represent all possible areas of impact across the risk portfolio. The more detailed the information in the consequence table, the more likely it that a comparable value will be selected during risk assessments. There may be consequences in a number of impact areas. The risk assessor should select the highest impact value.

MEASURES OF RISK
Once the consequence and likelihood have been assessed, generally there is some form of lookup table to determine the risk value. These risk tables may look similar to that above, although sometimes the axes are transposed or the scales on the axes are transposed. The likelihood assessment may include business and control owners and consequence assessment will certainly include the business owner. The risk value obtained from the risk assessment will be used to determine whether further risk treatment is required.

8.3 Information security risk treatment

The organization shall implement the information security risk treatment plan. The organization shall retain documented information on the results of the information security risk treatment.

Once the risk assessment has been concluded and the risk is rated, the rating is compared to the agreed risk acceptance criteria. If the risk rating is greater than the acceptable level of risk treatment options need to be considered.
There are four alternatives for risk treatment. These are:
1. Mitigating the risk by applying additional appropriate controls;
2. Knowingly and objectively accepting the risk, providing this clearly satisfies the organization’s risk management policy in terms of the levels of authorization required to accept risks above the defined risk acceptance criteria;
3. Avoiding the risk by avoiding or terminating the activity that creates the risk; and,
4. Transferring the associated business risks to other parties, e.g. insurers.
Transference of risk is an effective choice when the impact of this risk is financial in nature. For instance, insuring against loss from an environmental event such as a flood reduces the financial impact on the organization. The risk treatment plan you develop cannot simply remain as a statement of intent; it must be implemented. Where changes are needed to take into account new information about risks and changes to your risk assessment criteria, the plan needs to be updated and re-authorized. The impact of the plan must also be assessed and the results of this assessment recorded. This may be done as part of your Management Review or Internal Audit Processes or by using technical assessments such as network penetration tests, supplier audits, or unannounced third-party audits.

Some believe that outsourcing is a form of risk transference. However, the question remains “who suffers the most impact?”. Generally, it is not the outsourcer’s business that is most affected. Outsourcing transfers some of the operational aspects of risk mitigation to the outsourcer but it still remains the organization’s risk to manage. If the treatment choice is “mitigate” with additional controls, what control sets should be considered? As with the existing control environment, the standard does not mandate any specific set.
Possible control sets include:
• ISO 27002 (ISO 27001 Annex A)
• PCI-DSS for credit card security
• Australian Government’s Information Security Manual (ISM)
• NIST frameworks
• Other ISO 27nnn standards
• Unique controls designed by the organization
Remember that after the risk treatment has been determined, you need to reassess the ‘likelihood’ and “consequence” and calculate the measure of residual risk. At the conclusion of the control selection process, the control objectives and controls selected need to be compared to the control objectives and controls from Annex A to ensure that no necessary controls have been omitted. The risk owner MUST approve the risk treatments selected and also must accept any residual risk. This must be documented.

Risk treatment is usually done in a form of a simple sheet, where you link mitigation options and controls with each unacceptable risk; this can also be done with a risk management tool if you use one. According to ISO 27001, it is required to document the risk treatment results in the Risk assessment report, and those results are the main inputs for writing a Statement of Applicability. This means that the results of risk treatment are not directly documented in the Risk Treatment Plan. The risk treatment plan can be written only after the Statement of Applicability is finished. This is because the Risk treatment plan can be considered as an “Action plan” where you need to specify which security controls you need to implement, who is responsible for them, what are the deadlines, and which resources (i.e. financial and human) are required. But in order to write such a document, first, you need to decide which controls need to be implemented, and this is done (in a very systematic way) through the Statement of Applicability. The  ISO 27001 requires that the results from the risk treatment process should not be documented directly in the Risk Treatment Plan without doing the  Statement of Applicability. This may be because the authors of ISO 27001 wanted to encourage companies to get a comprehensive picture of information security – when deciding which controls are applicable in Statement of Applicability and which are not, the result of risk treatment is not the only input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In other words, SoA serves as a kind of checklist that takes a global view of the organization, and the Risk Treatment Plan wouldn’t be complete without such a check.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

Clause 7 concerns itself with resources. This applies to people, infrastructure, and the environment as much as physical resources, materials, tools, etc. This Clause is all about getting the right resources, the right people, and the right infrastructure in place to establish, implement, maintain and continually improve the ISMS. It deals with requirements for competence, awareness, and communications to support the ISMS and it could include making training and personnel available, for example. This clause also requires all personnel working under an organization’s control to be aware of the information security policy, how they contribute to its effectiveness, and the implications of not conforming. The organization also needs to ensure that internal and external communications relevant to information security and the ISMS are appropriately communicated. This includes identifying what needs to be communicated to whom, when, and how this is delivered.
It’s in this clause that the term “documented information” is referenced. Organizations need to determine the level of documented information that’s necessary to control the ISMS. There is also an emphasis on controlling access to documented information, which reflects the importance of information security. There is also a renewed focus on knowledge as a significant resource within your organization. When planning your quality objectives, a major consideration will be the current capacity and capability of your resources as well as those you may need to source from external suppliers/partners. This clause of the standard provides the requirements supporting the establishment and operations of an ISMS. Included in Clause 7 are:
7.1 Resources required to establish and operate an ISMS
7.2 Competency
7.3 Awareness
7.4 Communication
7.5 Documented Information

7.1 Resources

The organization must determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the information security management system.

Clause 7.1 provides information on the selection and allocation of resources to implement and operate an ISMS, and the requirements for ongoing awareness for all persons performing work within the scope of the ISMS and under the organization’s control. The requirement is to provide an adequate level of resources into the establishment, implementation, maintenance, and continual improvement of the information security management system. It does not actually mandate that the ISMS has to be staffed by full-time resources, just that the roles, responsibilities, and authorities are clearly defined and owned – assuming that the right level of resource will be applied as required. clause 7.1, which acts as the summary point of ‘resources’ commitment which is then more fully described with requirements in:
7.2 – Competence of the support resources for ISO 27001
7.3 – Awareness of the people doing the work for the ISMS to meet ISO 27001
7.4 – Communication about the ISMS to the interested parties internally and externally about the ISMS
7.5 – Documented information about the ISMS to demonstrate it conforms to the ISO 27001 standard
It is also worth remembering that Annex A 6 fits into this requirement nicely too, so when building out the ISMS responsibilities each of those controls could be considered at the same time.

One critical success factor for an ISMS implementation is having access to the right resources at the appropriate time. Remember that each person fulfilling a role within the ISMS is required to be competent in that role. It is therefore important to remind yourself of the core roles and consequently the core resources you will require. This applies to both the implementation and operations of the ISMS. Core roles will likely include:

• The ISMS Owner. Usually a very senior manager.
• The members of the governance forum, whatever label it is given.
• The person is responsible for information security management within the agency.
• Those responsible for various operational activities affecting information security. This includes operational support personnel such as server and network support teams, service desk personnel and human resource management staff.
• The ISMS Internal Auditor
• The role charged with the responsibility to ensure the ISMS conforms to the standard.
• The role charged with reporting the performance of the ISMS to executive management.

There are a number of questions that need to be posed and answered during implementation planning.

• Do we know what competencies we need?
• Do we have these competencies available?
• If not, can we obtain it by recruiting?
• Short term, can we contract them in?
• Longer-term, what training and development are required internally to ensure we maintain the necessary competencies?

There are a number of questions that need to be posed and answered during implementation planning. These questions primarily related to ensuring the appropriate competencies are available when required. They include questions around documenting the required competencies, identifying the existing competency set, and developing possible strategies for addressing any competency gaps. Gaps are generally addressed by:

• Hiring — obtaining permanent resources with the right competency set;
• Buying in short-term contract resources;
• Developing competencies “in house” through training and mentoring.

Decisions about these choices will depend on the extent of the competency gap and whether the competencies are required for the implementation or ongoing operation of the ISMS.

7.2 Competence

The organization must determine the necessary competence of all people doing work under its control that affects its information security performance. It must also ensure that these people are competent on the basis of appropriate education, training, or experience. Where applicable, it must take actions to acquire the necessary competence, and evaluate the effectiveness of the actions taken and must retain appropriate documented information as evidence of competence. Applicable actions may include, for example, the provision of training to, the mentoring of, or the reassignment of current employees or the hiring or contracting of competent persons.

ISO 27001 clause 7.2 basically says that the organization will ensure that it has:

• determined the competence of the people doing the work on the ISMS that could affect its performance
• people that are deemed competent on the basis of the relevant education, training or experience
• where required, take action to acquire the necessary competence and evaluated the effectiveness of the actions
• retained evidence of the above for audit purposes

Clause 7.2 requires all persons to be competent in their roles within the ISMS. Competency comes about through the provision of training, education, experience, and skills. These are all to be considered in the management of human resources. To implement and maintain an effective ISMS you need to have supporting resources in place. These resources will need to be sufficient:

• capable – if they are equipment or infrastructure; and
• competent – if they are people.
• at Management Review meetings.

There is a logical sequence that is reflected within this clause of the standard when addressing competency:

• Determine the necessary competency requirements
• Provide training or other actions to fill any gaps, considering past qualifications and experience. This may include recruiting.
• Evaluate the effectiveness of the training or actions
• Maintain records of education, training, skills, and experience, etc.

The need for people to be aware of their ISMS responsibilities is contained within Clause. The implementation of effective information security controls relies heavily on the knowledge and skills of your employees, suppliers, and contractors. To be certain of an appropriate knowledge and skills base you need to:

• define what knowledge and skills are required;
• determine who needs to have the knowledge and skills; and
• set out how you can assess or verify that the right people have the right knowledge and skills.

A whole bunch of skills and experiences required for successful implementation and ongoing management of an ISMS that is certified to ISO 27001, beyond expertise in physical security, cybersecurity, computer security, or other forms of information security per se. Those include commercial, legal, HR, IT, as well as the relevant products & services expertise for the work in scope. Building and running an ISMS is usually a collaborative team job. Your auditor will expect you to have documents detailing your knowledge and skills requirements. Where you believe the requirements are satisfied this will need to be supported with records such as training certificates, course attendance records, or internal competency assessments. Most organizations that already use tools such as training/skills matrices, appraisals, or supplier assessments can satisfy the requirement for competence records by expanding the areas covered to include information security.

TRAINING

The ISMS requires that all personnel are competent in terms of their role within the ISMS. Any competency gaps that have been identified need to be addressed. However, there is some specific ISMS-focussed training for some target user groups. Some of these groups and the type of training that may be required are listed in the following table.

The training plan should consider the following:

• user awareness training
• briefings for the Governance Forum
• targeted training for key “control owner” groups
  • Network support
  • Server support
  • Service desk (user support. incident response)
  • Human resources
• briefings for key executives and line management

When developing any training plan consideration must be given to the following:

• who the target audience is?
• what messages do they need?
• how will the message/training be delivered? Face-to-face, online, PowerPoint, team briefings?
• when the training will occur and how often it needs to happen?
• who will be responsible for organizing the training, updating the content, and delivering the material?
• Are assessments or effectiveness metrics required? Quizzes? Surveys?

This type of information can be captured through a “training needs analysis” exercise. Once this type of information is captured, a training program can be developed.

The training plan should cover:

• who the target audience is
• what messages they need
• how the message/training will be delivered
• when the training will occur
• how often the training needs to happen
• who will be responsible for organizing/delivering
• Whether any assessment mechanisms are required
• If so. what would that look like?

7.3 Awareness

People doing work under the organization’s control shall be aware of the information security policy, their contribution to the effectiveness of the information security management system, including the benefits of improved information security performance and the implications of not conforming with the information security management system requirements.

Clause 7.3 of ISO 27001 combines with clause 7.2 competence and 7.4 communication about the information security management system to all the relevant interested parties. Awareness is closely related to competence in the standard. People who work under the organization’s control must be made aware of the information security policy and its contents, what their personal performance means to the ISMS and its objectives, and what the implications of nonconformities may be to the ISMS. ISO 27001 is seeking confirmation that the people doing the work are aware of:

• the information security policy
• their contribution to the effectiveness of the ISMS including benefits from its improved performance
• what happens when the information security management system does not conform to its requirements

This generally will drive some level of training and awareness sessions targeting different audience groups. Awareness of non-conformance to the requirements of the ISMS must also be addressed. In addition to ensuring the specific competence of key personnel in relation to information security, the wider group of employees, suppliers, and contractors will need to be aware of the basic elements of your ISMS. As part of the implementation of the ISMS, the people within the organization must participate in the creation of the information security policy for top management to approve. They would have a good understanding of their role because it would have been agreed and documented as part of clause 7.1. This is central to establishing a supportive culture within the organization. All staff, suppliers, and contractors should be aware of the following:

• That you have an ISMS and why you have one.
• That you have an Information Security Policy and which particular elements of it are relevant to them.
• How they can contribute to your organization protecting its valuable information and what they need to do to help the organization achieve its information security objectives.
• Which policies, procedures, and controls are relevant to them and what the consequences are of not complying with them.
• Awareness and understanding for 6.1 risk management, 6.2 ISMS objectives and 9.1 broader measurement & evaluation, 9.2 internal audits, 9.3 management reviews, 10.1 non-conformities, and corrective actions, as well as continual improvements in line with 10.2.

The communication of this information can normally be done through existing processes and documents such as inductions, employment contracts, toolbox talks, supplier agreements, employee briefings or updates.

7.4 Communication

The organization must determine the need for internal and external communications relevant to the information security management system. While determining the communication system it must determine what to communicate, when to communicate, with whom to communicate, who shall communicate and the processes by which communication shall be affected.

Communications play a key role in the implementation of an ISMS. They help garner and maintain support for the program by keeping it and its benefits visible both within, and external to, the organization. The benefits of strong communications programs include ensuring the information security is “front of mind” and not considered a “side issue”. Good communications strategies extend beyond implementation and into normal ISMS operations. Key security dashboards, briefing’s, and alerts all form part of a strong communications regime.

Internal and external communication deemed relevant to the ISMS must be determined, as well as the processes by which they must be effected, considering what needs to be communicated, by whom, when it should be done, and who needs to receive the communication. To enable the processes in your ISMS to work effectively you will need to ensure you have communication activities that are well planned and managed. ISO 27001 details these concisely by requiring you to determine:

• what needs to be communicated;
• when it needs to be communicated;
• to whom it needs to be communicated;
• who is responsible for communication; and
• what are the processes for communication?

If your communication requirements are well defined in your processes, policies, and procedures then you do not need to do anymore to satisfy this requirement. If they aren’t then you should consider documenting your key communication activities in the form of a table or procedure that includes the headings detailed above. Remember, the content of these documents also needs to be communicated. Similar to the training domain. good communications require the identification of the target audiences, the mechanisms that can be used (either existing or new), the content of the communications, and the frequency of such communications. Again, some processes like a Communications Needs Analysis can identify these elements and allow for the development of a comprehensive communications plan. The involvement of resources from corporate communications areas adds significant benefit in this domain. Communication strategies play an important role:

• to maintain a commitment to the implementation and operations
• to win support for the ISMS
• To continue to keep information security “front of mind”
• Development of a communications plan provides a vehicle for messaging

Communications plans should consider:

• What existing communication mechanisms can be utilized
• What involvement from corporate communications and other groups within the agency may be required
• The existing levels of support within key areas of the agency and how this could be altered

Clause 7.4 requires a clear answer to a series of questions on security issues: Who should communicate? To whom? What messages? On what? When? And how?

1. On what? (content) Organizations should clearly communicate what is important to them: the need for information security and the need to conform to the requirements and policies. It will address risk management issues, new or changed security objectives, and vulnerabilities, events, or incidents to initiate the adequate answer of all, and especially the trained personnel who perform the planned reaction. Celebrating achievements and congratulating exceptional security behaviors has very positive effects. Including security clauses and requirements in the contract is also a way to communicate your requirements to services and product providers. Hence, it could be considered a part of the Communication Plan.
2. What messages? (form & format) Messages should be clear in their form and content to produce the expected behavior. The type of communication medium is looked at here. You can use short stories, images, metaphors, or cartoons. Messages should be short and focused on their real intent. You certainly remember the SMART criteria that you can use to make sure the message is complete.
3. Who? Organizations should clarify who is authorized to communicate, especially with external parties. Internally, top management and the CISO, and the help desk are good examples. Big companies have their Public Relations Officer to communicate with external parties. The communicator should have the appropriate authority to make sure the message will be received with the necessary attention and will be followed by the expected action or reaction.
4. To whom? Not everybody should receive all the messages. Messages should be aimed at a specific audience, depending on the classification of the information, the necessary technical knowledge, and the role in the organization. The Communication Plan should be effective and addressed only to those who will benefit from it or need to act based on it – e.g., different interested parties like users, partners, internal and external service providers, regulating bodies, shareholders, etc.
5. How? (process) The simplest and first way is the security policy and all the documents that describe what to do (and how) to meet the objectives of the policy. Messages should be prepared and approved, particularly in the case of incidents and crises. Defined channels (and protocols) should be utilized to make sure the communication reaches the intended audience at the best moment and with the best possible effectiveness. Examples: emails, pop-up screens, screensavers, posters, audio messages, meetings, policies, and directives, etc.
6. When? Communication should be both continuous and event-based (in reaction to events). You should make sure the communicated message is continuously retransmitted, for example, to newcomers, and at repeated intervals, to make sure it won’t get forgotten. You also should be able to modify the messages or introduce new messages or formats and channels when the situation requires it. Communicating in normal conditions might be seriously different in comparison to incidents or in crises.

Internal vs. External Communication Plan. It is important to recognize that the Communication Plan has both internal and external aspects. They will respond differently to the following questions.
Internal Communication Plan. Top management uses the internal Communication Plan to send messages on its objectives and commitment toward information security. Some examples are the Information Security Policy, the security organization with the key roles and responsibilities, the Awareness plan, the general and specific requirements to respond to incidents. However, the internal Communication Plan should not remain unidirectional. The channels (telephone and email, for example) should also be known and used to communicate “bottom-up” from the base (the users) to the management about events or some new vulnerability.

External Communication Plan. Most of the examples given above relate to the internal Communication Plan but are also fully applicable to the external Communication Plan. You may need to communicate to the external world: regulatory authorities, public authorities, shareholders, clients, and partners, to announce events either positive (successes) or negative (incidents, accidents, and crises). Here also you will need a Communication Plan answering the same questions as above. However, in this case, you’ll have to use more caution as you may not expose or disseminate sensitive information that will make your situation worse.

How to document the Communication Plan?

Depending on the size of the organization and its security objectives, the Communication Plan could be more or less formal, fully documented as a separate document, or simply stated in a few sentences within other policies, procedures, and plans. As long as the desired messages are passed to those who should make the best of it, your solution will fit your needs and the resources you can devote to it.

7.5 Documented information

7.5.1 General

The organization’s information security management system shall include documented information required by ISO 27001 and those determined by the organization as being necessary for the effectiveness of the information security management system. The extent of documented information for an information security management system can differ from one organization to another due to the competence of persons, the size of the organization and its type of activities, processes, products, and services, the complexity of processes and their interactions.

7.5.2 Creating and updating

When creating and updating documented information the organization shall ensure appropriate identification and description (e.g. a title, date, author, or reference number); format (e.g. language, software version, graphics) and media (e.g. paper, electronic); and review and approval for suitability and adequacy.

7.5.3 Control of documented information

Documented information required by the information security management system and by ISO 27001 Standard shall be controlled to ensure it is available and suitable for use, where and when it is needed; and it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity). The organization shall control documented information by addressing its distribution, access, retrieval, use, storage, preservation, including the preservation of legibility, control of changes (e.g. version control), retention and disposition. As appropriate, Documented information of external origin must be identified and controlled by the organization which are necessary for the planning and operation of the information security management system. Access can mean a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information, etc.

Clause 7.5 addresses the requirements relating to maintaining the relevant documents and records that support the operations of the ISMS. Formal records of document approval demonstrate conformance with this clause. To be of use, the documented information you use to implement and maintain your ISMS needs to:

• be accurate;
• be understandable to the individuals who use it regularly or occasionally; and
• support you to comply with legal requirements, manage information security risks and achieves your objectives.

So that your documented information always satisfies these requirements you will need to have processes in place to ensure that:

• documented information is reviewed where required by appropriate individuals before it is released into general circulation;
• access to documented information is controlled so that it cannot be changed accidentally, corrupted, deleted or accessed by individuals to whom it is not appropriate;
• information is deleted securely or returned to its owner when there this a requirement to do this; and
• you can track changes to information to guarantee that the process is in control.

Documentation is important to ensure that processes are performed in a manner consistent with the objectives of the management system. Documentation defines what you are going to do and provides evidence of you doing what you say. The extent of documentation is not defined by the standard and is influenced by a number of factors. These include:

• The size and primary functions of the organization:
• The complexity and interaction of business processes;
• The control environment, possibly influenced by external obligations;
• The competence of personnel:
• Any other legal or regulatory obligations.

Documents should always be constructed with the target audience in mind. They must be useful to those who need access to the information contained within the documentation. Organizations are expected to define their processes and document as appropriate. They must then follow their own documentation. “Say what you do and do what you say”.

The procedure that is not formally documented are permissible and have the following characteristics:

1. The procedure is systematical;
2. Communicated
3. Understood
4. Applied
5. Effective

Documentation, however, does require management. Such management includes document approvals. requirements on access and legibility and other specifications outlined in Clause 7.5 of the standard.

The source of your documented information may be either internal or external, so your control processes need to manage documented information from both sources. Organizations that have good document control typically have one or more of the following in place:

• A single person or small team responsible for ensuring that new/modified documents are reviewed before they are issued are stored in the right location, are withdrawn from circulation when superseded and that a register of charges
  is maintained.
• An electronic document management system that contains automatic workflows and controls.
• Robust electronic data back-up and hard-copy file archiving/ storage processes.
• Strong employee awareness of document control, record keeping, and information access/retention requirements.

7.5.1 General
“Documented information,” which you will see mentioned several times during this white paper, now covers both the “documents” and “records” concepts seen in the previous revision of the ISO 27001 standard.
This change was designed to facilitate the management of documents and records required by the standard, as well as those viewed as critical by the organization to the ISMS and its operation. It should also be noted that the amount and coverage of documented information that an organization requires will differ, according to its size, activities, products, services, the complexity of processes and their interrelations, and people’s competence.
7.5.2 Creating and updating
The standard requires that documented information created or updated in the scope of the ISMS must be properly identified and described, also considering its content presentation, and media used. All documented information must go under proper review and approval procedures to ensure they are fit for the purpose.
7.5.3 Control of documented information
The standard states that documented information required by the ISMS, and the standard itself, either from the internal or external origin, must be available and fit for use where and when needed and reasonably protected against damage or loss of integrity and identity. For the proper control of documented information, the organization must consider the provision of processes regarding the distribution, retention, access, usage, retrieval, preservation and storage, control, and disposition. The principle of Confidentiality, Integrity and Availability is applicable for documented information, it needs to be available when required and adequately protected from loss of confidentiality, unauthorized use or potential integrity compromise to address the following aspects:

• sharing and distribution clarity, controls over access to some or all of the ISMS – bearing in mind the access permissions for reading, updating, approving, deleting etc might need to differ based on the stakeholder role
• storage and preservation, including control of changes (showing older versions, historical approvals etc)
• retention and disposal also needs consideration

The difference between a document and a record: records are evidence of activity at a point in time. Documents are reviewed and updated on a periodic basis. They are usually versioned.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Policy of Configuration Management

XXX uses a wide variety of components in creating and running its ICT infrastructure and end-user devices. These consist of hardware, software, cloud services and networks and all are potentially vulnerable to attack from threats from different sources. In order to lessen the risk of these components becoming compromised, it is important that we identify the most appropriate ways of configuring them and then ensure that these methods are used throughout our ICT landscape.
This policy describes the main principles on which such standard configurations must be based and sets out the rules for their use.
This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access toXXX’s systems.
The following policies are relevant to this document:

• Information Security Policy
• Mobile Device Policy
• Network Security Policy
• Cloud Services Policy
• Configuration Management Process
• Change Management Process

New components that make up ISMS hardware, software, services and networks must have their required security settings defined and correctly configured prior to their implementation within our ICT environment.
Configurations of existing components must be reviewed periodically to ensure they meet the requirements of this policy.
Such components will include, but are not limited to:

• Endpoint devices, such as desktops, laptops, mobile phones and tablets
• Physical network devices, such as routers, switches and firewalls
• Physical servers, including system software such as operating systems, databases and web servers
• Cloud infrastructure, such as virtual servers, networks and storage
• Where possible, standard templates will be used to document the required configuration of ICT components. These templates will be subject to change and version control.
• The configurations defined will take appropriate account of available sources of information about securing the relevant components, such as vendor templates, guidance from cyber security authorities and best practice organizations, system hardening guides and our own information security policies.
• Details of configuration standards will be protected as sensitive information which would be of use to an attacker.
• Configuration standards must be reviewed on a regular basis and kept up to date with changes in the components themselves (such as new hardware or software versions) and the threats and vulnerabilities they face.
• The correct configuration of components will be monitored and instances where existing settings deviate from the established standard will be investigated and, if necessary, corrected.
• Where feasible, automated software methods such as Infrastructure as Code (laC) will be used to create components with the correct configuration. Automated audit tools may also be used to check configurations regularly and report on and correct those found to be non compliant.

SCOPE

Configuration Management covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships. Items that should be under the control of Configuration Management include hardware, software and associated documentation. This procedure is applicable to XXX.

PROCEDURE

The basic activities of Configuration Management are as follows:

• Planning. Planning and defining the purpose, scope, objectives, policies and procedures, and the organisational and technical context, for Configuration Management.
• Identification. Selecting and identifying the configuration structures for all the infrastructure’s Configuration Item(CI), including their ‘owner’, their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for CIs, labelling each item, and entering it on the Configuration management database (CMDB).
• Control. Ensuring that only authorised and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation, e.g. an approved Change request, and an updated specification.
• Status accounting. The reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’.
• Verification and audit. A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration management system.

Configuration management planning

. A Configuration Management plan should define:

• the purpose, scope and objectives of Configuration Management
• related policies, standards and processes that are specific to the support group
• Configuration Management roles and responsibilities
• CI naming conventions
• the schedule and procedures for performing Configuration Management activities: configuration identification, control, status accounting, configuration audit and verification
• interface control with third parties, e.g. Change Management, suppliers Configuration Management systems design, including scope and key interfaces, covering: CMDB
• locations of Configuration Management data and libraries controlled environments within which CIs are manipulated
• support tools (e.g. build and installation tools)
• housekeeping, including licence management, archiving and the retention period for CIs
• planned configuration baselines, major Releases, milestones, workload and resource plan for each subsequent period.
• Checks should be made to ensure that the staff, IT resources, and support tools – including the size of the CMDB to be made available to Configuration Management – are likely to be adequate.Where deficiencies are identified, steps should be taken to obtain further resources or procure enhanced support tools.

Configuration identification

The IT infrastructure configuration should be broken down and uniquely identified to enable effective control, recording and reporting of CIs to the level that the business requires. The scope should include the hardware, and software used to build, release, verify, install, distribute, maintain, recover and decommission CIs. This includes any environments and software tools used to build a CI. Examples of the components that should be identified are:

• hardware (including network components where relevant)
• system software, including operating systems
• business systems – custom-built applications
• packages – commercial off-the-shelf packages, standard products, and database products,
• physical databases
• environments
• feeds between databases, applications and EDI links
• configuration baselines
• software releases
• configuration documentation, e.g. system and interface specifications, licences, maintenance agreements, SLAs, decommissioning statement
• Change documentation, deviations and waivers
• other resources e.g. Users, suppliers, contracts
• other documentation e.g. IT business processes, workflow, procedures
• network components

CONFIGURATION CHANGE MANAGEMENT

Dept. Head along with IT must implement a controlled change process and provide tailored methods and standard operating procedures for effectively planning, recording, controlling, and validating product requirements and data that contain the requirements. Tailoring will depend on the organization and the level of control or complexity needed.
Configuration management control is accomplished by utilizing the CMDB, a centralized configuration management database, or a series of databases that provide central, logical access to configuration data, containing relevant information such as the configuration items and their attributes, baselines, documentation, changes, and relationships. Requests for Changes must be stored in the CMDB.

Configuration status Accounting
The CMDB tool must be used to track submitted Requests for Changes. The objectives of the system are to provide enhanced coordination, visibility, and accountability. Records describing configuration items must be established and maintained in the CMDB. The tool must assign a unique identifier to each Request for Change and maintain a repository of all change requests. Dept. Heads must record actions in sufficient detail that the content and status of each
Configuration Item is known and previous versions can be recovered. Organizations must maintain product description records, configuration verification records, change status records, and history of change approvals.
The CMDB must contain relevant information about configuration items, their attributes, baselines, documentation, changes, and relationships. The recording of changes must include:

• The reason for the changes
• If a proposed change to the configuration item is accepted, a schedule for incorporating the change into the configuration item and other affected areas
• Indication that changed configuration items have been released only after review and approval of configuration changes. Changes are not official until they are approved

CONFIGURATION VERIFICATION AND AUDITS

Configuration auditing must be performed by ISMS coordinator to verify the integrity of the processes, systems, items, and baselines under Configuration Management control.

• The ISMS coordinator conducts these audits to ensure baseline compliance of the configured assets’ hardware, software, and controlled documentation with established requirements, specifications, and functional parameters.
• Change control processes are also subject to Configuration Management Audits.
• Configuration Management Audits must be used to ensure the accuracy of the CMDB;
• determine the accuracy and completeness of Configuration Management processes;
• verify data and documentation;
• ensure project compliance with requirements, standards, and conventions.

All audit records and respective deficiencies must be placed into the CMDB, which shall be used to track corresponding action items, suspense dates, and close-out activities. The ISMS coordinator can decide whether these attributes need to be tracked within the CMDB since he/she is responsible for conducting periodic audits. The CMDB must be used to maintain a historical file of all audit information throughout the applicable life cycle.
The ISMS coordinator must conduct its audits on a periodic basis following a defined audit sequence.
The ISMS coordinator must have the responsibility to initiate the audit sequence and oversee its implementation.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

Information Security Policies (ISP)  is a set of rules enacted by an organization to ensure that all users or networks of the IT structure within the organization’s domain abide by the prescriptions regarding the security of data stored digitally within the boundaries the organization stretches its authority. An ISP is governing the protection of information, which is one of the many assets a corporation needs to protect.  Putting to work the logical arguments of rationalization, one could say that a policy can be as broad as the creators want it to be: Basically, everything from A to Z in terms of IT security, and even more. Characteristics of good security policies include conciseness, readability, actionability, enforceability, and flexibility. Policies are short and to the point in conveying principles that guide activity within the organization. Policies contain a minimum of specialized vernacular and acronyms; clearly explain any industry-specific terms. Employees at all levels will read the security policies to discern how they should act in the best interest of the organization; therefore, the policy should be actionable at every level of executive strategic planning, management of operations, and actual performance of tasks. The policy must allow for determination of compliance with the policy and enforcement of noncompliance. Moreover, policies should potentially apply to the organization for years and not become outdated with the end of life of any product supporting the policy. Any mention of specific product use is in a standard, not a policy. Explanations on how to use products are in procedures, not in policy.

Review your information security policies on a regular basis, with no more than 12 months from the last review. Define trigger events for a policy review. The first trigger event is the last review plus 12 months. Other trigger events may include a change in the business environment, like a merger, acquisition, or new business venture. Certainly, new legislation or regulatory reform will prompt policy review. Include a statement of review/revision trigger events in the information security policy. A key question is why capture all this detail in written documentation. Just like a contract, written documentation ensures a meeting of the minds. The organization is working off a common understanding of the expectations (e.g., the SMF interpretation guide) and a common understanding of terms (e.g., organization-specific security glossary or risk management glossary). Moreover, the key point is for the organization to capture the policy, standards, procedures, interpretations, and definitions that ensure these details are not just in the minds of a few individuals. It is possible to have excellent security practices in organizations that do not have a single written procedure. Although the practice is good, it is only as good and as enduring as the individual that practices it. The loss of that individual through retirement, resignation, or being hit by the proverbial bus implies a loss (or at least a degradation) of that excellent practice to the organization. Documentation captures knowledge and promotes the learning organization, where proven good practice by one becomes good practice available to all.

Out of carelessness mostly, many organizations without giving much thought choose to download IT policy samples from a website and copy/paste this ready-made material in an attempt to readjust somehow their objectives and policy goals to a mold that is usually crude and has to broad-spectrum protection. Understandably, if the fit is not quite right, the dress would eventually slip off. A high-grade ISP can make the difference between a growing business and a successful one. Improved efficiency, increased productivity, clarity of the objectives each entity has, understanding what IT and data should be secured and why identifying the type and levels of security required, and defining the applicable information security best practices are enough reasons to back up this statement. To put a period to this topic in simple terms, let’s say that if you want to lead a prosperous company in today’s digital era, you certainly need to have a good information security policy. The initial process in developing an information security policy is to identify which laws, regulations, and information security drivers are applicable to your organization.

1. Perform a high-level gap analysis of each regulatory requirement and driver that is applicable to determine where policy is needed.
2. Develop a prioritized action plan that will help you organize your efforts.
3. Prepare a summary document of the impact that the information security policy or policies will have on the organization. The document should:
   1. Describe the policy
   2. Communicate the reason or business justification for the policy, as well as the risks and negative impact of not implementing the policy
   3. Identify regulatory, technical, cultural, and organizational dependencies for implementation of the policy
   4. Identify milestones and possible roadblocks of implementation, compliance, and enforcement
   5. Identify impacted stakeholders
4. Develop the policy in collaboration with other key stakeholders at your organization.
5. Ensure the policy is vetted by impacted subject matter experts and business owners, including information security, legal counsel, human resources, and any other applicable steering committees.
6. Review resources such as the standards and regulations that address specific requirements (e.g., PCI DSS 3.0, HIPAA, GLBA).
7. Publish, communicate, train, and implement.

A. 5.1.1 Policies for information security

Control

Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.

Purpose

To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.

ISO 27002 Guidelines

At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. The information security policy should take into consideration requirements derived from:

1. business strategy and requirements;
2. regulations, legislation and contracts;
3. the current and projected information security risks and threats.

The information security policy should contain statements concerning:

1. definition of information security;
2. information security objectives or the framework for setting information security objectives;
3. principles to guide all activities relating to information security;
4. commitment to satisfy applicable requirements related to information security;
5. commitment to continual improvement of the information security management system;
6. assignment of responsibilities for information security management to defined roles;
7. procedures for handling exemptions and exceptions.

Top management should approve any changes to the information security policy.

At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization.
Examples of such topics include:

1. access control;
2. physical and environmental security;
3. asset management;
4. information transfer;
5. secure configuration and handling of user endpoint devices;
6. networking security;
7. information security incident management;
8. backup;
9. cryptography and key management;
10. information classification and handling;
11. management of technical vulnerabilities;
12. secure development.

The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to:

1. the organization’s business strategy;
2. the organization’s technical environment;
3. regulations, statutes, legislation and contracts;
4. information security risks;
5. the current and projected information security threat environment;
6. lessons learned from information security events and incidents.

The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others.
If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information.

Differences between information security policy and topic-specific policy

Information security policy

Level of detail: General or high-level

Documented and formally approved by: Top Management

Topic-specific policy

Level of detail: Specific and detailed

Documented and formally approved by: Appropriate level of management

Topic-specific policies can vary across organizations.

A Formal Approach to establish policy

The adoption of one or more information security policies is the first step that the organization takes to express its commitment to the protection of their information resources and the information entrusted to them by their and partners. The policy statement should clearly communicate the organization’s beliefs, goals, and objectives for information security.
The information security policy also provides the Organization’s leaders with an opportunity to set a clear plan for information security, describe its role in supporting the missions of the organization, and its commitment to comply with relevant laws and regulations. The policy should be brief, clear to understand, enforceable, and focused on desired behaviors and outcomes, and most importantly, balanced in affording security while enabling and preserving productivity.
An overarching information security policy document is often (though not always) drafted through a consensus-building process with solicitation and feedback from all identified stakeholders. Once approved and published, its effective communication and periodic reviewing and updating ensure that the policy stated intent and corresponding expectations are consistent and relevant over time to reflect changes in technology, laws, business practices, and other factors.
Prior to starting the policy development process, it is important to understand the difference between policies, procedures, guidelines, and standards. Organizational policies are typically broad, short statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. Procedures are more detailed and generally mandatory, describing how to accomplish a task or reach a goal. Guidelines sometimes referred to as best practices, contain information about how to accomplish a task or reach a specific goal, but may not be mandatory. Standards establish a rule from a recognized authority, with no deviation allowed.

Difference between Policy standard, Guidelines, Procedure, and checklist.

What’s in a name? We frequently hear people use the names “policy”, “standard”, and “guideline” to refer to documents that fall within the policy infrastructure. So that those who participate in this consensus process can communicate effectively, we’ll use the following definitions.

• A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. Policies are statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. They are generally represented in a paragraph or perhaps two but not pages. They might say “what” but not “how”. Checklists, procedures, standards, and guidelines all must implement, reflect, and support the applicable policy or policies. The entire set of statements is sometimes considered to be the “Policy.”
• A standard is typically a collection of system-specific or procedural-specific requirements that must be met by everyone. Standards are statements dictating the state of affairs or action in a particular circumstance. They establish a rule from a recognized authority, with no deviation allowed. For example, you might have a standard that describes how to harden a Windows 8.1 workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows 8.1 workstation on an external network segment. In addition, a standard can be a technology selection, e.g. Company Name uses Tenable SecurityCenter for continuous monitoring, and supporting policies and procedures define how it is used.
• A guideline is typically a collection of system-specific or procedural-specific “suggestions” for best practice. They are not requirements to be met but are strongly recommended. in other words, they are not mandatory, but a good idea. Effective security policies make frequent references to standards and guidelines that exist within an organization. Guidelines contain information about how to accomplish some task or reach a specific goal.   They may also contain an element of “best practice” — alternate actions might be available and might work, but what is being provided has proven to be the fastest, cheapest, etc. The more explanatory text is usually involved.
• Procedures contain one or more sentences describing how to accomplish a task or reach a goal – i.e., directive statements. The specified actions are generally mandatory for a specific situation. The more explanatory text is usually involved. A sequence is not necessary but sometimes is important.
• Checklists contain one or more statements dictating how to accomplish a task – i.e., “commands”. The items are applicable to immediate circumstances and mandatory in that situation. They are typically immediately at hand and written in simple language with no amplifying text. The sequence is always important. Flowcharts are also used as a method for conveying similar information.

Some organization has developed a “policy on policies” that provide an organizational statement and set of procedures about how policies are formatted, who develops them, and how they get approved. The benefit of a formal approach is that it makes policy development consistent and recognizes policy development and policy approval authorities. The formal approach can contain the following stages: 1) identify issues, 2) conduct analysis, 3) draft language, 4) get approvals, 5) determine distribution/education, 6) solicit evaluation and review, and 7) plan measurement and compliance. Stages 1 and 2 are considered “pre-development”. Stages 3-5 are part of “development”. Stages 6 and 7 are “maintenance”.
First, issue identification contains a proactive component and is designed to build upon a security risk analysis, including the identification of existing information or data security policies. Second, the identification of the policy owner, policy path, and team to develop the policy is critical to ensuring the ultimate success of the security policy. There are mixed views about whether or not to include legal counsel as part of the policy drafting team or whether they should be a part of a subsequent review process to determine the legal sufficiency of policy documents. There is a danger that security policy could become too legalistic or written in terms too complex for users or employees. On the other hand, lawyers should be knowledgeable about security requirements under Federal or state law. Third, drafting language and getting approvals is a strategic and political process at most organizations. Because of the urgency of computer and network security for our organizations, it may be more expedient to issue “guidelines” or “interim policies and procedures” to protect assets and ensure legal compliance while using shared governance processes for formal review and adoption of organizational policy. Fourth, increasing education and awareness of security issues and corresponding policies and procedures is critical. A policy that no one knows about or worse yet a policy that is not followed can do more harm than good. Finally, the maintenance stage underscores the importance of regularly evaluating security policies to ensure that they are effective and evolve as technology changes.

Policy Elements

If the goal of organizational policies is to direct individual behavior and guide organizational decisions, then the effectiveness of formal policy statements will depend upon their readability and usefulness. Many organization suffers from the lack of a common and consistent approach or format to writing organizational policies. The outline below suggests some common elements that should be included in any security policies.

1. Rationale or Purpose. The rationale or purpose statement expresses “why” the policy is being written. The rationale or purpose may also contain or cross-reference “background” materials or more explanatory details regarding legal, regulatory, or other factors that led to the development of the policy.
2. Policy Statement. The policy statement should be a concise statement of “what” the policy is intended to accomplish. The policy should only be a one or two-sentence description of general organization intent with respect to the specific topic of the policy. The policy statement should be general enough to provide some flexibility and accommodation to periodic changes in technology.
3. Scope of Policy. The scope of the policy can set important parameters such as to whom will the policy apply (e.g., faculty, staff, customers, vendors, and guests) and to what (e.g., paper and electronic records, information and computer assets, etc.)
4. Procedures. The procedures will detail “how” the policy statement will be attained. Procedures may include information on how to report computer security incidents. Procedures may also describe enforcement provisions or methods for appeal. Procedures are some times provided in a separate document or left for local determination to provide greater flexibility for updates as well as local control.
5. Roles and Responsibilities. The procedures may contain details about who is responsible for what. The policy should also identify who is responsible for enforcement or compliance and who will provide interpretations in the event of the need for clarification or when there is a dispute.
6. Definitions. Policies should be precise and easy to understand. Some times terms will need to be defined to clarify meaning. However, the policy should attempt to convey messages in simple yet precise terms; excessive definitions may make a policy document unreadable or subject it to greater scrutiny.
7. References. It is possible that there are other policies or organizational documents that complement, supplement, or help explain the provisions contained within the current policy. References to other policies or organizational documents and citations to statutory or regulatory items can improve the usefulness of the policy.

If a policy is a statement of intent (according to most definitions), then a policy for information security can be defined as a formal high-level statement that embodies the course of action adopted by an organization regarding the use and safeguarding of the organizational information resources. The policy statement should clearly communicate the institution’s beliefs, goals, and objectives for information security.
To be effective an information security policy must:

• Require compliance (i.e., it should be mandatory to the intended audience)
• Be implementable (e.g., impact on legacy systems and current infrastructure)
• Be enforceable. (i.e., failure to comply should result in disciplinary actions)
• Be brief and easy to understand
• Balance protection with productivity

Also, the information security policy should:

• State why the policy is needed (i.e., business reasons)
• Exemplify the organization’s commitment to information security
• Express leadership support for the role of information security in the carrying out of the organization’s missions,
• Focus on desired behaviours (e.g., acceptable use) and outcomes
• Define roles and responsibilities
• Outline the standards and procedures to be followed.

A careful balance must be reached to ensure that the policy enhances organizational security by providing enough detail that community members understand their expected role and contribution but not so much detail that the organization is exposed to unnecessary risk.

Policies for Information Security

There are a number of methods that can be used as a foundation for an organization’s information security policy framework.  Choosing the right policy framework is all about what will work best for the organization and its missions. The organization should consider the following when selecting a framework for its information security policy:

• What works for the Organization?
• What has not worked before?
• What fits the organization’s culture?
• What regulatory requirements must be met?
• What are the organizational drivers?
• What future technology is on the organization’s roadmap?
• What resources (staff, budget, skillsets) are needed to obtain the desired outcomes?

It is important to keep in mind that one of the main goals of an information security policy is to issue directives. The difficult part is deciding on the appropriate level of control to exert. The appropriate level should be informed by the following facts:

• If policies are too restrictive or hard to implement, people will find ways to circumvent the controls.
• Technical controls are not always possible or, at times, desirable.
• Ensure that directives are ‘top-down’—i.e., fully supported by top management.

Organizational Drivers

Since most information security practitioners would agree that it is impossible to protect everything the same way all the time, organizations should identify the business and technical drivers that will guide the creation and implementation of the information security policy as well as assist in its vetting, approval, and socialization. These drivers can be high-level statements that convey the organization’s priorities and direction and help stakeholders make the right decisions regarding what standards to require, what technology to deploy, and how to build the architecture required to implement the policy.
The information security CIA triad exemplifies the highest level driver – to preserve the confidentiality, integrity, and availability of organizational information resources. More specific examples include:

• Uniquely identify and authenticate all users and entities affiliated with the organization.
• Provide users with the least access required to perform their job function
• Adopt information security industry standards where appropriate.
• Implement mitigating controls proactively and based on risk and cost of risk mitigation
• Identify what information the organization maintains, where is it located, and who owns is responsible for it
• Classify the organizational data and safeguard it based on risk
• Balance the business needs to offer and deploy new applications and services against the security risks it might pose to the organization

Review of Information Security Policy

Most organizations will have a documented periodic policy review process in place (e.g., annually) to ensure that policies are kept up to date and relevant. In some cases, a policy manager would be the individual who would determine the need for a new policy or the update to an existing policy. In a small organization, the role of policy manager may be played by the Business Owner (e.g., the Chief Information Security Officer may be the owner/manager of the information security policy.)

Policy Review and Update Drivers

The information security policy owner or manager will review and update the policy at the required intervals or when external or internal drivers require the review and update of the policy. The following are the most common drivers that would prompt a review of the institution’s information security policy.

• Changes in Federal or State laws and regulations
• Changes in technology (e.g., increased use of mobile devices on campus)
• Major information security project deployments (e.g., deployment of Mobile device Management (MDM)
• Audit findings
• Policy format changes (e.g., new policy management function and process)
• Increased reliance on third-party service providers (e.g., outsourcing, cloud)
• New business practices (e.g., online education, telecommuting, telemedicine)

Policy Review and Update Process

The process to review and update the information security policy should include the following steps:

1. Document needed changes
2. Make changes to a draft version of the policy
3. Are the changes significant or alter the intent of the original policy?
4. If Yes, ensure the changes are vetted by impacted subject matter experts and business owners, information security, legal counsel, human resources if applicable, any other applicable steering committee
5. Publish, communicate, train, and implement

Example of Information security policy

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

This clause places requirements on ‘top management’ which is the person or group of people who directs and controls the organization at the highest level. Demonstrating leadership in regard to the ISMS is a core aspect of the IEC 27001 standard. Note that if the organization that is the subject of the ISMS is part of a larger organization, then the term ‘top management’ refers to the smaller organization. The purpose of these requirements is to demonstrate leadership and commitment by leading from the top. A particular responsibility of top management is to establish the information security policy, and the standard defines the characteristics and properties that the policy is to include. Finally, the clause places requirements on top management to assign information security-relevant responsibilities and authorities, highlighting two particular roles concerning ISMS conformance to ISO 27001 and reporting on ISMS performance. It is essential that top management provide the appropriate level of leadership in terms of direction, authority, policy, governance, and organization. Good leadership defines the business purpose of information security creates the mission statement, sets the strategy, provides staff focus on what is important with regard to the information security for the business and what the priorities are, motivates and inspires confidence and trust in the workforce that it is committed to protecting the business and nurtures security culture and security skills. Good ISMS leadership is needed to build a team that will successfully take forward the implementation of the ISMS, which will empower and motivate staff to be proactive followers and supporters in helping to protect the organization. A good ISMS leader will be passionate about being successful in managing the information security risks the organization faces. ISMS leadership should strive to inspire others to see information security as a business enabler, with the vision of turning information security risks into a business opportunity. Leadership is different than management—the former motivates and inspires, creates the vision and points people in the right direction, while the latter administers, controls, and follows the vision and organizes people. Both ISMS leadership and ISMS management together achieve an effective, robust, resilient ISMS. Leadership will be the champion of the ISMS, and management will control and manage the ISMS.

The “Leadership” clause has three sub-clauses ie
Clause 5.1  Leadership and Commitment
Clause 5.2 Policy
Clause 5.3 Organizational roles, responsibilities and authorities.

5.1 Leadership and commitment

Top management must demonstrate leadership and commitment by ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization. The top Management must ensure the integration of the information security management system requirements into the organization’s processes. The top Management must make available the resources needed for the information security management system. The top management must communicate the importance of effective information security management and of conforming to the information security management system requirements. The top Management must ensure that the information security management system achieves its intended outcome which preserves the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed. Top Management must direct and support persons to contribute to the effectiveness of the information security management system. They must also support other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility. They must promote continual improvement. 

The organization’s Top Management must provide leadership and show their support for ISMS. They must demonstrate a commitment to ISMS.  Ensure that ISMS policies are established. Ensure that ISMS objectives are established.  Ensure that ISMS achieves its intended outcomes.  Ensure that ISMS requirements become an integral part of the organization’s processes. Ensure that necessary ISMS resources are available when they are needed. Must communicate a commitment to ISMS.  Make sure that people understand how important information security actually is.  Encourage managers to demonstrate their leadership and commitment to information security within their own areas.

Implementing a Security Strategy

An effective information security strategy for an organization must take into account the overall strategic objectives of the Organization. Even when focusing on critical processes and legal mandates, it is necessary to extend protective measures beyond the underlying IT systems and associated administrative staff. For example, the marketing department has access to customer records, and this access must be considered when assessing the security risks associated with these data. A failure to provide marketing executives with securely configured workstations increases the risk of sensitive data being exposed via their computers. This risk can also be reduced by implementing a middleware solution to properly control which records each executive can access and to minimize the amount of sensitive data stored on their computers. Also, to be effective, security practices cannot rely completely on technological solutions. Continuing the example, policies are required to clearly define each employee’s responsibilities relating to s data and the security of their workstations. Also, awareness programs aimed specifically at employees and their responsibilities to safeguard information might be developed, possibly in conjunction with the CISO(Chief Information Security Officer)
To complicate matters, the operational needs of the Organization often directly conflict with security practices such as perimeter firewalls, port authentication, centralized configuration management, and strong authentication. Organizational networks must, therefore, be designed to balance security and privacy requirements while accommodating a wide variety of end-users and their needs – e.g., visitors, new employees arriving with computers, employees sharing large quantities of data with members of the organizations, remote access to a variety of network services for individuals who are traveling or telecommuting, and mobile users moving between classrooms, libraries, and indoor and outdoor study spots on campus. Although firewalls are becoming widely used to protect critical systems on organization’s networks, their use at the perimeter is less common because it is difficult to reconcile their restrictiveness with the need for an open networking environment that supports research, learning, and high-speed networking. Although centralized management is feasible for certain hosts on organizations’ networks, this approach is not suitable for most computers and many systems. In the end, security and privacy practices need to be integrated into operational practices in a way that makes the most sense.

Effective Organizational governance of the information security function is critical to a successful program. It can be both the “proof of the pudding…” with regard to management commitment and provide necessary guidance when deciding where to allocate scarce resources. This well-researched section draws from experts in the field and provides useful background and advice which can be adapted to a wide variety of cultures.

5.2 Policy

Top management must establish an information security policy which has to be appropriate to the purpose of the organization and must include information security objectives or provides the framework for setting information security objectives. It must also include a commitment to satisfy applicable Information Security requirements and a commitment to continual improvement of the information security management system. The policy must be documented , communicated within the the organization and as appropriate made available to interested parties, .

The organization must establish an information security policy for the organization. The Top Management must ensure that information security policy is appropriate and supports the organization’s purpose. The information security policy must include security objectives or can be used to establish these objectives. The information security policy must make a commitment to comply with all relevant information security requirements. An important aspect of conformance to the requirements of ISO 27001 and of achieving a successful ISMS development and implementation and ongoing management is that such task should be driven and led from the top, by top management. Top management should start by defining an appropriate information security policy for the ISMS. The policy should be a clear management statement of its intentions, objectives, and goals regarding information security and the protection of its information systems. This policy should reflect top management commitment and support for the ISMS to satisfy the requirements in Section 4.1 and address the issues in Section 4.2. It should be a directive from above that typically should address at least the following:

• The scope of information security, its importance to the business, and clarity about what the business information security objectives are (e.g., regarding the protection of the confidentiality, integrity, and availability of its information);
• The need for stall awareness: stall should be aware of their duties and responsibilities regarding the risks (e.g., their responsibility to handle and process sensitive company information in a way that protects it from compromise);
• What is acceptable and not acceptable with regard to behavior and use of its resources (e.g., acceptable use of the company email system);
• Its obligations to carry out its business in compliance with the laws and regulations, contractual obligations, best practices and standards that stall also need to comply with (e.g., compliance with laws on copyright, data privacy/protection and computer use/misuse/abuse);
• Reference to any other documents that stall needs to be aware of and comply with (e.g., more detailed security policies and procedures as well as any other relevant proceedings not directly related to security). This could be industry-specific policies such as those businesses that need to deal with environmental issues, aspects of health care, production of pharmaceutical products or food safety.

This management information security policy should be written in a way that the style and content are independent of any particular skill, process, or technical knowledge. For example, the content should be understandable by someone that is not an IT specialist, someone not trained in company finances or legal affairs, or does not have human resources skills. in other words, it should state information security objectives that are generally understood by all stalls not just people with highly technical backgrounds or certain professional qualifications or skills.

Approval, Communication, and Awareness

This management policy needs to be approved and signed by the CEO (or someone of similar management authority and accountable status) since the aim is to indicate management commitment and support. The policy needs to be communicated across the organization to all staff and interested parties. This could be in paper form or by electronic means or both. Some organizations display their policies on the walls of offices, computer rooms, and other areas to ensure they are continually accessible and visible. Other organizations resort to using ICT to distribute and have available their policies and procedures via their internal network. Others may choose to distribute it in paper only for the stall to keep at their own place of work. Whatever the method used, the policy should not be hidden away and forgotten. Stall needs to read, understand, and refresh their memories every so often about its contents and what it says about their specific information security responsibilities and duties. This policy needs to be reviewed and updated as necessary to take account of the changing nature of the information security risk environment and evolving organizational developments and changes. There needs to be a review process for maintaining this policy, as is the case with all policies and procedures, as part of the ISMS continual improvement process. This management policy is a high-level policy that “sets the scene,” and typically there will more detailed policies, which will give more specific rules and instructions on the implementation of information security protection. For example, policies on access control cover the rules of access to different organizational resources and facilities such as email servers, databases, network services, applications as well as physical access to buildings, offices, rooms, and storage equipment.

5.3 Organizational roles, responsibilities and authorities

Top management must ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated. Top management must assign the responsibility and authority for ensuring that the information security management system conforms to the requirements of this International Standard, and reporting on the performance of the information security management system to top management.  Top management may also assign responsibilities and authorities for reporting the performance of the information security management system within the organization.

Roles and Responsibilities

Involvement from top management is critical to the design and effectiveness of any information security program. The definition of “top management” can vary from organization depending on size and structure, but in general, “top management” should involve members of the senior executive team responsible for making strategic decisions within the organization. The intent of involving top management within the information security program is to ensure that enterprise governance is aligned with the information security governance framework. Components of a well-designed information security governance program include leadership, structure, and processes designed to protect an organization’s information security assets. Effective information security governance requires that top management have clear expectations about what to expect from the information security program, how to evaluate the organization’s risk posture, and how to define information security objectives that are in alignment with the strategic direction and goals of the organization. Top Management must allocate responsibility and authority for carrying out information security roles to the appropriate people within the organization. Top Management must communicate all relevant information security management roles, responsibilities, and authorities. Top management’s involvement with the information security program includes ensuring that the intended outcomes of the information security program are achieved, which could include the following:

• Alignment with business strategy to meet the organization’s strategic objectives.
• A risk management program that identifies and mitigates the impacts to an organization’s resources and assets.
• Effective and efficient resource management
• Timely and useful metrics reporting
• Value-added information security initiatives

Security is ultimately the responsibility of all employees within an organization; however, the most successful information security programs demonstrate effective leadership from top management by setting a “tone at the top” and championing the importance of information security through well-designed policy and direction. The result can be an organization with information security ingrained as part of its culture. The ISO 27001 standard requires that organizations demonstrate leadership and commitment from top management as outlined in Clauses 5 (Leadership) and 9.3 (Management review). The focus within Clause 5 is on the design of the information security management system (ISMS) which requires involvement from top management and includes the establishment of the information security policy and an organizational structure where the responsibilities and roles relevant to information security are defined and communicated. The focus within Clause 9.3 is to establish procedures for top management to be continually involved in the evaluation of the ISMS to ensure its effectiveness. The members of top management that are involved with the leadership of the ISMS should consider the scope of the ISMS. Involvement from top management can vary by organization, but the scope of the ISMS should be considered when determining who from top management will be involved from a leadership and commitment standpoint. Typically, organizations begin by selecting a committee responsible for overseeing the design, operation, maintenance, and improvement of the ISMS. The committee should include members from top management and members from the information security team.
An organization that is able to successfully implement the requirements of Clause 5 will establish an ISMS program with the oversight, support, and direction of top management; an information security policy that includes information security objectives and is appropriate to the organization; and an organizational structure that incorporates information security with upstream channels so that information security performance is effectively reported to top management. In addition to involving top management in the design of the ISMS, they are required to review and evaluate the performance of the ISMS on a continual basis. The frequent involvement of top management during the evaluation phase of the ISMS is a critical requirement. The intent is to provide regular feedback on the performance of the ISMS so that changes in the environment or processes not performing as expected are identified promptly so that corrective action can be successfully implemented. An organization that can successfully implement the requirements of Clause 9.3 will be able to consistently and continually evaluate the operation of the ISMS, with input from top management to ensure the intent and objectives of the ISMS are being achieved and that the improvements are implemented where necessary.

Day-to-day working and operational activities functioning effectively, and the proper management of staff, at all levels throughout the organization, can contribute to an effective information security business environment. In part, this requires a good information security culture within the organization to be in place, with appropriate awareness and understanding of the problems of information security risks and clear lines of responsibility and accountability. It is essential that roles and responsibilities for protecting specific types of information or information systems or for carrying out specific information security-related processes are clearly defined and allocated. For example:

• The owner of an information system should be given the information security responsibility and accountability for that system (of course,  these owners may delegate that day-to-day implementation of security to another individual or to a service provider, but they remain ultimately accountable for the protection of the system and the management of the information security risks);
• Personal data manager;
• Business owner—a specific department/group (ensures implementation of policy and procedures, defines information usage and classification for information in their custody, allocates information custodians,defines access roles and privileges, conducts staff training and awareness and provides protection of personal data under their control);
• Chief information security officer (CISO);
• Information security incident response team;
• Business continuity manager;
• Internal auditors;
• Human resource manager;
• IT services manager (IT service management, IT disaster recovery, involvement in incident management);
• IT and network administrators/managers (network management, secure network technologies, involvement in incident management);

Authorized users of information systems. In addition, all staff will have general responsibility for information security related to their day-to-day work. For example, reporting of unusual or suspicious behavior either related to their use of IT, network services, or related to other staff or visitors. Also, all individual staff needs to be aware of their responsibility for keeping their passwords and other types of access codes secure, to ensure that they are using organizational resources in accordance with the acceptable usage policy (e.g., rules for using email for sending file attachments).

Resources

As with any successful business venture, it is important to have the right types of resources for the jobs that need to be done. Having stall with the right competence to do a job properly, efficiently, and effectively is key to the overall success of the business. If it is a technical job, then the stall involved need to have the right level of knowledge and skill to handle the technical requirements of the job at hand, to resolve technical problems, and to be able to use techniques, methods, equipment, and procedures relevant to the technical area in question. If it’s a customer service job, then the staff involved must have the relevant skills needed to deal with customers (e.g., they are able to listen and respond effectively to customer’s questions and queries, they are able to satisfactorily resolve customer queries and problems, follow up on feedback from customers and generally be able to meet the expectations of the organization’s customers). Management needs to ensure that for specific information security tasks, it has the right people, with the right skills and knowledge, and experience. This can mean recruiting people who have the right existing skills and experience or recruiting people and providing a training program for them to develop the right skills and experience. In addition, all staff working in the field of information security, whether those with experience or those in training, need to keep up to date as the issues and risks in information security continually evolve, as do technology and business practices. Every organization strives to have human resources with certain core competence, and many organizations seek staff with information security skills. The market is expanding, becoming more buoyant, and becoming highly competitive. For many years, organizations have recruited information security personnel with hands-on experience, practical knowledge, and appropriate references. Even though this is still the general basis of recruitment, more and more organizations have started to request applicants have market-proven professional qualifications, personal certifications, and in some cases university qualifications or a combination of both. The current education and training market provides certified qualifications, for example, in areas such as:

• information security auditing;
• information security management;
• Risk management;
• Information assurance;
• Governance
• IT security;
• Physical security.

Training and Awareness

The organization needs to ensure that staff are aware of information security risks and have a sufficient understanding to support the organization’s information security policy to undertake their normal work functions and tasks. Staff should be trained in the use of information security policies and procedures, security controls applicable to their job function, and the correct use of IT (e.g., log-in procedures, keeping passwords safe, appropriate use of IT). Training should take place during:

• Induction training for new staff upon joining the organization. This should cover the company’s information security policies, procedures, and routine practices, whom to contact for help and support regarding information security matters and whom to report security problems to, initial familiarization with the common types of risk malware, hacking, protection of commercially sensitive information and the protection of personal data, fraud, use of email and so on.
• On-the-job training providing specifically tailored instructions on information security suited to the individual’s job function.
• Annual (or more frequent) refresher training to keep stalls up to date with new developments and to provide organization-wide reminders or more immediate remedial training as the result of a security incident or an emerging risk.

An organization can deploy a variety of methods to deliver effective information security awareness and training to its staff. The methods that an organization selects will depend on the business culture and its operational needs. Therefore, an information security awareness and training program should be tailored to the specifics of the organization. You should alternate between different methods, perhaps introducing an element of motivational instruction together with practical interactivity.

• Classroom-based training can be highly interactive—such training can vary from half-day/one-day induction/beginners training course, through to various intermediate/advance three-to-five-day training courses covering a range of specific topics.
• Computer-based/online web-based training and awareness is a good method for reinforcing information security principles and specific topics. Such training can be delivered as a set of modules, interactive or noninteractive, and be accessible to staff at a time and place convenient to the individual.
• Seminars, workshops, round-table discussions, and presentations are especially well suited for introducing the new subject matter and for organizations with multiple sites;
• Videos are also an effective way to provide training on various topics.
• Posters provide visual reinforcement of information security principles and specific topics.
• On-the-job/desktop training is available.
• Internal emails can be used to remind, reinforce and provide updates on organizational policies and procedures.

ISMS-Related Topics

Implementing the requirements of ISO/1EC 27001 covers many different tasks, activities, and processes that need to be carried out, and these are associated with a number of specific topics that information security professionals, practitioners and other staff will need to have knowledge of and develop experience in, depending on their particular job function. For example, an internal ISMS auditor will require knowledge of the auditing process and methods, whereas an ISMS risk manager would need knowledge and skills of the principles of risk management. These include:

• Principles of risk management
• Risk assessment;
• Risk treatment.
• Information security controls:
• Generic controls eg, as found in ISO 27002, NIST SP 800 etc;
• Sector-specific controls eg, as found in ISO 27010, 27011,27015, 27017, 27018, 27019.
• Performance evaluations:
• Measuring and monitoring methods and techniques eg, as found in ISO 27004
• ISMS auditing process and methods (eg., as found in 1S0 19011 and 27007).
• Certification and auditing
• Certification eg, as found in ISO 27006, ISO 17021;
• Auditing (e.g., as found in ISO 27007, ISO 19011).
• Legislation and regulations related to information security and privacy
• National and regional laws and directives;
• Standards covering privacy leg, as found in ISO 29100, 29134, 29190).
• Other specific security-related processes
• Incident handling (e.g., as found in ISO 27035, NIST SP 800-61);
• Business continuity e.g., as found in ISO 22301, ISO 27031
• Operational resilience e.g., as found in B5 16000.
• Specific IT security controls and mechanisms
• Network security (e.g., as found in ISO 27033);
• Applications security (e.g., as found in ISO 27034);
• Malware (eg. as found in NIST SP 800-83);
• Firewalls, IDS, IPS;
• Access control.

Example of Consolidated Roles and Responsibilities

1) Executive Vice President and Chief Information Officer

The executive vice president and chief information officer (CIO) are responsible for the following:

1. Acting as the senior information technology (IT) decision-maker and corporate change agent to securely integrate the key components of business transformation: technology, processes, and people.
2. Providing advice and assistance to senior managers on information security policy and their compliance-based performance.
3. Promoting the implementation of an information security architecture to mitigate information security-related risk.
4. Promoting the protection of corporate information resources across postal Service organizations and business partners
5. Together with the vice president of the functional business area (data steward) and chief privacy officer (CPO), approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. If this responsibility is delegated, notice to that effect must be writing.

2) Chief Postal Inspector

The chief postal inspector is responsible for the following:

1. Establishing policies, procedures, standards, and requirements for personnel, physical, and environmental security.
2. Approving the identification of sensitive positions.
3. Conducting background investigations and granting personnel clearances.
4. Conducting site security reviews, surveys, and investigations of facilities containing Postal Service computer and telecommunications equipment to evaluate all aspects of physical, environmental, and personnel security.
5. Providing technical guidance on physical and environmental security activities that support information security, such as controlled areas, access lists, physical access control systems, and identification badges; providing protection of workstations, portable devices, and media containing sensitive-enhanced, sensitive, or critical information.
6. Providing security consultation and guidance during the system, application, and product development to assure that security concerns are addressed and information and/or evidence that may be needed for an investigation is retained by the information resource.
7. Assisting the manager, Corporate Information Security Officer (CISO), with reviews, as appropriate.
8. Investigating reported security incidents and violations.
9. Conducting revenue/financial investigations including theft, embezzlement, or fraudulent activity.
10. Providing physical protection and containment assistance and investigating information security incidents as appropriate.
11. Funding CISO investigative efforts outside of those normally required.
12. Managing, securing, scanning, and monitoring the Inspection Service’s network and information technology infrastructure.
13. Defining high-risk international destinations where personnel is prohibited from traveling with their standard-issue Postal Service computers and communications equipment (including laptops, notebook computers, external hard drives, Blackberry devices, USB devices, etc.)
14. Providing temporary equipment to use when traveling to high-risk international destinations

3) Vice President, Information Technology

The vice president, IT, is responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.
2. Ensuring confidentiality, availability, and integrity of information processed by IT applications.
3. Ensuring compliance with the information security certification and accreditation processes.
4. Together with the vice president of the functional business area, accepting, in writing, residual risks of information resources under their control. The VP IT may delegate this authority to the applicable Business Relationship Management manager. If this authority is delegated, notice to that effect must be in writing.
5. Reporting to senior management on the status of an incident with a major IT application.
6. Defining and documenting secure coding best practices.

4)  Manager, Computer Operations

The manager of Computer Operations is responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.
2. Ensuring confidentiality, availability, and integrity of information processed at IT sites.
3. Ensuring the protection and secure implementation of the Postal Service IT infrastructure.
4. Supporting information security certification and accreditation processes.
5. Together with the vice president of the functional business area (data steward) and CPO, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from an IT facility.
6. Reporting to senior management on the status of an incident at a major IT facility.
7. Reviewing and utilizing C&A documentation in the IT Artifacts Library.
8. Resolving identified vulnerabilities.

5) Manager, Corporate Information Security Office

The manager, CISO, is responsible for the following:

1. Setting the overall strategic and operational direction of the Postal Service information security program and the program’s implementation strategies.
2. Engaging at any point on any level for issues related to information security that impact the Postal Service.
3. Recommending members to the Information Security Executive Council.
4. Developing and disseminating information security policies, processes, standards, and procedures.
5. Managing the certification and accreditation (C&A) process.
6. Providing guidance on application security, reviewing the C&A documentation package, and accrediting sensitive-enhanced, sensitive, and critical information resources developed for, endorsed by, or operated on behalf of the Postal Service.
7. Managing the Network Connectivity Review Board (NCRB) process.
8. Authorizing temporary access to information resource services.
9. Conducting site security reviews or providing support to the Postal Inspection Service during its site security reviews, as requested.
10. Providing consulting support for securing the network perimeter, infrastructure, integrity controls, asset inventory, identification, authentication, authorization, intrusion detection, penetration testing, and audit logs and for information security architecture, technologies, procedures, and controls.
11. Approving encryption technologies.
12. Providing leadership of the security initiatives for the Enterprise Architecture Forum.
13. Developing and implementing a comprehensive information security training and awareness program that is mandatory for all employees at the time of hire and annually thereafter.
14. Serving as the central point of contact for all information security issues and providing overall consultation and advice on information security policies, processes, standards, procedures, requirements,controls, services, and issues.
15. At least semi-annually, assessing the adequacy of information security policy and process to reflect changes to business objectives and the operating environment (including technology infrastructure, threats, vulnerabilities, and risks).
16. At least annually, assessing the adequacy of information security controls and recommending changes as necessary.
17. Establishing evaluation criteria and recommending security hardware, software, and audit tools.
18. Approving the establishment of shared accounts
19. Ensuring compliance with information security policies and standards through inspections, reviews, and evaluations.
20. Providing support to the Office of the Inspector General (OIG) and the Inspection Service during the conduct of investigative activities concerning information security, the computing infrastructure, and network intrusions, as requested.
21. Providing support to the chief postal inspector during the conduct of facility/site security reviews, as requested.
22. Escalating security issues to executive management and promulgating security issues and recommended corrective actions across the Postal Service.
23. Authorizing monitoring and surveillance activities of information resources.
24. Authorizing (in case of threats to the Postal Service infrastructure, network, or operations) appropriate actions that may include viewing and/or disclosing data to protect Postal Service resources or the nation’s communications infrastructure.
25. Confiscating and removing any information resource suspected of inappropriate use or violation of Postal Service information security policies to preserve evidence that might be used in forensic analysis of a security incident.
26. Reviewing and approving information security policy for mail processing equipment/mail-handling equipment (MPE /MHE).

6) Information Security Executive Council

The Information Security Executive Council consists of appropriate Postal Service representatives and serves as a steering committee advising the CISO and promulgating information security throughout the Postal Service.

7) Vice Presidents, Functional Business Areas

The vice presidents of Postal Service functional business areas are responsible for the following:

1. Ensuring resources are available for completing information security tasks.
2. Ensuring the security of all information resources within their organization.
3. Together with the VP IT, accepting, in writing, residual risks of information resources under their control. The vice presidents of functional business areas may delegate this authority to the applicable executive sponsor. If this authority is delegated, notice to that effect must be in writing.
4. Ensuring that contractual agreements require all suppliers, contractors, vendors, and business partners to adhere to Postal Service information security policies.
5. Together with the CIO and CPO, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. (If this responsibility is  delegated, the delegation of responsibility must be writing.)

8) Vice President, Engineering

The vice president, Engineering, is responsible for ensuring the security of information resources used in support of the MPE/MHE environment,  including technology acquisition, development, and maintenance.

9) Vice President, Network Operations

The vice president, Network Operations, is responsible for the security of the mail and information resources used in support of MPE/MHE strategies and logistics.

10) Officers and Managers

All officers, business and line managers, and supervisors, regardless of functional area, are responsible for the following:

1. Implementing information security policies, ensuring compliance with information security policies by organizations and information resources under their direction, and invoking user sanctions as required.
2. Identifying sensitive information positions in their organizations and ensuring that personnel occupying sensitive positions hold the appropriate level of clearance.
3. Managing access authorizations and documenting information security responsibilities for all personnel under their supervision.
4. Ensuring all personnel under their supervision receive information security training commensurate with their responsibilities upon hire and annually thereafter, and maintaining auditable training records when there isn’t an automated system.
5. Ensuring all personnel under their supervision comply with Postal Service information security policies and procedures.
6. Including employee information security performance in performance evaluations.
7. Supervising information security responsibilities of their onsite contractor personnel.
8. Processing departing personnel appropriately and notifying the appropriate system and database administrators when personnel no longer require access to information resources.
9. Initiating a written request for message data content or Internet usage monitoring and sending it to the CPO for approval.
10. Approving or denying requests, by personnel under their supervision, for access to information resources beyond temporary information resource services and reviewing those access authorizations on a semiannual basis.
11. Ensuring that all hardware and software are obtained in accordance with official Postal Service processes.
12. Protecting information resources and ensuring their availability through business continuity activities including plans, procedures, off-site backups, periodic testing, workarounds, and training/cross-training essential and alternate personnel.
13. Ensuring that personnel under their supervision who remove a portable electronic device or media from a Postal Service facility are aware of their responsibility for its security and have a place to secure the device or media when it is not being used. Ensuring compliance with Postal Service information security policy and procedures.
14. Reporting suspected information security incidents to the Computer Incident Response Team (CIRT) immediately, protecting information resources at risk during security incidents, containing the incident, and following continuity plans for disruptive incidents

11) Executive Sponsors

Executive sponsors, as representatives of the vice president of the functional business area, are the business managers with oversight (e.g., funding, development, production, and maintenance) of the information resource and are responsible for the following:

1. Consulting with the CPO for determining information sensitivity and  Privacy Act applicability.
2. Ensuring a business impact assessment (BIA) is conducted to determine the sensitivity and criticality of each information resource under his or her control and to determine the potential consequences of information resource unavailability.
3. Providing resources to ensure that security requirements are properly addressed and information resources are properly protected.
4. Ensuring completion of a site security review, if the facility hosts an information resource designated as sensitive-enhanced, sensitive, or critical.
5. Ensuring that contract personnel under their supervision comply with Postal Service information security policies and procedures.
6. Ensuring that all information security requirements are included in contracts and strategic alliances.
7. Ensuring compliance with and implementation of the Postal Service privacy policy; data collection, retention, and destruction policies; customer or employee privacy notices; and software licensing.
8. Appointing, in writing, an information systems security representative (ISSR).
9. Ensuring completion of security-related activities throughout the Information resource C&A life cycle.
10. Ensuring that information resources within their purview are capable of enforcing appropriate levels of information security services to ensure data integrity.
11. Preventing residual data from being exposed to unauthorized users as information resources are released or reallocated.
12. Authorizing access to the information resources under their control and reviewing those access authorizations on a semiannual basis.
13. Maintaining an accurate inventory of Postal Service information resources and coordinating hardware and software upgrades.
14. Ensuring appropriate funding for proposed business partner connectivity, including costs associated with the continued support for the life of the connection.
15. Initiating and complying with the network connectivity request requirements and process as documented in the Information Security Network Connectivity Process.
16. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.
17. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.
18. Funding application recovery (including but not limited to hardware/  software licenses required, continuity plan development, testing, and maintenance) for applications.
19. If the VP functional business area delegated this authority to the executive sponsor, the executive sponsor will work jointly with the VP IT (or the Business Relationship Management manager if this authority is delegated) to review the C&A documentation package, accept the residual risk to an application, and approve the application for production or return the application to the applicable life cycle phase for rework.
20. Reporting suspected information security incidents to the CIRT immediately, protecting information resources at risk during the security incident, containing the incident, and following continuity plans for disruptive incidents.
21. Coordinating the resolution of identified vulnerabilities with the appropriate IT organization (e.g., Computer Operations, Business Relationship Management, Solutions Development and Support, etc.).

12) Functional System Coordinators

The functional system coordinator (FSC) role is an ad hoc activity assigned by a data steward and is not a position or job function. An FSC has expert knowledge of the information resource and is familiar with the people and levels of access being requested. The FSC role may be required for all information resources registered in eAccess. The FSC role is restricted to Postal Service employees. An FSC is responsible for approving or denying a request based on the role or access level requested. If access to sensitive information is requested, the requestor must have a sensitive clearance. The FSC has the last level of approval before a request is sent to the log-on administrator to create the account, which will then become active.

13) Business Relationship Management Portfolio Managers

Business Relationship Management portfolio managers are responsible for the following:

1. Supporting the executive sponsor in the development of information resources and the C&A process, including the BIA, risk assessment, and business continuity plans.
2. If an ISSR has not been assigned by the executive sponsor, appointing an ISSR to perform security-related activities.
3. Providing coordination and support to executive sponsors and disaster recovery (DR) service providers for all matters relating to business continuity planning.
4. Reviewing the C&A documentation package and completing a risk mitigation plan for risks identified as high or medium. If a documented high or medium vulnerability will not be mitigated, preparing and signing a Risk Acceptance Letter as part of the C&A process.
5. Business Relationship Management portfolio managers are responsible for the following: If the VP IT delegated this authority to the Business Relationship Management portfolio manager, the Business Relationship Management portfolio managers will work jointly with the vice president of the functional business area (or the executive sponsor, if this authority is delegated) to review the C&A documentation package, accept the residual risk to an information resource, and approve the information resource for production or return the information resource to the applicable life-cycle phase for rework.
6. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.
7. Ensuring that the information resource is registered in eAccess.
8. Accepting personal accountability for adverse consequences if the information resource was placed in production before the C&A process was completed.
9. Completing along with their staff the annual C&A training.
10. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.
11. Resolving identified vulnerabilities.
12. Managing projects through their project managers who are responsible for the following:

1. Developing and maintaining C&A documentation as required.
2. Incorporating the appropriate security controls in all information resources. Ensuring that the information resource is entered in the Enterprise Information Repository (EIR) and updated as required.
3. Filing C&A documentation in the IT Artifacts Library and maintaining the hard copies and electronic copies for the appropriate retention periods

14) Managers of Information Technology Solution Centers

The managers of Information Technology Solution Centers are responsible for the following:

1. Sponsoring information security and business continuity management programs and ensuring that financial, personnel, and physical resources are available for completing security and business continuity tasks.
2. Ensuring confidentiality, availability, and integrity of data.
3. Ensuring the protection and secure implementation of the Postal Service IT infrastructure.
4. Ensuring compliance with the information security C&A processes.
5. Together with the vice president of the functional business area, accepting, in writing, the residual risk of applications and approving deployment.
6. Together with the vice president of the functional business area, approving the removal of portable electronic devices or media containing sensitive-enhanced or sensitive information from a Postal Service facility. (If this responsibility is delegated, notice to that effect must be writing.)
7. Managing projects through their project managers who are responsible for the following:

1. Incorporating the appropriate security controls in all information resources.
2. Notifying the NCRB when the business partner trading agreement ends or when network connectivity is no longer required.
3. On a semiannual basis, reviewing and validating business partner connectivity to the Postal Service intranet.
4. Functioning as the incident management team leader for their facility.
5. Identifying and training key technical personnel to provide support in business continuity planning for their facility, information resources housed in their facility, and the alternate DR facilities.
6. Resolving identified vulnerabilities.

15) Installation Heads

Installation heads are in charge of Postal Service facilities or organizations, such as areas, districts, Post Offices, mail processing facilities, parts depots, vehicle maintenance facilities, computer service centres, or other installations. Installation heads are responsible for the following:

1. Designating a security control officer (SCO) who is responsible for personnel and physical security at that facility, including the physical protection of computer systems, equipment, and information located therein.
2. Implementing physical and environmental security support for information security, such as the protection of workstations, portable devices, and media containing sensitive-enhanced, sensitive, or critical information.
3. Controlling physical access to the facility, including the establishment and implementation of controlled areas, access lists, physical access control systems, and identification badges.
4. Funding building security equipment and security-related building modifications.
5. Maintaining an accurate inventory of Postal Service information resources at their facilities and implementing appropriate hardware security and configuration management.
6. Maintaining and upgrading all security investigative equipment, as necessary.
7. Ensuring completion of a site security review, providing assistance to the Inspection Service and CISO as required, and accepting site residual risk.
8. Ensuring that the Postal Service security policy, standards, and procedures are followed in all activities related to information resources (including procurement, development, and operation) at their facility.
9. Ensuring that all employees who use or are associated with the information resources in the facility are provided information security training commensurate with their responsibilities and take appropriate action in response to employees who violate established security policy or procedures.
10. Cooperating with the Inspection Service to ensure the physical protection of the network infrastructure located at the facility.
11. Reporting information security incidents to the CIRT immediately, containing the incident, following continuity plans for disruptive incidents, and assessing damage caused by the incident.
12. Resolving identified vulnerabilities.
13. Developing, maintaining, and testing:

1. Workgroup Recovery Plan required for each business function.
2. Emergency Action Plans required for each facility to ensure personnel are safely evacuated and provides for the protection of the employees.
3. Incident Management Facility Recovery Plan required for each major IT site.
4. Disaster Recovery Plan (DRP) (business information systems disaster) documents required for each critical system that supports essential (core) business functions.

14. Implementing and managing the following plans and team members:

1. Emergency Action Plan.
2. Incident Management Facility Recovery Plan.
3. Workgroup Recovery and “Beyond” Continuity of Operations(COOP) Plans.
4. DRP (business information systems disaster) documents.

16) Chief Privacy Officer

The CPO is responsible for the following:

1. Developing policy for defining information sensitivity and determining information sensitivity designations.
2. Providing guidance on privacy issues to ensure Postal Service compliance with the Privacy Act, the Freedom of Information Act, Gramm-Leach-Bliley Act, and Children’s Online Privacy Protection Act.
3. Developing privacy compliance standards, customer or employee privacy notices, and customer data collection standards, including cookies and Web-transfer notifications.
4. Developing appropriate data record retention, disposal, and release procedures and standards.
5. Approving requests for message data content or Internet usage monitoring.
6. Consulting on and reviewing the BIA and approving the determination of information sensitivity.
7. Providing guidance throughout the investigation of a mass data compromise relating to the privacy of customer and employee/contractor personal information.
8. Developing communications to transmit to impacted parties to amass data compromise.

17) Inspector General

The inspector general is responsible for the following:

1. Conducting independent financial audits and evaluation of the operation of the Postal Service to ensure that its assets and resources are fully protected.
2. Preventing, detecting, and reporting fraud, waste, and program abuse.
3. Investigating computer intrusions and attacks against Postal Service information resources per agreement with the Inspection Service.
4. Investigating the release or attempted release of malicious code onto Postal Service information resources.
5. Investigating the use of Postal Service information resources to attack external networks.
6. Promoting efficiency in the operation of the Postal Service.
7. Funding CISO investigative efforts outside of those normally required.
8. The manager, Technical Crimes Unit (TCU), is responsible for the following:

1. Functioning as an ongoing liaison with the CIRT.
2. Serving as a point of contact between the CIRT and law enforcement agencies.
3. Conducting criminal investigations of attacks upon Postal Service networks and computers.

18) Manager, Business Continuance Management

The manager, Business Continuance Management, is responsible for the following:

1. Protecting the health and safety of Postal Service employees.
2. Ensuring the continuity of business, expediting recovery from a loss of a single critical system or a major disruption to business functions.
3. Reviewing and assessing Business Continuity Management (BCM) program plans.
4. Defining, planning, developing, implementing, managing, assuring the testing and exercising, and monitoring for compliance of a sustainable BCM program for the Postal Service.
5. Ensuring appropriate Business Continuity Plans (BCPs) are developed, tested, and exercised for business functions and information technology services.
6. Ensuring appropriate DRP documents are developed and business information systems are tested for all critical and business functions and services.
7. Certifying all DRP test and BCP exercise.
8. Developing and implementing lines of communication to the IT organization about BCM matters.
9. Promoting BCM awareness and providing training for Postal Service personnel.
10. Ensuring compliance with BCM and information security policies.
11. Establishing a BCM policy and strategy.

19) Manager, Telecommunications Services

The manager, Telecommunications Services (TS), is responsible for the following:

1. Implementing and maintaining operational information security throughout the network infrastructure including timely security patch management. Critical security patches for PCI-related information resources must be installed within 30 days of release.
2. Recommending and deploying network hardware and software based on the Postal Service security architecture.
3. Operational monitoring and tracking of all physical connections between any component of the Postal Service telecommunications infrastructure and any associated information resource not under Postal Service control.
4. Implementing security controls and processes to safeguard the availability and integrity of the Postal Service intranet including physical access to network infrastructure and the confidentiality of sensitive enhanced and sensitive information.
5. Implementing the network perimeter firewalls, demilitarized zones, secure enclaves, and proxy servers.
6. Designating TS representative to the NCRB.
7. Ensuring secure and appropriate connectivity to the Postal Service intranet.
8. Ensuring network services and protocols used by Postal Service information resources provide the appropriate level of security for the Postal Service intranet and the information transmitted.
9. Implementing secure methods of remote access and appropriate remote access controls.
10. Implementing two-factor authentication and the associated infrastructure for network management.
11. Implementing only Postal Service-approved encryption technology.
12. Implementing appropriate network security administration and managing accounts appropriately.
13. Maintaining the integrity of data and network information resources.
14. Supporting the implementation of approved security incident detection and prevention technologies (e.g., virus scanning, intrusion detection systems, and intrusion prevention systems) throughout the perimeter.
15. Maintaining an accurate inventory of Postal Service network information resources.
16. Monitoring network security alerts and logs and providing network security audit logs to the CISO ISS.
17. Ensuring that recovery plans and sufficient capacity are in place for the recovery of the telecommunications infrastructure for the IT-supported Postal Service sites.
18. Identifying and training key technical personnel to provide support in BCM for information resources housed in IT-supported Postal Service sites.
19. Monitoring network traffic for anomalies, conducting perimeter scanning for viruses, malicious code, and usage of nonstandard network protocols, and immediately reporting suspected information security incidents to the CIRT.
20. Protecting information resources at risk during security incidents (if feasible) and providing support for CIRT incident containment and response.
21. Approving all wireless technology before any implementation activities are initiated.
22. Implementing and managing wireless local area network connectivity.
23. Detecting unauthorized access points.
24. Resolving identified vulnerabilities.

20) Managers Responsible for Computing Operations

The managers responsible for computing operations are responsible for the following:

1. Implementing information security policies, procedures, and standards and ensuring compliance.
2. Coordinating and implementing standard platform configurations based on the Postal Service security architecture.
3. Creating and maintaining a timely patch management process and deploying patches to resources under their control. Critical security patches for PCI-related information resources must be installed within 30 days of release.
4. Maintaining an accurate inventory of Postal Service information resources, tracking and reacting to security vulnerability alerts, coordinating hardware and software upgrades, and maintaining appropriate records.
5. Deploying and maintaining anti-virus software and recognition patterns to scan for malicious code and usage of nonstandard network protocols.
6. Supporting the C&A process for internally managed information resources.
7. Ensuring that remote access is appropriately managed.
8. Implementing appropriate security administration and ensuring that accounts are managed appropriately.
9. Maintaining the integrity of data and information resources and ensuring the appropriate level of information resource availability.
10. Ensuring the installation of the authorized internal warning banner
11. Disseminating security awareness and warning advisories to local users.
12. Reporting suspected information security incidents to the CIRT immediately, protecting information resources at risk during security incidents, implementing containment, and assisting in restoring information resources following an attack.
13. Resolving identified vulnerabilities.

21) Manager, Corporate Information Security Office, Information Systems Security

The manager, CISO ISS is responsible for the following:

1. Determining the requirements and standards for secure enclaves.
2. Assessing information resources to determine the need for placement in a secure enclave.
3. Recommending and approving standard configurations and hardening standards for Postal Service information resources.
4. Approving two-factor authentication (e.g., digital certificates, digital signatures, biometrics, smart cards, and tokens) and the associated infrastructure for network management.
5. Approving and managing intrusion detection systems and intrusion prevention systems.
6. Approving, managing, and ensuring appropriate perimeter penetration testing and network vulnerability scans and testing.
7. Providing support to the OIG during the conduct of investigative activities concerning information security, the computing infrastructures, and network intrusion as requested.
8. Approving the use of networking monitoring tools, except those used by the OIG.
9. Providing support to the chief postal inspector during his or her conduct of site security reviews as requested.
10. Conducting monitoring and surveillance activities.
11. Collecting, correlating, and reviewing all Postal Service security audit log files and security alerts.
12. Reviewing information security policy and processes for MPE/MHE.
13. Developing and maintaining an information security architecture and coordinating a secure Postal Service computing infrastructure by setting standards and developing the security processes and procedures.
14. Removing network connectivity from any computing device that does not meet the defined operating system and anti-virus software and recognition pattern thresholds.
15. Managing the NCRB to control connectivity to the Postal Service computing infrastructure.
16. Designating the chairperson of the NCRB and additional ISS representatives to the NCRB, as required.
17. Ordering the disabling of an information resource or network connection that does not comply with Postal Service policies, procedures, and standards or which is found to pose a significantly greater risk than when originally assessed.
18. Managing the CIRT to help the Postal Service contain, eradicate, document, and recover following a computer security incident and return to a normal operating state.

19. The NCRB is responsible for the following:

1. Managing the Postal Service network connectivity process through the implementation of the Information Security Network Connectivity Process.
2. Developing system connectivity requirements for Postal Service connections to external systems, externally facing information resources (e.g., FTP servers), and connections via the Internet to Postal Service development, production, and internal networks.
3. Developing standard connectivity and documentation criteria to expedite approval of connectivity requests without additional board action.
4. Requesting additional information, security reviews, or audits about proposed or approved connections, if deemed necessary.
5. Evaluating connectivity and firewall change requests and approving or rejecting them based upon existing policy, best practices, and the level of risk associated with the request.
6. Consulting with executive sponsors on network information security requirements.
7. Assisting the requester in identifying alternative solutions for denied requests that are acceptable to the requester and the Postal Service.
8. Reviewing new information resource, infrastructure, and network connections and their effects on overall Postal Service operations and information security.
9. Recommending and approving network services and protocols.
10. Recommending changes to the business partner network. In situations where high-risk factors exist, issuing mitigating requirements for connectivity.

20. The CIRT is responsible for the following:

1. Providing an immediate and effective response to computer security incidents as they occur.
2. Working with an organization to contain, eradicate, document, and recover following a computer security incident.
3. Engaging other Postal Service organizations including, but not limited to, the OIG and Inspection Service.
4. Escalating information security issues to executive management as required.
5. Conducting a post-incident analysis, where appropriate, and recommending preventive actions.
6. Maintaining a repository for documenting, analyzing, and tracking Postal Service security incidents until they are closed.
7. Interfacing with other governmental agencies and private-sector computer incident response centers.
8. Participating in and providing lesson learned information from information security incidents into ongoing information security awareness and training programs.
9. Developing and documenting processes for incident reporting and management.
10. Providing support to the OIG and the Inspection Service, as requested.
11. Designating an information security policy and process program manager who is responsible for establishing, documenting, and disseminating information security policies, standards, and processes.

22) Managers, Help Desks

The managers, Help Desks, are responsible for the following:

1. Creating the entry for the problem tracking management system for security incidents reported to the Help Desks.
2. Providing technical assistance for responding to suspected virus incidents reported to the Help Desks.
3. Escalating unresolved suspected virus events to the CIRT.

23) Contracting Officers and Contracting Officer Representatives

Contracting officers and contracting officer representatives are responsible for the following:

1. Ensuring that information technology suppliers, contractors, vendors, and business partners are contractually obligated to abide by Postal Service information security policies, standards, and procedures.
2. Thoroughly vetting service providers for PCI services prior to engagement that includes a risk analysis and documentation to reflect due diligence to the PCI assessor.
3. Updating the PCI Program Management Office (PMO) with status information on service providers for the PCI environment.
4. Verifying that information technology suppliers, vendors, and business partners responsible for storing, processing, or transmitting Postal Service payment card information complete an annual Letter of Attestation providing an acknowledgement of their responsibility for the security of payment card data, under the current PCI DSS.
5. Monitoring service provider PCI compliance at least annually.
6. Verifying that all contracts and business agreements requiring access to Postal Service information resources identify sensitive positions, specify the clearance levels required for the work, and address appropriate security requirements.
7. Verifying that contracts and business agreements allow monitoring and auditing of any information resource project.
8. Verifying that the security provisions of the contract and business agreements are met.
9. Confirming the employment status and clearance of all contractors who request access to information resources.
10. Verifying all account references, building access, and other privileges are removed for contractor personnel when they are transferred or terminated.
11. 11. Notifying the CIRT of any security breaches reported to them by the service providers.

24) General Counsel

The general counsel is responsible for the following:

1. Ensuring that information technology contractors, vendors, and business partners are contractually obligated to abide by Postal Service information security policies, standards, and procedures.
2. Ensuring that contracts and agreements allow monitoring and auditing of Postal Service information resource projects.

25) Business Partners

Business partners may request connectivity to Postal Service network  facilities for legitimate business needs. Business partners requesting or using connectivity to Postal Service network facilities are responsible for the following:

1. Initiating a request for connectivity to the Postal Service executive who sponsors the request.
2. Complying with Postal Service network connectivity request requirements and process.
3. Abiding by Postal Service information security policies regardless of where the systems are located or who operates them. This also includes strategic alliances.
4. Protecting information resources at risk during security incidents, if feasible.
5. Reporting information security incidents immediately to the CIRT, the executive sponsor, and the information systems security officer (ISSO) assigned to their project.
6. Taking action, as directed by the CIRT, to eradicate the incident, recover from it, and document actions regarding the security incident.
7. Allowing site security reviews by the Postal Inspection Service and CISO.
8. Allowing audits by the OIG.

26) Accreditor

The manager, CISO, functions as the accreditor and is responsible for the following:

1. Reviewing the risk mitigation plan and supporting C&A documentation package together with business requirements and relevant Postal Service issues.
2. Escalating security concerns or preparing and signing an accreditation letter that makes one of the following recommendations: accepting the information resource with its existing information security controls, requiring additional security controls with a timeline to implement, or deferring deployment until information security requirements can be met.
3. Forwarding the accreditation letter and C&A documentation package to the Business Relationship Management manager and executive sponsor.

27) Certifier

The manager, Security Certification and Accreditation Process, who is appointed by the manager, CISO, functions as the certifier and is responsible for the following:

1. Managing and providing guidance to the ISSOs.
2. Reviewing the C&A evaluation report and the supporting C&A documentation package.
3. Escalating security concerns or preparing and signing a certification letter.
4. Forwarding the certification letter and C&A documentation package to the accreditor.
5. Maintaining an inventory of all information resources that have completed the C&A process.

28) Security Control Officers

SCOs ensure the general security of the facilities to which they are appointed, including the safety of on-duty personnel and the security of mail,  Postal Service funds, property, and records entrusted to them . SCOs are responsible for the following:

1. Establishing and maintaining overall physical and environmental security at the facility, with technical guidance from the Inspection Service.
2. Establishing controlled areas within the facility, where required, to protect information resources designated as sensitive-enhanced, sensitive, or critical.
3. Establishing and maintaining access control lists of people who are authorized access to specific controlled areas within the facility.
4. Ensuring positive identification and control of all personnel and visitors in the facility.
5. Ensuring the protection of servers, workstations, portable devices, and information located at the facility.
6. Consulting on the facility COOP plans.
7. Conducting annual facility security reviews using the site security survey provided by the Inspection Service.
8. Reporting suspected information security incidents to the CIRT and providing support for incident containment and response, as requested.
9. Responding to physical security incidents and reporting physical security incidents to the Inspection Service.
10. Interfacing with CIRT, Inspection Service, CISO, or OIG, as required.

29) Information Systems Security Representatives

ISSRs are appointed in writing by the executive sponsors or the Business Relationship Management portfolio manager and are members of the information resource development or integration teams. The role of the ISSR can be performed in conjunction with other assigned duties. If an ISSR is not assigned, the project manager assumes the role. ISSRs are responsible for the following:

1. Providing support to the executive sponsor and Business Relationship Management portfolio manager, as required.
2. Promoting information security awareness on the project team.
3. Ensuring security controls and processes are implemented.
4. Notifying the executive sponsor, Business Relationship Management portfolio manager, and ISSO of any additional security risks or concerns that emerge during development or acquisition of the information resource.
5. Developing or reviewing security-related documents required by the C&A process as assigned by the executive sponsor or Business Relationship Management portfolio manager.
6. Working with the ISSO to complete the eC&A artifacts in the eC&A system and sending other required artifacts (e.g., TAD, operational training, etc.) or their location (i.e., URL) to the ISSO.

30) Information Systems Security Officers

ISSOs are responsible for the following:

1. Chairing the C&A team.
2. Ensuring that a BIA is completed for each information resource.
3. Ensuring that the responsible project manager records the sensitivity and criticality designations in EIR.
4. Providing guidance on how information resources are vulnerable to threats, what controls and countermeasures are appropriate, and the C&A process.
5. Conducting site security reviews or helping the Inspection Service conduct them.
6. Reviewing the C&A documentation package.
7. Preparing and signing the C&A evaluation report and forwarding the evaluation report and C&A documentation to the certifier.
8. Advising and consulting with executive sponsors, Business Relationship Management portfolio managers, and ISSRs during the BIA process so they know the background for

1. baseline security requirements that apply to all information resources and
2. Recommending security requirements to executive sponsors and Business Relationship Management portfolio managers during the BIA process, based on generally accepted industry practices and the risks associated with the information resource.

31) System and Network Administrators

System and network administrators are technical personnel who serve as computer systems, network, server, and firewall administrators, whether the system management function is centralized, distributed, subcontracted, or outsourced. System and network administrators are responsible for the following:

1. Implementing information security policies and procedures for all information resources under their control, and also for monitoring the implementation for proper functioning of security mechanisms.
2. Implementing appropriate platform security based on the platform specific hardening standards for the information resources under their control.
3. Complying with standard configuration settings, services, protocols, and change control procedures.
4. Applying approved patches and modifications in accordance with policies and procedures established by the Postal Service. Ensuring that security patches and bug fixes are kept current for resources under their control.
5. Implementing appropriate security administration and ensuring that log-on IDs are unique.
6. Setting up and managing accounts for information resources under their control in accordance with policies and procedures established by the Postal Service.
7. Disabling accounts of personnel whose employment has been terminated, who have been transferred, or whose accounts have been inactive for an extended period of time.
8. Making the final disposition (e.g., deletion) of the accounts and the information stored under those accounts.
9. Managing sessions and authentication and implementing account time-outs.
10. Preventing residual data from being exposed to unauthorized users as information resources are released or reallocated.
11. Testing information resources to ensure security mechanisms are functioning properly.
12. Tracking hardware and software vulnerabilities.
13. Maintaining an accurate inventory of Postal Service information resources under their control.
14. Ensuring that audit and operational logs, as appropriate for the specific platform, are implemented, monitored, protected from unauthorized disclosure or modification, and are retained for the time period specified by Postal Service security policy.
15. Reviewing audit and operational logs and maintaining records of the reviews.
16. Identifying anomalies and possible internal and external attacks on Postal Service information resources.
17. Reporting information security incidents and anomalies to their manager and the CIRT immediately upon detecting or receiving notice of a security incident.
18. Protecting information resources at risk during security incidents, assisting in the containment of security incidents as required, and taking action as directed by the CIRT.
19. Participating in follow-up calls with the CIRT and fixing issues identified following an incident.
20. Ensuring that virus protection software and signature files are updated and kept current for resources under their control.
21. Ensuring the availability of information resources by implementing backup and recovery procedures.
22. Ensuring compliance with Postal Service information security policy and procedures.
23. Monitoring the implementation of network security mechanisms to ensure that they are functioning properly and are in compliance with established security policies.
24. Maintaining a record of all monitoring activities for information resources under their control.
25. Assisting with periodic reviews, audits, troubleshooting, and investigations, as requested.
26. Resolving identified vulnerabilities.

32) Database Administrators

Database administrators (DBAs) are responsible for the following:

1. Implementing appropriate database security based on the platform-specific hardening standards for the information resources under their control.
2. Implementing information security policies and procedures for all database platforms and monitoring the implementation of database security mechanisms to ensure that they are functioning properly and are in compliance with established policies.
3. Applying approved patches and modifications, in accordance with policies and procedures established by the Postal Service.
4. Maintaining an accurate inventory of Postal Service information resources under their control.
5. Implementing appropriate database security administration and ensuring that log-on IDs are unique.
6. Setting up and managing accounts for systems under their control in accordance with policies and procedures established by the Postal Service.
7. Disabling accounts of personnel that has been terminated, transferred, or have accounts that have been inactive for an extended period of time.
8. Making the final disposition (e.g., deletion) of the accounts and the information stored under those accounts.
9. Managing sessions and authentication and implementing account time-outs.
10. Preventing residual data from exposure to unauthorized users as information resources are released or reallocated.
11. Testing database software to ensure that security mechanisms are functioning properly.
12. Tracking database software vulnerabilities, and deploying database security patches.
13. Ensuring database logs are turned on, logging appropriate information, protected from unauthorized disclosure or modification, and retained for the time period specified.
14. Reviewing database audit logs and maintaining records of log reviews.
15. Assisting with periodic reviews, audits, troubleshooting, and investigations, as requested.
16. Ensuring the availability of databases by implementing database backup and recovery procedures.
17. Identifying anomalies and possible attacks on Postal Service information resources.
18. Reporting information security incidents and anomalies to their manager and the CIRT immediately upon detecting or receiving notice of a security incident.
19. Protecting information resources at risk during security incidents, assisting in the containment of security incidents as required, and taking action as directed by the CIRT.
20. Resolving identified vulnerabilities.

33) All Personnel

All personnel, including employees, suppliers, consultants, contractors, business partners, customers who access non publicly available Postal Service information resources (e.g., mainframes or the internal Postal Service network), and other authorized users of Postal Service information resources are responsible for the following:

1. Complying with applicable laws, regulations, and Postal Service information security policies, standards, and procedures.
2. Displaying proper identification while in any facility that provides access to Postal Service information resources.
3. Being aware of their physical surroundings, including weaknesses in physical security and the presence of any authorized or unauthorized visitor.
4. Protecting information resources, including workstations, portable devices, information, and media.
5. Always using their physical and technology electromechanical access control identification badge or device to gain entrance to a controlled area.
6. Ensuring no one tailgates into a controlled area on their badge.
7. Performing the security functions and duties associated with their job, including the safeguarding of their log-on IDs and passwords.
8. Changing their password immediately, if they suspect that the password has been compromised.
9. Prohibiting any use of their accounts, log-on IDs, passwords, personal information numbers (PINs), and tokens by another individual.
10. Taking immediate action to protect the information resources at risk upon discovering a security deficiency or violation.
11. Only using licensed and approved hardware and software.
12. Protecting intellectual property.
13. Complying with Postal Service remote access information security policies, including those for virtual private networks, modem access, dial-in access, secure telecommuting, and remote management and maintenance.
14. Complying with acceptable use policies.
15. Maintaining an accurate inventory of information resources for which they are responsible.
16. Protecting information resources against viruses and malicious code.
17. Calling the appropriate Help Desk for technical assistance in response to suspected virus incidents.
18. Immediately reporting to the CIRT via telephone or email and, as appropriate, to their immediate supervisor, manager, or system administrator, any suspected security incidents, including security violations or suspicious actions, suspicion or occurrence of any fraudulent activity; unauthorized disclosure, modification, misuse, or inappropriate disposal of Postal Service information; and potentially dangerous activities or conditions.
19. Taking action, as directed by the CIRT, to protect against information security incidents, to contain and eradicate them when they occur, and to recover from them.
20. Documenting all conversations and actions regarding the security incident and completing PS Form 1360, Information Security Incident Report, or an acceptable facsimile. If an individual removes a portable electronic device from a Postal Service facility, he or she must do the following:

1. If the device contains sensitive-enhanced or sensitive information, request approval in writing from his or her functional area vice president (data steward), CPO, and the VP IT Operations or their designees.
2.  Reporting any missing or stolen device or media immediately to his or her manager, the CIRT via e-mail to xxxt@xxx.xxx.gov, and to the local Inspection Service office. If the device has been stolen somewhere other than Postal Service premises, report the theft to the local police as well.

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

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Clause 4: Context of the organization

As per  ISO, the definition of Context of the Organization is “business environment“, a “combination of internal and external factors and conditions that can have an effect on an organization’s approach to its products, services and investments and interested Parties“. The concept of Context of Organization is equally applicable to Not-for-profit organizations, public service organizations, and governmental organizations. Also in normal language, this concept is also known as the business environment, organizational environment, or ecosystem of an organization.

Information security management is a major issue worldwide. It describes the behaviors of commercial organizations and government bodies, many of whom are seizing opportunities to analyze their records of customer and citizen personal information. Merging this with volumes of traded ‘anonymized’ data, these organizations aim to harvest new insights, seeking competitive advantages and efficiencies. There is also a wider black market trade that includes personal account IDs and passwords, credit card details, commercial intellectual property, and sensitive financial data. The value of that information is motivating theft, funding organized crime, satisfying nation-state espionage, and driving the evolution of globally-dispersed technical threats to challenge established operational principles and practices. Organizations are increasingly embracing online opportunities to promote their business and consolidate their position in the marketplace through the use of mobile device applications and social networking presence. Mobile devices and ‘the internet of things’ have dissolved traditional organizational perimeters and are dispersing information both geographically and logically across the internet. This presents a wide exposure to diverse and sophisticated technical threats.

Clause 4 requires an organization to establish the context of its ISMS. It has to determine its needs and expectations and those of interested parties and decide the scope of the ISMS. The new “context” clause requires an understanding of the organization and its needs, determine external and internal issues and consider interested parties and their requirements. Requirements of interested parties may include legal and regulatory requirements and contractual obligations. Context determines the information security policy and objectives and how the organization will consider risk and the effect of risk on its business. An appropriate scope for the ISMS is now required. This clause in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues (i.e. those that affect the organization’s ability to achieve the intended outcome(s) of its ISMS) with the requirements of interested parties to determine the scope of the ISMS. It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS. Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled non-conformant with the standard. The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements of the standard.
To establish an ISMS the organization needs to define the ISMS which includes the following steps:

4.1 Understanding the organization and its context

The organization must determine its external and internal issues which should be relevant to its purpose and can affect its ability to achieve the intended outcome of its information security management system. While determining these issues the organization can refer to establishing the external and internal context of the organization as given in Clause 5.3 of ISO 31000:2009. ISO 31000 is a standard that provides guidelines for risk management, and this is what it suggests could be included when identifying internal and external issues. Please note that ISO 31000 gives guidelines only; therefore, they are not mandatory.

The idea of the context of the organization’s overall business is maintained here. There is an explicit requirement to consider both internal and external issues which might impact the organization’s purpose and affect its ability to achieve the expected outcomes of the ISMS. External and internal issues have to be determined that are relevant to the organization’s purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. There are expectations that these considerations and resulting conclusions will need to be documented. To reinforce the theme that runs throughout the Annex SL there is a note referencing ISO 31000 Risk management – Principles and guidelines. Here you have to understand your organization and its context. Identify and understand your organization’s context before you establish its information security management system (ISMS).  Identify the internal issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence your internal stakeholders could have. Determine the influence your approach to governance could have.  Determine the influence your organization’s capabilities could have.  Determine the influence your organization’s culture could have. Determine the influence your organization’s contracts could have. You have to identify the external issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence environmental conditions could have. Determine the influence key trends and drivers could have.  Determine the influence external stakeholders could have.

An organization’s risk assessment process should address the strategic, organizational, and security risk management contexts. Security risk management is applicable across all facets of an organization’s functions, or activities. In particular, the risk assessment needs to be appropriate to the prevailing and emerging risk environment. Establishing the context is critical as it sets the basis on which all subsequent risk assessment activities are conducted. The Step in establishing the context could include:

1. Communication & Consultation

Communication and consultation with external and internal stakeholders should take place during all stages of the establishing Organizational context. Therefore, plans for communication and consultation should be developed at an early stage. These should address issues relating to the ISMS itself, its causes, its consequences (if known), and the measures being taken to treat it. Effective external and internal communication and consultation should take place to ensure that those accountable for implementing the management process and stakeholders understand the basis on which decisions are made, and the reasons why particular actions are required. A consultative team approach may:

• help establish the context appropriately;
• ensure that the interests of stakeholders are understood and considered;
• help ensure that risks are adequately identified;
• bring different areas of expertise together for establishing context;
• ensure that different views are appropriately considered when determining organizational context, defining risk criteria and in evaluating risks;
• secure endorsement and support for a treatment plan;
•  enhance appropriate change management during the whole  process; and
• develop an appropriate external and internal communication and consultation plan.

Communication and consultation with stakeholders are important as they make judgments based on their perceptions. These perceptions can vary due to differences in values, needs, assumptions, concepts, and concerns of stakeholders. As their views can have a significant impact on the decisions made, the stakeholders’ perceptions should be identified, recorded, and taken into account in the decision-making process. Communication and consultation should facilitate truthful, relevant, accurate, and understandable exchanges of information, taking into account confidential and personal integrity aspects.

2. Establishing the context of ISMS

By establishing the context, the organization articulates its objectives, defines the external and internal parameters to be taken into account when managing risk, and sets the scope and risk criteria for the remaining process. While many of these parameters are similar to those considered in the design of the Information Security management framework, when establishing the context for the ISMS processes, they need to be considered in greater detail and particularly how they relate to the scope of the particular management process.

3. Establishing the external context

The external context is the external environment in which the organization seeks to achieve its objectives. Understanding the external context is important in order to ensure that the objectives and concerns of external stakeholders are considered when developing its Security risk criteria. It is based on the organization-wide context, but with specific details of legal and regulatory requirements, stakeholder perceptions, and other aspects specific to the scope of the Information Security management process. The external context can include, but is not limited to:

• the social and cultural, political, legal, regulatory, financial, technological, economic, natural and
• competitive environment, whether international, national, regional or local;
• key drivers and trends having an impact on the objectives of the organization;
• and relationships with, perceptions and values of external stakeholders.

4. Establishing the internal context

The internal context is the internal environment in which the organization seeks to achieve its objectives. The Information Security management process should be aligned with the organization’s culture, processes, structure, and strategy. Internal context is anything within the organization that can influence the way in which an organization will manage its Security risk. It should be established because:

1. risk management takes place in the context of the objectives of the organization;
2. objectives and criteria of a particular project, process or activity should be considered in the light of objectives of the organization as a whole; and
3. some organizations fail to recognize opportunities to achieve their strategic, project or business objectives, and this affects ongoing organizational commitment, credibility, trust, and value.

It is necessary to understand the internal context. This can include, but is not limited to:

• governance, organizational structure, roles, and accountabilities;
• policies, objectives, and the strategies that are in place to achieve them;
• capabilities understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems, and technologies);
• the relationships with and perceptions and values of internal stakeholders;
• the organization’s culture;
• information systems, information flows and decision-making processes (both formal and informal);
• standards, guidelines, and models adopted by the organization and form and extent of contractual relationships.

5. Establishing the context of the risk management process

The objectives, strategies, scope, and parameters of the activities of the organization, or those parts of the organization where the risk management process is being applied, should be established. The management of risk should be undertaken with full consideration of the need to justify the resources used in carrying out risk management. The resources required, responsibilities and authorities, and the records to be kept should also be specified. The context of the risk management process will vary according to the needs of an organization. It can involve, but is not limited to:

• defining the goals and objectives of the risk management activities;
• defining responsibilities for and within the risk management process;
• defining the scope, as well as the depth and breadth of the risk management activities to be carried out, including specific inclusions and exclusions;
• defining the activity, process, function, project, product, service or asset in terms of time and location;
• defining the relationships between a particular project, process or activity, and other projects, processes or activities of the organization;
• defining the risk assessment methodologies;
• defining the way performance and effectiveness is evaluated in the management of risk;
•  identifying and specifying the decisions that have to be made;
• and identifying, scoping or framing studies needed their extent and objectives, and the resources required for such studies.

Attention to these and other relevant factors should help ensure that the risk management approach adopted is appropriate to the circumstances, to the organization, and to the risks affecting the achievement of its objectives.

6. Defining risk criteria

The organization should define criteria to be used to evaluate the significance of the risk. The criteria should reflect the organization’s values, objectives, and resources. Some criteria can be imposed by, or derived from, legal and regulatory requirements and other requirements to which the organization subscribes. Risk criteria should be consistent with the organization’s management policy, be defined at the beginning of any management process, and be continually reviewed. When defining risk criteria, factors to be considered should include the following:

• the nature and types of causes and consequences that can occur and how they will be measured;
• how likelihood will be defined;
• the time-frame of the likelihood and/or consequence;
• how the level of risk is to be determined;
• the views of stakeholders;
• the level at which risk becomes acceptable or tolerable;
• and whether combinations of multiple risks should be taken into account and, if so, how and which combinations should be considered.

The ISO 27001 standard is structured according to the “Plan-Do-Check-Act” (PDCA) model. In the Plan phase, an ISMS is established, in the Do phase the ISMS is implemented and operated, in the Check phase the ISMS is monitored and reviewed, and in the Act phase, the ISMS is maintained and improved. In the Plan phase, the scope and boundaries of the ISMS, its interested parties, environment, assets, and all the technology involved are defined. In this phase also the ISMS policies, risk assessments, evaluations, and controls are defined. Controls in the ISO 27001 are measures to modify risk. The context of the organization starts with a gathering of information about the organization. The next activity is the context establishment. This initial step is important for all following steps and is responsible, whether the risk management can be implemented to a sufficient extent and on a sufficient level of detail. The next step is risk identification, which determines the potential loss. Then risk estimation tries to rate the consequences of loss on a qualitative or quantitative scale as well as the likelihood of occurrence. The risk evaluation step compares the level of risks against the risk acceptance criteria, defined during the context establishment. Then, the risk treatment step sets up the controls. In the risk acceptance step, residual risks have to be accepted by managers of the organization.

Example of External issues relevant for ISMS

1. Legal and regulatory.
   XXX recognize there are legal and regulatory requirements over and above the requirements as established by our internal requirements.

2. Cultural

• Personal data – There is a known external demand for personal data (especially financial i.e. Credit card details, address details and dates of birth) and significant inducements can be offered to staff for the collection of information this could affect “confidentiality‟.
• Hacking and unauthorized interception of communications is an issue we know about targeting contact centers, this could affect “confidentiality”.
• Wages in our industry are low and so bribery is an ever-present threat, this could affect “confidentiality‟.

3. Connectivity

• Power and connectivity – utility failures are common and have occurred in the past. We have had power cuts due to local power demand increases that have interrupted mains power (new building and expanding businesses: the infrastructure cannot cope). IT connectivity has also been interrupted by this high demand. This could impact on ‘integrity’.
• International clients are also expecting state-of-the-art technology, fast connection speeds for sales and call handling report visibility (statistics). This has an impact on our commitments contained in our service level agreements. 

4. Location

•  Physical location, our location is in an area of high criminality (due to many hi-tech businesses located nearby) and adjacent offices have been attacked by thieves which could have an impact on “confidentiality‟.
• Environmental – no particular flooding or storm damage is anticipated.

5. Competition

Employees could take XXX or customer information to a competitor. There are many competitors located close to our office. Staff can often move from our company to a competitor quickly. This could affect “confidentiality‟.

6. Economic pressures

• It is understood that when some of our competitors are under pressure for new revenue, they may be more likely to illicit sources of information on our customers from our key employees. This could also entail poaching key members of staff and securing access to confidential information. The loss of a key member of staff with the customer data they have access to could impact us heavily. This could affect  “confidentiality‟ and the viability of XXXX.
• In tight financial times, customers are seeking cost-saving alternatives, we are therefore seeing a large increase in sales inquiries putting pressure on our internal resources and IT and IS systems.
•  

Example of Internal issues relevant for ISMS

1.Information systems

Some of our systems are old and due to be replaced. New systems will be more complex and possibly harder to support. Possible “integrity‟ issues.

2. Organization’s culture

Historically our company has been sales driven, the need to bring in work has outweighed other considerations such as “confidentiality‟. This has resulted in a misalignment between its strategic direction and IS policy. The integration of IS into the organization‟s sales processes may not be strictly adhered to and top management support to demonstrate leadership in IS may be compromised when large orders are at stake.

3. Relationships and perceptions and values of internal stakeholders

• Historically we have had a high turnover in staff and this means staff could take data with them on departure. We understand that the skill sets of our call center staff are limited and as such documented processes and guidance are more important. Also comprehending the nature of IS policies and their importance and consequences may not be fully recognized and hence information security incidents are more likely.
• Many skills and decision-making authorities are restricted to a very few senior staff who know each other very well, this has led to a competence and documentation „gap‟ through informality.

4. Human Resource Security and Capabilities (knowledge)

The high staff turnover has caused XXXX difficulties in retaining core knowledge, such as system support and customer relations. This may cause issues. Staff is recruited from the local workforce and because of the low wages and skills expectation, they may not be well off financially or well educated. This may leave them more vulnerable to bribery and corruption.

5. Governance, organization and roles and responsibilities

As a small company, responsibilities have been retained by a small management team. As we grow this may be difficult to achieve but is needed.

6. Standard working procedures and guides

Processes have not been documented because of their retention and ownership by senior individuals only. As we grow this lack of documentation may cause problems.

7. Contractual relationships with our suppliers

As a small new business, our purchasing power and influence are restricted; as we are not able to include IS requirements in contracts, also some suppliers do not have formal contracts with us. Hence the scope of our ISMS excludes all IS outsourced processes. As ‘Data Cleansing’ is a current outsourced process, this naturally causes our clients concerns around “Confidentiality‟ and “Integrity‟.

4.2 Understanding the needs and expectations of interested parties

The organization must determine the interested parties and their requirement that are relevant to and can be addressed through the information security management system. The requirements of interested parties may include legal and regulatory requirements and contractual obligations.

The organization shall determine interested parties that are relevant to the information security management system and the requirements of these interested parties relevant to and it can be addressed through information security. The organization must identify all of the parties that have an interest in your organization’s ISMS. and must also identify their requirements including their needs and expectations.  Let’s start with understanding what interested parties are – they are nothing else but stakeholders, i.e., persons or organizations that can influence your information security/business continuity or persons or organizations that can be affected by your information security or business continuity activities. So, typically, interested parties could include:

• employees
• shareholders/owners of the business
• government agencies/regulators
• emergency services (e.g., firefighters, police, ambulance, etc.)
• clients
• employee families
• media
• suppliers and partners
• … and anyone else that you consider important for your business.

How can you identify them? Just ask your top executives, as well as heads of departments about who is important for their business, and then assess whether they could be interested in your information security or business continuity. Also, chances are that your existing documentation (e.g., business plans) already contains such information.
Having identified its interested parties, there are now demands on an organization to consider their needs and expectations. However, these needs and expectations are only those relevant to information security. There are expectations that these interested parties and their requirements will need to be documented. Previously the involvement of interested parties was restricted to feedback and communication; now they are at the heart of the ISMS. There is a note clarifying that legal and regulatory requirements and contractual obligations may be included in the requirements of interested parties. The identification of interested parties is not as important as the second step: identification of their requirements. Here’s why it is important: you need to know what all the interested parties want from you, and you need to figure out how to satisfy all these requirements in your ISMS. For example, shareholders want the security of investment and a good return, clients want you to comply with security clauses in the contracts you signed with them, government agencies want you to comply with information security continuity laws and regulations, the media want quick and accurate news related to your incidents, etc. However, you have to be more specific than this – you have to specify exactly which laws and regulations, which security or continuity clauses exist in the contracts, and so on. The best way to collect this information is to study their written requirements (legislation, contracts, etc.) and/or interview their representatives. Once you have all this information, you will need to “configure” your information security or business continuity to be compliant with your stakeholder expectations – this means you’ll have to identify the requirements before you start developing the details of your ISMS.  A good practice is to write a procedure that defines who is in charge of identifying all the interested parties and their legal, regulatory, contractual, and other requirements and interests; such a procedure also needs to define who is in charge of updating this information and how often this is done. If you work in a larger organization, such organizations usually have compliance departments or compliance officers – they would be the most natural department/person to do this kind of a job. If not, you can try to negotiate whether your legal department could do this job – if not them, then you, the information security or business continuity coordinator, will have to do it yourself. Once the requirements are clearly identified, you need to define who is in charge of complying with them – these responsibilities could be very different: IT department would be in charge of complying with technical requirements, human resources department for, e.g., confidentiality statements, information security coordinator with new policies and procedures, etc.

Examples of Understanding the Needs and Expectations of Interested Parties

The interested parties that are relevant to the ISMS of XXX have been determined below their individual expectations.

1.Customer:
Requirements are as follows:

1. To provide products, services, and maintenance support in accordance with contractual requirements.
2. To provide products, services, and maintenance support in the event of any disruption.
3. To Provide provide products, services and maintenance support in  accordance with applicable legal requirements.
4. To Provide provide products, services, and maintenance support in accordance with any additional, applicable industry, third party or end-user requirements (e.g. NHS Digital, IGSoC approval).
5. To provide products, services, and maintenance support at any time (24/7/365).
6. ISO 27001 Compliance
7. 99.9% Availability of Systems
8. Meeting SLA (4hr response – contact center)
9. PCI DSS Requirements 9 & 12
10. To provide products, services, and maintenance support that add value.

2. End Users
Our products and services interact with various groups of end-users.
Requirements are as follows:

1. Products and services that we directly provide, and those that our customers provide (using our systems), are available when required.
2.  Our products and services are reliable and simple (to use).
3. There is a simple and effective process to enable lone workers to specify accurate, complete and up-to-date personal details.
4. Our products and services adequately protect personal data (contact details) and sensitive personal data (medical details).
5. We can support our products and services at all times.
6. In the event of a disruption, we can continue the operation of products and services that we directly provide, and continue to provide support for those that customers provide (using our systems).

3, Partners:
These may be agents or system partners, recruitment companies, or others. Their reputations may be damaged if we have a breach, we may be damaged if they have a breach. Our contracts with some key partners may have or need IS clauses.
Requirements are as follows:

1. We provide any correct and complete technical information that they require, to enable them to amend, enhance, and rectify any faults in, their Application Programming Interface (API), in order to enable us to develop software that communicates and exchanges data with their API, in accordance with our requirements.
2. We develop software in accordance with any mutually agreed schedule.
3. Our relationship is not adversely affected by the departure or absence of any of our workers.
4. We comply with any confidentiality and non-disclosure agreements.
5. We provide required training, to enable the reseller to sell our products and services.
6. We efficiently expedite orders.
7. Adherence to contractual agreements

4. Suppliers and Contractors
Even a supplier may be affected by an incident if our use of their systems results in negative publicity for the supplier they may not want to supply us. Data suppliers may not trust us with marketing lists
Requirements are as follows:

1. We purchase their products and/or services.
2. Where applicable, we provide complete and accurate information when we require their technical support.
3. Where applicable, we subscribe to their technical support.
4. Adherence to contractual agreements
5. Adherence to payment terms

5. Employees
We currently have approximately 30 employees, in roles of management, software development, computer and telephony engineering, sales, telemarketing, account management, finance, and administration.
Requirements are as follows:

1. The company is profitable and provides secure work.
2. The company provides a safe and appropriate work environment.
3. The company provides the required training and support.
4. The company clearly specifies its requirements and expectations of workers.
5. Workers believe that they can positively contribute to the success of the company.
6. The company facilitates dialogue with workers so that they are aware of their contribution.
7. The company protects their personal information.
8. The company pays fairly for work.
9. The company provides opportunities for continuity of employment
10. The company provides opportunities for advancement

6. Insurers
If fines or damages were the results of an incident (breach of contract or regulator) this would affect profits and so investors and owners. Our insurer may be liable to contribute depending on insurance wording.
Requirements are as follows:

1. The Company should be meeting policy requirements
2. The Company should be making timely payment of premiums
3. The company should be reporting changes in circumstances

7. Management/Shareholders
Breaches could affect our share price or our investors could withdraw. The professional reputation of the company and its management could be questioned if we had a breach.
Requirements are as follows:

1. Return on capital

8. Trade bodies/associations
Although we are not members of any trade bodies/associations we may seek to join at a later date. Organizations such as the Direct Marketing Association (DMA) have security requirements that we would need to follow.
Requirements are as follows:

1. Membership requirements
2. Meeting standards to which the organization adheres
3. Provision of guidance
4. Terms and Conditions for the workers

9. Regulators
We are not directly subject to any industry-specific regulatory authority, but we are subject to various legal requirements from applicable legislation.

10. Government agencies
With recent government breaches, government departments have to be squeaky clean, they have not inspected us yet but may in the future. The governments IL2/3/4 requirements around IS may affect us if we take on that sort of work.
Requirements are as follows:

If a breach broke the law we could be fined, face restrictions or directors face imprisonment.

10)  Media / Commentators
Interest in Information Security is growing, we should expect any incident to be reported and suffer bad publicity, perhaps suffering the loss of customers as a result.

4.3 Determining the scope of the information security management system

The organization must determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization should take into account the external and internal issues referred to in 4.1; It must also take into account the requirements of its interested parties identified in clause 4.2; It must consider the interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations. ISO 27001 requires you to write a document for the ISMS scope.

ISMS scope and boundaries determine the extent to which the ISMS is applied in an organization. Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). Identifying the right ISMS scope is crucial because it will assist organizations in meeting their security requirements and planning for ISMS implementation, for the organization e.g. determining resources, timeline, and budget required. Figure out what your organization’s ISMS should apply to and what its boundaries should be. However, if the scope is not accurately defined, this will result in unnecessary wastage of resources (in terms of time, cost, and effort) because, when risk assessment exercises are conducted on different scopes, it will result in inaccurate identification of information security risks. Furthermore, if the ISMS scope is not aligned with the organization’s security requirements, the organization may find that ISMS is a waste of time and resources; thus not valuing the benefits of implementing it. The scope of ISMS can be defined in terms of the organization as a whole, or parts of the organization. Use boundaries and applicability information to clarify the scope of your organization’s ISMS. The selected ISMS scope should be critical to the organization in meeting its business objectives. In general, the ISMS scope should cover the end-to-end process to deliver services and/ or produce products. It should cover the complete elements of people, process and technology, and relevant assets within the process. The ISMS scope should be derived from organizational known risks. For example, in a financial institution, the risks of unauthorized access to online transactions may give a critical impact on its business operations. Thus, the ISMS scope for this financial institution can be defined as online transaction services. Examples of questions that can guide organizations when defining the ISMS scope and boundaries:

1. Which service in your organization will be covered by the ISMS?
2. How and why is the selected service critical to your organization?
3.  What are the characteristics of the selected service; i.e. business, the organization, its locations, assets, and technologies to be included in the ISMS?
4. Will you require external parties to abide by your ISMS?
5.  Are there any interfaces or dependencies between activities performed by the organization; and those performed by another? Should they be considered?

The amount of effort required to implement ISMS is dependent upon the magnitude and complexity (among others) of the scope to which it is to be applied. Nevertheless, organizations should consider factors such as information security and business requirements, expectations from stakeholders, and the expected resources when defining the ISMS scope. To ensure that the ISMS is implemented effectively, it should be viewed as an enabler to achieve organizational business objectives. In order to identify ISMS scope and boundaries, organizations should perform the following activities:

1. Consider the organization’s information security requirements which have been identified in Clause 4.1 – Define Information Security Requirements;
2. Consider any interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations;
3. Consider critical services that can cause a major impact on the organization and/or nation arising from losses of confidentiality, integrity or availability;
4. Define the organizational scope and boundaries;
5. Define Information Communication Technology (ICT) scope and boundaries,
6. Define physical scope and boundaries; and
7. Integrate elementary scope and boundaries to obtain the ISMS scope and boundaries.

For clarity, organizations may seek the advice of a Certification Body (CB) on the proposed ISMS scope and boundaries, as and when the need arises. Ensure that the ISMS scope is documented and approved by the top management. Control your organization’s ISMS scope document.

Purpose of formal scope definition

The scope definition serves the purpose of stating exactly what it is that an organization does that is certified to be effectively controlled by the requirements of the standard. Without a formal scope definition, the statement of an organization being ISO 27001 certified could mean a great deal or not much at all. The scope statement should state exactly what it is that an organization does that is certified to the standard.
A bad Example of scope could be XYZ company’s information security system.
This provides no details as to what products or services the company provides that have been found to meet the requirements of the standards.

An Example for scope could be The development, operation, and administration of the scheduling and planning Software as a Service platform provided by company XYZ.
This scope statement tells us that the fictional organization has been certified in not just the operation and administration of its SaaS platform, but also the development as well. This also means that the people and information systems associated with the development, operation, and administration of the system are in scope and need to meet the requirements of the standard as well. In the event this fictional company also provided other services, such as consulting, there should be no confusion or assumption that this separate service meets the requirements of the standard as it is not documented in the formal scope and wouldn’t have been subject to the certification audit.

Strategies for Determining and Defining the boundaries of your ISMS

• First – Understanding your organization and the issues that are most relevant to it, and the needs and expectations of people and organizations who have the most interest in it. Please note that the requirements of people and organizations interested in your company should include any legal or regulatory requirements your organization is subject to. For example – if your company provides financial consulting, it would make sense to ensure that the people, processes, systems, and information involved with your client’s data is in scope. It would also make sense to ensure that your company is not in violation of any laws or regulations specific to financial consulting, or to the countries/states/counties, etc. you operate your business in. It would not make sense for the same business to have a scope that only includes their sales department, who do not have access to or influence on any customer data or its security. In short, you want to be sure you are meeting the requirements and/or wishes of those who have the most influence on the ability to reach the organization’s goals.
• After considering the details and parties most relevant to your organization and its goals, you should have a good idea of what information should be within the scope of your system.
•  Now the boundaries of the ISMS must be determined, which can be thought of as a perimeter serving as a demarcation between a trusted controlled environment, and the outside world.
• In many cases, the easiest and safest way to determine your boundaries is to include the whole organization. All of its people, processes, systems, and physical locations would be included. For smaller organizations with a single office, or those only offer one product or service, it will most likely be less resource-intensive to take this approach. Determining the people and processes to be included in this case is easy, as it is everyone who is part of the organization. Similarly, the physical perimeter for your location(s) is also easily identifiable.
• Determining the logical boundaries for your data network can be aided by identifying where the demarcation points for entry and exit exist, or where your organization has control and visibility of the network and where it does not.
• If it exists, an organizational chart may easily identify the departments/people that are involved with the specific product or service that is in scope. However, if there are individuals that are out of scope but occupy the same offices or buildings, they will have to be treated the same as any other person outside of scope and controlled as such. This could include separate physical areas secured to only allow in-scope personnel to have access, separate information systems, putting contracts in place with other organizational units to define and enforce information security-related requirements, etc. Any physical locations wherein scope personnel work from,  or that are involved with the data and systems used for the in-scope good or service will need to be included in the scope.
• For limited scopes, a strategy for determining the logical boundaries of the ISMS is to create a high-level data flow chart that illustrates a logical mapping of the associated data. It isn’t necessary to identify each unique server/ router/ switch/ storage array etc. at this point. For example, if you have 27 database servers in geographically diverse locations where in-scope data could end up, just identify database servers as a single point on the map. Start with all of the possible ways the data enters your systems/buildings, all of the potential places it will go to be stored/ processed/archived, and all possible exit points. Also, note the possible ways it can get between these locations. After you have created the high-level map you can go back and drill down each potential system the data could end up at to each unique instance of the resource in order to end up with a comprehensive list of the systems that would need to be in scope. Working with this list of systems, you can then identify the physical locations they reside, methods of transport between them, and individuals with access to these systems.
• Narrowing the scope of your ISMS can reduce its initial cost in resources, or potentially, increase it. Being able to roll out the ISMS at a single location can certainly be much less daunting than implementing at multiple, but due to the ease with which data networks can cross-organizational and geographical boundaries, it may not be realistic. I suggest that you should first determine what it is that your organization does that would have the greatest benefit for your interested parties by being controlled by an ISO 27001 certified ISMS, and then working from there to identify the people, processes, systems, and data that are involved in it.
• The feasibility and sensibility of limiting the scope of your ISMS will greatly depend on the specifics of your organization and its context. The key point to remember is that, with a limited scope, organizational assets outside of the scope must be treated the same as those external to your company.

Different scopes

Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). An organization is often sub-divided into smaller ISMS scopes (e.g. an ISMS relating to a particular project, service, audit or policy, etc). In either case, the scope determines the boundaries and applicability of information security management and controls. The scope will be shaped by:

• the business of an organization
• the needs and expectations of relevant interested parties
• the organizational structures that are currently in place.

It is important to correctly define and agree with the scope with the relevant senior stakeholders at the outset, so as to manage expectations, agree in advance what is (and is not) to be achieved, and ensure that applicable security requirements for relevant systems are identified and implemented. An organization will typically have multiple scopes relating to information security. For example, the overall scope for information security is likely to be considered as the entire organization. However, in most Higher Education environments it would be difficult to tackle the whole organization in one go. Similarly, it would be an almost impossible task to certify the entire organization against an ISO/IEC 27001 standard or other standards like PCI DSS. Thus the organization should consider having multiple, smaller, scopes, each of which is tailored to the protections required for the information it encompasses. For example, the scope of a PCI DSS audit is determined by protecting only payment cardholder data. Starting with a reduced scope (as opposed to trying to tackle too much too quickly) may also increase the chances of success, and of achieving the objectives of the ISMS in a reasonable time. Examples of scopes include:

• scope of an ISMS for the purposes of ISO/IEC 27001 certification
• scope to which a policy applies
• system components potentially affecting the security of cardholder data for PCI DSS compliance
• scope of an audit
• scope of specific information security projects and services
• scope of responsibility in contractual agreements.

How to define the scope of an ISMS

1. Identify what needs to be protected
One of the first questions to ask is “what needs to be protected”? It is likely that there will be many information assets that need to be protected in order to support the organization in achieving its business objectives. It is important to understand which of these the organization considers to be most important, and so a risk-based, prioritized approach should be taken to scoping. In order to establish that assets are actually worth protecting, the organization should justify why each asset requires protection. The scope of an ISMS may initially be defined to include only specific processes, services, systems, or particular departments. Success stories can then be presented as a business case for expanding the scope of the ISMS or creating another, separate scope with different requirements and protections. In order to make the scope entirely clear, especially to third parties, it is a useful exercise to identify what is not in scope (e.g. the activities of the HR department). Either way, the scope should clearly define what is being included, based on the business objectives and information assets to be protected, and it should be clear that anything else is out of scope.

2. Monitor and review
The scope of an ISMS, policy, audit or project is not static and may evolve over time as circumstances, threats, technologies, and requirements develop. Therefore scoping is not something that should be done once at the beginning of a project and then forgotten about. Rather, the scope should be monitored and reviewed at regular intervals and/or in the light of significant changes. In the event of an audit (be it for internal control or certification purposes) one of the first things an auditor should do is to review and assess the appropriateness of the scope. Factors that might affect/change the scope of an ISMS include:

• time dependencies: e.g. the scope of a particular ISMS and/or security project may only be applicable for a particular time period
• change in the regulatory environment
• changes/updates to standards and/or third-party requirements
• change in the organization (e.g. organization structure changes)
• identification of non-conformities and/or incidents indicating the incorrect scope
• the overall maturity of ISMS (scope may increase over time)
• change in processes and practices (e.g. ceasing certain activities)
• outsourcing services.

Outsourcing and third parties

Outsourced may be defined as “Any element that is not wholly controlled, managed, built, implemented and maintained by staff employed by the organization.”
Cloud services may be defined as  “A shared computer-based storage solution for data that is based on a virtualized computing environment.” Cloud services can describe any shared environment, which can be provided both locally or outsourced.
All organizations will outsource some activities to third parties. Some third parties are taken so much for granted that, when questioned, staff do not remember them – e.g. the cleaning teams, waste removal contractors, and potentially accountants or auditors. Their activities may not be under scrutiny, yet they may have the highest levels of access.
There are many reasons why an organization may want or need to outsource some (or all) of its IT provision. As information technology changes and evolves extremely quickly, it can be more cost-effective to outsource some of an organization’s IT solution or to use cloud storage or services. Economies of scale mean that large data warehouse-style storage facilities can offer cheap storage and extremely good availability. Externally hosted services may also provide specialist IT knowledge and support that is not available within the organization. If managed properly, outsourced IT or cloud technology carries no greater risk and arguably less risk than managing an in-house IT environment. However, poorly sourced or managed outsourcing, or inappropriate cloud provision, can be extremely risky. When cloud services are used, there can be multiple parties involved in the production of the overall service. For example, infrastructure and software services can be provided by different organizations. Scoping in this context will involve having a clear understanding of the system components involved and the security responsibilities of each service provider. These security requirements should be included in any contractual agreements. Responsibility for implementing security may be outsourced, but the accountability cannot be, and so it is, therefore, important to understand the scope of an ISMS in this context. Put simply, when it comes to meeting certain security requirements, outsourced functions or processes will be in scope for an ISMS, but the suppliers are unlikely to be. It is up to the organization to decide how it may be assured that the services provided are of an appropriate standard.
Understanding an organization’s relationship with third parties is extremely important to ensure security for the business and the information that it holds, especially where information security may be put at risk by third party activities, even though their activities are not obviously related to information (e.g. cleaners). When working with any third party, it is important for information security that the following are defined:

• Legal responsibility, accountability, and insurance: all the parties’ responsibilities must be detailed and understood. Running through a risk assessment process will uncover many areas where accountability needs to be defined. Disaster planning and incident response is also a good way of verifying that ownership and insurance responsibilities are correctly scoped.
• Access and authorization: it is essential to make sure the rules and regulations for who can access what are clearly defined. If the organization is allowing contractors into buildings, it should understand who has the keys or access codes; and who ensures the staff is trained and things are secure. Out of hours office cleaning staff often have more physical access to an organization than even the most trusted day staff. Access to IT systems and data should also be considered.
• Disclosure and privacy: the organization should define and categorize the information that is being used and shared, and specify the applicable rules and regulations.
• Contract terms: The terms of contracts with third parties should be clearly defined to make sure that all parties are clear on the expectations of the work to be conducted, and sanctions or liabilities in the event of default are assigned.

When selecting a third party, questions such as the following should be considered:

• What data are going to be on the outsourced system? Do the data include any sensitive information, or have special requirements?
• What laws or regulations applicable to the service provider who is supplying the IT provision? If it is a company outside of the EU, how will that interact with the requirements of the data which it will handle? Where will the data itself be stored?
• Who needs access to the IT solution? Is it something that needs a lot of physical involvement or does it not need any attention for many months?
• Are there restrictions on who administers the system? Who will the administrators be and who controls the access rights?
• Where is the system physically housed? Is the facility secured, who is it shared by, and who controls the access?
• Does the outsourced service provider themselves outsource any of their provision (e.g. off-site back-ups)?
• How do they manage the security controls which their third parties are handling?
• What service level is expected or provided? What levels of assurance for confidentiality, availability, and integrity of data are there? Check the policies in place within your organization.
• At the end of the business relationship, how will it be possible for the organization’s information to be extracted from the third party environment in a usable form?
• What provisions (if any) are in place for compensating the organization for the impact of a business continuity incident or disaster (e.g. loss or exposure of information)?

Examples of Scope

1. Voice Connect design, develop, supply and support the following:
Integrated telephony and multiple media computer messaging products and services;
An Alarm Receiving Centre (ARC) that provides a lone worker monitoring service;
A Payment Portal that enables a cardholder to use a touch-tone phone to make payments.

2. The company is committed to protecting its information and that of its customers. To achieve this goal, the company has implemented an Information Security Management System in accordance with ISO/IEC 27001: 2013. The company’s ISMS is applicable to the following areas of the business:

• Finance department
• Internal IT systems and networks used for back-end business (such as email, timesheets, contract development and storage, and report writing)
  (Note: IT systems on which company software is developed and stored are part of the Software Development ISMS. Refer to the Software Development Security Manual for more information.)

3. The ISMS offers protection to all information processed stored in the E-commerce servers or transmitted through it and desktops connected to E-commerce servers through a dedicated LAN.
The e-commerce server and the desktops are located on the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020. It also includes the following :

1. Law, HR and Admin functions associated with e-commerce.
2. DR site located at 607 Raheja Centre, Nariman Point, Mumbai – 400 021.
3. Development Server located at the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020

4. This ISMS applies to all information assets used or supported by Lancashire County Council in the course of its business. In the main, this refers to the information and record-keeping systems of the five Directorates and the three Direct Service Organisations but the specific areas covered by the ISMS are as follows.
Areas covered by this ISMS:

• Corporate network and all assets connected to it including Pensions Scheme
• All hardware-software and information records held by employees or agents of Lancashire County Council for Lancashire County Council business purposes
• People’s Network
• The LGFL network
• Shared sites where facilities are supported by Lancashire County Council
• Facilities owned by Lancashire County Council and connected to its networks but operated from the premises of other organizations.
• Privately owned equipment used in the course of employment with the County Council
• The Contact Centre
• Telephony network

Areas not covered by the ISMS

• LCDL
• Organizations for which Lancashire County Council is merely the accountable body
• Schools

4.4 Information security management system

The organization must establish, implement, maintain and continually improve an information security management system which must include the processes and their interaction, in accordance with the requirements of this International Standard.

Organizations of all types and sizes:

1. collect, process, store, and transmit information;
2. recognize that information, and related processes, systems, networks, and people are important assets for achieving organization objectives;
3. face a range of risks that may affect the functioning of assets; and
4. address their perceived risk exposure by implementing information security controls.

All information held and processed by an organization is subject to threats of attack, error, nature (for example, flood or fire), etc., and is subject to vulnerabilities inherent in its use. The term information security is generally based on information being considered as an asset that has a value requiring appropriate protection, for example, against the loss of availability, confidentiality, and integrity. Enabling accurate and complete information to be available in a timely manner to those with authorized needs is a catalyst for business efficiency. Protecting information assets through defining, achieving, maintaining, and improving information security effectively is essential to enable an organization to achieve its objectives, and maintain and enhance its legal compliance and image. These coordinated activities directing the implementation of suitable controls and treating unacceptable information security risks are generally known as elements of information security management. As information security risks and the effectiveness of controls change depending on shifting circumstances, organizations need to:

1. monitor and evaluate the effectiveness of implemented controls and procedures;
2. identify emerging risks to be treated; and
3. select, implement and improve appropriate controls as needed.

To interrelate and coordinate such information security activities, each organization needs to establish its policy and objectives for information security and achieve those objectives effectively by using a management system.
An Information Security Management System (ISMS) consists of the policies,  procedures, guidelines, and associated resources and activities, collectively managed by an organization, in the pursuit of protecting its information assets. An ISMS is a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an organization’s information security to achieve business objectives. It is based upon a risk assessment and the organization’s risk acceptance levels designed to effectively treat and manage risks. Analyzing requirements for the protection of information assets and applying appropriate controls to ensure the protection of these information assets, as required, contributes to the successful implementation of an ISMS. The following fundamental principles also contribute to the successful implementation of an ISMS:

1. awareness of the need for information security;
2. assignment of responsibility for information security;
3. incorporating management commitment and the interests of stakeholders;
4. enhancing societal values;
5. risk assessments determining appropriate controls to reach acceptable levels of risk;
6. security incorporated as an essential element of information networks and systems;
7. active prevention and detection of information security incidents;
8. ensuring a comprehensive approach to information security management; and
9. continual reassessment of information security and the making of modifications as appropriate.

Information

Information is an asset that, like other important business assets, is essential to an organization’s business and consequently needs to be suitably protected. Information can be stored in many forms, including digital form (e.g. data files stored on electronic or optical media), material form (e.g. on paper), as well as unrepresented information in the form of knowledge of the employees. Information may be transmitted by various means including courier, electronic or verbal communication. Whatever form information takes, or the means by which the information is transmitted, it always needs appropriate protection. In many organizations, information is dependent upon information and communications technology. This technology is often an essential element in the organization and assists in facilitating the creation, processing, storing, transmitting, protection, and destruction of information.

Information security

Information security includes three main dimensions: confidentiality, availability, and integrity. Information security involves the application and management of appropriate security measures that involve consideration of a wide range of threats, with the aim of ensuring sustained business success and continuity and minimizing impacts of information security incidents. Information security is achieved through the implementation of an applicable set of controls, selected through the chosen risk management process and managed using an ISMS, including policies, processes, procedures, organizational structures, software, and hardware to protect the identified information assets. These controls need to be specified, implemented, monitored, reviewed, and improved where necessary, to ensure that the specific information security and business objectives of the organization are met. Relevant information security controls are expected to be seamlessly integrated with an organization’s business processes.

Management

Management involves activities to direct, control and continually improve the organization within appropriate structures. Management activities include the act, manner, or practice of organizing, handling, directing, supervising, and controlling resources. Management structures extend from one person in a small organization to management hierarchies consisting of many individuals in large organizations. In terms of an ISMS, management involves the supervision and making of decisions necessary to achieve business objectives through the protection of the organization’s information assets. Management of information security is expressed through the formulation and use of information security policies, procedures, and guidelines, which are then applied throughout the organization by all individuals associated with the organization.

Management system

A management system uses a framework of resources to achieve an organization’s objectives. The management system includes organizational structure, policies, planning activities, responsibilities,  practices, procedures, processes, and resources.
In terms of information security, a management system allows an organization to:
a) satisfy the information security requirements of customers and other stakeholders;
b) improve an organization’s plans and activities;
c) meet the organization’s information security objectives;
d) comply with regulations, legislation and industry mandates; and
e) manage information assets in an organized way that facilitates continual improvement and adjustment to current organizational goals.

Process approach

Organizations need to identify and manage many activities in order to function effectively and efficiently. Any activity using resources needs to be managed to enable the transformation of inputs into outputs using a set of interrelated or interacting activities – this is also known as a process. The output from one process can directly from the input to another process and generally this transformation is carried out under planned and controlled conditions. The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management, can be referred to as a “process approach”.

Establishing, monitoring, maintaining and improving an ISMS

1.Overview
An organization needs to undertake the following steps in establishing, monitoring, maintaining and improving its ISMS:

1. identify information assets and their associated information security requirements
2.  assess information security risks and treat information security risks
3. select and implement relevant controls to manage unacceptable risks  and
4. monitor, maintain and improve the effectiveness of controls associated with the organization’s information assets.

To ensure the ISMS is effectively protecting the organization’s information assets on an ongoing basis, it is necessary for mentioned steps to be continually repeated to identify changes in risks or in the organization’s strategies or business objectives.

2. Identifying information security requirements
Within the overall strategy and business objectives of the organization, its size, and geographical spread, information security requirements can be identified through an understanding of:

1. identified information assets and their value;
2. business needs for information processing, storage and communication; and
3. legal, regulatory, and contractual requirements.

Conducting a methodical assessment of the risks associated with the organization’s information assets will involve analyzing: threats to information assets; vulnerabilities to and the likelihood of a threat materializing to information assets; and the potential impact of any information security incident on information assets. The expenditure on relevant controls is expected to be proportionate to the perceived business impact of the risk materializing.

3. Assessing information security risks
Managing information security risks requires a suitable risk assessment and risk treatment method which may include an estimation of the costs and benefits, legal requirements, the concerns of stakeholders, and other inputs and variables as appropriate. Risk assessments should identify, quantify, and prioritize risks against criteria for risk acceptance and objectives relevant to the organization. The results should guide and determine the appropriate management action and priorities for managing information security risks and for implementing controls selected to protect against these risks. Risk assessment should include the systematic approach of estimating the magnitude of risks (risk analysis) and the process of comparing the estimated risks against risk criteria to determine the significance of the risks (risk evaluation). Risk assessments should be performed periodically to address changes in the information security requirements and in the risk situation, e.g. in the assets, threats, vulnerabilities, impacts, the risk evaluation, and when significant changes occur. These risk assessments should be undertaken in a methodical manner capable of producing comparable and reproducible results. The information security risk assessment should have a clearly defined scope in order to be effective and should include relationships with risk assessments in other areas, if appropriate.

4. Treating information security risks
Before considering the treatment of risk, the organization should decide the criteria for determining whether or not risks can be accepted. Risks may be accepted if, for example, it is assessed that the risk is low or that the cost of treatment is not cost-effective for the organization. Such decisions should be recorded. For each of the risks identified following the risk assessment, a risk treatment decision needs to be made. Possible options for risk treatment include:

1. applying appropriate controls to reduce the risks;
2. knowingly and objectively accepting risks, providing they clearly satisfy the organization’s policy and criteria for risk acceptance;
3. avoiding risks by not allowing actions that would cause the risks to occur;
4. sharing the associated risks to other parties, e.g. insurers or suppliers.

For those risks where the risk treatment decision has been to apply appropriate controls, these controls should be selected and implemented.

1.Selecting and implementing controls
Once information security requirements have been identified, information security risks to the identified information assets have been determined and assessed and decisions for the treatment of information security risks having been made, then selection and implementation of controls for risk reduction apply.  Controls should ensure that risks are reduced to an acceptable level taking into account:

1. requirements and constraints of national and international legislation and regulations;
2. organizational objectives;
3. operational requirements and constraints;
4. their cost of implementation and operation in relation to the risks being reduced, and remaining proportional to the organization’s requirements and constraints;
5. they should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.
6. the need to balance the investment in implementation and operation of controls against the loss likely to result from information security incidents.

The controls specified in ISO/IEC 27002 are acknowledged as best practices applicable to most organizations and readily tailored to accommodate organizations of various sizes and complexities. Other standards in the ISMS family of standards provide guidance on the selection and application of ISO/IEC 27002 controls for the information security management system. Information security controls should be considered at the systems and project requirements specification and design stage. Failure to do so can result in additional costs and less effective solutions, and maybe, in the worst case, the inability to achieve adequate security. Controls can be selected from ISO/IEC 27002 or from other control sets, or new controls can be designed to meet the specific needs of the organization. It is necessary to recognize that some controls may not be applicable to every information system or environment, and might not be practicable for all organizations. Sometimes it takes time to implement a chosen set of controls and during that time the level of risk may be higher than can be tolerated on a long-term basis. Risk criteria should cover the tolerability of risks on a short-term basis while controls are being implemented. Interested parties should be informed of the levels of risk that are estimated or anticipated at different points in time as controls are progressively
implemented. It should be kept in mind that no set of controls can achieve complete information security. Additional management actions should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.

2. Monitor, maintain and improve the effectiveness of the ISMS
An organization needs to maintain and improve the ISMS through monitoring and assessing performance against organizational policies and objectives and reporting the results to management for review. This ISMS review will check that the ISMS includes specified controls that are suitable to treat risks within the ISMS scope. Furthermore, based on the records of these monitored areas, it will provide evidence of verification, and tractability of corrective, preventive and improvement actions.

3. Continual improvement
The aim of continual improvement of an ISMS is to increase the probability of achieving objectives concerning the preservation of the confidentiality, availability, and integrity of information. The focus of continual improvement is seeking opportunities for improvement and not assuming that existing management activities are good enough or as good as they can. Actions for improvement include the following:

1. analyzing and evaluating the existing situation to identify areas for improvement;
2. establishing the objectives for improvement;
3. searching for possible solutions to achieve the objectives;
4. evaluating these solutions and making a selection;
5. implementing the selected solution;
6. measuring, verifying, analyzing, and evaluating results of the implementation to determine that the objectives have been met;
7.  formalizing changes.

Results are reviewed, as necessary, to determine further opportunities for improvement. In this way, improvement is a continual activity, i.e. actions are repeated frequently. Feedback from customers and other interested parties, audits, and reviews of the information security management system can also be used to identify opportunities for improvement.

ISMS critical success factors

A large number of factors are critical to the successful implementation of an ISMS to allow an organization to meet its business objectives. Examples of critical success factors include:

1 information security policy, objectives, and activities aligned with objectives;

2. an approach and framework for designing, implementing, monitoring, maintaining, and improving information security consistent with the organizational culture;

3. visible support and commitment from all levels of management, especially top management;

4. an understanding of information asset protection requirements achieved through the application of information security risk management ;

5. an effective information security awareness, training, and education program informing all employees and other relevant parties of their information security obligations set forth in the information security policies, standards, etc., and motivating them to act accordingly;

6. an effective information security incident management process;

7. an effective business continuity management approach; and

8, a measurement system used to evaluate performance in information security management and feedback suggestions for improvement. An ISMS increases the likelihood that an organization will consistently achieve the critical success factors required to protect its information assets.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.