Search results

Home / Search

Category:
Select
Select

11269 results

Guest

Guest

Create New Topic As guest or Sign in

HTML tags are not allowed

Select

Assign topic to the user

  • Privacy by design and privacy by default

    Data Protection By Default and By Design is one of the key principles in GDPR, as stated by Article 25 and recital 78 (Appropriate Technical and Organisational Measures). Article 25 GDPR actually focuses on the implementation of the data protection principles stated in Article 5 GDPR through a proactive approach. It mentions that “the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymization, which are designed to implement data-protection principles, such as data minimization, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects”. Thus, according to Article 25 GDPR, data protection must be thought of as ex-ante.

    Privacy by design is a concept first mentioned in 1995 by Ann Cavoukian, former Information & Privacy Commissioner, Ontario, Canada, and it encompasses 7 principles:

  • Proactive not reactive; preventive, not remedial
  • Privacy as the default setting
  • Privacy embedded into the design
  • Full functionality – positive-sum, not zero-sum
  • End-to-end security – full lifecycle protection
  • Visibility and transparency – keep it open
  • Respect for user privacy – keep it user-centric 

    • Her work shaped the modern privacy and personal data protection regulations today.

    You can find more information at these links:

  • Conformio - acceptance of residual risk in reports

    The residual risk is accepted in the Risk Register module, in the risk treatment step. After the definition of the risk treatment option and selection of applicable controls, the residual risk is automatically calculated and approved by the risk owner.

    Additionally, in the Risk Assessment and Treatment Report, the accepted residual risks are listed, and in the Statement of Acceptance of Residual Risks, there is a summary of the accepted residual risks and their respective risk owners. These documents can be found in the Documents module, ISO 27001 folder, Lists Reports Statements, and Plans sub-folder.

  • MVP

    According to the MDR, Article 8 - Use of harmonized standards, it is the manufacturer's obligation to prepare and manufacture their medical device according to the harmonized standards published in the Official Journal of the European Union. On that list is more than 300 different standards considering how the certain medical device must be prepared, The only standard that is on that list considering the quality management system is ISO 13485:2016. Therefore, ISO 13485 is necessary to be implemented.   

    For more information, see: 
    EU MDR Article 8 – Use of harmonised standards - https://advisera.com/13485academy/mdr/use-of-harmonised-standa

  • Query on Classification of ISMS

    First is important to note that the term “audit point” does not exist in the ISO audit context, and assuming that by “audit point” you mean a list of deficiencies, not nonconformities, the closest term for an ISO audit would be observation.

    In this case, it is possible to take advantage of a QMS internal audit to check the status of observations raised in the last ISMS audit.

    You can do that when reviewing the status of previous QMS nonconformities. You only need to take care in planning the audit to consider this as a separate activity of the QMS internal audit, so you can plan the necessary time for the QMS internal audit.

    An additional reminder is that you cannot include any information about the ISMS observations in the QMS report. The best approach would be for you to perform a QMS and ISMS integrated audit (this is possible because ISO 27001 and ISO 9001 share compatible internal audit requirements.)

  • 5 Core Tools in IATF

    As you know, these 5 core tools are APQP-PPAP-FMEA-SPC and MSA.

    I am stating the item numbers of the IATF 16949:2016 standard and the relevant core tools below.

    • PPAP: 7.1.3.1-7.5.3.2.2-8.3.4.4-8.3.6.1-8.5.6.1-8.6.1
    • MSA: 7.1.5.1.1-9.1.1.2-9.1.1.3
    • All Core tolls: 7.2.3-7.2.4-9.2.2.2
    • APQP: 7.5.3.2.2- 8.1.1-8.2.3.1.3-8.3.2.1-8.3.4.1-8.3.4.2-8.3.6.1-8.5.6.1-9.1.1.2-10.2.4
    • FMEA: 7.5.3.2.2-8.3.2.2-8.3.3.3-8.3.5.1-8.3.5.2-8.5.1.1-8.5.6.1-8.7.1.4-8.7.1.5-9.1.1.1-9.1.1.2-9.2.2.3-10.2.3-10.2.4-10.2.6-10.3.1
    • SPC: 8.2.3.1.3-8.3.5.2-9.1.1.1-9.1.1.2-9.1.1.3

    • Datacenter room

      ISO 27001 does not prescribe what a data center room is, neither its layout nor internal furniture, so organizations are free to define them as they see fit.

      The location you will use as a data center, its layout, and furniture will depend on the related risks and if you accept them or not. For example, normal office furniture may not be recommended, but it is less expensive than datacenter-oriented furniture. Having a separate room for endpoint maintenance can be more secure, but if it is possible to accept the risk related to having communication and server equipment in the same room, it is acceptable by the standard.

      A common reference you can use is the standard EIA TIA 942, which defines specifications for telecommunications infrastructure of data centers and computer rooms, and you can find it at this link: https://global.ihs.com/doc_detail.cfm?&csf=TIA&item_s_key=00414811&item_key_date=860905&input_doc_number=TIA%2D942&input_doc_title=

    • Scope of the ISMS

      1- A previous answer on the Risk Assessment Table mentions that "a small organization generally identifies between 50 to 100 assets" [1], which is far more than the assets we've identified so far. That led me to think that perhaps we should split up our assets and assess them individually, even if that leads to duplication. I'll try to explain what I mean with the following example.

       

      We have different databases, but they're all operated in the same way and exposed to similar vulnerabilities, therefore we have grouped them as a single asset named "database" and applied the same security controls. We could theoretically assess risks for each one of them independently, considering that e.g., they may not store data with the same level of confidentiality, resulting in database A having a Risk Score of 3 (non-acceptable risk) while database B is deemed to be no higher than 2 (acceptable risk).

      Now, we always choose to apply the most stringent security controls even to the least critical assets, at least as long as doing so doesn't incur in excessive costs or efforts on our side. So, for example, we always enforce root encryption for all our databases in order to protect from vulnerabilities such as "inadequate disposal of storage media'', regardless of what data may be contained in them. That is why in the end I see no use in evaluating the risks for each one of them separately, instead of simply considering them to be the same asset with the same security controls. Is that reasoning correct?

      Your reasoning is correct. When similar assets are under similar risks, you can use a single asset to cover them and use different assets when they are under different risks.

      For example, you do not need to record organizations laptops as individual assets (you can add a single asset called "laptop"), but if they have specific purposes with different risk levels you can use specific assets like "laptop", "development laptop", and "finance laptop". The same concept applies to cellphones of your organization and other assets. 

      For further information, see this article:

      2 - That aside, another aspect I wanted to confirm is whether the risk assessment process should include technical details about vulnerabilities (e.g. CVE-2022-1234: privilege escalation may result in unauthorized access to database XYZ) or simply serve as a high-level overview, e.g. gathering all vulnerabilities potentially leading to unauthorized access of a given asset as a single item in the table.

      The reason I'm asking is because according to your documentation, listing at least 500 risks should be straightforward even for a small organization, but as I stated above, by grouping up similar assets with identical vulnerabilities we end up being far from that number. That makes me think we must be doing something wrong.

      Please note that you should record different vulnerabilities in different lines in the table, because they may require different controls to treat them.

      For example, unauthorized access can be related to weak passwords, or outdated software, which requires different controls to be treated.

      This article will provide you a further explanation about risk assessment:

    • Question about the risk assessment table

      ISO 27001 does not prescribe a detailed level for risk assessment and risk treatment, so organizations are free to define the detail level they see fit to provide them the confidence they are treating risk properly.

      For example, for some organizations naming an asset as a “database” is enough to map all relevant risks, while for others they find it more useful to use specific assets for different databases because they have different risks specific for each one.

      Another good example is the asset “laptop”, for which you can list all common risks, and then add assets like “development laptop” and “sales laptop”, for which you identify specific risks related to the activities they are used to.

    • SOA; CONTROL APPLICABLE vs. CONTROL IMPLEMENTED?

      1 - Can you help me explain the implementation of SoA?

      The implementation of SoA, i.e., of the controls identified as applicable, is made according to what is defined in the Risk Treatment Plan, which defines actions, responsible, and deadlines.

      For example, if control A.12.3.1 Information backup is defined as applicable in the SoA, in the Risk Treatment Plan you will define activities like elaboration, approval, and publication of a Backup Policy, and the acquisition and implementation of a software solution to be implemented in your environment.

      For further information, see:

      2 - Is SoA acceptable if not all applicable controls are implemented? (control applicable) are not (control implemented)?

      I’m assuming you are asking about SoA acceptance considering certification purposes.

      Considering that, during a certification audit it can accept that certain controls stated in the SoA as applicable are not implemented if:

    • all the major risks are resolved before the certification
    • in the Risk Treatment Plan it is clearly defined that those controls will be implemented at a later date
    • the risk owners have accepted the risks related to controls that will be implemented later.

      • These materials will also help you regarding Risk Assessment and Treatment:

    • ISO 27005:2018

      If I understood correctly, you want insight into the relevance of ISO 27005 to currently ISO 27001 based ISMS’s.

      Considering that, although the asset, threat, and vulnerability risk identification method are no longer mandatory for ISO 27001, it still continues to be one of the most used approaches, due to its simplicity, so you should keep the ISO 27005 standard in your read list. For other approaches for risk assessment, you should consider also reading ISO 31010, which covers other Risk assessment techniques.

      For further information, see:
Page 117-vs-13485 of 1127 pages

Didn’t find an answer?

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

CREATE NEW TOPIC +