Scope of the ISMS

Please note that in the example you provided the software solutions are used as boundaries for the information that needs to be protected (in this case, the customer sensitive information), so the software solutions themselves are not part of the ISMS scope.

This approach affects the ISMS because, while this makes the scope smaller, it increases its complexity, because the organization needs to define how this scope is separated from other elements of its cloud environment.

As a physical analogy, you can think about a scope where only a department in the whole organization is part of the ISMS scope. This makes the scope smaller, but you need to define how this department will be separated from the other departments that are not part of the scope.

Hi Rhand,

You say:

so the software solutions themselves are not part of the ISMS scope.

I'm not entirely clear on your answer.

I would assume that the developed software solution should be part of the ISMS scope, if only because it represents an important, if not the most important asset of the organization (intellectual property) that needs appropriate controls to be protected from loss, corruption, breaches of confidentiality, etc.

So to my opinion it should be included in the scope. Am I correct?

Please note that ISMS scope cannot be defined around a product - ISO 27001 scope is defined in terms of processes, information and/or location.

What you can include in the ISMS scope that will be related to the software solution is the software development and maintenance process (a secure process increases the likelihood of delivering a secure product), and the information related to the software source code (e.g., specification documentation, architecture blueprint, written code, etc.).

For further information, see:
- How to define the ISMS scope https://advisera.com/27001academy/knowledgebase/how-to-define-the-isms-scope/

A previous answer on the Risk Assessment Table mentions that "a small organization generally identifies between 50 to 100 assets" [1], which is far more than the assets we've identified so far. That led me to think that perhaps we should split up our assets and assess them individually, even if that leads to duplication. I'll try to explain what I mean with the following example.
We have different databases, but they're all operated in the same way and exposed to similar vulnerabilities, therefore we have grouped them as a single asset named "database" and applied the same security controls. We could theoretically assess risks for each one of them independently, considering that e.g. they may not store data with the same level of confidentiality, resulting in database A having a Risk Score of 3 (non-acceptable risk) while database B is deemed to be no higher than 2 (acceptable risk). Now, we always choose to apply the most stringent security controls even to the least critical assets, at least as long as doing so doesn't incur in excessive costs or efforts on our side. So for example, we always enforce root encryption for all our databases in order to protect from vulnerabilities such as "inadequate disposal of storage media'', regardless of what data may be contained in them. That is why in the end I see no use in evaluating the risks for each one of them separately, instead of simply considering them to be the same asset with the same security controls. Is that reasoning correct?

That aside, another aspect I wanted to confirm is whether the risk assessment process should include technical details about vulnerabilities (e.g. CVE-2022-1234: privilege escalation may result in unauthorized access to database XYZ) or simply serve as a high-level overview, e.g. gathering all vulnerabilities potentially leading to unauthorized access of a given asset as a single item in the table.
The reason I'm asking is because according to your documentation, listing at least 500 risks should be straightforward even for a small organization, but as I stated above, by grouping up similar assets with identical vulnerabilities we end up being far from that number. That makes me think we must be doing something wrong.

1- A previous answer on the Risk Assessment Table mentions that "a small organization generally identifies between 50 to 100 assets" [1], which is far more than the assets we've identified so far. That led me to think that perhaps we should split up our assets and assess them individually, even if that leads to duplication. I'll try to explain what I mean with the following example.

 

We have different databases, but they're all operated in the same way and exposed to similar vulnerabilities, therefore we have grouped them as a single asset named "database" and applied the same security controls. We could theoretically assess risks for each one of them independently, considering that e.g., they may not store data with the same level of confidentiality, resulting in database A having a Risk Score of 3 (non-acceptable risk) while database B is deemed to be no higher than 2 (acceptable risk).

Now, we always choose to apply the most stringent security controls even to the least critical assets, at least as long as doing so doesn't incur in excessive costs or efforts on our side. So, for example, we always enforce root encryption for all our databases in order to protect from vulnerabilities such as "inadequate disposal of storage media'', regardless of what data may be contained in them. That is why in the end I see no use in evaluating the risks for each one of them separately, instead of simply considering them to be the same asset with the same security controls. Is that reasoning correct?

Your reasoning is correct. When similar assets are under similar risks, you can use a single asset to cover them and use different assets when they are under different risks.

For example, you do not need to record organizations laptops as individual assets (you can add a single asset called "laptop"), but if they have specific purposes with different risk levels you can use specific assets like "laptop", "development laptop", and "finance laptop". The same concept applies to cellphones of your organization and other assets. 

For further information, see this article:

• How to handle Asset register (Asset inventory) according to ISO 27001 https://advisera.com/27001academy/knowledgebase/how-to-handle-asset-register-asset-inventory-according-to-iso-27001/

2 - That aside, another aspect I wanted to confirm is whether the risk assessment process should include technical details about vulnerabilities (e.g. CVE-2022-1234: privilege escalation may result in unauthorized access to database XYZ) or simply serve as a high-level overview, e.g. gathering all vulnerabilities potentially leading to unauthorized access of a given asset as a single item in the table.

The reason I'm asking is because according to your documentation, listing at least 500 risks should be straightforward even for a small organization, but as I stated above, by grouping up similar assets with identical vulnerabilities we end up being far from that number. That makes me think we must be doing something wrong.

Please note that you should record different vulnerabilities in different lines in the table, because they may require different controls to treat them.

For example, unauthorized access can be related to weak passwords, or outdated software, which requires different controls to be treated.

This article will provide you a further explanation about risk assessment:

• ISO 27001 risk assessment: How to match assets, threats and vulnerabilities https://advisera.com/27001academy/knowledgebase/iso-27001-risk-assessment-how-to-match-assets-threats-and-vulnerabilities/