Answer:
When I work with organizations, facilitating the implementation of a quality management system according to ISO 9001:2015, about clause 7.1.6 “Organizational Knowledge, I draw the following matrix:
The first and second paragraphs of clause 7.1.6 are about quadrants 1 and 2.
Quadrant 1 is about what we know that we know – that is written in procedures, work instructions, tables, specifications. Normally, is listed or codified in job descriptions and when someone starts in a new position human resources plans an integration program with that knowledge transfer.
Quadrant 2 is about what we don’t know that we know – that is work experience not codified, you know, unwritten rules. Normally, is transferred through coaching with more experienced job partners.
The third and fourth paragraphs of clause 7.1.6 are about quadrants 3 and 4.
Quadrant 3 is about what we know that we don’t know – that is information that when an organization realizes that is missing can be obtained through training, books, seminars, consultants, suppliers, technical magazines. For example, this question fits in this quadrant.
Quadrant 4 is about what we don’t know that we don’t know – I call it the radar. How does the organization keep a radar working relevant information that can change the future of the business? Normally, organizations keep track of anything new through books, magazines, blogs, conferences, networking, suppliers, …
For example, many years ago, I was working in a process engineering team in the chemical industry. One afternoon, one of my colleagues, reading a technical magazine, started to comment in loud voice about a new kind of material for storage silos. Rapidly, we in the room started a kind of brainstorm about benefits and drawbacks. After that, my colleague contacted the manufacturer, requested technical information and presented it to our board of directors. After some calculations, it was easy to conclude that the new material had a lot of advantages. We used it in the next plant expansion.
So, organizational knowledge can be much more than work instructions. Just about quadrant 1, don’t forget to mention job descriptions that list knowledge requirements.
Use of Mobile Device and Teleworking Policy and Clear Screen and Clear Desk Poli
If a Mobile Device & Teleworking Policy and Clear Screen & Clear Desk Policy would not be adequate, would there be another more 'achievable' way how to restrict access?
Answer: First of all, sorry for this confusion.
Use of Mobile Device and Teleworking Policy and Clear Screen and Clear Desk Policy is the proper treatment for situations like that, where you do not have control over some locations from where employees can access information (home, office, etc...), since these policies define secure behavior for teleworkers when they are out of organization premises.
2. I assume the Risk Treatment Table only has to contain the unacceptable risks, right?
Answer: Besides unacceptable risks, the Risk Treatment Table also has to include acceptable risks related to controls you want to make modifications or improvements (e.g., if you want to update a technology related to a control, or setup new parameters).
Legal requirements identification
Do you have a comprehensive list of all of them that I can edit and select the ones that are applicable to us ?
Answer:
The development of such a list would require legal knowledge of laws and regulations of many countries, and this kind of knowledge is out of our field of expertise.
Generally speaking some other examples you should consider are:
- Protection of personally identifiable data
- Continuity of telecommunication services
- Protection against computer systems misuse
- Secure exchange of data
In this case we suggest you hiring local legal advisers to evaluate your identified requirements documents.
ISMS documentation
Answer:
In the ISMS implementation, the risk assessment and treatment process is performed after ISMS scope and Information Security Policy definition, starting with the definition of the Risk Assessment and Treatment Methodology.
After implementation risk assessment is normally performed once a year or every time there is a significant change on organizational context.
- the replacement scheme
- the task documenting
as you said in on of the articles?
Answer: Through replacement scheme (where during normal operation different people perform the same activity) you ensure that more than one person knows how to perform an activity, so in case the main operator is unavailable other person can resume his activities.
Regarding documentation, it ensures that knowledge will be retained by the organization in case the person who performs it leaves the organization, as well as it helps to define a standard way of doing things, supporting the replacement scheme.
2. Is there any specific requirement in the standard to regarding these 2 points?
Answer: There is no requirement for replacement scheme in ISO 22301, however clause 7.2 (competence) requires persons are competent for doing work that affects business continuity, and this can be used to support the replacement scheme practice.
Regarding documentation, clause 7.5.1, requires documentation of information determined by the organization as being necessary for the effectiveness of BCMS. So, if a critical activity is considered important to the organization for business continuity, then it should be documented.
The certification coverage will depend on the ISMS scope definition. If it is issued to corporate X, then we need to verify which locations (i.e., addresses) where included. If the address of any subsidiary or affiliated entity is included, then it is covered by the certificate (of course this entity will have to go through all certification process together with the main Corporate X)
Adopting a single certificate for all units or separated ones for each unit is a business decision, depending on their objectives and strategies, but in general organizations like these adopt the model of one certification for each unit, because a change on an unit does not impact the certification of other units.
These articles will provide you further explanation about scope definition:
Answer:
Emergency changes are specific to the organization and need to be defined on case-by-case basis. Meaning, they depend on the organization, services, processes in place, roles and responsibilities, etc. Therefore, it's not realistic to have common procedure for all possible cases.
However, what we have in our toolkit is definition of Emergency Change authority and respective roles (e.g. ECAB and its members).
Also, following article can provide you more information „How to manage Emergency Changes as part of ITIL Change Management“ https://advisera.com/20000academy/blog/2016/01/19/how-to-manage-emergency-changes-as-part-of-itil-change-management/
Rework or repair and ISO 9001
Answer:
Rework or Repair are possible ways of treating product or service non conformities. Product or service non conformities is the subject of ISO 9001:2015 clause 8.7.
Repair may also be used in the context of after sales service, for example, because the customer made a bad use of the product and broke it. After sales service is the subject of ISO 9001:2015 clause 8.5.5 as post-delivery activities.
Answer: If the alternative controls chosen to be implemented have reduced the risks to acceptable levels, then controls A.10.1.1 and A.10.1.2 are not applicable and for justification you can state that there are no risks demanding control implementation.
On the other hand, if the alternative controls chosen to be implemented have not reduced the risks to acceptable levels, and you still decided not to implement controls A.10.1.1 and A.10.1.2 (e.g., because the costs related to the implementation are greater than the expected impact of risk occurrence), then you can state that related risks (IDs xxx, yyy, zzz, etc.) are accepted by top management decision.
2. If two controls have the same risk, what do we write at the justification for selection/non-selection at the second control if we implemented the first one and ther e are no other unacceptable risks?
Answer: If the first control applied has reduced the risk to acceptable levels, for the second one you can state that there are no risks demanding control implementation.
3. Do we really have to restrict access in case we'd like to access the information systems in the datacenter? We do have a Mobile Device and Teleworking Policy and Clear Screen and Clear Desk Policy which is being implemented.
Answer: If there are no unacceptable risks related to unrestricted access to information (not only by employees, but by customers, suppliers, contractors, external parties, etc.), nor legal requirements demanding access control, you do not have to restrict access to information, but this is almost an impossible situation, because any organization has in some degree some information it wants to restrict access to. Additionally, Mobile Device and Teleworking Policy and Clear Screen and Clear Desk Policy implement some degree of access control (e.g., by defining who is eligible for teleworking an by requiring screen lock when user is absent of his workstation).
4. Besides the GDPR, is there anything else that may be relevant to document in the 'List of Legal, Regulatory, Contractual and Other Requirements' ? Perhaps eventual NDA's with stakeholders (e.g. customers) that are very sensitive to security, data, etc. ?
Answer: GDPR is an example of legal requirement related to laws, and your business probably will have some other laws or regulations related to its business that it must comply with. Other examples may be contracts with bug customers and SLA with suppliers. Since we are not legal experts, in these cases we recommend that organizations hire local legal advisers to guide them in this requirements identification.
5. If we implement control A.9.2.5 (Review of users access rights), what should we as a webhosting company review for sure (systems, networks, services and physical access) ?
We definitely have to review the physical access to the datacenter. I think we have to review access to Jelastic (server management) as well. Aside of that I wouldn't know anything else. I don't think we'd have to review access to more than 90 servers, right?
Answer: What you should review will depend on the results of risk assessment and the identified legal requirements (without these information we cannot provide a more precise answer). For example, why are you sure you have to review physical access (e.g., because of risks, or because of legal requirements)?
Regarding the review of your servers, the same concept applies. If you have risks or legal requirements that demand the review of 45 servers (because of information stored or processed by them), then you only have to review these 45.
6. If we implement control A.12.3.1 (Information backup), we must test backup copies. If we are going to test these manually, it will take a very long time (since there are only 4 employees which are doing the webhosting services), is there a more 'achievable' way to test these backup copies?
Answer: Besides automatic tests (which require investment on equipment and software), an alternative you could use is to define a sample size with an acceptable degree of confidence and perform the tests only on the samples, changing the samples every time you perform the test (for sample size definition statistical knowledge is required). This is a way to ensure the backup process is working without a 100% test.
For example, you may find that for a 98% of confidence your backup process is working, you need to test 8 of 100 backup units, and only 1 can fail (if more that 1 fail you will have to test all units). This way, if your process is working properly you have to work on only 8 backups each time you have to test your process (of course, each time you perform the test you have to use a different set of backup units).
7. Records of testing backup copies: Which fields are mandatory?
Answer: ISO 27001 does not prescribe mandatory fields for backup record, but as good practice you can consider at least these fields: which information was requested to be backed up, the requester, the date of request, the date when the backup was performed, the result of the backup procedure (successful / fail) and where the backup was stored.
8. Records of log reviews: Which fields are mandatory?
Answer: Also for this one ISO 27001 does not prescribe mandatory fields for log reviews, but as good practice you can consider at least these fields: Source of log information (e.g., access control server), purpose of the log (e.g. identify unauthorized access, attempts of unauthorized access), expected results (e.g., no login attempts on non working hours) recorded results (success/fail logins), decisions taken (e.g., situation ok, open an incident, etc.).
This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy.
If you decline, your information won't be tracked when you visit this website. A single cookie will be used in your browser to remember your preference not to be tracked.