Start a new topic and get direct answers from the Expert Advice Community.
CREATE NEW TOPIC +Guest
1 - According to my understanding of your answer these are not required to be documented as it does not specifically say so (see red text above). If a policy and an implementation is required as it is advised in A.10.1.1, shall I really understand it not to be required to be documented?
Your understanding is correct. Unless the standard explicitly states that something needs to be documented, you do not need to develop a document.
2 - The documentation that I have purchased does not have templates for all requirements, for instance A.12.4-7. How come? Am I to understand it as A.12.1-3 are supposed to be documented (at least “if applicable) but A.12.4-7 are not?
Versus controls that has the word “documented” in them, as for instance A.12.1.1 Documented operation procedures – Control – Operating procedures shall be documented and made available to all users who need them.
shall be documented.
I am afraid that I am missing something here.
Please note that from section A.12, only control A.12.1.1 explicitly states that documentation needs to be developed. All other controls do not require policies or procedures to be documented.
The toolkit is developed to cover all mandatory documents (e.g., Information Security Policy, ISMS scope, etc.), and the most frequent documents adopted by organizations, to not overwhelm them with the administrative effort to maintain documents.
In case you identify any need to document a control for which there is no template available, you can use the blank template included in your tool kit to develop the document, and you can contact us to solve questions about the development or schedule a meeting so one of our experts can provide orientation on how to develop the documents.
A risk based approach is stated in clauses 7.10 Nonconforming work b) and 8.7.1 Corrective Action, b. In 8.7.1 e, and 8.7.2 the requirement is clearly specified that a laboratory must refer to the risk and opportunities in the register and take the degree of action according to the risk. i.e a high risk requires appropriate resources and action to reduce the risk to a level the laboratory identifies as appropriate. The low risks could justified as not needing action.
Practically the laboratory must state your approach. E.g treat assign resources to reduce all high risks to an acceptable level, consider reducing medium risks if solutions and resources are readily available, while accepting any low risks without further action.
Start off with considering that you are never looking for a singular root cause to take one action to address a nonconforming event. You are seeking the best possible practical, executable solutions to implement, and then monitoring and reassessing the remaining risk. Certain actions can be complicated, time consuming and expensive to implement while a combination of other actions may be less costly and quicker, while reducing risk of a reoccurring event to a suitable, but not “zero” level.
For more information have a look at the article Corrective actions principles and root cause analysis in ISO 17025 at https://advisera.com/17025academy/blog/2020/11/04/corrective-actions-principles-and-root-cause-analysis-in-iso-17025/
And the available toolkit https://advisera.com/17025academy/iso-17025-documentation-toolkit/
I assume that MTBF means the mean time between failures.
I'm not an expert in maintenance, however, I will answer considering the MTBF as an indicator that we want to improve by increasing the mean time between failures. Thus, I would apply the classic quality tools. I would start with a Pareto chart with the reasons for failure. Then, for the most frequent reasons, I would perform a cause analysis using, for example, the cause-effect diagram to determine the root causes. Then I would develop actions to eliminate those root causes.
I recommend consulting the following materials:
Does your organization design products or services?If your organization has a brand and sells products or services designed by it, then clause 8.3 is applicable. Also relevant for a decision is the scope of the QMS. Consider the case of an organization that designs products and also manufactures products designed by customers. The organization may decide that the QMS scope includes only the manufacturing products designed by the customers, and in that case, clause 8.3 is not applicable. The following material will provide you with more information about the non-applicability of a clause:
Yes, this requirement is mandatory for all companies that have implemented ISO 13485. But, of course, you will adapt it to your situation. This means that you will have as a part of the medical device file:
So, you will be concentrating only on your device, not the final medical device.
Most changes in ISO 27001:2022 are related to Annex A, reorganizing controls from the 2013 version and adding 11 new controls. Contents of the ebook are still valid to help implement an ISMS ISO 27001 compliant.
These materials will give you an understanding of the changes:
Start with an initial assessment followed by a GAP analysis. That will give you the answer – what needs to be done.
Once you have a scope of work, prioritize like explained in the articles
Also consider implementing ITSM tool, because it will improve efficiency of the implementation, automate tasks and provide you with more control of the activities, tasks and teams/people.
Please note that the section regarding external correspondence refers to electronic and physical documents you need for your ISMS that come from external parts like customers, suppliers, regulatory agencies, etc. If an external document is irrelevant to the ISMS, you do not need to control it as an external correspondence.
For example, specifications sent from a customer contracts from a supplier and a law from a government agency. The ISO 27001 standard is an example of an external document required by the ISMS.
For further information, see: