Answer: If you already have controls implemented, you should consider the totals of likelyhood and consequence after their implementation, so that your risk assessment table reflects the current situation of your environment. The existing controls should be included in the "Existing Controls" column.
Answer: The classification of each document will depend on the information the organization will include to complete the document. In a general manner, documents with processes results (planned or achieved), formulas, drawings, instructions and other elements that gives your organization a competitive advantage should be considered restricted. Policies in general should be considered internal, since many people inside you organization will need to access them. The Quality Policy is an example of a document you should consider public, since people inside and outside the organization may have access to it.
2) Also like to know how many documents are needed related to business continuity. I can see only Backup_Policy_Cloud_EN and Disaster_Recovery_Plan_27001_Cloud_EN. Do we need back up procedure/back up plan and back up logs
Answer: To be compliant with ISO 27001 business continuity requirements, you need only the disaster recovery plan, considering the recovery of IT infrastructure/services. If you consider your organization needs to consider other business process or all the steps in business continuity management, I recommend you check out ISO 22301 Documentation Toolkit.
Regarding the Backup, you can include the information describing the backup plan and how to perform the procedure in the policy document itself (see comments in section 3.1) or decide to create a separated document, what suits you best. As for backup logs, you need to generate and manage as evidence your backup process is being performed and achieving its proposed results. The log generation will depend upon the process you use in your organization (e.g., performed manually by your staff or automatically by a specific tool)
3) I also didn't found controls for A 18 Compliance
Answer: If you consult the list of documents in your ISO 27001, 27017 and 27018 Documentation Toolkit it will show you which documents support each controls of ISO 27001 Annex A. In the case of A.18 controls the documents are "Procedure for Identification of Requirements", "List of Legal, Regulatory, Contractual and Other Requirements", "Policy for Data Privacy in the Cloud ", "Acceptable Use Policy", and "Policy on the Use of Cryptographic Controls".
Lack of resources for Change implementation
Answer:
Changes are, prior to the implementation, assessed, evaluated and authorized. After that comes implementation planning, e.g. who (resources) and when (time plan). So, this is the first moment when you can influence which resources will be dedicated to which change. Later on, once change is ready for deployment, you still have time to manage i.e. prioritize implementation and its schedule. Important is to manage change implementation right from the creation of RfC (Request for Change). read the article "ITIL/ISO 20000 Request for Change – Your steering wheel throughout the change lifecycle" https://advisera.com/20000academy/blog/2015/09/01/itiliso-20000-request-for-change-your-steering-wheel-throughout-the-change-lifecycle/ to learn more.
Threat analysis
Answer: You are correct in your thinking that the server room should be analysed in the context of the server, and that threats which impact the server will also affect the server room (after all, the server room is a protection for the server), but you should note that impacts may be different for the server and the server room, resulting in different control measures. For example, pollution applied to a server affects only the server, while pollution applied to a server room affects all the servers in the room, as well as other equipment and assets inside the room (e.g., network devices, UPSs, etc.). To mitigate pollution i mpacts you may define a maintenance plan for both servers and server room, but the details of each plan will be completely different.
Authorized change is interface/connection between Change Management and Release and Deployment Management.
Documentation review
Answer: ISO 27001 does not require an ISMS Implementation Project Plan as documented information. The plan required by the standard as documented information is the Risk Treatment Plan Plan (clauses 6.1.3 e and 6.2). During documentation review you use the risk treatment plan to verify if all documentation implemented conform the deadlines defined, or you update the risk treatment plan itself if a policy review is needed because of the changes in risk (e.g., a new risks or changes in an already identified risks).
>1 - What I understand is that if an IS policy updated, then the old policy shall be stored in a secure location as a record and only authorized users have access to it. Controls should be implemented as per the classification of the document. In case if there is some requirement of retrieving the old version of IS policy, for instance, an external auditor wants access to the old policy, then the access shall be provided after necessary approval.
Answer: Your understanding of the consequences of the IS policy update is correct.
>2 - For clarification of “Documents of external origin”, can you give some example. If somebody sends a parcel to a friend who is working in an organization, how can it be applicable? who will define the classification of such things? In addition to this, is this the duplication of work that the person sitting at the reception is first registering the parcel and then the one who is the recipient of the parcel.
Answer: You can understand documents of external origin as all documentation outside sole organization control that is relevant to the ISMS, for example a law, industry standard or contract with customer/supplier.
Considering your example, the first thing to be observed is if this parcel is intended to the organization or to the person himself.
If the parcel is intended to the person himself it should be considered private mailing and you should consult your internal policies regarding the receipt of personal mailing in the organization to know how to proceed (yes, if this situation occurs in your organization you should consider how to handle this in at least one of your policies).
If the parcel is intended to the organization, the person to whom it its addressed should apply the information classification according the parcel content.
Regarding the parcel register process, the role of the person at the reception is only to input the parcel information in the incoming mail register and forward the parcel to the intended recipient, the one who has the responsibility to formally acknowledge the parcel receipt in name of the organization. So, there is no duplication or work, since the person at the reception fills one part of the incoming mail register (the parcel information), and the recipient fills another (the receipt acknowledge).
Documenting RTO and RPO
Answer: Considering ISO 22301:2012, the mandatory requirement is that there are defined recovery objectives. How they are defined is an organization's decision, so you can use a single value or a ranged one.
Using single values to RTO and RPO makes easier to communicate to people the organization's general expected results. Using a range of values makes more sense when the organization wants to monitor specific situations in the recovering progress, so it can evaluate if the general results can be achieved until the maximum value defined, and make proper adjustment decisions.
For example, you can adopt a single RTO of 8h, meaning your recovery objectives from "A to G" must be achieved in 8h, or you can adopt a RTO range from 4 to 8, considering that at 4h you should recover objectives A-B-C, at 6h you should recover objectives D-E-F, and at 8h you should recove r objective G. In both cases you have to recover objectives A to G in 8 hours, but by using a ranged value you can have more control over the recovering process. Of course the trade off is that your recovering plan will get more complex.
One thing you also should note is that only RTO is measured in time. The RPO is measured in terms of system state (e.g., the RPO will be the system's situation 4 hours before the incident, which not implies the system will be recovered in 4 hours).
Answer: Roughly speaking, to formulate a good security policy you should consider the following steps: 1) identify and understand the requirements that justify the need for a policy (e.g., clauses of a standard or contract, business decisions, etc.); 2) consider the results of risk assessment, so measures to control relevant risks are supported by the policy; 3) make your policy manageable and integrated to you process (its hard to follow huge policies that are very different of the daily operations); 5) get high level approval (so the policy has more enforcement power); and 7) train and make people aware of the policy (if no one knows the policy, how can you expect they will follow it?)