Explain procedure of Incident Management and Business Continuity Management
Can you please explain me the whole procedure of incident management and business continuity management
Answer:
Regarding the procedure of incident management, with these main points I will try to explain you the procedure:
a.- Recept and classification of the incident: You detect an incident in your organization, and you classify it in accordance with a criteria (you can consider minor incident, major incident, etc)
b.- Treatment of the incident: Depending of the type of incident, you need perform actions to resolve it (when the incident is resolved, you can close it)
c.- Learning from incidents: After the incident is resolved, you can learn how was resolved, and register all information for a possible future similar incident.
d.- Collection of evidence: Finally, all information registered about the incident, can be useful as evidence in legal and other possible proceedings.
Regarding the Business Continuity Management, there is a standard which can help you to implement a BCMS (Business Continuity Management System) in your orga nization. This standard is ISO 22301, and you can find here more information about it What is ISO 22301? : https://advisera.com/27001academy/what-is-iso-22301/
And with this free webinar you can see an overview of the BCM implementation process ISO 22301: An overview of the BCM implementation process : https://advisera.com/27001academy/webinar/iso-22301-overview-bcm-implementation-process-free-webinar-demand/
After getting the management involved
How are you ? I am a young ciso awared of the benefits of iso 27001 and would like to implement it in my bank. We have never used an isms yet, i need your advises to know which step are important right after getting the management involved. We count 200 people working here and as a bank, which process would you advise me to start from ? Thank you very much
I'm trying to find the best documentation to help me redesign a support model for a company. The end users are external customers and the current L1 and L2 teams are more product specialists in their area mind you L1 does make coffee and put out lunch for customers! Do you have anything that could help?
Answer:
We only have documents for the implementation of ISO 27001 (and ISO 22301), and these standards are not specifically designed for a support model, although you can see this template Incident Management Procedure : https://advisera.com/27001academy/documentation/incident-management-procedure/, and this Operating Procedures for information and Communication Technology : https://advisera.com/27001academy/documentation/security-procedures-for-it-department/, which are related to the IT support (but remember that ISO 27001 is focused in the protection of the information). You can see a free version of each document clicking on Free Demo tab.
Anyway, in your case, the standard that I think that can help you, because it is related to the management of IT services (and their support), is ISO 20000. Here you can find information about this standard What is ISO 20000? Learn why ISO 20000 can benefit your organization : https://advisera.com/20000academy/what-is-iso-20000/
Is the SoA considered public?
"Is the SoA considered public? It specifies which controls have been implemented and verified in the certificate. It seems to me that the 27001 certificate is useless if you don't have access to the SoA that was used."
Answer:
Generally the SoA is not considered as a public document, because can have internal information about the organization (for example can contain references to internal documents), so my recommendation is that you consider this document as Internal use or Restricted. There are various types of information, here you can see them Information classification according to ISO 27001 : https://advisera.com/27001academy/blog/2014/05/12/information-classification-according-to-iso-27001/
And from my point of view, for external people, it is not necessary to have access to the SoA (with some exceptions, for example auditors), keep in mind that the certificate is issued by a certification body, which has reviewed the SoA in a certification audit process.
Finally, this article about the importance of the Statement of Applicability can be interesting for you The importance of Statement of Applicability for ISO 27001 : https://advisera.com/27001academy/knowledgebase/the-importance-of-statement-of-applicability-for-iso-27001/
Semi quantitative
An easy example about semi quantitative method:
Likelihood
0-40% - Low
40-60% - Medium
60-100% - High
Note that I use a scale of numerical values (0-100%), but for each range I use a qualitative value.
Assets, risks and legal requirements
Couple of questions for you, as Im trying to gather as much information as possible before we have the templates.
1. What level of assets do we need to go down to on the Inventory of assets. E.g computers, servers, phones etc.
2. What is the breakdown required on the List of risks?
3. Do you have any recommendations on where to find the list of legal, regulatory, contractual and other requirements.
No, I am sorry, we do not have this. Generally the certification bodies have books about the standards that certify (BSI, Bureau Veritas, etc), so maybe you can find anything in their website related to ISO 27001:2013. But keep in mind that our free webinar can be enough for the preparation of the exam.
Anyway, we have a free ebook related to the cybersecurity that maybe can be also interesting for you, you can download it from here 9 steps to cybersecurity : https://advisera.com/books/9-steps-to-cybersecurity-managers-information-security-manual/
Policies and procedures
I need some clarity over what must be policy according to ISO27001 2013. I used a document called "List of Documents IS27001 Premium Documentation Toolkit" (Attached) which states all document names and whether they are "Mandatory according to ISO27001". Why would something non-mandatory be a policy?
Would an ISO27001 assessor criticise an organisation for having a procedure (rather than a policy) in these non-mandatory areas?
Answer:
Right, a non-mandatory document can be a policy, for example the Information Classification Policy, this is so because the standard ISO 27001:2013 does not establish for the control "A.8.2.1 Classification of information that you need to have a document. Read the description: Information shall be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification. However, in the description of the control A.9.1.1 Access control policy you can read An access control policy shall be established, documented and reviewed based on business an d information security requirements. So, when you see in the standard shall be documented you need a document (mandatory). If not, can be a best practice to have a document but it is non mandatory.
Yes, generally an ISO 27001 assessor could criticize you, because the most logical is to have a policy for those controls that are related to policies: A.6.2.1 Mobile device policy (non mandatory to have a document), A.10.1.1 Policy on the use of cryptographic controls (non mandatory to have a document), etc.
You can have a procedure, for example Use of Mobile Devices where you can detail how to use Mobile devices in the organization, but you can include the basic rules in a policy. So, my recommendation is that if you want to have a document for a non-mandatory area and it is related to a policy, you can have a procedure and also you can have a policy, because they are different things.
Finally, maybe this article can be interesting for you: 8 criteria to decide which ISO 27001 policies and procedures to write : https://advisera.com/27001academy/blog/2014/07/28/8-criteria-to-decide-which-iso-27001-policies-and-procedures-to-write/
Determine external and internal issues
"How to do determine external and internal issues that are relevant to organisation purpose and that affect its ability to achieve the intended outcome(s) of information security management system"
According to the article "Explanation of ISO 27001:2013 clause 4.1 (Understanding the organization)" : https://advisera.com/27001academy/knowledgebase/how-to-define-context-of-the-organization-according-to-iso-27001/, the issues are determined during the RA process and hence there is no need to perform any additional steps to identify the internal / external issues. However, my doubt here is that at this stage (4.1) we are still in the process of determining the scope and the RA (6.1) is at a later stage. So ideally, these 'issues' that we determine at 4.1 should come from a brainstorming session or discussion with relevant stake holders. Please correct me if I have misunderstood something here.
2.- My second and main doubt is while determining these 'issues', do we also need to consider issues that could affect the ISMS in a positive way? As per my understanding, an 'issue' is something that could prevent my ISMS from achieving its intended outcome (its objectives). However, it was pointed out by an auditor that while determining th e issues while considering clause 4.1, we should also consider factors that could influence the ISMS in a positive way. For example, an issue identified was lack of management commitment (this could lead to difficulty in achieving the ISMS objectives). The auditor mentioned that should also consider something Strong management commitment as this could influence the outcome of the ISMS in a positive way (i.e. help the ISMS achieve its objective). I wanted to know if this is necessary or if defining issues the way I have determined it so far (as something that could prevent the ISMS from achieving its outcome) is sufficient to meet the requirement of 4.1
Answers:
Point 1: Yes, you are right, internal and external issues will be mostly discovered during the risk assessment process, but remember that also identifying interested parties. On the other hand, it is not necessary to identify issues related to the RA at the beginning of the implementation (can wait), but you can consider, as a best practice, a brainstorming session or discussion with relevant stake-holders, and after redefine issues during the RA if necessary.
Point 2: From my point of view, it is not necessary to identify issues that could affect the ISMS in a positive way, with issues identified during the RA process, and by identifying interested parties, can be enough. Anyway, can be a best practice to consider issues that could affect the ISMS in a positive way (for example related to Strong management commitment), and also can be a best practice to perform the SWOT analysis (Strengths-Weaknesses-Opportunities-Threats), and PEST analysis (Political-Economical-Social-Technological impacts).
Finally, maybe this article related to security objectives can be interesting for you ISO 27001 control objectives Why are they important? : https://advisera.com/27001academy/blog/2012/04/10/iso-27001-control-objectives-why-are-they-important/