When you have a set of assets with the same features which are affected with the same threats/vulnerabilities, you can create a set of assets with them. This set will be an unique asset, so you can define the same asset owner. It is my recommendation, but keep in mind that the standard not establishes how you have to do it, so you can have in your list all repeated assets, but I think that it is not efficient.
It is quite common that a company wants to certify its data center. To do this, you need to think about this like a project, so basically the first thing that you need is a project plan. Please read this article for more information about this ISO 27001 project How to make it work": https://advisera.com/27001academy/blog/2013/04/22/iso-27001-project-how-to-make-it-work/
About the Statement of Applicability, it is one of the more important documents in the ISMS for any company, because basically is a list of controls with the applicability of each one (which are applicable and and which are not). So, you can write this document only after the execution of the risk assessment & risk treatment. To know more about the main activities that you need to perform in the implementation of the ISMS please re ad this article ISO 27001 implementation checklist" : https://advisera.com/27001academy/knowledgebase/iso-27001-implementation-checklist/
Software development company
If your projects are include in the scope of the ISMS, sure, you need to implement both controls, because both are related with the protection of the information (it is the more important thing in the ISO 27001).
In the Annex A, you can find this security control: A.9.4.3 Password management system. What could happen if your company do not have this control? Any unauthorized person could have access to restricted information.
Also you can find this control: A.12.4.1 Event logging. Here you can ask me: Why this control is important? If there are many attempts of unauthorized access, it is likely that someone is trying to access to restricted information, and you need a control to avoid this.
Therefore, if you implement an ISMS in your organization, and the risk assessment determines that the risk level is not acceptable, you must implement these 2 controls.
Our methodology asset-based is very easy and useful because it focuses on each element that contains information. We only give support for our methodology. Anyway, if you want to focus on business processes (also you can focus on areas of responsibility), you can develop it with the following points:
1.- List the business process
2.- Identify the types of business risk
3.- List the general categories of technical risks and vulnerabilities
4.- Develop a rating scale for each technical risk category
5.- Perform the process analysis
6.- List the risk mitigation practices available for each process
7.- Define the mitigation cost
8.- Prioritize potential mitigation steps
Confining a registrar to the scope that has been defined
I realize the ISMS can be a system that covers more than just security operations, but for initial purposes the *** and ISMS are defined as one and the same. The definition will change over time as scope increases. Just curious.
Answer:
Just because you have defined a certain ISMS scope does not mean such scope is feasible - for example, if there are no clear boundaries for such a scope, then you would have to expand the scope.
Therefore, if your scope is not feasible you should listen to the certification auditor; if your scope is feasible then you have to prove to certification auditor why do you think so. Generally, the recommendation is that the information security should cover the entire organization.
We have a webinar about how to conduct an internal audit according to ISO 22301, which I think that can be useful for you, but you need to buy one of our toolkit to see it. I give you the following URL if you are interested in the purchase Internal audit: How to conduct it according to ISO 27001 and ISO 22301/BS 25999-2": https://www.iso27001standard.com/webinar/internal-audit-how-t************************************************************
Include controls in the SOA
We included a set of controls from 2005 version, but our SOA apparently didn't have strong justification for inclusion. And now we don't want to exclude those controls in 2013 version but sadly we cant find the strong justification.
Answer:
If there are another purpose for the inclusion of a control, you can include it in the SOA. For example, if you have controls added by ISO 27001:2005, and you dont want to exclude them, you can include as justification: Included by ISO 27001:2005