Search Results

FAQ about maturing your ISMS - what to do next after the implementation slog and thrill of certification Up Up Up Maturity How should we prepare for recertification? Email everyone shortly before the recertification audit, reminding them of their responsibilities towards both information security and the ISMS. Give them guidance and tips on how to conduct themselves during the audit. This is a classic security awareness opportunity! Unlike the interim surveillance audits which tend to focus on specific areas, a recertification audit will give the entire ISMS a thorough once-over. Since your ISMS has been in operation for some time (~3 years), the auditors will naturally expect to find a mature ISMS that is nevertheless moving forward, proactively responding to the inevitable changes using the C orrective A nd P reventive A ction (continual improvement or maturity) processes embedded within the ISMS. Recertification requires a formal audit. That can be tough for organisations that have let their ISMS drift or decay after the elation of their initial certification. Renewal of your certification is not a forgone conclusion! The audit’s prime focus will, of course, be to check and confirm conformity with ISO/IEC 27001 . The key issue is to determine that you are effectively managing your information security usng the framework specified in the standard. Use this checklist as a basis for planning the things you need to do before the audit: Check that your ISMS internal and external audits are fully up to date, with plans in place for future audits. Are all audit findings/observations, recommendations and agreed actions either completed and closed off, or currently in progress (with clear signs of that actually happening, in practice)? Use the results of recent audits to drive forward any necessary changes and to reinforce the concept that the audits are all about making justified improvements. (It is worth double-checking that any other similar audits covering information risks, controls and compliance/conformity are also addressed.) Collate evidence of continuing management commitment to the ISMS such as minutes of security committee meetings, decisions and actions taken, approved corrective or preventive action plans and the results of follow-up or close-out actions, and budgets. Complete a full management review of the ISMS, including your SoA and RTP. Document all findings and recommendations as preventive or corrective actions and ensure all actions are suitably initiated, allocated and managed. Try to get all significant issues closed off, or at least well under way, before the audit ... which means doing the management review in good time. Review your information risks . If there have been significant changes in the external business environment (e.g. new legal or regulatory compliance obligations, new ISO27k standards , new security partners), internal situation (e.g. reorganisations) or technologies (e.g. new platforms and application systems in IT, OT, IoT, cloud or AI), you may need to redo your information risk assessment from scratch using the documented methods, and update your RTP. All risks should be treated, in other words avoided, controlled, shared or explicitly accepted by whoever is accountable and, for significant risks, there should also be contingency plans in place in case the treatments fail. Review all the ISMS documentation (policies, standards, guidelines, procedures etc .) to ensure it is up to date, complete, formally approved/mandated/signed off, version-controlled and made available to those who need it (e.g. uploaded into the ISMS area on your intranet). Ruthlessly seek out and destroy old or outdated ISMS documentation. Get your information security awareness and training activities bang up to date and ensure a plan is in place for future activities. Ensure everyone knows where to find the ISMS policies and related materials and is aware of the content (a useful tip is to give everyone a shortcut to the information security documentation on their desktops). Ensure everyone is familiar with, and in fact actively complies with their responsibilities towards information security, for example any obligations arising from privacy legislation and relevant information security procedures. Check the documentation relating to any recent information security incidents , for instance to confirm that corrective or preventive actions were documented and duly completed. Step back from the detail to confirm that the process is operating smoothly. Review your information security metrics . Given that your ISMS has matured, are they still relevant and useful or do they need adjusting? Have you in fact been routinely reporting and measuring against them (collate recent evidence to prove it) and have any actions necessary been taken (again, check those CAPA plans)? Get yourself round each area of the business and grill likely audit interviewees (both managers and staff) regarding their part in the ISMS. Ask them some searching questions (try the auditors’ favourite “Show me...” to check that they can actually produce solid evidence substantiating whatever they claim or believe to be true) and try to find the weaknesses or concerns before the auditors turns up - not to hide them but to address them! This is invaluable preparation or training for the auditees. Tell them up front that you are not being harsh with them but are asking stiff questions to help them prepare and make the actual recertification audit go more smoothly. It’s tough love. Remember that the ISMS is dynamic, constantly adapting to changing business needs arising from evolving information risks. It will never be perfected or finished as such but, so long as it is properly managed, reviewed and fully supported by management, you will be fine. What if things change after we are certified? Stay in touch with your certification body, keeping them updated with (significant) changes and giving them the opportunity to say whether further surveillance visits or audits are in order. Building a strong working relationship with your auditors has the distinct advantage of "no surprises" on both sides, but it takes a little effort to establish and maintain the relationship, as indeed do all relationships (business or otherwise!). That depends on the nature and scale of the changes. Change is an inevitable and inherent part of the challenge. Minor changes to the ISMS are expected to occur as it naturally evolves in line with changing business needs for information security, for example through the action of various internal reviews triggering corrective and preventive actions: these should have no effect on your certification status since they are an anticipated and normal part of any ISMS. Larger scale business or organisational changes may involve more significant changes to the scope of the ISMS, for example other parts of the business being integrated with the ISMS, mergers/acquisitions or downscaling/divestments: these may be substantial enough to invalidate your original certificate without at least a surveillance visit from your certification auditors, but it's impossible to give hard-and-fast rules. Whether your ISMS changes are deemed substantial enough to invalidate your certificate, or to warrant recertification, depends on several factors such as: The scale or size of the change/s; The nature or type of change/s; The likely impact of business and organisational changes on your ISMS and/or information risks and hence the risk treatments required; How long it has been since your last certification or surveillance audit, and how long before the next one; and The certification body's policies and practices in this regard. Aside from the certification angle, you should definitely update your information asset and information risk/control registers and maybe your RTP and SoA. You may need to update your security policies and perhaps restructure the team managing and running the ISMS, which may well imply the need for a new budget. Don’t forget to check your ISMS internal audit plans too, and if appropriate adapt your metrics accordingly. How can we boost our security culture? Use suitable metrics to measure relevant parameters of your corporate security culture and drive it in the right direction, adjusting the approach and celebrating successes along the way. Try these five tips for size: Culture is heavily influenced by management, especially senior management. This is one of the key reasons that genuine senior management support is essential when implementing an ISMS ... which implies the importance of addressing senior management, helping them understand and appreciate the value of information security from the earliest opportunity. Corporate culture is also heavily influenced by powerful opinion-formers within the organisation (at any level of the hierarchy), by internal communications and networks (both formal and informal), and by the wider business/industry and national cultures in which people live. These are influenceable to varying degrees. An effective information security awareness program will identify and target the people/groups, themes, messages and styles across all these areas. Culture is an emergent property or characteristic of the organisation, demonstrated by people's actions and beliefs even when they are not being watched. This includes senior management: it is no good them saying “This awareness session is essential for everyone” if they don’t make a genuine effort to attend and actively participate. Changing corporate culture as a whole may be viewed as a massive long-term change management activity. Anyone who truly understands how to do massive change management reliably can make a fortune! It is a very complex and difficult topic, highly dependent on the specific context, plus the history leading up to the decisions to change. A serious information security or privacy incident, for example, is a classic trigger to “Do something, now! ”. Culture is dynamic: it will continue to change or evolve naturally even after it has been pushed in a certain direction, and that future evolution is not entirely controllable. This is the main advantage of rolling or continuous security awareness programs, since a single awareness event or course will gradually be forgotten and awareness levels will decay unless constantly refreshed. Covering a planned, regular sequence of security topics is a good way to make sure that the materials remain interesting and engaging, along with having excellent awareness content prepare by people who understand and empathise with the audiences. Plan to develop and enhance the security culture over the long term. Investing time and effort consistently into this will pay dividends - it is worth it. Tackle it in bite-sized chunks rather than all at once, aiming for incremental, solid improvements rather than dramatic but often short-lived effects. Which security metrics should we use? If metrics are to provide management with answers, what are their questions? The G oal- Q uestion- M etric method, coupled with the PRAGMATIC approach, is a powerful way to build a worthwhile suite of valuable information security metrics. It's tough to give simple advice on metrics: it is arguably the hardest part of what we do. But here goes. It is unrealistic to expect a standard set of security metrics, in just the same way that there is no universal set of security controls: there are simply too many variables. In time, a core set of reasonably commonplace controls and metrics may emerge from the mire but there will probably never be total consensus. Even if there was a standard set, you would still have to extend it to suit your unique situation anyway. In short, there is no way around figuring out the information risks, controls and metrics that matter to your particular organisation. Metrics-related references worth studying: ISO/IEC 27004 - the current 2016 version is useful, the long-awaited next edition promises to be even better; "IT Security Metrics " book by Lance Hayden explains the G oal-Q uestion-M etric structured approach in the IT security context; "PRAGMATIC Security Metrics " book by Krag Brotby and Gary Hinson lays out a method for systematically specifying, selecting/designing and improving information security metrics. The accompanyin website SecurityMetametrics.com has an FAQ. "Metrics: you are what you measure ", a brilliant paper by Hauser and Katz, warns about inadvertently driving the organisation the wrong way as a result of inappropriate metrics; NIST SP800-55 "Measurement Guide for Information Security" (2024) – volume 1 (identifying and selecting measures) and volume 2 (developing an information security measurement program). Well-written, up-to-date, and FREE! As you read through that lot, start thinking hard about what you and your management might really want to know about how you are doing on information security, and start defining and prioritising the collective requirements. This is the crux of your problem. Management probably wants to know things like “Are we secure enough?” or “Are we more secure now than last quarter?” and “What are our most significant information risks?” and “Why is information security so expensive?”! These are really tough questions to answer, so work hard to refine them and make them at least partly answerable. Hint: look at those parts of the ISMS which caused you the most grief when designing and implementing it. Are there parts of the ISMS that remain self-evidently painful to operate? If so, these are classic ISMS process improvement opportunities, and hopefully good places to gather metrics that will help you justify, plan and make those improvements, with the spin-off benefit that you will be making things easier for those involved. It may seem too early but it's almost certainly worth talking to your management about what they might expect during this metrics design phase. Look at what kinds of metrics they get from other management systems. Find out what they actually use versus what they get, and look for clues about what kinds of things work best in your organisation. Consider phoning your peers at other similar organisations for some good ideas. Find out what formats and styles of reporting they like best or hate most. Ask them what few reports they could really not do without. Think minimalist at the start. Next, start looking at the realities of gathering information on those things you really want to know, and continue refining your requirements. Some metrics will be straightforward (great! These are probably keepers), some will be feasible but more difficult (bear these in mind - may need more work) and some will be so awkward and/or costly that the effort required to measure them will outweigh any benefit obtained (park these, at least for now: you may revisit them later as your ISMS matures). Be careful with any existing infosec metrics: some of them may be being measured simply because they are easy to measure, such as simple counts of things (“23 malware incidents this month”, “23 million spams blocked today” or whatever). Unfortunately, such simple metrics typically don't tell management, especially senior management, anything really worthwhile. While a few may have value to the Information Security Manager as operational metrics, most are at best ‘nice to have’ numbers rather than “Oh boy, this one is in the red, we’d better turn dial ZZY to the left 20 degrees”! Most of all, avoid the temptation to list and discuss all the information security-related things you can measure, like a giant shopping list. Some of them may be worthwhile ingredients, but most will be distracting and unhelpful. Trust me, this is not an effective way to start designing your ISMS metrics. If you must have one, keep the shopping list to yourself but share the menu. Finally, towards the end of your lunchtime (!), it's time to start experimenting, trialling a few metrics, getting the data gathering, analysis and presentation processes working and getting feedback from management. Give them some ‘sample’ reports and ask them if they know what to do about the things you are reporting. This is where all your pre-work starts to pay off, hopefully. If you have chosen well, you should by now be ready to routinely report a few good metrics, and more than that use management should be using them to make decisions. Management should be saying “Ah, I see, yes, nice, let's have more of these ...” and “Mmm, that's not quite what I had in mind. I really need to know about ...”. During this stage, you will inevitably find that you need to gather more detailed ‘supporting’ metrics to underpin the high level/strategic management stuff, and you will also figure out that there are various routine/operational issues and controls within the ISMS that deserve measuring and using for day-to-day purposes by the Information Security Manager and team. Now is the time to work on defining targets. At what level, exactly, does metric 26 go ‘into the red’? Why there? Is it a point or a range? Whereabouts on the scale can we relax? Then, over the next several decades (!!), keep on refining your metrics, testing new ones, dropping the ones that aren't working and responding to changes in your ISMS, the risks and controls, the people, the fashions, the good ideas you pick up at conferences ... and extending the answer to this FAQ with your wisdom. How can I become an ISO27k consultant? Dive deep to figure out your value proposition as a consultant - not your amazing personal qualities but the valuable business benefits you bring to clients, substantially outweighing your charges. Why should clients employ you rather than your competitors, if anyone? What's in it for them? Start by studying the ISO27k standards – in particular the core set: ISO/IEC 27000 (overview & glossary) ISO/IEC 27001 (formal ISMS specification) ISO/IEC 27002 (catalogue of security controls) ISO/IEC 27003 (ISMS implementation) ISO/IEC 27004 (security metrics) ISO/IEC 27005 (risk management process) ISO27k "Lead Auditor " or "Lead Implementer " courses can be a quick way to tackle the basics, depending on the nature and quality of the course materials and the competence of the trainers ... but 'basics' is the crux of it. A few hours or days in class is barely a start. ISO/IEC 27021 describes the competencies generally expected in this area. Continue your self-development by actively researching and learning about governance, risk and control concepts. Study NIS2 , DORA , PCI-DSS , COBIT , privacy laws, COSO ERM and so on. Take a good look at the remaining ISO27k standards including ISO/IEC 27701 , plus others such as ISO 22301 and the NIST SP 800 series and other certifications such as SOC 2 and Cyber Essentials . Impress potential clients with the breadth and depth of your knowledge. Read voraciously. If you are not one already, read-up on becoming a consultant (what that entails, how to start out, key aspects, things to expect, things to do, things to avoid ...) and running a business (useful to understand clients, even if you anticipate joining an established consultancy). Aside from all that reading, real-world experience is crucial. Take on small infosec-related projects. Do research. Keep up with recent incidents, vulnerabilities and advisories. Write and publish papers. Participate actively in professional communities such as the ISO27k Foru m , LinkeDin , ISACA ENGAGE and ISSA . Seek mentorship or guidance from more experienced peers. Accumulate knowledge, experience and expertise in governance, risk and control, in security, privacy, resilience and so forth. Your competence, credibility and hence success as a consultant influences the nature and quality of your work, and vice versa . You'll know when you have gained sufficient wisdom to make a real difference in the world - and so will your peers and clients. Meanwhile, slog. Previous Up Next

