Some of the questions may seem obvious, sorry about that. I´ll list them so I think it´ll be easier to address;
- Any document that is related to a control, marked with “*” in the LoD, is only mandatory only if such control applies, right?
- Access control policy; why is it mandatory in CoM but depends on if control is applicable in LoD?
- 8.A.8 Acceptable use of Assets (CoM) is Acceptable use p olicy (LoD)?
- A.12 Any difference between Operating procedure for IT management and Operating procedure for ICT?
- 8.A.14 Secure System Engineering principles (+ Appendix) in the Checklist, is this one the same as Secure Development Policy (+ appendix) template from the toolkit? I guess, but just to make sure
- 8.A.15 Supplier Security Policy; this one is not checked as mandatory in the LoD, but the Annex is (only if a control applies) and it is also in the CoM?
- 8.A.17 Disaster Recovery Plan (LoD) is Business Continuity Procedures (CoM), right?
- Definition of security roles and responsibilities (CoM); is this in Template 02 in the toolkit or somewhere else?...
Answer:
The general answer for your question is always to follow the content of your toolkit, in this case the list of documents file (LoD), because it is the most updated version considering the standard's requirements and templates content.
Regarding your specific questions:
- Any document that is related to a control, marked with “*” in the LoD, is only mandatory if such control applies, right?
Answer: Yes, your understanding is correct
- Access control policy; why is it mandatory in CoM but depends on if control is applicable in LoD?
Answer: If you read the article again, you will see in the first paragraph of section "Mandatory documents and records required by ISO 27001:2013" a note informing that "...documents from Annex A are mandatory only if there are risks which would require their implementation.)". So, in both documents the Access Control Policy depends on if control is applicable.
- 8.A.8 Acceptable use of Assets (CoM) is Acceptable use policy (LoD)?
Answer: These titles refer to the same template. Please consider the information in the list of documents file of your toolkit as the most updated.
- A.12 Any difference between Operating procedure for IT management and Operating procedure for ICT?
Answer: No differences.
- 8.A.14 Secure System Engineering principles (+ Appendix) in the Checklist, is this one the same as Secure Development Policy (+ appendix) template from the toolkit? I guess, but just to make sure
Answer: Secure System Engineering principles is one topic in the Secure Development Policy, which covers other controls, like Identification of security requirements.
- 8.A.15 Supplier Security Policy; this one is not checked as mandatory in the LoD, but the Annex is (only if a control applies) and it is also in the CoM?
Answer: Please consider it as not mandatory as listed in the list of documents file of your toolkit.
- 8.A.17 Disaster Recovery Plan (LoD) is Business Continuity Procedures (CoM), right?
Answer: The Disaster Recovery Plan template can be used to cover the controls related to Business Continuity Procedures on small and medium size organizations. On some organizations their requirements may define the development of additional documents.
- Definition of security roles and responsibilities (CoM); is this in Template 02 in the toolkit or somewhere else?
Answer: General roles and responsibilities can be defined in the Information Security Policy, while specific responsibilities and roles are described throughout all templates.
Time between surveillance audits
Answer:
Surveillance audits have to be performed at least once a year. Consider a certification audit performed in November 2018, the first surveillance audit will take place in November 2019, and the second (and last) surveillance audit in November 2020. After this, in November 2020, the certificate would expire, and a company could go for the recertification audit.
Some certification bodies schedule surveillance audits within a time frame inferior to 12 months to avoid a situation where a surveillance audit find major nonconformities and there is no time to close those nonconformities until the 12 month limit after the last audit, situation that should translate into a loss of certification.
ISO 27001 Annex A is not to be used as a document for the ISMS. It is a reference for the definition of which controls to use to protect information and to built the Statement of Applicability. The SoA differs from Annex A because it only makes reference to the controls on Annex A (it does not contain the description of each control), and contains other information, such as which controls are applicable, whether they are implemented or not, and justi fication of controls from Annex A you are not using.
While ISO 22000 defines requirements for food safety management systems, ISO 22301 defines requirements for business continuity, so organizations can manage conditions to protect business from disruptive incidents when they arise, and ensure minimal continuity levels.
Considering your demands, you should look for training on ISO 22000. Unfortunately at this moment we do not provide such training.
To extend the ISMS scope you have to perform all the steps as if you were implementing the ISMS for the first time, in an scale equivalent to the size of this extension.
While you will have less effort related to common requirements such as document and record control, internal audit and management review, the effort for the risk assessment and treatment will depend on how similar this extension is to the current scope. If they are similar you may use existent controls and security metrics with only minor adjustments.
Included in your toolkit there is a List of Documents file that shows which controls from Annex A are covered by each template from your toolkit. This file is on the root folder of the zip file your received.
Processes periodicity
Answer:
Considering as example a software development company, as processes performed on a daily basis that we can mention are codification and testing activities. As for weekly based process you can think of the release of a new version on production environment.
ISO 27001 does not prescribe how many controls you must use to treat a risk, so you can use as many controls as you see is proper for your organizations (the applicable controls will have to be stated as such on the SoA. It is important to note that while applying multiple controls can significantly decrease a risk, it will also require more administrative effort, and these controls may also introduce new risks, so this approach should balance security with effort and new risks.
Answer: ISO 27001 does not require you to assess assets, but it does require you to assess likelihood and impact of a risk. When the impact of a risk is assessed, you have to take into account the effects of this risk on the confidentialiy, integrity and availability of your data.
Q2: Does the RTP have to cover all risks identified against each of the controls or only high/medium risks identified from your risk assessment performed against the companies assets?
Answer: The Risk Treatment Plan (RTP) has to cover only the controls that have not yet been implemented - it doesn't matter to which assets or risks those controls are related to. The risk treatment process has a differentu purpose than the RTP - it has to cover only the unacceptable risks, i.e. the highest risks you identified during the risk assessment process.
The development of business continuity plans often requires the involvement of several persons, because the plan has to consider multiple views such as business, operation, financial, etc. Since these people normally have low experience on developing BCPs, it is the role of the BC manager / implementer to coordinate their efforts, guiding them on the identification of needed information and resources, defining objectives and activation/deactivation conditions, etc. On some cases, after gathering all the information, they can elaborate the part of the plan that involves the activities they will be involved with, while you can write the parts more related to the Business Continuity Management System (e.g., communication plan).