Answer:
If you can protect the patient data, you can include it in your scope, but you can also identify what areas, processes, information systems, etc. that are related to this information, For example, the information is stored in a server? Human Resources area has information about employees involved in the treatment of information?
Basically you should define the scope as information, systems, processes, areas, etc. but not in terms of controls.
Answer:
You are right, I mean, you can certify ISO 27001 for a limited scope of your organization, and you can exclude, for example, the cloud environment. But, if you have implemented ISO 27017/2018, which is simply a code of best practices with specific controls related to the cloud, it is very easy to extend the scope of the ISO 27001 to the cloud environment, because these standards only include some new security controls. So, in this case, our recommendation would be to extend the scope of the ISO 27001 to the cloud environment.
Regarding your second question, there are some certification bodies offering certifies against ISO 27017/27018, although are not regular certificates like ISO 27001, ISO 9001, etc.
One of the most useful CSA's resources is the Cloud Controls Matrix, currently on version 3.0.1. It is a mapping of CSA recommended practices to the most known standards and regulations regarding information protection. Considering ISO standards, this matrix maps CSA practices to:
So, if someone whishes to create a vendor assessment guideline alignend with CSA practices, he can use the Cloud Controls Matrix to identify which CSA recommendations are mapped to supplier management practices from ISO 27001 (items marked with A.15.x.x) and ISO 27002 (items marked with 15.x.x), and choose those that are best fit for his organization. He also can use the same method to align his guideline to ISO 27017 (s ecurity in cloud services) and ISO 27018 (protection of PII).
Policies are clear, simple statements of how your organisation intends to conduct its services, actions or business. They provide a set of guiding principles to help with decision making. Policies don't need to be long or complicated – a couple of sentences may be all you need for each policy area.
Procedures describe how each policy will be put into action in your organisation. Each procedure should outline:
- Who will do what
- What steps they need to take
- Which forms or documents to use.
Procedures might just be a few bullet points or instructions. Sometimes they work well as forms, checklists, instructions or flowcharts.
Policies and their accompanying procedures will vary b etween workplaces because they reflect the values, approaches and commitments of a specific organisation and its culture. But they share the same role in guiding your organisation.
In terms of ISO 9001 it is more common to write a procedure for HR, Biomedical Engineering, IT, Purchasing and Warehouses, and so forth because they fit better with the attributes of a procedure mentioned above.
Second, you might find some controls applicable even though there are no related risks: there are cases when you have to comply with some laws or regulations - e.g. applying encryption - even though the risk assessment does not show any related risks.
Answer:
Basically the asset value is the same that the impact value, and can be calculated as an assessment of impact of loss of confidentiality, integrity and availability of information.
I didn't know if I should have our quality manual follow the same format as the new ISO:2015. i.e have the following clause headings.
0) Introduction
1) Scope
2) Normality references
3) Terms and definitions
4) Context of organization
5) Leadership
6) Planning
7) Support
8) Operation
9) Performance evaluation
10) Improvement
Is it advisable though to update to reflect new versions of the ISO?
Answer:
There is no requirement for Quality Manual to follow structure of the standard. The reason why companies decide to do so is because it helps them see how each of the clauses are met in their Quality Management System. Other than this, there are no reasons for adopting the clause headings of the standard in the manual.
In order to evaluate risks you need to define criteria. Criteria can be based on one or several features. Usually the criteria for evaluation of risk is a severity or consequence of the risk, if the risk has big severity or consequence, it is ranked higher on the list of risks or it can be labeled as significant risk in opposition to insignificant risks with small severity or consequence.
Another feature that can be taken as a criteria for risk evaluation is frequency of occurrence or probability. Some risk can have a big consequence but it rarely happens, so such risk can be considered as insignificant or low on the list of priorities. The risk with high probability and big consequence should be considered as significant, or unacceptable and such risk should be addressed.
There are additional criteria for evaluation of risk, such as detection, that can be used but the number and type of criteria to be used will depend on the needs of the company. Smaller companies will use simpler criteria that can be qualitative or quantitative and bigger and more complex companies will use more criteria and qualitative methodology.