Answer: If all the risks are acceptable, this would mean that you do not need to implement any control, so this would mean that Risk Treatment Plan is not needed.
I must add that if you have such situation, there is something wrong - it is impossible to have all the risks at the acceptable level, so you might have not identified all the risks, or you have been assigning the impact or likelihood too low, or your acceptable level of risk is too low. In any case, not having Risk Treatment Plan will create big problems during the certification audit.
Also I would like to know if it's possible to have a detailed list of Control and Objectives to clarify my thoughts when I'm filling out the Statement of Applicability Table.
Answer: In the ISO 27001 Toolkit you purchased, you have the Statement of Applicability template that lists the names of all controls from ISO 27001 Annex A; however to read the description of ea ch of those controls and get the suggested control objectives, you need to purchase the ISO 27001 standard, you can find it on the ISO website: https://www.iso.org/standard/54534.html
By the way, together with the toolkit you received video tutorial that explains how to fill out the Statement of Applicability - there you can see how to fill out this document, including examples of control objectives.
Transfers of coded (pseudonymized) data from EU to US
1. If the US processor is certified in Privacy Shield, would that cover the transfer, or would standard contractual clauses need to be signed between the EU exporter and US importer (of could these be signed between the US controller and US processor on behalf of the EU exporter)?
2. Would the US controller need to make sure there was also a Data Processing Agreement between the US controller and US processor in place since EU coded data is being processed?
3. Is pseudonymized data still considered personal data once transferred to the US or would it not be personal data any more?
Answer:
Before answering your questions I just want to mention something regarding Privacy S hield. First of all Privacy Shield predates the EU GDPR and this is not 100% in line with its provisions and secondly it has been challenged in front of the European Court of Justice and its future is uncertain. Having this in mind I would advise against using Privacy Shield as a safeguard to transfer data to the US.
1. To be sure that your transfer would not be challenged by any Supervisory Authority and that it won't be affected by the outcome of the Privacy Shield litigation, I would advise using controller to processor Standard Contractual Clauses to legitimize your transfer to an US processor. The SSCs can be signed by a US controller on behalf of the EU exporter. The EU would need to issue a power of attorney to the US entity to enter into a SSC based Data Transfer Agreement.
2. The US controller would basically act on behalf of the EU controller which is needed to ensure the legality of all onward transfers.
3. Yes, as long as the data belong to data subjects “in the Union” even if is pseudonymized it would still be considered personal data.
The organization, in this case NHS Trust Hospital, must act on the subject access request without undue delay and at the latest within one month of receipt. You should calculate the time limit from the day after the hospital received the request (whether the day after is a working day or not) until the corresponding calendar date in the next month.
The timeline for responding can be extended for two additional months if the request is complex or you have sent great number of requests to the hospital. If the hospital cannot respond within one month of receiving your request they should let you know and explain why the extension is necessary.
2. In case the processor is not certified in Privacy Shield, to which contract should the standard contractual clauses be added?
Answers:
1. The safeguards should be ensured by the data exporter, if I understand correctly that the hospital would be in the EU. So the data exporter and data controller would be the EU hospital and the data importer and the processor would be the US located lab.
2. The Standard Contractual Clauses (controller to processor version) should be between the EU hospital (data exporter) and the US Lab (data importer).
Plan de calidad
Respuesta:
La estructura del plan de calidad será diferente en tanto en cuanto han cambiado algunos requisitos de la norma, como por ejemplo que la organización ahora tiene mayor libertad para decidir qué documentación incorporar en su SGC, como son los procedimientos, otros nuevos requisitos a incorporar en el sistema como es la determinación del contexto de la organización, o la identificación de los riesgos y oportunidades. Todo ello será necesario tenerlo en cuenta a la hora también de la planificación de los hitos de cada proceso dentro del proyecto, los recursos necesarios así como las correspondientes responsabilidades.
Básicamente el Plan de Calidad debe de contar con los siguientes elementos
- Planificar las diferentes etapas de su proyecto
- Establecer las funciones y responsabilidades individuales
- Supervisar y organizar por completo su implementación de ISO 9001
Answer: I assume you are referring to a document Statement of Applicability - this document is written so that it is compliant with both ISO 27001 and ISO 22301. However, if you are using only ISO 27001 Toolkit then documents like "Exercise and test plan", and "Review after incidents" do not exist because they are not required by ISO 27001.
You can use the following text for implementation method of control A.17.1.3: "The Disaster recovery plan is reviewed by [job title] every 3 months, and is audited during internal audit every 12 months."
Problems with inventory of assets
If you were to document each and every process, this would mean you would have hundreds of documents - so no, it is not mandatory to document every process.
Developing a process means you have to define exactly what are the inputs, what are the steps in performing certain activities, who is responsible, what is the timing, what are the outputs, etc.
If you do not want to document that process, this means you have to agree with all people involved exactly how this is done, in detail.
If you want to document that process, you simply have to write down everything you have defined.
Answer: I am sorry, but we don’t have a specific checklist for this, but commonly the points of a BCP are the following:
- Roles and responsibilities
- Key contacts
- Plan activation and deactivation
- Communication
- Incident response
- Physical sites and transportation
- Order of recovery for activities
- Recovery plans
You can check in your BCP if these points are in place.
En el contexto de la ISO 27001 (que es sobre la protección de la información del negocio), el criterio debe ser el riesgo: Si estás compartiendo información con partes externas, y no tienes un Acuerdo de Confidencialidad con estas partes externas, existe un riesgo importante relacionado con la revelación de información. Por tanto, básicamente, en mi opinión, debes establecer Acuerdos de Confidencialidad con todas las partes interesadas que puedan acceder a información es pecífica de tu negoio (esta información específica puede ser internal confidencial, etc).
Answer: If you want to implement only the ISO 27002, which is a code of best practices about information security, you don’t need the ISO 27001. But remember that you cannot certify ISO 27002, only ISO 27001 is certifiable, because this standard - I mean, ISO 27001- defines an Information Security Management System.
The core of ISO 27001 is the risk management, and basically you will need to identify and treat risks, and for the treatment, you can use the ISO 27002, because it gives you specific information about how to implement security controls. So, the logic is to implement ISO 27001, using the code of best practices of ISO 27002 to know how to implement security controls for the treatment of risks identified.