Join the global self-help community of >5,000 ISO27k/infosec professionals, lurk and chip-in if you feel inspired. It's FREE! The ISO27k Forum The Forum is a Google Group/email reflector for ISO27k practitioners, a supportive global community of peers-helping-peers. The back story Since its launch back in 2006, the ISO27k Forum has grown steadily into a supportive and friendly global community of more than 5,000 information security professionals, most of whom are actively using the ISO/IEC 27000-series standards and willing to share their experience, expertise and wisdom freely with others. Membership of the Forum is free for those with a genuine professional interest in the ISO27k standards , particularly those with practical implementation experience and knowledge they are willing to share with the community. We also welcome students and newbies taking their first baby steps, studying and in time maybe adopting the standards. The Forum and this website demonstrate our support for the liberal social principles on which the Web was founded - our way to give a little back to the online world that gives us so much. Purpose and vision This is a practitioners’ group with a practical focus, where (almost!) every contribution is treasured and every member valued. We mostly discuss matters of interest and concern to those interpreting and applying the ISO27k standards in genuine real-world situations (see the typical topics ). Typical ISO27k Forum members: Are generally interested in information security standards; May have relevant professional qualifications, having completed ISO/IEC 27001 Lead Auditor or ISO27k Lead Implementer training, CISSP, CISM, CISA, CRISC, GIAC and similar; May be CISOs, ISMs, CROs, Compliance Managers, Cybersecurity Managers, Infosec Consultants, IT Security Specialists, Security Analysts or whatever; May be students, academic researchers and teachers; Would like more information about applying the standards in real life, beyond that available on this website and elsewhere; Are planning to implement, actively implementing, fully conformant with or simply using the ISO27k standards , or are auditing organisations against the standards, or are advising others about the standards; May work for organisations that have been certified conformant with ISO/IEC 27001 or are working towards that point; Would like to help promote the standards more widely; May be involved in the standards bodies and committees responsible for developing the standards, or have an interest in this aspect; Wish to discuss information security management standards, practices, methods etc. with the community of professional peers; Are here to give and to take, to contribute knowledge and learn new stuff. Sharing is important to us. As a member put it, “We are a TEAM - T ogether E veryone A chieves M ore”. Sign me up! Our favourite topics The Forum is a low-volume high-quality group. We discuss anything and everything ISO27k-related, such as: Assurance - ISMS internal audits, management reviews, certification, surveillance, accreditation, supplier security audits, trust centres ...; B usiness C ontinuity M anagement including resilience, recovery and contingency planning, and ISO 22301; Business cases : reasons to embrace the ISO27k standards in furtherance of business objectives, going beyond mere conformity, and gaining executive/board-level support; Concepts and terms-of-art in risk and security e.g. threats, vulnerabilities, probabilities, impacts, exposure, incidents, CIA, preventive, detective, corrective controls, people, process, physical, technology controls, inherent and residual risks, risk appetite, risk tolerance, risk vs opportunity, protecting and exploiting information ...; Control attributes - using the parameters, characteristics or features to select and make the most of security controls; Documentation - mandatory vs discretionary, audiences, purposes, content, document controls ...; Governance of information, information risk, information security etc ., including organisation structures, reporting lines, direction, oversight, monitoring and conformity, management support and involvement, integrating management systems; How to implement the standards - pragmatic advice from those who have been there, done that; Information risk management methods such as B usiness I mpact A nalysis, threat intelligence, risk modelling; Information security controls for software, system, network and service development, provision and acquisition, for cloud, privacy, safety, IT, OT, AI, IoT ...; I nformation S ecurity M anagement S ystems, of course, plus viable strategies, implementation plans, resourcing, timescales, priorities, options, shortcuts, tips; Metrics for measuring information risk and security, for monitoring, reporting and management; News about ISO27k and related standards; Policies , procedures, rules, guidelines, laws and regulations, content, structure, purpose and value, compliance, conformity, enforcement and reinforcement; Preventive and corrective actions , continual improvement, maturity, post-incident reviews ... and incident management; Privacy , data protection, safety, quality and other obligations; Risk analysis tips e.g. common information security threats to consider, methods and tools, ‘where to start’ advice; Scope , S tatement o f A pplicability and R isk T reatment P lans - what they are, how they differ, what they do, what they are supposed to contain ...; Security awareness - why it’s needed, how to do it, making it cost-effective; 'The ISO27k way ' - a systematic, structured, information risk-driven approach underpinning all the ISO27k standards; Tools and resources supporting busy CISOs, ISMs, SOCs, analysts, trainers, documenters and consultants. This is just a potted selection to give you a flavour of the discussion. As well as the FAQ , we have accumulated a huge amount of worthwhile content in the group’s archive so it's worth getting to grips with Google’s search syntax . Projects Occasionally, ISO27k Forum members collaborate in crowdsourcing topical issues, such as drafting new materials for the ISO27k Toolkit. We have also contributed to the promotion and further development of the ISO27k standards. Privacy If you join the ISO27k Forum, you will obviously receive ISO27k-related emails. We will not exploit, sell or give away your email address or other personal information. If you post a message to the Forum, your email address is shown in the message header. Other members may email you directly rather than the entire group. We actively discourage anyone from overtly advertising on the Forum or pestering members but vendors may contact you directly/off-list if you express an interest in their products. Feel free to create a unique email address solely for the Forum and please let us know if you receive spam. We utterly detest and actively fight spam. Any Forum members who spam other members will be fed limb-by-limb, organ-by-organ to the ravenous bugblatter beast of Traal or, under our environmental policy, may be gently composted back into mother Earth. Forum tips and etiquette (important!) Guidelines to keep the ISO27k Forum on track, and benefit the whole community: Please be professional and respectful at all times. The Forum is deliberately non-commercial: No advertising or promoting your organisations and products, no commercial offers, no vacancy notices etc. Definitely no spamming! Conventional email signatures are fine though. Just be discreet. Take commercial matters off-line with individuals, not via the Forum.. Add your name to your postings: what should we call you? The Forum’s primary language is plain English. Be considerate. Browse the archives (using the Google Groups search ) before posting. Glance back a few weeks at least to see where current threads arose. Read the ISO27k FAQ . Stay on-topic! This Forum is exclusively about the ISO/IEC 27000-series standards and closely related matters. Take a moment to explain your context: Why are you writing? Why does it matter? What have you already done in an attempt to find an answer? What type of organisation do you represent? Industry? Size? Location? How mature is your ISMS? What stage are you at? When responding to a post, don’t change the subject line unless you are deliberately heading off at a tangent. Gmail and other mailers string related messages into threads by the subject line. For further advice on asking questions intelligently, see here and here . Manage your subscription via the Google Groups web interface: Receive each message individually or as regular digests. Suspend Forum emails temporarily or permanently (access online instead). Change your email address. Unsubscribe and leave the Forum.. File Forum emails automatically in your email software. All emails contain “[ISO 27001 security]” in the subject line: set up a rule to move emails with that subject string into a suitable folder to browse, search and read at your leisure. Respect intellectual property rights and laws: Do not circulate copyright materials (such as ISO/IEC standards!) on the ISO27k Forum unless you are the copyright owner or have the copyright owner’s express permission. This is a hard and fast rule, no exceptions, no second chances. Don't risk the Forum's existence as well as prosecution. It is generally OK to share URLs for materials legitimately published on the Web, rather than sharing the content. Respect the copyright of Forum members too. Don't share Forum postings elsewhere without first getting the authors’ agreement. Finally, if you are unclear about the rules, bothered about recent exchanges or wary of posting something inappropriate, email the Forum Admin . If you have a keen interest in the ISO27k standards and intend to participate actively in the community, apply to join the ISO27k Forum . Membership is FREE but please make your case briefly when you apply to join: in just a few short words, persuade us that you are qualified and willing to share. If you ignore this request and leave the application blank, don’t be surprised if your application is rejected just as rudely. Aside from excluding spambots, we like to know what brought you here and what interests you.

