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

  • QMS, Quality Manual, Quality Procedures and Quality Management Plan

    A QMS, as ISO 9000:2015 defines, is part of a management system related to quality. While implementing a QMS an organization may develop non-mandatory documents like a Quality Manual, a kind of the QMS’s identity card, Quality procedures, documents that set rules about how organizations should act in certain circumstances. Concerning what is a Quality Management Plan, that terminology is not very common with ISO 9001:2015. So, different people may mean different things. For example, a QMP may mean how the QMS is applied in a particular project.

    Companies that work on a project basis, like construction companies, normally have to develop a QMP for each project. Many times it is a client request.

    You can find more information about documentation below:

  • QMS Manager Rights

    According to clause 5.3 of IS 9001:2015, for each organizational role relevant to the QMS, organizations must determine authorities and responsibilities. Each organization may determine different documents and ways of compiling those authorities and responsibilities. For example, some organizations use job descriptions to do that.

    Now, what those authorities and responsibilities are, for each role and organization is defined by each organization and approved by top management.

    You can find more information below:

  • Risk Assessments in Conformio

    1. Can assets be put in a hierarchy, so that filing cabinets can be seen as part of an office building, or firewall as part of a server? I think this would have benefits for overview and determining potentially assets affected by incidents related to other assets below or above in the hierarchy. I'm not sure whether this makes sense from a Risk Management perspective.

    While this functionality would be interesting, it is not currently available in Conformio because it is not required by the standard (even the guidelines from ISO 27002 for ISO 27001 Annex A control A.8.1.1 Inventory of assets do not mention this), and the building of such hierarchy would mean a whole module by itself (it is a whole discipline of ITIL and ISO 20000 - Service Asset and Configuration Management).

    For further information, see:

    2. I see the same vulnerabilities for different assets, like inadequate change control for laws, regulations, etc but also for policies, procedures and work instructions. Is there a way to optimize this and to reduce the number of vulnerabilities?

    Please note that a single vulnerability may impact different assets like in the example you provided, but it is not mandatory to associate that vulnerability for all listed assets. These relations are only suggestions provided to help you perform risk assessment, so you can decide to not select the vulnerability for some assets.

    For further information, see:

  • Question ISO 27001 implementation

    Certifying only the small company is possible, provided it is legally separated from the bigger company, and you can include in the Information Security Management scope only the elements the small company controls (you do not need to separate everything).

    For example, in physical terms, this means that this small company should be located on a floor of its own, not shared with employees of the bigger company.  

    In terms of policies and procedures, they should be divided in a way that you can control all the elements of your documentation, i.e., even if you need to follow the guidelines of the bigger company, you can do that in your own way. For example, you can implement access control in different ways.

    Please note that if you find out that implementing such separation is too complex or costly, then an alternative would be to certify both companies, keeping the bigger company scope as small as possible (e.g., including only the processes that directly interact with the small company).  

    These materials will help you regarding scope definition:

  • Questions Regarding Clinical Evaluation

    We have noticed that our current clinical evaluation report does not meet the MDR requirements due to unsatisfactory documentation. Eventhough all clinical tests and results are good enough for proofing the product usage  the consultant company did not properly documented as regulatory requested format and contents .So we need to reorganize CER report  and need a new company/individual  to assist us. Our intention is to work with a competent and reliable agent. In addition to CER work we also need to rework on some tests(Biocompatibility). So I need your guidance and recommendation for selecting a test center and CER process.Do you know any source for recommending us?

  • Does ISO 19011:2018 align or integrate with ISO 27001?

    ISO 19011 is a management system audit standard and can be used to help fulfill ISO 27001 requirements from clause 9.2 – Internal audit (e.g., provides guidelines for audit program planning, auditor selection, audit report documentation, etc.).

     This article will provide you a further explanation about internal audit:

    These materials will also help you regarding internal audit:

  • Infosec procedures

    Control A.10.1.2 is covered in our template Policy on the Use of Encryption. You can take a look at its demo at this link: https://advisera.com/27001academy/documentation/policy-on-the-use-of-encryption/

    A vulnerability procedure is not mandatory for ISO 27001 and is not a common document adopted by organizations, so there is no template covering the specific clause of the standard related to it (control A.12.6.1 - Management of technical vulnerabilities).

    Control A.12.6.1 does not prescribe how many scans are necessary for each classification asset. You should define these based on the results of risk assessment and applicable legal requirements.

     This article will provide you with a further explanation about key management:

    This article will provide you with a further explanation about vulnerability management:

    For detailed processes and more technical reference you should consider NIST Special Publications:

  • Quantity of risks

    Considering that you will still receive inputs from your technical people, as a starting point, ~200 risks, with ~15% of them to be treated is a good scenario.

    Please note that the auditor will be more concerned about the quality of the identified risks (i.e., how relevant they are for the organizations) than their quantity. The single point you need to pay attention to is to not overlook obvious risks, i.e., risks that someone with proper competence in the process or asset would easily identify. To mitigate this risk, you need to include in the risk assessment the personnel involved with the process or asset.

    An additional thing to note is that risks for which you already have implemented controls (and you will only accept the risk) also count for your relevant risks.

  • ISMS metrics related to Scope

     Regardless of the perspective, the development of metrics follows some general rules:

    • Business relevant: the indicator should be aligned to clear business objectives or legal requirements.
    • Process integrated: activities to collect the necessary data for a KPI should add the least amount of work possible.
    • Assertive: the indicator should be capable of pinpointing relevant issues (e.g., process steps, organizational areas, resources, etc.) that need attention.

    Considering Product development, some examples are:

    • Percent of products of the portfolio supported by the ISMS
    • Number of product development incidents related to information compromise
    • Incident resolution time
    • Percent of controls assessment performed
    • Number of improvement initiatives

    For further information, see:

  • ISMS metrics, from Product development perspective

    Regardless of the perspective, the development of metrics follows some general rules:

    • Business relevant: the indicator should be aligned to clear business objectives or legal requirements.
    • Process integrated: activities to collect the necessary data for a KPI should add the least amount of work possible.
    • Assertive: the indicator should be capable of pinpointing relevant issues (e.g., process steps, organizational areas, resources, etc.) that need attention.

    Considering Product development, some examples are:

    • Percent of products of the portfolio supported by the ISMS
    • Number of product development incidents related to information compromise
    • Incident resolution time
    • Percent of controls assessment performed
    • Number of improvement initiatives

    For further information, see:
Page 107-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 +