Information security standards have at least two characteristics:
1) they can cure most sleep problems and
2) Some describe a relatively perfect world where those responsible for information security have plenty of time and where there are enough resources to analyse needs and document decisions.
Even though I may have started this post a little sarcastically, I'm actually a big supporter of standards and "best practice"; I see no reason to reinvent good stuff. I cannot do anything about the standards being boring, but I write this post to suggest some responsible shortcuts to a good start on risk assessments and as a pragmatic approach to ISO 27001 compliance (should you want that).
The first shortcut is called not all assets. An asset in the ISO 27001 is rather broadly defined as anything that has value to the organisation, and the standard says you are to "identify assets within the scope". I know of no company that has charted all assets. I suggest you start by "just" assessing your main business processes. Not any other type of asset and certainly not everything with an ip-number. You may later expand the scope to also include the services or systems that support your business processes (called sub-systems in NIST SP800-37). You and your colleagues probably already have a good sense of what business processes matter most to your business. This shortcut is basically a materiality criterion that allows you to perform fewer risk assessments and to spend our time on the more important ones.
The second shortcut is not all threats. If you look, you'll likely find that many information security standards contain fairly comprehensive threat catalogs. Further, if you make your own threat brainstorm to list everything that could possibly go wrong, you quickly discover your threat catalogs are becoming much too long to be operational. This shortcut is to split the assets into types, and then identify which threats are relevant to different asset types. For example, not all types of assets can burn. Business processes, IT services, logical servers, etc. does not burn. It is only the more physical types, such as hardware and buildings. And even within the different physical assets one can make responsible shortcuts by only assessing the threat from the fire at a datacenter, not individually on all the equipment that also stands in the data center. The shortcut here gives fewer threat assessments.
Inheritance is the name of the third shortcut. Good practice and some standards prescribe to make both the Business Impact Assessments (BIA) and probability assessments. The latter is performed by estimating how vulnerabile your assets are to the relevant threats.
Here is the problem: It's difficult to make both kinds of assessments on an asset. Example #1: It is difficult to make vulnerability assessment on a business process. Example #2: It's more than difficult to make a business impact assessment on a server; few people,if any, know which business processes a server supports and how important those are to the business.
The solution to this challenge is to identify dependencies between your assets. In a business process, you can identify which other assets it depends on. Business Impact Assessment are then done "only" on a business process level. Business Impact values are then inherited downwards to the supporting assets.
Vulnerability assessments are made "only" on the supporting assets, e.g. applications, virtual servers, and data centres. The vulnerability scores are inherited upwards to the business process.
This method gives us a dependency hierarchy with BIA scores and vulnerability or probability scores for each asset, so it's easy to calculate a risk score for each asset.
This shortcut results in fewer impact and vulnerability assessments, and you'll benefit from assessments that are actually feasible to perform.
The fourth and last shortcut is to do high-level assessments first. When you conduct a BIA, you will ask how much a security incident is expected to impact revenues, costs, image, and contractual and statutory compliance. The fourth shortcut is to assess these factors collectively, not individually. The same goes for vulnerability assessments, where protection for multiple threats can be assessed together. Granted, it is a shortcut, and you can probably find experts who say that this is not good enough. I still think it makes sense to begin at a high level. You'll subsequently get plenty of opportunities to refine and evaluate your assets in more details, where that makes sense. Therefore, this is also a responsible shortcut, especially if your organisation has not yet made risk assessments a recurrent, regular routine.
Remember that risk assessments and risk management - as all other security efforts - is a process, not a project. Apply this knowledge to use the shortcuts to a great extent and run your risk assessments gently at the first run. You can refine later, for example, by including more assets, more threats, involving more people (more reviews), or going into more details in your assessments.
I'm suggesting that these shortcuts will save you time (your own time, your colleagues', or even your consulting costs, if you have such). The shortcuts will also get you closer to ISO 27001 compliance with less effort (I know; we're ISO 27001 certified).