Answers to common questions and concerns about managing information risks and security controls under ISO27k Up Up Up Information risks What are 'information risks'? Simply put, information risk is 'risk pertaining to information' . Breaking it down: Information is the valuable meaning or knowledge that we derive from data, the content of computer files, paperwork, conversations, expertise, intellectual property and so forth. Risks , in this context, are the uncertain prospect of harmful incidents. So, stitching it back together, information risk can be laboriously defined as 'Uncertainty involving or affecting information, normally the deliberate, incidental or accidental action of threats exploiting exposed vulnerabilities, causing harmful impacts'. To put that more succinctly, I define information risk as 'risk pertaining to information' . While the ISO27k standards neither define nor use 'information risk', and 'information security risk' is not actually defined, two notes to the definition of 'risk' in ISO/IEC 27000 mention it: 'information security risks can be expressed as effect of uncertainty on information security objectives [and] Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization'. I prefer a business perspective: reducing the number and severity of adverse business impacts to an accceptable level is the primary objective of information security. Is there a list of information risks? The suggested resources are all generic, useful reminders of the general types of risk worth considering. Pore over your organisation’s incident records and past risk assessments for further inspiration, and work with management to identify and consider information risks in your particular business context. Yes, several e.g. : IT Grundschutz Catalogue (the baseline IT protection manual) includes an extensive threat catalogue, exhausting if not exhaustive; ISO/IEC 27002 , NIST SP 800-53 and various other information security and privacy standards, laws and regulations are, in effect, incomplete information security control catalogues that may mention threats, vulnerabilities and impacts; ISO/IEC 27005 identifies a few threats and vulnerabilities in an annex; Mitre’s CVE ( C ommon V ulnerabilities and E xposures) is a useful, well-regarded catalogue of cybersecurity (meaning primarily technological/IT system) vulnerabilities. Again, not totally comprehensive but close enough for government work; Mitre’s CAPEC ( C ommon A ttack P attern E numeration and C lassification) is a structured catalog of cybersecurity ‘attacks’ i.e . how some threat agents exploit some vulnerabilities. Most information risk analysis and management support tools, systems, methods and advisories include examples or lists of stuff to consider. There are books, websites and articles on this topic. And finally, don't forget Google and AI. What is information risk management? This is a complex, busy process, liable to go badly wrong. ISO27k provides a sensible management structure or framework to help keep it on-track. ' Management' indicates someone proactively addressing information risks on an ongoing basis, along with related governance aspects such as direction, control, authorisation and resourcing of the processes. The first stage is to Identify potential information risks. Several factors or information sources feed-in to that: Vulnerabilities are the inherent weaknesses within our facilities, technologies, processes (including information risk management itself!), people and relationships, some of which are probably unrecognised or not fully appreciated; Threats are the external actors and natural events that might cause incidents if they acted on vulnerabilities causing impacts [Note: malicious, fraudulent, inept, coerced or misled insiders can present threats: we are not purely concerned about evil hackers, malware and terrorists roaming the Interwebs!]; Assets are, specifically, information assets - valuable information content plus, to a lesser extent, the associated storage media, computer hardware devices etc. ; Impacts are the harmful effects or consequences of incidents affecting assets, damaging the organisation and its business interests, often also third parties; Incidents range in scale from minor, trivial or inconsequential events up to disasters and outright catastrophes; Advisories, standards etc. offer relevant warnings and guidance from organisations such as CERT, the FBI and NSA, ISO/IEC, journalists, bloggers and podcasters, technology vendors plus information risk and security professionals. Threat and vulnerability intelligence services can be useful, along with security advisories and patch notifications from software, hardware, service and information suppliers. Next, the evaluate risks stage involves considering all that information in order to determine the significance of various risks, which in turn drives priorities for the next stage. The organisation’s appetite for risks is a major concern here, reflecting corporate strategies and policies as well as broader cultural drivers and personal attitudes of the people engaged in risk management activities. Treat risks involves avoiding, mitigating, sharing and/or accepting them. This stage involves both deciding what to do and doing it (implementing the risk treatment decisions). Handle changes might seem obvious but it is called out due to its importance. Information risks are constantly in flux, partly as a result of the risk treatments, partly due to various other factors both within and without the organisation. The ISO27k way is risk-driven, such that the most significant risks at any point should be in hand … but there is always more to do, so this is an endless journey across shifting sands. Finally, a reminder that the organisation often has to respond to external obligations such as legal and regulatory compliance plus market pressures, customer expectations, commercial contracts etc . These also change from time to time, and should be actively monitored. What risk analysis method should we use? Determine your own risk analysis, risk management and/or governance requirements and evaluate the methods, tools, products etc. carefully. There is further advice on how to select specific methods/tools in the next FAQ. Since neither ISO/IEC 27001 nor ISO/IEC 27005 specify or require a particular risk analysis method, you can select whichever method or (better still) methods align with your organisation’s expertise and situation. Risk analysis methods are broadly categorised as quantitative (based on mathematical modelling and statistical analysis) or qualitative (experiential, subjective). ISO/IEC 27005 offers general advice on selection and use of methods in the ISMS context but does not insist on any specifics. It is perfectly acceptable, and often beneficial, to mix-n-match multiple methods. For instance, a high-level overview method might identify broad areas of concern (such as privacy), which can then be examined in detail using focused methods (e.g. privacy impact assessments). Leverage the expertise of business departments such as Internal Audit, Risk Management, Health and Safety, Finance, Project or Programme Management and Operations, as their methods can often be applied to information risks. There is no need to abandon familiar tools simply for ISO27k. However, be mindful of discrepancies in results from different methods. Avoid simplistic approaches like choosing the least costly controls or addressing only the most obvious 'key' risks. Instead, use the analyses as decision support tools for management. Managers need to determine appropriate security investments, risk appetite and improvement timelines. This requires a combination of vision, expert advice and practical judgment. Below is a very brief introduction to a number of information risk analysis and management methods, standards, guidelines and tools, plus some aimed at supporting G overnance, R isk and C ompliance and even S ecurity I nformation and E vent M anagement. Analog Risk Assessment (ARA) is a deceptively straightforward and quick method to analyse, discuss and consider risks subjectively and simplistically according to their relative probabilities of occurrence and levels of impact; Calabrese’s Razor is a method developed by Chris Calabrese to help the C enter for I nternet S ecurity prioritise technical controls in their security configuration guides. It helps evaluate and compare the costs and benefits for each control on an even footing; COBIT from ISACA is a comprehensive model guiding the implementation of sound IT governance processes/systems, including to some extent information security controls; COSO ERM (C ommittee O f S ponsoring O rganisations of the Treadway Commission's E nterprise R isk M anagement framework) is a general structured approach for managing all forms of organisational risk; Delphi is a forecasting technique involving successive rounds of anonymous predictions with consolidation and feedback to the participants between each round; DIY (D o I t Y ourself) methods offer a genuine alternative, not just a straw man. DIY involves using risk analysis methods with which you or your organisation are already familiar, perhaps home-grown methods or even those that are not normally used to examine information risks. With the same underlying principles, can your existing risk analysis methods, processes and tools be adapted for information risks?; FMEA (F ailure M ode and E ffects A nalysis) is commonly used in engineering design. It focuses on the possible ways in which a system might possibly fail, almost regardless of the causes; The UK’s IRM (I nstitute of R isk M anagement), AIRMIC (Association of Insurance and Risk Managers) and ALARM (The National Forum for Risk Management in the Public Sector) jointly released A Risk Management Standard way back in 2002, for all forms of organisational risk, not just information risk; ISO 31000 offers guidance on the principles and implementation of risk management in areas such as finance, chemistry, environment, quality, information security etc .; ISO/IEC 27005 isn’t really a risk assessment or management method as such, more of a meta-method, an approach to choosing methods that are appropriate for your organisation; Mehari is a free open-source risk analysis and management method in several European languages developed by CLUSIF (Clu b de la S écurité de l'I nformation F rançais) and CLUSIQ ; NIST SP 800-30 “Risk Management Guide for Information Technology Systems” is a free PDF download from NIST . An accompanying guideline is also available and also free; NIST SP 800-39 “Managing Risk from Information Systems - An Organisational Perspective” is another freebie from NIST; OCTAVE (O perationally C ritical T hreat, A sset, and V ulnerability E valuation) is CERT ’s risk-based strategic assessment and planning technique for security. It takes a business rather than technology-centric view of security risks. OCTAVE Allegro is a quick version of OCTAVE; Risk IT from ISACA complements their other excellent tools COBIT and ValIT ; Stochastic modelling methods using Markov chains , stochastic Petri nets , Monte Carlo simulation , Bayesian or other statistical techniques and probability theory are commonly applied to estimate uncertain risk values from incomplete data in the financial industry; Verinice is a free open-source tool supporting the BSI IT-Grundschutz standards . It’s very nice. We are not selling, recommending or endorsing any of them. We haven’t even used all of them, personally, and we don't know your requirements except in very general terms. OK, how should we select risk analysis methods? Don’t get completely hung-up on this: go with what you have and make it work for you, learning, refining, moving ahead. This is classic opportunity for 'continual ISMS improvement'. Read ISO/IEC 27005 for starters and think carefully about what you want. What do you expect the method or tool to achieve for you? Which factors and/or features are most important? Are there any things the method or tool should not do (e.g. gobble-up excessive amounts of limited resources)? Determine your requirements such as: Quantitative or qualitative : opinions vary on the relative value of quantitative versus qualitative methods. Few information security or risk management professionals would recommend truly quantitative analysis of information risks in all circumstances due to the shortage of reliable data on incidents (probabilities and impacts), although they are potentially useful in some more narrowly-defined situations. One solution to this dilemma is to use quick/simple qualitative risk assessments followed by risk analyses on selected ‘high risk’ areas using more detailed qualitative or quantitative methods; Scope : are you purely looking at “information risks” or risks in a broader sense, and what do you really understand by “information risks” anyway: are you in fact concerned about risks to information assets, or business risks that happen to involve information, or something else? Furthermore, which information assets are you concerned with? What will happen with the out-of-scope risks that could be just as significant for the organisation, especially if they remain unrecognised, unanalysed and untreated? Scalability : are you looking to support a relatively simple analysis of risks for a single process or IT system, an organisation-wide analysis, or all of the above? Will you be completing the analysis just once or repeatedly, and if so how often? Maintainability and support : some methods use AI/decision support software, whereas others are procedural or can be supported by generic tools such as spreadsheets. Clearly, therefore, they vary in the amount of technical expertise required to install, configure and maintain them. Home-grown tools can be more easily and cheaply developed and modified in light of your experiences whereas commercial tools tend to be slicker and more polished; Usability : some methods and tools lead the user through the risk analysis process a step at a time, whereas others are more free-form but arguably assume more knowledge and expertise of the users. Some attempt to reduce the information gathering phase to simplistic self-completion questionnaires for risk non-specialists, others require competent risk analysts; Value : simply put, value means the business benefits of the tool less the associated costs . Purchase price is not the only factor here. Can you explain the SoA and RTP? Don’t get hung up on the names and acronyms. Concentrate on their purpose, which is to clarify the relationship between your organisation's information risks and their treatments. Let's assume that, despite studying ISO/IEC 27001 , you are unsure. The S tatement o f A pplicability is a formal definition of the controls employed by your ISMS. There needs to be some rationale to explain your reasoning and persuade the auditors that important decisions to include or exclude controls from Annex A or from elsewhere were made not arbitrarily but rationally, according to the risks. Be ready for some robust audit discussions if you decide not to implement common controls at all, blithely accepting significant risks. Likewise, be ready for some robust management discussions if you decide to implement all of Annex A simply simply because it’s an ISO standard, not because the controls are appropriate and necessary to mitigate (reduce) unacceptable risks. The R isk T reatment P lan lists the risks identified and evaluated in your risk assessment, along with the associated treatments: unacceptable risks may be mitigated with controls listed in the SoA, or avoided, or shared with other organisations. Small risks may be willingly accepted if they fall within management’s risk appetite or if the controls would cost more than the anticipated incidents, while various other risks (such as the possibility of erroneous assumptions within, and hence decisions based upon, your risk analysis) are implicitly and necessarily accepted. How should we handle our client 's information risks? This may be an opportunity to sell your client some security/risk consultancy services! Either way, have your pet lawyer take a very careful look at any contracts or SLAs relating to third party information assets in your care, to be crystal clear about your information security obligations and liabilities. The managers of, say, commercial shared data centre services should ideally involve (key) clients directly in (part of) the risk analysis. Helping client managers understand and elaborate the information risks relating to their assets should clarify what they expect and enables the supplier to appreciate what is expected – the priorities, for example. What comes first, and why? If clients are unwilling or unable to engage fully with the risk analysis, managers should at least assess the information risks relating to the contracts and services from the supplier’s perspective, including the risk that clients may have unrealistic or inappropriate expectations about the information security services provided. A serious information security incident involving the supplier would almost certainly damage customer relations, might lead to legal arguments over the contract/SLA and could either put clients out of business or see them defect to another supplier. Similar considerations apply in other circumstances where the organisation handles information assets belonging to third parties - customers’ personal data and credit card details, for instance. What is the difference between risk assessment and audit? Challenging the status quo can be a valuable, if cathartic experience. At the end of the day, just remember that the primary aim of both activities is to improve the organisation, stimulating management to make changes for the better. These are change catalysts, opportunities to improve. Risk assessment identifies and analyses potential risks, while an audit typically evaluates the effectiveness of existing controls at keeping risks within the corporate risk appetite. Risk assessment tends to be a theoretical 'what if' exercise, often involving workshops, discussions and models to identify and explore inherent and residual risks. It is conducted by those familiar with the area, including risk managers and security experts. An audit, on the other hand, is a more practical, hands-on 'show me' activity. Among other things, auditors examine and validate the controls in place to determine if they adequately address various risks – both in theory (if they worked as designed and documented, would they be sufficient?) and in practice (are they, in fact, working as designed and documented?). A key distinction is independence: audits can only be conducted by independent auditors, providing an unbiased perspective. Auditors bring fresh eyes, challenge assumptions and identify blind spots. Compliance audits, such as ISO/IEC 27001 certification audits, specifically assess adherence to regulations and standards. They also consider the risk of non-conformity: significant issues can not only prevent certification but underline the ISMS, potentially putting the organisation’s entire approach at risk. Finally, the risk assessment process itself is auditable, while auditors must also manage audit risks, such as failing to identify, evaluate and report critical issues appropriately. Which compliance obligations are relevant to ISO27k? The obligations or rules expressed formally in legal language tend to be minimalist, meaning that compliance alone may not protect the organisation’s business interests. Compliance is necessary but not sufficient. You may prefer to handle this separately from the ISMS. The organisation's compliance with various obligations can be an important driver to implement an ISMS, not least because the ISMS can take some of the weight off management’s shoulders. Managers generally either accept the need to comply, or can be persuaded to do so in order to avoid the personal adverse consequences (typically fines, prison time and career limitations). As to which obligations are relevant, there are loads of them! Although I A m N ot A L awyer, here is an incomplete listing of the general types or categories of laws, regulations etc . that have some relevance to information, information risk, information security and thus potentially the ISMS: Building codes – structural integrity, resistance to fires, floods, earthquakes, fire exits … Business records – financial reporting, tax, credit, banking, money laundering, company accounts … Business continuity – critical infrastructure, resilience … Classified information – governmental and military, spying, official secrets, terrorism, organised crime … Commercial contracts – N on D isclosure A greements, digital signatures, maintenance and support agreements, Internet/distance selling, invoicing, credit and payment, PCI-DSS , plus various other obligations on or towards business partners, suppliers, customers, advisors, owners … Community relations – being a good neighbour, supporting the underprivileged … Consumer protection – product designs, advertising, branding, warranties, fitness for purpose, merchantability, quality and security ... Corporate governance – company structure, ownership and control, obligations of Officers, independent oversight/audits … Cryptography – standards, laws and regs e.g. restrictions on use and export of strong crypto … Defamation – libel, slander ... Employment – disciplinary process, pre-employment screening/background checks, contracts of employment, codes of conduct … Environmental – pollution, eco-friendliness, greenwashing … Ethics – morals, cultural and religious aspects e.g. Sharia law; Forensics – chain of custody, warrants and warrantless searches, admissibility ... Fraud – identity fraud, misrepresentation, embezzlement, malfeasance … Freedom of information – enforced disclosure, including ‘discovery’ in legal disputes; Hacking – malware, ransomware/coercion, denial of service, unauthorised access … Health and safety – safety-critical control systems, fire exits, building standards/codes, industrial control systems, working conditions, hazards … Industry-specifics – some industries are tightly regulated, others less so … Insurance – terms and conditions, excesses, disclosure of relevant facts ... Intellectual property – copyright, trademarks, patents, DMCA, trade secrets, publication/disclosure etc . protecting both the organisation’s IP and that of third parties; Permits – operating licenses in some industries and markets, software licenses … Pornography – paedophilia, discriminatory/offensive materials, blackmail … Privacy – data protection, personally identifiable information … Surveillance – spying, wiretapping, CCTV, monitoring, investigation, forensics … Technical – standards and interoperability e.g. ISO27k, TCP/IP, DNS, Windows compatibility … Telecommunications – networking, lawful/unlawful interception, mail fraud … Theft – of hardware and media … Trespass – right of access, right to exclude, ‘citizen’s arrest’ … International – as well as domestic laws and regulations, those in other countries might also be applicable if your business has an international presence or uses cloud and other services hosted overseas … ++ Others : speak to your Legal/Compliance team about this. By the way, beware changes to the legislation and ‘case law’ (where judges/courts interpret things in particular ways, sometimes setting legal precedents). Aside from being familiar with the obligations, someone needs to keep on top of the associated policies, contracts, agreements, standards and codes, plus awareness and training, compliance/conformity assessments and enforcement aspects. For example, do you have the policies and procedures in place for exceptions and exemptions ? Do you need to check compliance and perhaps enforce your organisation’s obligations on third parties e.g. confidentiality agreements with business partners and former employees? Warning : assuming you are an information security professional looking into this, be very wary of being expected or even perceived by colleagues and management as a legal expert. Even professional lawyers specialise because the field is too broad for anyone to be entirely competent across the board. Senior managers generally own and are accountable for corporate compliance. Don’t take on their mantle! By all means offer general advice and guidance but leave them fair and square with the compliance burden. For your and their protection, explicitly recommend that they seek the guidance of competent professionals. Once again, for good measure, IANAL and this FAQ is not legal advice. What should we do about exceptions? Key to this approach is the personal accountability of Information/Risk Owners for adequately protecting their information assets. If senior management doesn't understand or support concepts such as exceptions, exemptions, accountability, responsibility, ownership, information assets and risk, then patently the organisation has significant governance issues to address first! First understand the vital difference between exceptions and exemptions*: Exceptions are un authorised noncompliance/nonconformity with requirements, typically identified by audits, management reviews, during the system design phase when developing software and processes, or revealed by information security incidents; Exemptions are authorised noncompliance/nonconformity. Exemptions are the way to formalise risk management decisions when Information/Risk Owners explicitly accept specific identified risks on behalf of the organisation for legitimate business reasons. For example, imagine that an IT systems audit has identified that system A is configured to accept passwords of at least 6 characters, while the corporate password standard mandates at least 8 characters. This is an exception that should be brought to the attention of the Information/Risk Owner for system A. The owner then considers the situation, considers the risk to the organisation and to the information asset, takes advice from others and decides how to treat the risk. The preferred response is to bring the system into line with the policies. However that is not always possible. If instead the decision is to accept the risk, an exemption to the specific policy requirement is granted, but - and this is the important bit - the Information/Risk Owner is held personally accountable by management for any security incidents relating to that exemption by simple extension of their accountability for protecting their information assets. Exemptions should be formalised e.g. : The Information/Risk Owner should be required to sign a crystal-clear statement regarding their understanding and acceptance of the risk to their asset if the exemption is granted, acknowledging that they are personally accountable if the risk materialises; The exemption should be granted by being countersigned on behalf of management by an authoritative figure such as the CEO or CISO; Optionally, the exemption may specify compensating controls (such as explicit guidance to users of system A to choose passwords of at least 8 characters in this case); All exemptions should be formally recorded on a controlled corporate register; All exemptions should be reviewed by the owners and management periodically (e.g. every year) and, if still required and justified, renewed using the same formal process as the initial authorisation. Typically exemptions may be renewed and continue indefinitely just so long as the owner is prepared to continue accepting the risk and management is prepared to accept the situation, but some organisations may impose limits (e.g. an exemption automatically expires after one or two years and cannot be renewed without a majority vote in favour by the Board of Directors). If there are loads of exceptions and especially exemptions to what are supposedly mandatory requirements, management really ought to reconsider whether the requirements are truly mandatory. If in fact they are, any current exemptions should be set to expire at some future point, forcing owners to select risk treatments other than ‘accept the risk’. Information Security should take up the challenge to help improve conformity. If the requirements are not in fact mandatory after all, the policies etc . should be revised accordingly. * Note: organisations use different words for these two concepts, such as exceptions and waivers, or exemptions and waivers, or even exemptions and exceptions with their meanings reversed. The specific terms don’t particularly matter provided they are clearly defined, the distinction is clearly understood and they are used consistently in practice. I’m confused about ‘residual risk’ … Proactively and systematically managing residual risks indicates a mature or maturing ISMS. It suggests the organisation already has a grip on its unacceptable risks and is taking a sensible, realistic approach. Residual literally means 'of the residue' or 'left over'. So, residual risk is the left-over risk remaining once risk treatments have been applied. So, for example, suppose after risk assessment there are 3 risks (A, B and C): risk A is acceptable, B and C are not acceptable. After risk treatment, B becomes acceptable but C is still not acceptable. Which is the residual risk: just C? Or B and C? It’s a trick question. In fact, A, B and C all leave some (residual) risk behind ... Accepted risks are still risks: they don't cease to have the potential for causing impacts simply because management decides not to do anything about them! Acceptance merely means management doesn't believe they are worth reducing further. Management may be wrong (Shock! Horror!) - the risks may not be as they believe, or things may change; Mitigated or controlled or managed risks are still risks: they are reduced but not eliminated, usually, and the controls may fail in action (e.g. antivirus software that does not recognise and block 100% of all malware, or that someone accidentally disables one fateful day); Eliminated risks are probably no longer risks, but what if the risk analysis was mistaken or the risks aren’t in fact 100% totally eliminated? What if the situation changes? Avoided risks are probably no longer risks, but again the risk analysis may have been wrong, or someone may deliberately or inadvertently take the risk anyway, especially if there are weak or missing administrative controls and awareness of the decision to avoid the risk; Shared risks are reduced but are still risks, since the sharing may not turn out well in practice (e.g. if an insurance company declines a claim for some reason) and may not be adequate to completely negate the impacts (e.g. the insurance 'excess' charge, or denial of claims). Remember that the manager/s who elected to share risks are personally accountable for those decisions if it all turns to custard, goes pear-shaped or hits the fan ... Previous Up Next

404 error: Page not found Could be an availability or integrity failure Try removing .html from the URL and reloading the page, or find your way to the page you seek using the menu. Go home