Search results

Home / Search

Category:
Select
Select

11272 results

Guest

Guest

Create New Topic As guest or Sign in

HTML tags are not allowed

Select

Assign topic to the user

  • Improvement Log

    Please note that ISO 27001 does not prescribe any specific document for logging improvements, but typically the improvements will be documented through Corrective actions.

    To see what fields to consider, please take a look at this template of a corrective form: https://advisera.com/27001academy/documentation/corrective-action-form/

    This article will provide you with further explanation about continual improvement:

  • Change Management and QMS

    Regarding your question about where change management procedures are captured in a QMS, if you are talking about changes for production or service provision please check clause 8.5.6. However, if you are talking about changes to the quality management system please check clause 6.3.

  • Should we have risk management procedure including FMEA for all product lifecycle?

    You can make a Risk analysis for your part of the life cycle (sales and storage??) but then claimed that other parts of the risk analysis are within a particular outsourced company. To allow your awareness of this, you need to have an exact number of documents and revisions of the risk analysis from your outsourced companies, and during your audits of the outsourced companies you need to audit their risk analysis as well. 

    All of this is of course part of the Quality agreement. Just have in mind that no meter that you outsource everything, you are responsible for the product because it is under your name. So, you need to have control over all processes. 

  • Second party audits for an ISO Certified company

    The ISO 9001:2015  standard does not have a clear expectation in this regard, you need to look at the customer-specific requirement. However, the IATF 16949 standard clearly stated its wishes for 2nd party auditors in article 7.2.4.
    In my opinion, first refer to the customer-specific requirements, then you can refer to article 7.2.4 of the IATF 16949:2016 standard if you want.
    Also, VDA 6.3 requirement is available for VW and Mercedes customer-specific requirements. 

     

  • Adapting GDPR material to South African context

    A lot of the documentation that is present in our EU GDPR Documentation Toolkits can be reused or adapted for POPIA compliance. Namely, all the documents related to Preparations for the Project, Personal Data Policy Framework, Privacy Notices, Mapping of Processing Activities, Managing Data Subject Rights, Security of Personal Data, and Personal Data Breaches can be used for POPIA compliance with minor adjustments. Regarding the other documents present in our Documentation Toolkit, they need some more customization related to specific POPIA articles. 

    Please consult these resources as well:

  • ISO Standard for KYC

    I’m assuming that by KYC you mean “Know Your Customer”, a set of processes that allow banks and other financial institutions to confirm the identity of the organizations and individuals they do business with, and ensure those entities are acting legally.

    From that perspective, we do not see a need for financial institutions to use ISO 27001 (nor any other standard from the ISO27k series) for the KYC process.

    For further information, see:

    • What is ISO 27001 https://advisera.com/27001academy/what-is-iso-27001/

    • Gap analysis

      En primer lugar, es importante tener en cuenta que el kit de herramientas proporciona todos los pasos y documentos para la implementación, y la mejor manera para usted es seguir la lógica del kit de herramientas.

      Teniendo en cuenta eso, puede usar los resultados del análisis de brechas para decidir qué controles priorizar (una vez que comience a trabajar en la carpeta Plan de implementación), pero el análisis de brechas, en general, no es necesario para las organizaciones pequeñas, porque el esfuerzo para realizarlo no aporta una ventaja significativa al proceso de implementación (es mejor realizar la evaluación de riesgos durante la implementación).

      Tenga en cuenta que se utiliza un análisis de brechas para evaluar su situación actual con respecto a los requisitos de ISO 27001, por lo que puede usarlo ahora mismo. En este momento, el análisis de brechas le dará una idea del esfuerzo para implementar el estándar.

      Para obtener más información, consulte:

    • Internal Audit and Statement of Applicability

      Thanks for your response. Regarding my second question, it was more about the Statement of Applicability. Having completed the Risk Treatment process and selected which controls we want to implement, is the idea that we then go into the Statement of Applicability to ONLY justify the controls we have said yes to? Do the two documents need to correlate essentially?

      Answer: Your assumption is partially correct. The Risk Treatment Table and the Statement of Applicability (SoA) documents are indeed correlated, but in the SoA, besides the justifications for the controls you deem applicable, you also need to justify the exclusion of controls you do not apply, and if applicable controls are implemented or not.

      For example, if I find a control on the Statement of Applicability and think there's a place to implement that control in our ISMS, do I need to go back into the Risk Treatment and find which risk that would be applicable to and note it down?

      Answer: No, there is no need to go back to the Risk Treatment Table. In other words, in the Statement of Applicability you can select controls as applicable without having a reference to a particular risk.

    • Documented processes

      Please note that ISO 27001 does not require all processes included in the ISMS scope to be documented. Unless a process is specifically required by the standard (e.g. Risk assessment and risk treatment process in clause 6.1.2), or the organization states that it needs to be documented, then you do not need to document it.

      For further information, see:

    • Gap analysis question

      First is important to note that the toolkit provides all the steps and documents for the implementation, and the best way for you is to follow the logic of the toolkit.

      Considering that, you can use the results of the gap analysis to decide which controls to prioritize (once you start working on the folder Implementation Plan), but gap analysis, in general, is not required for small organizations, because the effort to perform it does not bring a significant advantage to the implementation process (it is better to perform the risk assessment during the implementation).

      Please note that a gap analysis is used for you to assess your current situation regarding ISO 27001 requirements, so you can use it right now. At this time the gap analysis will give you an understanding of the effort to implement the standard.

      For further information, see:

Page 29-vs-13485 of 1128 pages

Didn’t find an answer?

Start a new topic and get direct answers from the Expert Advice Community.

CREATE NEW TOPIC +