We have implanted ISO 27001 in 2012 but we wrote the policy by our self, can we template for procedure and guide lines for the latest services, such as storage using cloud services.
No conformidades relacionados con los controles del Anexo A ISO 27001
Buenos días, a los controles del anexo A de la ISO27001:2013 se pueden levantar no conformidades o solo a los numerales de la norma.
Respuesta:
Sí, porque por ejemplo hay varios documentos obligatorios relacionados con los controles de seguridad del Anexo A de la ISO 27001 (por ejemplo A.8.1.1 Inventario de activos), y si tienes implementados estos controles pero no tienes el correspondiente documento obligatorio, el auditor puede levantar una no conformidad.
Differences between ISO 27001:2005 and ISO 27001:2013
Differences about risk treatment between 27001 2005 and 27001 2013
Answer:
Regarding the risk treatment, there are no big differences (although in relation with treatment options in the 2013 revision, you are free to consider any option that you find appropriate -not only apply controls, accept risks, avoid or transfer them-), but regarding the risk assessment there are some important changes, for example you need to identify risk owners for each risk, you do not need to use the assets-threatsvulnerabilities methodology to identify risks, etc.
This article can be interesting for you What has changed in risk assessment in ISO 27001:2013 : https://advisera.com/27001academy/knowledgebase/what-has-changed-in-risk-assessment-in-iso-270012013/
Templates for technical controls
The templates were very helpful especially the statement of applicability for the security policy Which will help in implementing security in our environment.
Could you advice on other material that can be helpful in securing information, network security, Access control and system security.
I am re-using in ISMS a QMS procedure for nonconformities management. May I merge incident management with nonconformities management in the same procedure?
Answer:
From my point of view it is not recommendable, because they are different things from information security point of view. Anyway, in ISO 27001 it is not mandatory to have a documented procedure for nonconformities management (only is mandatory to have records about results of corrective actions). So, will be better if you maintain your incident management as independent procedure documented, although you can use you QMS procedure for nonconformities management, but remember, in ISO 27001 is not mandatory to have a documented procedure for this.
To know the list of mandatory documents and records of ISO 27001:2013, this article can be interesting for you List of mandatory documents required by ISO 27001 (2013 revision) : https://advisera.com/27001academy/knowledgebase/list-of-mandatory-documents-required-by-iso-27001-2013-revision/
Finally, this article can be also int eresting for you "How to handle incidents according to ISO 27001 A.16" : https://advisera.com/27001academy/blog/2015/10/26/how-to-handle-incidents-according-to-iso-27001-a-16/
Implementation method and status of controls in Statement of Applicability
For example, for A.9.4.3 Password Management System, we typically use LastPass to store and when necessary share passwords. We do not have a formal Access Control Policy but we plan to develop one in the coming months.
So in a case like this, what should we include in the Implementation Method and Status columns? Should Status reflect that we recognize the current implementation needs to be improved?
Answer:
In this particular case you should write that the implementation method is "Installation of LastPass and writing the Access Control Policy", and your current status would be "Partially implemented." Of course, after you write your Access Control Policy, you would change the status to "Implemented."
Handling documents of external origin
Could this section be scoped only to related records of external origin? I'm not sure how relevant this is for what we manage. I work for a cloud software company, so we're mostly managing documentation and artifacts related to our infrastructure.
Thanks for any feedback or examples of how others have handled this.
Answer:
In its clause 7.5.3, ISO 27001:2013 explicitly requires you to control documents of external origin that are important for your ISMS. So basically you have to decide what's important, so you might control notifications about the vulnerabilities, communication with your clients related to security issues, etc. In other words, you don't have to control everything.
Incoming m ail register is not a mandatory document, you can simply have a table where you register who received some important external document, or where such document is stored.
Assistance on nonconformities
1. Finding:
Although the principles for engineering secure system is in place, however the same is not documented and maintained.
A. 14.2.5
On reviewing the SOA it was found that secure system engineering principles is applicable , however the same is not available for review.
2. Finding :
Although bcp has been consolidated however test records for the scenarios where the probability is high is not evident.
Req: A14.1.5
Objective evidence:
On reviewing the business continuty plan & risk assessment register it was found that fire were identified under high risk category and suppose to be tested.
From my point of view it is better if you put all information in the same document, I mean in the backup policy. You can include in the backup policy the details of frequency of the different activities, it is not a problem.
Regarding your second question, from my point of view, the document could be written by the responsible of backups (or by an IT expert in backups), and could be reviewed and/or approved by the CISO or by the Head of IT department.
You should show it in any way that is convenient for you - for example, if you have a software that automatically creates reports or dashboards, then you can show the results to the auditor in that way.
On the other hand, if you prepare some more complex results manually, than you can use some form or a report (for more complex measurements).
In other words, every ISMS measurement must be documented, but not every ISMS measurement must be written in some form.