[...] is this a repetitive task that has to be done in the beginning of each risk assessment process (given that risk assessment conducted for certain limited scope such as a web service)?
Exactly. But the part you put in brackets is really important. Take a look at this picture.
You can see here that context establishment takes place before every risk assessment. The scope is defined within the context establishment.
First of all, we have to answer the following question:
What does 'context' mean within the ISO/IEC 27005?
Consider the following note:
ISO/IEC 27001:2005 does not use the term “context”. However, all of Clause 7in ISO/IEC 27005 relates to the requirements “define the scope and boundaries of the ISMS” [4.2.1 a)], “define an ISMS policy” [4.2.1 b)] and “define the risk assessment approach” [4.2.1 c)], specified in ISO/IEC 27001:2005.
and the output of the context establishment process:
Output: The specification of basic criteria, the scope and boundaries**, and the organization for the information security risk management process.
These three "items" establish the context.
Basic criteria are the criteria that detail your risk management process. These criteria follow your risk management approach and this approach follows the objectives and the scope of your risk management.
Basic criteria can be:
- Risk evaluation criteria
- Impact criteria
- Risk acceptance criteria
I don't want to go into these criteria too much, because they are all well described within the norm.
Scope and boundaries
The scope and boundaries always refer to the information security risk management. They need to be defined to "ensure that all relevant
assets are taken into account in the risk assessment. In addition, the boundaries need to be identified to address those risks that might arise through these boundaries."
This part is crucial and probably the most complicated in the whole process. If your scope is too wide, the gathering of information can take so much time, that once you are done you have to start over again, because so much has changed in the meantime. The more time you need, the more money and ressources will be spent. If your scope is too narrow, you will exclude a lot of and important information and therefore a lot of possible risks. The worst part about this: there is no standard or "good" recipe for this. If you have never done this before, get help from the outside and go through this process step by step.
Important note that is often forgotten: "Additionally, the organization should provide justification for any exclusion from the scope."
Do not just leave parts of your organization out. This isn't only meaningful for an audit, but it's also helpful for you and your team. Why would you choose a scope the way you did and why does it make more sense than any other way?
Organization for information security risk management
This one is pretty easy (to understand): your risk management process has to be organized. Roles and responsibilities have to be alloted, and all formal activities that come with a risk management process have to be conducted. This is all very straightforward and highly formalized.
All quotes as well as the figure are taken from ISO/IEC 27005, Second Edition 2011-06-01