On the ISO2700 forum one user gave a long description of his information gathering process but expressed frustration over what to do with it all all, the assets, the threats and so forth, and trying to make it into a risk assessment.
It was easy for the more experienced of us to see what he was missing.
He was missing something very important -- a RISK MODEL
The model determines what you look for and how it is relevant.
How do you know WHAT assets are to be included in the ISO-27K Asset Inventory?
This question and variants of the "What are assets [for ISO27K]?" comes up often and has seen much discussion on the various InfoSec forums I subscribe to.
Perhaps some ITIL influence is need. Or perhaps not since that might be too reductionist.
The important thing to note here is that the POV of the accountants/book-keepers is not the same as the ISO27K one. To them, an asset is something that was purchased and either depreciates in value, according to the rules of the tax authority you operate under, or appreciates in value (perhaps) according to the market, such as land and buildings.
Here in Canada, computer hardware and software depreciates PDQ under this scheme, so that the essential software on which you company depends is deemed worthless by the accountants. Their view is that depreciable assets should be replaced when they reach the end of their accounting-life. Your departmental budget may say different.
Many of the ISO27K Assets are things the accountants don't see: data, processes, relationships, know-how, documentation.
Let us leave aside the poor blog layout, Dejan's picture 'above the fold' taking up to much screen real estate. In actuality he's not that ego-driven.
What's important in this article is the issue of making OBJECTIVES clear and and communicating (i.e. putting them in your Statement of Objective, what ISO27K calls the SoA) and keeping them up to date.
Dejan Kosutic uses ISO27K to make the point that there are high level objectives, what might be called strategy, and the low level objectives. Call that the tactical or the operational level. Differentiating between the two is important. They should not be confused. The high level, the POLICY OBJECTIVES should be the driver.
Yes there may be a lot of fiddly-bits of technology and the need for the geeks to operate it at the lower level. And if you don't get the lower level right to an adequate degree, you are not meeting the higher objectives.
he documentation required and/or needed by ISO-2700x is a perenial source of dispute in the various forums I subscribe to.
Of course management has to define matters such as scope and applicability and the policies, but how much of the detail of getting there needs to be recorded? How much of the justification for the decisions?
Yes, you could have reviews and summaries of all meetings and email exchanges ..
But that is not and has nothing to do with the standard or its requirements.
The standard does NOT require a management review meeting.
Some people seem to be making life difficult for themselves with risk models such as "Impact * Probability" and as such have lead themselves into all manner of imponderable ... since this model hides essential details.
I discuss the CLASSICAL risk equation in my blog
There is a good reason for, no make that MANY good reasons, for separating out the threat and the vulnerability and asset rather that just using "impact".
Any asset is going to be affected by many
Any control will almost certainly address many assets and in all likelihood deal with many threats and vulnerabilities.
Any reasonable approach will try to optimise this: make the controls more effective and efficient by having them cover as many assets, threats or vulnerabilities as possible.
As such, the CLASSICAL risk equation can then be viewed as addressing residual risk - the probability AFTER applying the controls.