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
My question is: Is it required to create one big asset inventory file or it is ok to keep them separately?
Answer:
Both options are ok for the standard, but I think that you can keep each inventory files of each department/section and also you can integrate them in a unique file that you can keep separately. In this way I think that will be more easy for you for the risk assessment, because for me is more easy to work with an unique file (in the risk assessment) that with different files.
Lograr la certificacion en la norma ISO 22301
Como ya sabes, antes de la certificación tienes que implementar la ISO 22301 en tu organización, y hay muchas cosas importantes que son necesarias para hacer esto: Plan de proyecto (recursos necesarios, fechas, costes, etc), definición del alcance para la ISO 22301, implementación del PDCA (este es similar al PDCA de otras ISOs como por ejemplo ISO 9001, ISO 27001, etc), e implementar los elementos de la Continuidad de Negocio: BIA, Análisis de Riesgos, Estrategia de Continuidad de Negocio, Plan de Continuidad de Negocio, etc.