This section of the standard is about understanding as much as possible about the organisation itself and the environment in which it operates. The key point about the ISMS is that it should be appropriate and relevant to the specifics of the business it is protecting. To ensure this, the people implementing and running the ISMS must be able to answer questions about what the organisation does, where, how and who for (plus many others).
The ISMS will also be affected by the situation within the organisation (internal issues) and outside the organisation (external issues). Internal issues are factors such as the culture, management structure, locations, management style, financial performance, employee relations, level of training etc. that define the organisation. External issues are those less under the organisation’s control such as the economic, social, political and legal environment that it must operate within. All of these issues (internal and external) will have bearing on the priorities, objectives, operation and maintenance of the ISMS. This is particularly relevant when we discuss the areas of risk assessment and control selection where a comprehensive knowledge of how the organisation operates and what could affect it are essential.
The standard also requires that the way in which the ISMS fits in with the controls already in place within the organisation such as corporate risk management, business strategies and policies is defined and that all interested parties are identified, together with their needs and expectations.
One of the items that should be defined and documented is the organisation’s risk appetite. This refers to the overall attitude to risk; is the organisation risk-averse and therefore wants to minimize risk at every level? Or is the attitude that of high risk/high reward where not everything will work out well but enough will deliver results to keep the company going? Or is it somewhere in between?
This needs careful consideration and discussion with top management; unless the organisation is obviously very conservative or obviously very “high stakes” the answer is probably somewhere around the middle. This factor is used later on when deciding what to do about risks identified during a risk assessment – to treat them or to accept them. Risk appetite can be defined at many levels within the organisation and so may vary according to what is being risk assessed and also at what point in time, so a clear understanding is very helpful.
The context section is also the one where the scope of the ISMS is defined. Again, this needs careful consideration. If your organisation is small it usually makes sense to place everything it does within the scope because often it can be more difficult to manage a limitation to the scope than to simply cover everything. As the organisation grows in size so do the issues with scope. There are three main areas in which the scope might be limited; organisation structure (e.g. one division or group company but not others), location (e.g. the Rome office but not the San Diego one) and product/service (e.g. the outsourcing/hosting service but not the software development service). It is perfectly acceptable to start with a smaller scope for certification and then widen it out year by year as the ISMS matures and everyone becomes more familiar with what’s involved. In fact if you need to achieve certification within a short timescale this may well be the best route. You must ensure however that your exclusions make sense and can be justified to the auditor.
One point to note is the difference between the scope of the ISMS and the scope of certification to the ISO/IEC 27001 standard; they don’t have to be the same. You can (if it’s useful to do so) have a fairly wide ISMS scope but only ask for certification to a part of it initially. As long as the part in question meets all the requirements of the standard then it should be acceptable.
The Toolkit provides a template document that prompts for most of the information described above and groups the documented information required for context, requirements and scope into one place. It is perfectly acceptable to split this content into more than one document if that works better for you.