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

  • Inquiry on IT Risk Assessment and IS Risk Assessment

    1 - I was assigned to do a review on company (financial institution) IT and IS Risk Assessment. However, I am confuse about the difference of both assessment? 

    I'm assuming that by ISRA you mean "Information security risk assessment", and that by ITRA you mean "Information Technology risk assessment".

    Considering that, although they have an overlap, IT risk assessment and IS risk assessment focus on different things. IS risk assessment focuses on impacts related to the loss of confidentiality, integrity, and/or availability of information, while IT risk assessment focus on impacts that affects information technology assets and/or provided information technology services.

    The overlap is that part of IS risk assessment covers information and communication technologies, and part of IT risk assessment covers information related to provided information technology services.

    2 - how will I start? 

    Although these are independent assessments, since information in many situations relies on information technology assets, starting with the IS risk assessment review may provide you with a better understanding when performing the IT risk assessment review because as part of IS risk assessment you need to list all information related assets - and for IT assets you will perform the IT risk assessment.

    3 - And what about IT Risk Policy Manual and IT Risk management Framework is same?  how is this related on both ISRA and ITRA?

    The IT Risk Policy Manual and IT Risk management Framework are not the same.

    An IT Risk management Framework provides the general elements for a risk management process (e.g., risk assessment, risk treatment, etc.), while an IT Risk Policy Manual defines the specific rules defined by the organization to be applied to the risk management process.

    Risk management framework and risk policy should be developed for information security, and potentially include a further explanation for IT.

    This article will provide you with a further explanation of ISO 27001 information risk assessment:

    • 6 main steps in risk management https://advisera.com/27001academy/iso-27001-risk-assessment-treatment-management/

    • Choosing the right Certification Body for ISO27001 Compliance

      Hello Jaya.

      I would also like to add that you can also consider some more dimensions:

      -Do you think it can be beneficial to have the accreditation body to be from the same country as the entity audited (cultural similarities, same language - no language barriers etc)?

      Why is this important? Well, maybe the staff at the entity/entities only speaks the local language and don't know other languages, which will be an issue for an external auditor that needs to interview the staff.

      -Do you need to conduct onsite interviews or can it be done remotely? If some elements need to be conducted onsite (inspect data centers, inspect physical security controls etc), then perhaps it might be less costly to select an accredited body that is local due to travel costs (accommodation, flights etc) for the external auditors.

    • Justification and control objectives

      Please note that justifications in the Statement of Applicability need to be based on applicable legal requirements, relevant risks, or management decisions (in general because management considers the implementation of control as a good practice).

      Considering that, the fact that you operate on a remote structure wouldn’t be enough. Since you stated that you do not have legal or contractual reasons for justifying some controls, you should review the results of the risk assessment to see if any identified risk can be used as a justification. If there are no relevant risks, you do not need to implement any controls.

      In case you decide to implement a control regardless of the lack of legal requirements and relevant risks, you can state as justification that the control implementation is considered good practice management.

      For further information, see:

    • MDR article 120 significant changes

      Yes, it is, because you need to prove that the new company that provides sterilization is just as good as the previous one (so that it has a valid ISO 13485 certificate for its type of sterilization, that you have sterilization validation results with the new provider, that you have done biological indicator tests with the new provider, etc.). Also, in your risk analysis, you should check whether any new risks have appeared with the change of sterilization provider: for example, how long is the transport from you to the new provider, is it longer or shorter, has the responsibility for transport changed.

    • Regarding safety precautions in IATF 16949:2016 QMS standard

      The subject of product safety is specified in article 4.4.1.2 in the IATF 16949:2016 standard.

      At the same time, safety issues are mentioned in articles 8.2.2.1, 8.3.3.1, 8.5.1.2, 8.5.2.1, and 9.3.2.1 of the same standards.

    • Evidence of InfoSec Awareness Training

      ISO 27001 does not prescribe a format to document evidence of InfoSec Awareness Training, so organizations can adopt the format that best fits their needs (e.g., certificates, attendance lists, exam results, etc.).  

      This article will provide you with a further explanation of competence evidence for ISO 27001:

      For an example of a document that can be used as evidence, please take a look at this template: Training and Awareness Plan https://advisera.com/27001academy/documentation/training-and-awareness-plan/

      This material may also help you regarding InfoSec Awareness Training:

    • Secure system engineering principles (clause A.14.2.5)

      ISO 27001 does not specify how to document secure system engineering principles, so organizations are free to document them as best fit their needs.To see a document covering secure system engineering principles compliant with ISO 27001, please see this demo template: https://advisera.com/27001academy/documentation/secure-development-policy/In its section 3.3 Secure engineering principles you can document the principles you have in place (e.g., adoption of user authentication techniques, secure session control, data validation, etc.), or refer to the documents where they are explained (e.g., documents about guidance on secure programming techniques).

      These articles will provide you with further explanation:

      • What are secure engineering principles in ISO 27001:2013 control A.14.2.5? https://advisera.com/27001academy/blog/2015/08/31/what-are-secure-engineering-principles-in-iso-270012013-control-a-14-2-5/
      • How to integrate ISO 27001 A.14controls into the system/software development life cycle (SDLC) https://advisera.com/27001academy/how-to-integrate-iso-27001-controls-into-the-system-software-development-life-cycle-sdlc/

      • Do we need an incident management procedure?

        ISO 27001 does not require an incident management procedure to be documented, so you only need to document one in case you have a legal requirement (e.g., law, regulation, or contract) demanding such procedure to be documented.

        Only response plans require documentation, in case-control A.16.1.5 (Response to information security incidents) is stated as applicable in the Statement of Applicability.

      • ISO 45001 - Interdependencies in the components of an OHS system

        While ISO 45001 does not require an analysis of these interdependencies, clause 4.4 does ask that you identify the processes of the OHSMS and understand their interactions. One way that many companies do this is through a flowchart that includes the OPH&S processes and their linkages so that you understand exactly what is included in the OHSMS, and how they interact so that you can understand where inputs come from and where outputs go so that you can better plan and manage the processes. It is not required to align this with the clauses of the standard, but some companies will also do this.

        To learn more about the requirements of ISO 45001 in more plain language, see the whitepaper:

        • Clause-by-clause explanation of ISO 45001:2018 https://info.advisera.com/45001academy/free-download/clause-by-clause-explanation-of-iso-45001

        • Incidents

          Please note that the incident registers are records, and as such, they should not be deleted and should be evaluated in the context when they were created.

          Considering that, for the first case, you need to document which incidents were created only for testing purposes and store this document as a management decision.

          For the second case, you need to show to the auditor the incident procedure that was valid at the time the incidents were recorded. The auditor needs to evaluate the processes at that time considering that procedure, not the current one.
Page 70-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 +