Search results

Guest

Guest

Create New Topic As guest or Sign in

HTML tags are not allowed

Assign topic to the user

  • 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

  • Gxp versus 13485

    Yes of course that you can.

  • Offshore Requirements

    1- I didn't plan to separate offshore vs. domestic work. Is that typical?

    By offshore vs. domestic work, I’m assuming that you refer to people that work outside your country of operation (offshore), and people that work in your country of operation (domestic).

    Considering that, ISO 27001 does not prescribe how to define the ISMS scope, so organizations can develop it as best as it fits their needs.

    It is acceptable to cover work performed in the country of operation and foreign countries in a single scope, and you should make your decision based on the quantity and complexity of the legal requirements related to foreign places you operate.

    For example, you may have different requirements related to the protection of information stored and/or processed offshore that you may apply to all your scope, and you can avoid that by defining separated scopes.

    2 - Please let me know if these requirements will be fulfilled: I think these would be, but I don't quite understand Incident Response vs. Incident Plan vs. Incident handling - aren't these all covered by the same Policies and Procedures and part of the overall plan? IR-1.1 Develop policies and procedures for Incident Response. IR-6.1 Report security incidents to appropriate personnel or government authorities in a timely manner. IR-8.1 Develop a comprehensive Incident Response Plan for the organization. IR-5.1 Implement mechanisms for tracking and documenting security incidents. IR-4.1 Develop an incident-handling process for the organization. Does this have to be separate?

    First is important to note that incident response, incident plan, and incident handling refer to different things:

    • incident handling refers to the general steps to treat an incident (e.g., incident communication, incident classification, incident treatment, and incident closing)
    • incident response refers to a response to a specific incident (e.g., in case of data loss the incident response is to recover the data from backup)
    • incident plan refers to defining specific steps to be followed and resources to be used

    Considering that, the Incident Management Procedure document covers incident handling, and in its section 3.4 (Treating Major Incidents) you can either define incident responses and their plans in the procedure or make reference to external documents covering the specific incident responses and related incident plans.

    For further information, see:

    3 - Offshore-48 Complete a security assessment of the organization's offshore location(s) and/or third party's offshore location(s) annually. Offshore-20 Requires antivirus software to be active and up to date on workstations.

    I’m assuming that by Offshore-48 and Offshore-20 you mean different business units.

    Considering that, you can have different plans for different business units, considering the results of risk assessment, but please note that since such plans are unique for each company, it is unfeasible to provide templates for such plans, so you will need to develop them by your own. In case you need support to develop such specific plans, you can schedule an online meeting with one of our experts in this link: https://advisera.com/27001academy/consultation/

  • Measuring Equipment

    If your production is outsourced, you need to have information on which measuring equipment is used for the production, quality control, and storage of your medical device and definitively you need to have proof that that equipment is regularly calibrated (you need to see the calibration certificates). 
    Usually, you will check this during the audit that you will conduct on your outsourced production. 

  • Possible risks associated with clauses of ISO 17025

    Note that the Risks will differ between laboratories, depending on the organisation structure and field of work. For example some laboratories have addition regulations to comply with, e.g. Veterinary or Medical Cannabis testing or calibration laboratories.

    In all cases the priority is to identify possible risks that could impact on you not meeting your objectives.

    Some Examples:

    1. Ineffective QMS - A common example is the risk that laboratory policies and objectives are not aligned with your context. For example while turnaround time is a key performance requirement for an internal quality control laboratory due to production impact, yet turnaround time is not one of the established objectives. Impact a) operational performance.
    2. Risks to impartiality – examples are given in the standard, for example personal relationships, shared resources. Example Impartiality due to Shared Resources, where Preference given to production personnel for use of shared resources. Impact a) operational performance (Delay in turnaround time for lab test results). b) Quality (undue pressure on lab personnel, resulting in deviations).
    3. Risks related to statements of conformity if the decision rule to include or exclude Measurement Uncertainty is not suitable. This can result in a false pass or false fail Impact a) Quality b) Legal / Regulatory
    4. Risk levels not considered when taking corrective action for nonconforming work. Impact a) Financial (wasted resources) and b) Quality and Operational (reoccurring non-conformances).
    5. Ineffectiveness of activities, for example Management Review. Impact a) If MR itself is not effective, then risks will go unidentified. Impact a) Financial, Operational and Reputation
       

    A tip – find out or ask your accreditation body about the top 5 or 10 deficiencies in laboratories in your sector – and then look at the risk you may have vulnerabilities on those topics, for example Technical Records.

  • ISO 27001 compliance in a system

    ISO 27001 compliance or certification would be a must if you have customers who require this standard, or if you have a regulation that would require it, or if your top management decided this has a strategic importance. If none of this is true, then there is no requirement to comply with ISO 27001.

Page 53-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 +