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

  • Clause reference

    From your question I’m understanding you want to know how to use an Internal audit checklist based on ISO 27001:2013 considering the references from ISO 27001:2022.

    Considering that, your first assumption is correct. The first column references the ISO standard clause. 

    Regarding mapping the corresponding control in the evidence section, I suggest you add a second column beside the column clause, so you can have the two columns providing the link between the clause from both versions. For example: https://i.imgur.com/JFfCfM7.png

    This way works better when you handle multiple controls from ISO 27001: 2013 that were merged in a single control in ISO 27001:2022 (this data about controls placed in a specific column makes reading them easier).

    For further information, see:

    • ISO 27001:2013 to ISO 27001:2022 Conversion Tool https://advisera.com/insight/iso-27001-2013-to-iso-27001-2022-conversion-tool/

    • ISO 27001 A.8.11

      Thank you, Rhand!  This is very insightful.

    • Controls 10.1.1 + 10.1.2

      1 - Working for a company that does not store any of the data in house and handles software development in github, how would we apply cryptography?

      We are not GitHub experts, so our recommendation to you is to consult GitHub staff to see how to apply cryptography to data at rest in your repositories.
      Maybe these links can provide some information:  

      2 - I understand you need certain processes to include encryption, but I don't quite see where I could use it.

      You can use the results of risk assessment and identified applicable legal requirements (e.g., laws, regulations, and contracts), to build an understanding of where to apply cryptography.

      For example, from a contract with a customer, you can identify a clause demanding that all codes developed for that customer must be encrypted, or the results of risk assessment demonstrate that a specific module represents a competitive advantage to your company, so keeping the confidentiality of that code through encryption can be a solution.

      For further information, see:

      3 - We use SSH tunnels for an encrypted connection from computers into secure coding environments, but how could we use this in our policy?

      You can define the use of SSH tunnels in section 3.1 of the Cryptographic Policy. For example:

      https://i.imgur.com/UGihIZK.png

    • Register of requirements: Granularity of entries

      ISO 27001 does not prescribe the granularity related to requirements registering, so you can define the granularity to be used as best it fits your organization. 

      For example:

      • You can use a general entry covering contracts with the same content
      • You can use specific entries to associate contracts with specific customers
      • You can add entries related to specific clauses present in different types of contracts

      You can apply one or all criteria suggested or create your own additional criteria.

    • Data breach

      If your employer did a mistake by sending the wrong data about you to the authorities, this is a breach of Art 5.1.d – the Accuracy Principle – in UK GDPR and of Art 5.1.f – the Integrity and Confidentiality Principle – in UK GDPR. You can file a complaint, per Article 77 GDPR - Right to lodge a complaint with a supervisory authority or to seek an effective judicial remedy against your old employer, per Art 79 GDPR - Right to an effective judicial remedy against a controller or processor.

      Please also consult these links:

    • Privacy Act in Canada

      I’m assuming that by PIPEDA you mean the Personal Information Protection and Electronic Documents Act.

      Considering that, since you have customers in other countries, you should assess privacy-related laws and regulations in these countries to check if those define some kind of requirement related to the protection of their citizens’ private data stored/processed in other countries.

      In case there are no such requirements, it would be sufficient to specify conformance with PIPEDA.

      For further information, see:

      • How to comply with EU GDPR, UK GDPR, and Data Protection Act https://advisera.com/eugdpracademy/blog/2021/05/25/how-to-comply-with-eu-gdpr-uk-gdpr-and-data-protection-act/
      • Comparison of GDPR With Leading Privacy Regulations Worldwide [free webinar on demand] https://advisera.com/eugdpracademy/webinar/comparison-of-gdpr-with-leading-privacy-regulations-worldwide-free-webinar-on-demand/

    • Server's decommissioning

      ISO 27001 does not prescribe how to proceed with the server decommissioning, but you can consult the NIST Cybersecurity Framework for guidance:

      Please note that NIST standards are not mandatory for ISO 27001 implementation or certification.

    • BCM policy

      First is important to note that, at the document level, to be compliant with ISO 27001:2013 Annex A.17 controls you only need to document disaster recovery plans. Controls from section A.17 do not require a business continuity management document.

      In case you consider this auditor observation relevant to your business, the document you should consider is a Business Continuity Plan, and you can take a look at a demo of this document at this link: https://advisera.com/27001academy/documentation/business-continuity-plan/

      This article will provide you with a further explanation of Disaster Recovery: 

    • Data Center and Disaster Recovery Site

      Please note that ISO 27001 does not prescribe how far apart a data center and a disaster recovery site should be.

      Additionally, most regulations and industry practices also do not define any specific distance to recovery sites, because many factors can affect what would be considered a “safe” distance (e.g., type of disaster, access to public services, risk level, etc.). From our experience, we suggest you start a discussion suggesting a distance between 30 miles (50 kilometers) and 100 miles (160 kilometers) away from your primary location, and from that analyze your organization's context (a geographic situation, available resources, required investment, etc.).  

      This article will provide you with a further explanation of the distance of the recovery site:

      This material will also help you regarding the distance of the recovery site:

    • MDR Device Labelling

      This symbol is not required to be on the labels according to the MDR 2017/745 and harmonized standard ISO 15223-1:2021 Symbols to be used with information to be supplied by the manufacturer — Part 1: General requirements. But it is not forbidden. So, you just need to explain in your technical file what is the meaning of this symbol. 

      For more information check https://www.iso.org/standard/77326.html
Page 52-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 +