Search results

Guest

Guest

Create New Topic As guest or Sign in

HTML tags are not allowed

Assign topic to the user

  • How to document the external and internal context of the organisation

    Debasish,

    In my opinion, it is not necessary to write a separate document for the context of the organization (clause 4.1 in ISO 27001:2013) - you can cover it through these documents:
    - Business plan (if you have one)
    - ISMS Scope
    - List of requirements from your interested parties
    - Risk assessment report
  • step 1 of transmission guid

    The first step in our white paper is about identifying the interested parties - please read this article which explains this topic into detail: How to identify interested parties according to ISO 27001 and ISO 22301 https://advisera.com/27001academy/knowledgebase/how-to-identify-interested-parties-according-to-iso-27001-and-iso-22301//

    By "arrangement" you could have a written or oral agreement, or something similar.
  • Change the top-level policy

    Our white paper "Twelve-step transition process from ISO 27001:2005 to 2013 revision" suggests you can change the title of the policy if you wish, but this is not necessary; also if you wish you can also delete some items from the policy because they are not needed any more. However, if your ISMS Policy is compliant with ISO 27001:2005, you can leave it as it is and it will be compliant with ISO 27001:2013 as well.
  • How does an organization become able to audit / certify against 27001?


    An organization can start issuing ISO certificates if it becomes accredited, i.e. if it gets the license for doing such a job. The accreditations are issued by a local government body in each country - e.g. in UK this is the UKAS, whereas in the United States this is ANAB.
  • Incident management procedure-A.16.1.5 is new control?

    I basically agree with you there is no big difference between incident management controls in ISO 27001:2005 and ISO 27001:2013; the only difference is that control A.16.1.5 of 2013 revision requires incident procedures to be documented, while controls in 2005 revision did not have such requirement.
  • step2

    I assume you refer to our free download "Twelve-step transition process from ISO 27001:2005 to 2013 revision"?

    An interface is something that stands between your ISMS and the outside world - for example, if room A is within the scope, and room B is out of the scope, then the door between those two rooms is an interface; if you have two segments on your local network, the network device that is in between them is an interface. Therefore, your ISMS scope has various interfaces as borders to the outside world.

    See also this article: Problems with defining the scope in ISO 27001 https://advisera.com/27001academy/blog/2010/06/29/problems-with-defining-the-scope-in-iso-27001/
  • ISO27001 recertification to 2005 or 2013

    Mark,

    Re-certification against ISO 27001 is completely the same as the initial certification. Certification/re-certification against ISO 27001 2005 revision will be possible until October 2014 - after that, you will be able to certify/re-certify only against ISO 27001:2013.

    These articles will also help you:
    - How to make a transition from ISO 27001 2005 revision to 2013 revision https://advisera.com/27001academy/knowledgebase/how-to-make-a-transition-from-iso-27001-2005-revision-to-2013-revision/#2005
    - Infographic: New ISO 27001 2013 revision – What has changed? https://advisera.com/27001academy/knowledgebase/infographic-new-iso-27001-2013-revision-what-has-changed/
  • Taking into account existing controls in the risk assessment


    Answer: During the risk assessment you should take into account the existing controls, because they decrease the probability of your risk.

    If we take the existing controls into account only in risk treatment table, there will be a lot of risks that are actually already on the acceptable level, since the controls are already in use.

    Answer: This is true, but in your Statement of Applicability you will define those controls as applicable because you're already using them.
  • Liniking the risk assessment with business continuity management


    Answer: The purpose of the risk assessment is to identify which incidents can happen to your company. Therefore, if you didn't perform the risk assessment and started writing your business continuity plans, then you have a high chances of not covering all major incidents in your response plans.

    Further, the purpose of business continuity management is to prevent some of the incidents. If you didn't know which incidents could happen, how will you be able to prevent them?
  • Qualitative and/or Quantitative Risk Assessment

    Ysong,

    ISO 27001 does not prevent you from mixing the qualitative and quantitative risk assessment, but frankly speaking such approach would be very unusual, and not very practical.

    The problem is that you have to assess consequences and likelihood in order to calculate the level of risk. If you have both consequence and likelihood assessed qualitatively (e.g. using scale 1 to 5), then it is not difficult to calculate the level of risk; however if your consequence is e.g. 2, and your likelihood e.g. 13%, you wouldn't be able to use formula - you would need to use tables with pre-defined logic, which could complicate the calculation.
Page 1101-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 +