{"id":1670,"date":"2018-11-30T12:01:42","date_gmt":"2018-11-30T12:01:42","guid":{"rendered":"https:\/\/iso27001.solutions\/?p=1670"},"modified":"2019-03-11T17:56:10","modified_gmt":"2019-03-11T17:56:10","slug":"define-the-isms-scope","status":"publish","type":"post","link":"https:\/\/ismsalliance.com\/trends\/iso-27001-implementation\/define-the-isms-scope\/","title":{"rendered":"Define the ISMS Scope"},"content":{"rendered":"

How to decide the scope for an ISMS?<\/h2>\n

Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS)<\/a>. An organisation is often sub-divided into smaller ISMS scopes (e.g. an ISMS relating to a particular project, service, audit or policy etc).<\/p>\n

In either case, the scope determines the boundaries and applicability of information security management and controls. Scope will be shaped by:<\/p>\n

\u2022 the business of an organisation
\n\u2022 the needs and expectations of relevant interested parties
\n\u2022 the organisational structures that are currently in place.<\/p>\n

It is important to correctly define and agree 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.<\/p>\n<\/div>

<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
<\/a><\/span><\/div><\/div>
<\/div><\/div><\/div><\/div><\/div>
<\/div>
<\/div>
<\/div>

Different scopes<\/h2>\n<\/div>
<\/div>
<\/div><\/div>
<\/div>

An organisation 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 organisation. However, in most Higher Education environments it would be difficult to tackle the whole organisation in one go. Similarly, it would be an almost impossible task to certify the entire organisation against a standard such as ISO\/IEC 27001<\/a> or PCI DSS. Thus the organisation 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.<\/p>\n

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.<\/p>\n

Examples of scopes include:<\/strong><\/p>\n

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

<\/div>
<\/div>
<\/div>

How to define the scope of an ISMS ?<\/h2>\n<\/div>
<\/div>
<\/div><\/div>
<\/div>

Identify what needs to be protected<\/h3>\n

One of the first questions to ask is \u201cwhat needs to be protected\u201d? It is likely that there will be many information assets that need to be protected in order to support the organisation in achieving its business objectives. It is important to understand which of these the organisation considers to be most important, and so a risk-based, prioritised approach should be taken to scoping. In order to establish that assets are actually worth protecting, the organisation should justify why each asset requires protecting.<\/p>\n

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.<\/p>\n

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).<\/p>\n

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.<\/p>\n

Understand the organisation<\/h3>\n

The scope of an ISMS should take advantage of the organisational, management and governance structures that currently exist. The person(s) tasked with managing information security across an organisation should therefore begin by identifying relevant structures, and any constraints set by the structures that currently exist. If there is no governance currently in place then progress will be limited when trying to identify requirements and risk, and implementing security controls across the entire organisation. The scope of any initial work
\nmay therefore be to implement an appropriate management and governance framework (see Chapter 2, Information security governance).<\/p>\n

Where the scope of an ISMS is defined by the need to protect a particular asset (e.g. cardholder data) or delivery of an objective (e.g. certification against ISO\/IEC 27001) then it is important to first understand system components and structure involved in the delivery of relevant services. This may include, for example, obtaining system diagrams showing data stores and flows and relevant IT systems. Personnel involved in managing and delivering all system components will then likely be considered \u201cin scope\u201d.<\/p>\n

Ensure endorsement of scope<\/h3>\n

The scope of an ISMS, policy, project or audit etc. should be endorsed and formally agreed by the relevant senior stakeholders (top management), to manage expectations and clearly define the objectives that will be delivered. Failure to correctly identify and formally agree the scope in this way is likely to lead to unclear objectives, difficulties in measuring progress and ultimately decrease the chances of success.<\/p>\n

For those managing information security, it is important to consider the boundaries of control and authority. If, for example, the security of services or systems in a particular department are beyond the control or authority of the owners of the ISMS, they should not be included in the scope.<\/p>\n

In the context of an audit, agreeing which systems are in scope may be particularly important so as to ensure that it is clear which systems the auditor is authorised to access and under what circumstances. Failure to obtain such authorisation in advance could even lead to a breach of law (such as the Computer Misuse Act 1990).<\/p>\n

Monitor and review<\/h3>\n

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.<\/p>\n

Rather, 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.<\/p>\n

Factors that might affect\/change the scope of an ISMS include:<\/strong><\/p>\n

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

<\/div>
<\/div>
<\/div>

Outsourcing and third parties<\/h2>\n<\/div>
<\/div>
<\/div><\/div>
<\/div>

Outsourced<\/strong>: Any element that is not wholly controlled, managed, built, implemented and maintained by staff employed by the organisation.<\/p>\n

Cloud services<\/strong>: A shared computer-based storage solution for data that is based in a virtualised computer environment. Cloud services can describe any shared environment, which can be provided both locally or outsourced.<\/p>\n

All organisations will outsource some activities to third parties. Some third parties are taken so much for granted that, when questioned, staff do not remember them \u2013 e.g. the cleaning teams, waste removal contractors, and potentially accountants or auditors<\/a>. Their activities may not be under scrutiny, yet they may have the highest levels of access.<\/p>\n

There are many reasons why an organisation 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 organisation\u2019s IT solution, or to use cloud storage or services. Economies of scale means 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 organisation.<\/p>\n

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.<\/p>\n

Scoping considerations for cloud and outsourcing services<\/h3>\n

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 organisations.<\/p>\n

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.<\/p>\n

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 organisation to decide how it may be assured that services provided are of an appropriate standard.<\/p>\n

For further information, the ICO has produced a guide on the use of cloud computing, and UCISA has a briefing paper on cloud computing.<\/p>\n

Scope and third party contracts<\/h3>\n

Understanding an organisation\u2019s 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).<\/p>\n

When working with any third party, it is important for information security that the following are defined:<\/strong><\/p>\n