Excerpt 1 — Chapter 1, "Introduction": why cybersecurity management is not about technologyThe simplest way to manage an organization's cybersecurity is to draw up a list of technical measures ("install antivirus software," "enable multi-factor authentication," "encrypt disks") and carry them out one by one. This approach has an obvious advantage — simplicity — but also a systemic flaw: it does not answer the question of which measures this particular organization actually needs, to what extent, and what to do when there are not enough resources for "the whole list." It also creates a false sense of completeness: "we implemented everything on the list — so we are secure," even though the real level of risk depends not on the length of the list but on how well the measures match the specific threats and the value of the organization's assets. Excerpt 2 — Chapter 1: cyber risk within enterprise risk managementIf cybersecurity is about managing risk rather than a checklist of technical measures, the logical continuation of this idea is as follows: cyber risk is not a separate, isolated category discussed only by the IT department in its own language. It is one of the types of risk that any enterprise faces — alongside financial, reputational, operational, and supply chain risk. It should be managed within the same frame of reference as other enterprise risks. Excerpt 3 — Chapter 14, applying the Chapter 10 mapping methodology: where a mapping gap becomes a technical projectThe last row is the central conclusion of this step, and of the whole case study: the mapping table shows honestly that no Annex A control exists for PR.AA-04 that can simply be marked "done" and the gap considered closed. An organization relying only on the SoA, or only on the mapping table, could mistakenly conclude that because A.5.17 partially covers the topic, no further action is needed — which is exactly why the gap analysis, the SoA, and the risk register above all consistently define SSO as a separate, explicit technical project, rather than a derivative action from existing controls. Excerpt 4 — Chapter 14, closing paragraph of the bookThe running case study in this chapter has shown that the fifth step of the Chapter 7 methodology — "the organization can repeat these steps as often as needed" — is not a rhetorical flourish but a real operating cycle: MFA for contractors, backup encryption, and automatic deactivation in the ERP, each opened by a separate cycle in Chapters 6–7 and 13, were already closed and verified by the time this chapter began, and the very fact of their closure — through broadening the profiling scope to identity management across the ERP and CRM together — opened up a new, precisely formulated gap, PR.AA-04, reflected consistently and at once in the updated profile, the action plan, the SoA, the risk register, and the mapping table. It is precisely this consistency among five tools converging on a single decision, not the mere existence of each tool on its own, that is the practical upshot of building an integrated cybersecurity management system.
Implementing ISO/IEC 27001:2022 is easier with the right guide. Packed with practical steps, ready-to-use templates and real-world examples, this book helps you build, manage and certify an effective Information Security Management System with confidence.