Search Results

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 adverse impacts'. To put that more succinctly, information risk is 'risk pertaining to information' . While the ISO27k standards neither define nor use 'information risk', 'information security risk' is defined in ISO/IEC 27000 as 'Potential that a threat will exploit a vulnerability of an asset or group of assets and thereby cause harm to an organisation'. The harm is described in terms of a loss of confidentiality, integrity or availability of information, mere technicalities. I prefer to take the organisation's perspective: reducing the number and severity of possible adverse business impacts 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 SP800-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 catalos of cybersecurity ‘attacks’ i.e . how some threat agents exploit some vulnerabilities; Good information security textbooks are worth studying too, for example: Security Engineering by Ross Anderson is a well-respected source; Cem Kaner’s book Testing Computer Software has a lengthy, structured appendix listing common software errors, some of which create vulnerabilities; Building Secure Software by John Viega and Gary McGraw, plus Gary’s other books , discuss the concept of threat modelling to develop security specifications for application software; The Security Development Lifecycle by Michael Howard and Steve Lipner outlines Microsoft’s approach to threat modelling using STRIDE (S poofing identity, T ampering, R epudiation, I nformation disclosure, D enial of service and E levation of privilege). Most information risk analysis and management support tools, systems, methods and advisories include examples or lists of stuff to consider. 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 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 the ISO27k standards don't mandate a particular method, you can select wnhichever methods align with your organisation’s expertise and requirements. Risk analysis methods are broadly categorised as quantitative (based on mathematical modelling and statistical analysis) or qualitative (experiential, subjective). ISO/IEC 27005 offers 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. Management must determine appropriate security investments, risk appetite and improvement timelines. This requires a combination of management 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 method to analyse, discuss and consider risks subjectively and simplistically according to their relative probabilities of occurrence and leves 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 provides 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 E nterprise R isk M anagement framework) is a general structure/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, 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 (e.g. Delphi ). Can your existing risk analysis methods, processes and tools be adapted for information risks?; FMEA (F ailure M odes 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 Institute of Risk Management (IRM), Association of Insurance and Risk Managers (AIRMIC) and ALARM, The National Forum for Risk Management in the Public Sector, jointly released A Risk Management Standard 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 most 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 that you have and make it work for you, learning, refining, moving ahead. 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 modified in the 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 information risks and their treatments. Let's assume that, despite reading 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 or opportunities to improve. Risk assessment identifies and analyses potential risks, while an audit 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 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, WPA2, 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, setting 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 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 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 evidently 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 Owner 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; 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 year 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 certain 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 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; 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). 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

Detailed answers to a bunch of Frequently Asked Questions about the ISO/IEC 27000-series information security standards ISO27k FAQ This unusually detailed FAQ poses and addresses F requently A sked Q uestions regarding ISO27k, the ISO/IEC 27000 standards. There is a lot to say, lots of pragmatic advice to offer. FAQ topics About the ISO27k standards Implementing the standards Managing information risks ISO27k documentation Assurance ISMS maturity A gentle introduction to the information security standards Guidance on interpreting and applying the standards in practice Tips on identifying, analysing, evaluating and treating the risks Required documents - SoA, RTP, policies, procedures, records ...? Guidance on auditing and certification for confidence and trust Ideas on using continual improvement to embed and mature your ISMS

FAQ about the 'documented information' required or implied by ISO/IEC 27001 and the others, with pragmatic advice on keeping the red tape under control (it's an information risk!) Up Up Up Documentation How should we prepare ISMS documentation? Competent, skilled documenters/technical authors should know how to use the tools of their trade - templates, styles, diagrams etc. If your ISMS materials are, frankly, shoddy and inconsistent, professional assistance may be a valuable investment. Rather than attempting to manage a mountain of paper documents, declare the electronic online versions definitive. Set up a suitable structure for the ISMS materials (strategies, policies, procedures, guidelines, training courses, awareness content, reports, metrics ...) in a communal area (such as your intranet or LAN) with controlled access. It is worth developing a consistent style and format (a.k.a. 'look and feel') for each type of ISMS-related material. Consistency helps bind them into a coherent, professional suite. Parts of the ISMS are inevitably formalised (e.g. policies), whereas others can usefully be more user-friendly (e.g. guidelines). Review and maintain the documentation continually. 'Spring clean' occasionally to address out-of-date or inconsistent materials and identify gaps or improvement opportunities. Do you have a logo with which to ‘brand’ your ISMS-related documentation? If not, an internal competition to generate one is a little security awareness opportunity! What should our information security policy cover? The documentation is never truly “finished” but needs to be updated from time to time to reflect changes both within and without the organisation (e.g. the emergence of new information security threats). It helps to have a reasonably complete policy suite but it need not be totally comprehensive provided the ISMS processes drive routine maintenance updates. That's up to management. See ISO/IEC 27002 for a decent outline of what the policy (or rather policies) should cover, as a minimum. A hierarchical structure is common: At the tip are a few fundamental principles or axioms - things such as 'least privilege' and 'CIA triad' perhaps, or risk management and accountability, or minimising the number and severity of incidents, or whatever. In a sense, these are your top-level information security objectives. Next comes some sort of overall corporate information risk and security policy - an overarching statement by senior management regarding the principles, mandating and explicitly supporting the ISMS for the business as a whole (or at least the area in scope). Individual policies covering specific information security topics or issues (e.g. “Email security policy”, “Network access control policy”) tend to be quite formal but need not be stilted. Typically they: specify security responsibilities; offer explanations to aide reader comprehension; reference/link higher and lower levels of the hierarchy, binding things together; are general/technology-neutral; and are succinct - ideally no more than a few pages at most. Corporate security standards expand on the high-level policies with technical details needed for their implementation e.g. a standard for 'Windows desktop security' would typically specify Windows security parameters and activities such as patching, antivirus, backups, logging, alerting etc . Standards (both corporate and public) can be used as criteria for technical conformity assessments, including automated checks, and guide the security aspects of provisioning and configuring new systems. The base level consists of procedures and guidelines , plus advisories, course materials, awareness content, newsletters, blogs and so forth - stuff to help people understand and make good use of the policies, standards etc . What ISMS documentation is mandatory? You need to prepare all the mandatory docs for certification, no question, so this is clearly something important to incorporate into your ISMS implementation planning. Beyond that, avoid creating reams of unnecessary material, adding costs, complexity and red-tape. KISS! Just 14 (yes, seriously, just 14) types of document are mandatory in the sense of being formally required of every organisation seeking certified conformity to ISO/IEC 27001: Clause 4.3 - ISMS scope Clause 5.2 - Information security policy Clause 6.1.2 - Information security risk assessment procedure Clause 6.1.3 (d) - S tatement o f A pplicability Clause 6.1.3 - Information security risk treatment procedure Clause 6.2 - Information security objectives Clause 7.2 - Personnel records Clause 8.1 - Operational planning and control [see below ] Clause 8.2 - Risk assessment reports Clause 8.3 - R isk T reatment P lan Clause 9.1 - Security measurements (=metrics !) Clause 9.2.2 - ISMS internal audit programme and audit reports Clause 9.3.3 - ISMS management review reports Clause 10.1 - Records of nonconformities and corrective actions Some on the list may consist of multiple items (e.g . a set of topic-specific policies), and some may be combined (e.g. risk assessment and treatment can be covered in a risk management policy, procedure or guidelines). Furthermore, the ISMS auditing standard ISO/IEC 27007 notes that: There should also be a documented audit process sInce the definition of 'audit' states that it is a 'documented process'; Clause 7.5.1(b) requires 'documented information detemine by the organization as being necessary for the effectiveness of the ISMS' - a rather vague and open-ended requirement that the organisation needs to interpret and satisfy for itself. Read on. In practice, most organisations choose to prepare and incorporate rather more than those mandatory items, for business reasons. There are usually many more discretionary documents such as: Those needed to justify, manage and track the typical ISMS implementation project, plus ISMS changes and various other substantial infosec-related activities; Info regarding governance of the ISMS e.g. structure charts/organograms, descriptions of ISMS-related roles and responsibilities, broad principles, axioms and imperatives; ISMS management information - various strategies, metrics, reports, plans, budgets etc.; Docs concerning the information risks, as generated by the risk management process; and, most numerous of all ... Docs concerning the organisation’s information security controls, such as policies, procedures, guidelines, parameters, lists and databases, operational information, reports, logs, event records, alerts and alarms, diagrams, help text ... lots of stuff here! ISO/IEC 27001 clause 8.1 says “Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned.” In theory, someone could become confident without any written records (e.g. by directly observing ISMS activities as they are performed) but the absence of readily-auditable evidence would undoubtedly upset the certification auditors in practice. They typically expect to review all the mandatory documentation and sufficient discretionary items to confirm that the ISMS both conforms with the standard, and is operating as documented. Won't a document management system help manage all those docs? A largely manual process with some automation is a good way to explore and elaborate on your objectives or requirements, at least at the start. If you decide to invest in an ISMS support system, you will have a better appreciation of the product evaluation and selection criteria. Before you get carried away by the thought of 'all those docs', remember that your primary objective is to manage the organisation’s information risks and security controls effectively and efficiently for sound business reasons, not to generate and manage reams of red tape, accumulating unnecessary burdens and costs. The KISS rule applies: K eep I t S imple and S traightforward. Less is more. Get a grip. Starting with the 14 mandatory ISMS documentation types, do you really need reams of detail or will brief summaries suffice? Who actually needs to read and understand them? Who are they for? What are the objectives or purposes? Next the discretionary docs: again, don't go bonkers with the keyboard. Keep them short and sharp where that makes sense. In particular, be sure to document what you actually do , not what you think perhaps might be quite nice to do possibly in an ideal world. Clearly distinguish mandatory or obligatory activities by using keywords such as 'shall' or 'must', leaving weasel-words such as 'appropriate', 'if necessary', 'ideally', 'should' and 'may' for the remainder. Some documentation (such as details of applicable legal and regulatory obligations, or health and safety requirements that are relevant to information risk and security) may be better managed outside the ISMS (e.g. by your legal/compliance and HR or H&S teams, respectively). That's a scoping issue. So, given all that, do you actually need a 'system' to manage ISMS docs, or can you get by with the simple tools and processes to hand? Do we need a 'policy manual' or an 'ISMS manual'? P ublish key documents such as your information security policy once, definitively, and refer to them consistently from elsewhere. A basic naming convention is useful. Use a formal D ocument (or C ontent) M anagement S ystem only if that helps. No, neither, at least not if you are thinking of a thick physical book or lever-arch file full of policies, procedures etc . Electronic documents are preferred. However, it is worth cataloguing, introducing or outlining, and referencing your policies and other ISMS documents somewhere e.g . in the ‘Security Zone’ on your intranet. As well as making it easier to keep important documents accessible and under control, the certification auditors will appreciate having a neat list of the key ISMS documents, and you will have a handy shopping-list of the docs the auditors are most likely to ask for. For bonus marks, identify the document owners, plus the issue and revision status if that helps keep the materials reasonably up-to-date – not just for the sake of it though. If your document management policy states definitively that ‘policies must be reviewed and re-approved every year’, even a single, trivial example of a slightly out-dated policy is potentially an adverse audit finding. How much detail is appropriate for a security policy on, say, working in secure areas? Keep all policies reasonably succinct, short and sweet. If needed, prepare less formal supporting materials such as procedures, guidelines and training course slides to suit the intended audience and subject. Regarding corporate policies, procedures and the like, shorter and more succinct is almost always better. It means less to: Write; Review, consider, check out, discuss ...; Approve; Implement i.e. mandate, circulate to the relevant people and put into practice; Read and understand; Train people about or at least make them aware of; Police i.e. check/ensure compliance/conformity with, and audit against; and Maintain. That's quite a burden when you think about it, costly too. Minimisation makes sense but there are practical limits. The documents need to be sufficiently comprehensive to meet your organisation’s particular risk mitigation needs, expansive and clear enough not to be totally cryptic, and need a certain gravitas to be considered by management and staff as actual policies. A single policy stating something like “Keep all our information assets secure” or "Don't be evil" scores very high on the succinctness scale but very low on the “What on Earth am I meant to do to comply with this policy?” scale! ISO/IEC 27002 guides you on the sorts of controls you ought to consider in the specific area you are working on. It makes sense to use the standard as a basis, a starting point. See how well it fits your organisation’s needs (considering your particular risks, circumstances and other supporting controls), modify it as necessary, then implement your policy ... and finally drop into ‘maintenance mode’ where subsequent practice, incidents, near misses and any changes in the security threats and vulnerabilities or business impacts in that part of your ISMS imply the need to change your controls. Your policy development process will, in time if not already, come up against the challenge that many potential subject areas could be covered by multiple policies, looking at similar issues from different angles. “Working in secure areas”, for instance, begs obvious questions about what constitutes “working” (do you mean just employees on the payroll, for instance, or does it apply to contractors and cleaners?), and how you have identified and defined “secure areas” (is there a physical risk assessment process?). You can carve up all your controls in numerous ways, and (trust me!) it is very easy to end up with a totally unworkable mess of overlapping, conflicting and yet gappy policies if the overall policy development process is not itself well managed. So, think and plan ahead, using s tandards such as ISO27k and the NIST SP800s as a basis for your policy set. Can we share our SoA with third parties? Should we? Think this through when preparing and maintaining your SoA. Along with the RTP and others, it's an important document, so take care. If your S tatement o f A pplicability conforms to ISO/IEC 27001 clause 6.1.3d, it will list the 'necessary' and 'unnecessary' [information security] controls in scope of your ISMS along with the specified justifications and implementation status. You may consider some or all of this information to be sensitive since sharing it increases the risk of inappropriate access and perhaps exploitation. On the other hand, not sharing it (being reluctant or flatly refusing to disclose it) increases the risk that third parties such as business partners, investors, authorities, customers and prospects may decline to engage and do business with your organisation. Your reluctance to provide assurance that various unacceptable information risks are being duly mitigated could be a barrier, indicating limited trust. If you decline to share it with the certification auditors, your conformity certificate will almost certainly be refused. So, in ISO27k terms, these are simply information risks for management to evaluate and treat in the normal way, using the risk management processes in your ISMS. If certification is important to the business, some degree of risk is inevitable: the trick is to manage it in the best interests of the organisation, overall . Consider for instance: Who should or should not see your SoA? Why them? What are the requirements or expectations of the intended recipients? How will they use the information - what for? What are the implications of inappropriate disclosure? How significant are the impacts? How likely is this to happen over a realistic timescale? What information must your SoA contain, exactly? Can it be phrased discreetly or in such a way that the most sensitive details are witheld or provided separately only if appropriate? Can you reasonably restrict its sharing and onward disclosure by legal or other means, such as through binding non-disclosure agreements? If the preventive controls partially or completely fail, what security options remain? How can you detect and respond to inappropriate disclosure? Previous Up Next

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 simplified 8-point 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 CAPA 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 IT (e.g. new platforms and application systems), 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 controls 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. 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 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 success as you go. 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 and training session is essential for everyone” if they don’t make the 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 after it has been (somehow) 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. Using a 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 eloquently described by Lance Hayden in "IT Security Metrics" is an excellent approach, made even more powerful by "PRAGMATIC Information Security Metrics" by Krag Brotby and Gary Hinson, a way to design or select worthwhile metrics from a shortlist. 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 that you should check out include: ISO/IEC 27004 - the current 2016 version is useful, the next promises to be even better; SecurityMetametrics.comfor an FAQ on security metrics and security maturity metrics designed to support ISO/IEC 27002. Selecting security metrics that are appropriate for your organisation starts by figuring out things such as who are the audiences for the metrics, and what do they expect to achieve with the information. "IT Security Metrics" book by Lance Hayden explains the Goal-Question-Metric structured approach in the IT security context; "You are what you measure", a 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? Figure out your U nique S elling P oint or value proposition as a consultant. What business benefits do you offer clients, substantially outweighing your charges? Why should clients employ you rather than your competitors, or simply muddling along on their own? 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 information security controls ISO/IEC 27005 (information security 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. Continue your self-development by actively researching and learning about governance, risk and control concepts. Become familiar with NIS2, DORA, PCI-DSS, COBIT, privacy laws and so on. Take a proper look at the remaining ISO27k standards, and others such as ISO 22301 and the NIST SP800s. Impress potential clients with the breadth and depth of your knowledge. Real-world experience is crucial. Take on small projects. Do research. Write papers. Participate actively in professional communities such as the ISO27k Forum. Seek mentorship or guidance. Read voraciously. 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 - and so will your peers and clients. Meanwhile, slog. Previous Up Next

FAQ about auditing, testing, reviewing and evaluating things in the context of ISO27k Up Up Up Assurance How to conduct an ISMS internal audit (in detail)? Personally, I use mind-maps to help me think through the likely risks and anticipated controls, and to structure each audit job. Process diagrams, flowcharts, swim lane charts, Ishikawa (fishbone, cause-and-effect) diagrams and so on may suit you better. Don’t forget to include sufficient contingency time in your plan ... for those things that don't go entirely as planned. Start by studying ISO 19011, the ISO standard for auditing management systems, for general advice, plus ISO/IEC 27006 , ISO/IEC 27007 and ISO/IEC TS 27008 for more specific advice on ISMS audits, plus the core ISO27k standards about the ISMS itself. Your Internal Audit Department, if you have one, is an obvious place to seek help (e.g. audit policies and procedures) and ISACA is another recommended resource. The typical audit process goes something like this: Agree the audit scope (what's in and just as importantly what's out of scope), purpose/objectives and criteria for the audit (e.g. man-days or elapsed time available, expected audit deliverables) with audit and maybe business management. [Each audit normally flows from some form of risk-based audit planning and scheduling.] Review the situation and the background to the audit, considering the risks potentially of concern in the area of scope and any concerns or loose ends arising from prior audit reports, management reviews etc . You may need to do some initial scoping/feasibility work on the job, and check any previous ISMS-related audit reports and maybe the audit files to get a feel for the likely problem areas. Either way, try not to lose sight of your independence, in other words think about the risks and issues in broad, fairly theoretical terms, assuming nothing about the controls that one would naturally expect to be in place ... just in case they aren't. Draw up an audit work program (an I nternal C ontrols Q uestionnaire, checklist or whatever you call it) showing the issues you intend to check and indicating in what level of detail you will check them. Leave yourself some space for notes to record findings and your initial analysis while things are still fresh in your mind. Consider and plan the audit fieldwork i.e. how you will actually check the things of interest on your ICQ through interviews, observation, data analysis, sampling, testing ... Draw up your shopping list of things and information you will need, people you want to speak to etc . and reconfirm the timescale for the audit assignment: you will often have lined yourself up more work than you can reasonably complete in the time available, so revisit the scoping for clues about management’s priorities for the audit. Identify and contact your lead contact/s for the audit and work with them to line up and prepare for the fieldwork, hopefully sorting out many of the items on your shopping list (e.g. arranging initial interviews, obtaining reports, policies etc . that you will want to review). It's best to contact the contact as early as possible in the process: good contacts can help with the planning too, but be cynical if they try to steer you away from anything! Perform the audit fieldwork, keeping your contact up to date with developments, preliminary findings, concerns, any problems conducting the audit etc . A helpful audit contact can act as a sounding board for emerging audit concerns and possible recommendations, and a source of additional inside knowledge. Work systematically through your ICQ. Analyse the findings, generating a list of priority issues (must-fix items) and ‘additional items’ (often included in reports just for information, but that depends on audit working practices). My preference is to draw up a SWOT analysis identifying the key S trengths, W eaknesses, O pportunities and T hreats - no more than about 5 or 6 items per category to keep things at a high level. You may need to revisit certain parts of the ICQ to confirm significant findings, collect additional evidence, and generally substantiate the key issues. Stay objective, for instance basing your work on facts backed by audit evidence . Draft an audit report with recommendations addressing the priority issues, and get this reviewed within the audit function, or by your manager at least. A ‘file review’ is normal in order to confirm that everything reportable is being duly reported, and everything reported is traceable to sound audit evidence. This requires sorting and indexing the audit evidence, cross-referencing it to the ICQ etc . Work with senior and middle management to clarify any audit concerns and recommendations, and to align priorities and timescales with business objectives and constraints. Normally, as part of this phase, you would present and discuss the SWOT analysis, the draft audit report and the key findings and recommendations with client management. Discuss the recommendations, and seek their outline agreement to the actions arising. It's important to give management some time and space to consider anything serious, particularly if they would have to juggle priorities and assign resources to this. You may need to meet senior managers individually to explain and discuss things further, and sometimes to consider alternative approaches (business managers generally know best how to implement improvements, but you should by now have established your credibility and hence have influence). Finalise the report, ideally including a firm action plan with dates and responsibilities for resolving the issues and even better something from management formally confirming that they accept the report and intend to carry out the recommendations. ssue the report to the appropriate people. It may help to create and circulate a brief executive summary (maximum 1 or 2 sides) for senior management but make the full report available to those who need the details. Decide whether and how to follow-up to ensure that the action plans are in fact completed properly, if this is audit's responsibility [it varies between organisations: in some, management is entirely responsible for completing recommended and agreed actions]. In others, management request audit's help to check for completion.] Follow-up and if necessary escalate any outstanding issues to (more) senior management. If appropriate, revisit the findings and risks to confirm if the issues raised are still of concern, and apply pressure through management to get the job done. Close the audit file. Prune out the irrelevant information, keeping relevant evidence, reports, feedback from management etc . and making notes for the next ISMS audit. Store the audit file securely as the contents are probably somewhat sensitive. For pure conformity assessments (such as ISO/IEC 27001 certification audits), the key risks and issues relate to non-conformity with mandatory requirements laid out in the standards of course, and ISO/IEC 27006-1 may help. For pure management systems audits, the focus is self-evidently on the management system and processes, which are driven by ISO/IEC 27001, and ISO/IEC 27007 may help. For more broadly-scoped ISMS internal audits, there may well be other more or equally important issues worth reviewing for the business ... like for example whether the information security controls are adequate in practice (see ISO/IEC TS 27008), and whether various obligations towards third parties (such as customers, partners, regulatory authorities or owners) are satisfied (e.g. is the ISMS a cost-effective use of corporate resources?). I work in Internal Audit Department. Do we have to perform ISMS internal audits as per clause 9? This is an opportunity for all those involved. Sit down with those in charge of the ISMS to talk about what they have done, what they anticipate you doing now, and how they see the relationship developing over time. As an independent function, you do not answer to the ISMS team and they cannot force you to provide information or do things for them in a certain way. However, as Internal Audit, you work for - or at least in conjunction with - the organisation's senior management and are presumably be expected to support the organisation's strategic aims. If the ISMS has management's full support [a not insignificant assumption - something your audit might want to establish!], it is reasonable for them to invite you to audit it thus fulfilling the requirements for ISMS internal audits. However, the manner in which you perform the audit, the way you plan and perform it, is really your domain. For example, you would need to develop the audit program, schedule the work, assign suitable auditors etc . How much advance notice and other information to give them is up to you, although in the interests of making the audit as effective as possible, I would try to work with them on this. Right now, they are probably quite sharply focused on conformity with ISO/IEC 27001 and are simply trying to fulfil the standard's requirement for internal ISMS audits, which you should read to understand. They may not appreciate your role in life, nor the value you can bring to the party. It sounds as if they are perhaps unfamiliar with the way you normally work, and probably have a naïve view of how you would approach the job (e.g . simplistic/crude conformity assessment or compliance auditing). They almost certainly presume that your audit would be entirely constrained within the scope of their ISMS whereas you would probably be interested in the wider picture, potentially including information security and information risk management issues elsewhere in the organisation. On a more positive note, it makes a pleasant change for auditors to be 'invited-in' by prospective auditees! This could be an ideal opportunity for Internal Audit to get to work on the ISMS and make positive recommendations for improving the organisation's information security controls, risk management, compliance/conformity and governance (at least within the scope of the ISMS for now), knowing that the implementation team and hopefully management has the incentive to address any issues quickly in order not to stall or preclude the certification. Personally, however, I would be cautious about being too ambitious with your audit at this stage since recommending major changes could be seen as derailing the ISMS project, while a softly-softly approach would leave the door open for further ISMS audits supporting their PDCA-based internal management review and improvement activities. With an effective ISMS in place, you can expect the information security situation to be more stable as it comes under better management control, and then to improve gradually of its own accord. You have a part to play in making this happen as effectively and efficiently as possible. In particular, your independent viewpoint gives you the advantage of making sure that the ISMS is not blind-sided by some unanticipated issue that the ISMS management team was unaware of, and the chance to promote generally accepted good risk/security management practices based on the standards or other sound sources. An ISMS is a long-term corporate commitment to professional information security management and that surely has to be a positive thing, both for audit and for the rest of the organisation. Consider ISMS auditor training with support from technology auditors. How to confirm the status of controls in the SoA? You might like to hold off the certification auditors for a few months after the ISMS is considered “implemented”, in order to build up your stock of evidence demonstrating that the processes are operating correctly, in addition to letting the processes settle down a bit. Your implementation project plans should therefore show a short hiatus between implementation and certification, supplementing the usual contingency allowance in case of implementation delays. Auditors should check that identified ISMS controls are truly in operation, not merely listed as such in some dusty old policy manual or intranet website. Evidence is key! For example, you need to have experienced at least one incident to confirm that the incident management process actually works in practice and is not just a fine set of words in your ISMS policies. This is analogous to the situation with ISO 9000 where the auditors typically check that genuine quality issues have been identified through quality reviews etc ., addressed following the stated QA processes and resolved, not just that you say you will deal with them in a certain way should they ever happen. Clearly, it is not reasonable to wait until there has been a total disaster to check that your contingency planning processes function correctly - there are pragmatic limits to this principle, thankfully! But you should probably have completed at least one contingency planning exercise or D isaster R ecovery test including the vital post-test washup to identify things that need fixing. For common information security controls that are in action all the time (e.g. antivirus, access controls, user authentication, security patching, backups), the auditors will want to check the evidence (they may call them “artefacts” or “records”) relating to and proving their operation. Remember, an ISMS is for life, not just for the certificate. How do we tell whether the 'control purposes' are achieved? This is primarily a risk management or business decision for the Information/Risk Owners who are accountable for protecting and exploiting 'their' information assets. Information security and risk management people can advise them, of course, but should avoid going beyond their brief and, in effect, accepting accountability for information security matters that rightfully belong to management. Achievement of the purposes or objectives of your security controls can be determined by management, by auditors or by others checking the controls to decide the extent to which the corresponding objectives are satisfied. HINT: such checks are tricky if the control purposes/objectives are unclear, general, ambiguous, uncertain, inadequately considered and specified, or totally unstated. Start there! Security incidents obviously suggest that the controls are less than perfect ... so one way to identify controls worth a close look is to rummage through your information security incident records and reports for evidence or hints about missing or ineffective controls. Make a special effort to tease out and re-evaluate longstanding issues. Don’t be hoodwinked into ignoring issues that “have always been a problem” or “will never be solved”: if they are in scope of the audit or review, they are almost certainly worth checking. An experienced, competent IT auditor’s unjaundiced eye and techniques for assessing and reporting on such issues might just unblock the drains and help the organisation achieve real progress. Control purposes that are unsatisfied are obvious candidates for security improvement, but the prioritisation or urgency or necessity of that work depends on the significance of the risk and the degree of nonconformity. For example, a control intended to minimise malware risks may require “up-to-date antivirus software running on all applicable systems”. The antivirus software used, the updating process, the range of systems to be protected, and the realities of implementing the control on a wide range of systems mean that some systems may not be fully protected right now for a variety of practical reasons, but so long as all the main/most important systems and a large proportion of the remainder are adequately protected, the organisation may (or may not) be willing to accept the residual risk. Management may even make a conscious risk management decision not to insist on full 100% implementation of antivirus if the costs of doing so on every single system outweigh the business benefits. Will certification auditors audit our security controls? Regardless of whether or not the certification auditors audit the controls, the organisation should still be checking its own information security controls routinely, typically through management reviews and internal audits. The certification auditors may therefore ask to see some evidence that you are routinely checking your controls, for example management review or internal audit reports, along with agreed action plans to address any improvement recommendations. To a limited extent, yes, but the primary purpose of the certification audit is to confirm whether you have an effective, conformant ISMS in operation, not whether you have secured the information. It’s a subtle but important difference. As Patrick Morrissey put it on the ISO27k Forum: “An ISO/IEC 27001 certificate does not mean that your organisation is secure. It states that your ISMS is working ” In principle, if you have an effective, fully conformant ISO/IEC 27001 ISMS in operation, then the ISMS (not the ISO27k standards, nor the auditors) will ensure that there are adequate security controls in place. This approach also means that strictly speaking you needn’t necessarily have a completely comprehensive suite of information security controls to pass the certification audit, just so long as your ISMS will ensure that it will improve in due course. The vital concern is that the organisation should have information security under management control and be proactively directing and controlling it. The certifications auditors may, however, want to undertake some substantive testing of the information security controls to confirm that you are in fact doing what you say you are doing, just as they may check that, for example, you have undertaken an information risk analysis and duly considered the risks in you specific context in order to specify your control requirements. In other words, they will seek evidence that the ISMS processes are operating correctly and in many cases that will involve confirming that certain security controls are operational. Will the certification auditor check our ISMS internal audit processes? How? Take it easy, don't fret! Like taking an examination, the audit should go smoothly if you have done your homework. Preparing your paperwork in advance of the auditor's visit will help you both. Sort out your ISMS policies, audit plans, audit files, audit methods, audit reports etc. - get them straight and be ready to offer relevant information promptly if/when the auditor asks for it. Being well organised and helpful makes the auditor’s job easier, reduces stress and increases confidence in how you conduct your internal audits. Assuming they represent an accredited certification body that has adopted ISO/IEC 27006 , the certification auditor/s will have been trained and will act professionally, diligently checking conformity with the ISO/IEC 27001 standard following a standardised audit process derived from the ISO/IEC auditing and certification standards. ISMS internal audits are a relatively small but quite important element of the ISMS in terms of continuous improvement and assurance, so you can expect the auditor to explore your internal audit practices a little, more or less depending on how much time they have and how much risk they consider is associated with the internal audits as compared to other aspects of the ISMS. A certification auditor’s prime objective is self-evidently to check your organisation’s conformity with the standard’s formal specifications, so at its most basic they will look at what ISO/IEC 27001 specifies for ISMS internal audits under clause 6 and ask you to demonstrate how you do it, using the evidence from past ISMS internal audits as proof. A good auditor will probe your ISMS audit plans, procedures and report/s, exploring aspects such as: How you audited: did you perform the audit in accordance with your own audit policy/standard/process? Are your ISMS internal auditors competent (what are their qualifications and experience at ISMS or other types of audit)? Are they truly independent of the areas being audited (independence is the critical distinction between audits in clause 9.3 of ISO/IEC 27001 and management reviews in 9.2)? What you audited: did the scope of the audit match that of the ISMS, or was it more limited in scope, in which case are you planning to fill in the gaps later? What you found : this will give the auditor clues about the state of your ISMS and may identify issues/concerns deserving further investigation; What was the outcome , in other words what did the audit achieve? Did all agreed audit recommendations (including corrective actions arising from non-conformities but possibly also more creative improvement suggestions) get fully actioned and signed-off on time and was your ISMS actually improved? More generally, how does management react and respond to audits? Do they take them seriously? Do ISMS internal audits add value to the organisation? Listen carefully to any summing up or findings or recommendations the auditor makes as there may well be some helpful suggestions about how to improve your ISMS, and if they are stated by an independent, competent external auditor, they tend to carry weight with management. Even if the final audit report officially says “No issues, fully conformant”, the auditor may raise minor concerns, snags or improvement suggestions informally. A good auditor will also compliment your organisation on certain aspects of its ISMS, and those kinds of comment make good security awareness materials. It's nice to be given a clean bill of health and to be certified, but a positive comment about something your organisation is doing well can really make someone's day! What if we dispute the findings or have issues with the auditors? Auditors and auditees are mere mortals. We all have our ‘off days’. Handling disputes sensitively can make a huge difference, for example by focusing on the factual evidence and explicit requirements from the standard rather than the personalities and subjective opinions, passions or prejudices of those involved. It’s perfectly reasonable to ask “Show me” - and that goes equally for both auditees and auditors (e.g. if an auditor is asking you for or to do something that you do not believe is required by the standard). Avoid highly emotive words such as “incompetent”. If it gets fraught, take a break. If all else fails, clients can choose different certification bodies, and certification bodies do not have to bid for every single sales opportunity ... Certification auditors hold almost all the cards in respect of certification audits. To a large extent, what they say goes since they can steadfastly refuse to issue a certificate if they believe your organisations does not satisfy a mandatory requirement. ISO/IEC 27001 certification auditors must audit strictly against the formal specifications in ISO/IEC 27001 (no more, no less). The accreditation process, plus the standards relating to audit processes and certification, are designed to ensure that that is exactly what happens. The whole certification scheme hinges on it. Any doubt that the certification auditors have followed proper procedures and audited strictly against the formal requirements could discredit the issued certificates and, by implication, all of ISO27k . Concerns about certification audits are an order of magnitude more serious than for internal audits, and two orders more than for internal management reviews or assessments. If a client has a genuine concern about a certification audit finding, recommendation, or auditor, they should first discuss it with the auditor and/or the assignment manager. Most things can be addressed at this informal level, with reference to the relevant standards, procedures and audit evidence. This happens fairly often in practice. Discussion and clarification of this nature is a normal part of any audit. Thankfully it is usually the end of the matter: although one or both parties may feel a little aggrieved, they normally reach “an understanding” - a delicate agreement or a truce at least - and move on. If the concern has not been resolved or cannot be taken further at the informal level (for example, the client believes the auditor is incompetent or misguided or plain wrong about something, but the auditor and/or the audit manager disagrees), they can complain formally to the audit company senior management about the situation and try to negotiate a mutually acceptable settlement. They should of course expect a robust response from the auditor and the company management (including the re-examination and re-presentation of the audit evidence and analysis), but if there is merit to the complaint, the audit company should have an internal process for dealing responsibly with it. It may be handled as a supplier-customer complaint, or as an audit issue, or a certification issue, or a legal issue (more below) or all of the above. This is quite rare but I'm quite sure it happens. I believe partners in audit partnerships are jointly liable for their work, so they will take complaints seriously if they are raised to that level, but the potential conflict of interest is obvious. If that complaint process fails - for example if the response is still unsatisfactory to the client, or if they feel they have not been treated professionally - they can potentially complain to the accreditation body that accredits the certification company. To get anywhere, the client would need to provide sound evidence concerning the dispute, essentially having to prove that the certification company and/or its auditors are not worthy of being accredited. The accreditation body should have a formal procedure for dealing with such complaints. I personally have never heard of such a case, but it's conceivable. The client can also complain to the professional bodies that certify and represent individual auditors - for example ISACA for CISAs. Again, they are likely to get a robust response from the professional body who will probably have a standard process to review the complaint, assessing evidence from both sides before siding with the auditors, their members (!). It would take very strong, hard evidence of professional misconduct or incompetence to persuade them to find against their members, coupled with a highly professional ethics or professional standards committee. I am aware of occasional complaints of this nature, but most probably never see the light of day. Vanishingly few cases go beyond a temporary suspension of the member concerned, but expulsion is the ultimate threat. At some point in this escalation, the dispute is likely to be handed to the lawyers, implying that they will look at the standards, contracts, policies, procedures and so forth with a strict legal eye, as well as assessing the evidence relating to the dispute. Any ambiguity in ISO/IEC 27001 that led to the dispute will be brought to the fore, with each side's auditors making their case. Ultimately, it may come down to the opinion of a judge in court. It would be an extremely serious matter if a dispute ever got to this stage, clearly, since losing accreditation would be a huge commercial setback to an audit or certification company, as well as a knock to the accreditation and auditor professional bodies (since it is implied that they should not have accredited or certified the auditors) and again to ISO27k as a whole. Can we demand that key suppliers are certified against ISO/IEC 27002? Study the standards! The answers are there! No, organisations can be assessed, audited or reviewed but not formally certified against ISO/IEC 27002 . One reason is that ISO/IEC 27002 lays out general good practice guidance rather than prescriptive requirements. Certification auditors would therefore have to apply their judgement and discretion when checking conformity with the standard, which is evidently beyond them. In truth, the variation that would arise in practice to reflect each organisation’s specific context and information security needs would detract from the value of a generic certification scheme. Context is all-important. An organisation can be reviewed informally or even audited against ISO/IEC 27002 by competent technology auditors, consultants or experienced information security professionals familiar with ISO27k : this is the “gap analysis” activity common to many ISMS implementations. Information security controls currently in operation in the organisation are compared against those recommended by ISO/IEC 27001 , looking for gaps that will probably have to be addressed at some point during the ISMS implementation project (if the missing controls are judged necessary to mitigate identified, evaluated and unacceptable information risks). ISO/IEC 27001 lays out a formal specification for an ISMS, with the emphasis very much on ‘management system’ rather than ‘information security’. The management system element of an ISMS is more easily specified in a generic yet formal way than the information security controls, and therefore ISO/IEC 27001 is the standard against which organisations are formally certified. This does however leave us with a problem: how can organisations place confidence in the actual information security controls of their business partners? Their ISO/IEC 27001 certificate only tells us that they have a working and compliant management system, and we assume that therefore they have assessed their information risks, implemented appropriate information security controls, and are proactively managing them ... well in fact that’s quite a lot of assurance when you think about it. Business partners can still opt to disclose more information about their actual information security controls, for example by sharing their information security policy manuals or by permitting third parties to audit their information security controls (perhaps using ISO/IEC TS 27008). How do we get an ISO27001 certificate? Establish contact with accredited certification auditors as soon as you like. They don’t bite and most will happily answer basic questions about the process if it leads to business for them and a smoother audit for both of you in the long run. First obtain and read the core standards: ISO/IEC 27000 combines a glossary and outline of the whole ISO27k series - useful for explaining to management; ISO/IEC 27001 , the ‘certification standard’, formally specifies the I nformation S ecurity M anagement S ystem; ISO/IEC 27002 offers a menu of information security controls from which to pick a hearty meal; ISO/IEC 27005 to order your meal, selecting controls according to your information risks. Next comes information risk analysis. Set the scene with management, then line up the relevant parts of the organisation and people to engage with the process. They should be reasonably open to the concept of improving their information security controls and you will probably have to engage suitable risk and security experts to make this process as painless and effective as possible. The risk analysis may be called a 'gap analysis' or 'ISO27k review' since it may make sense to compare your existing controls against the advice in the standard, looking for weaknesses and omissions as you go, or you may prefer to do a zero-base risk analysis, assuming that there are no controls in place. The advantage of the latter approach is that you might identify unnecessary controls that can perhaps be deinstalled later. By the way, 'the relevant parts of the organisation' relates to the scope of your intended certification. You have the option to certify the whole enterprise or specific parts. Scoping is a critical management decision. Work closely with senior management to clarify what is in and out of scope of the ISMS, with the important proviso that everything declared as out-of-scope is inherently untrusted from the perspective of the in-scope elements, therefore suitable security controls (both technical and non-technical e.g. contracts or SLAs) are probably needed for data flows, systems, networks, processes etc . that cross the scope boundary. Minimising the scope is not necessarily the easy option it may seem! Having completed the analysis, you face the challenge of persuading senior management to invest in information security, explaining the issues and risks that the analysis identified in terms they appreciate. This is a tricky balancing act: over-egg your dire predictions and they may back away saying you are being sensationalist. Underplay the security issues and they may not pay much attention to the need for improvements. It really helps to lean on someone with prior experience in this area. Management's appetite for addressing the issues you identify will determine the financing and priorities for the next step. If management say 'no' at this point, perhaps reconsider your career options. With management backing, you now implement the security improvements. Easier said than done! It could be a mere formality if your setup is already very security aware and competent in this area. It could be an extremely arduous job if you are starting from a low base, such as an organisation which has habitually underinvested in information security, has made strategic changes in its use of, and dependence on, IT (e.g. it has started using the Internet for business processes/transactions and communications, rather than simply for promotional websites), or where there are no clear accountabilities for information security. It is impossible for me - or indeed for you - to say how long or how costly this phase will be for you until you have completed the previous steps, and even then you can only estimate. With the improvements well under way and security gradually becoming an inherent part of business-as-usual, it's time to think forward towards ISO/IEC 27001 certification. Like other ISO management systems standards, ISO/IEC 27001 is process-focused - it specifies a 'management system' for information security comprising a suite of management processes. Certification involves contacting a suitable accredited certification body to review your I nformation S ecurity M anagement S ystem ... I'm sure there's more to it. What is really involved in being certified? Genuine management support is essential. It is futile to attempt an ISMS implementation without it. Time invested in explaining to managers what the ISMS is and more importantly how it benefits the organisation is time well spent. Listen hard to find out what managers really need from information security and pick up opportunities for strategic alignment. If the ISMS supports or enables key business objectives, it is less likely to be seen as an impediment to progress, and is harder for reluctant managers to resist. The main activities are as follows: Get management support - easier said than done! This typically involves raising management’s awareness of the costs and benefits of having an ISO/IEC 27001 compliant ISMS. A great way to start is to raise management’s awareness of some of the key current information risks and potential good practice controls (drawn from ISO/IEC 27002 ) that are not yet in place, perhaps through a “gap analysis” (an outline risk assessment and overview of the work needed to achieve conformity) followed by a business case and/or strategy for the security improvement (ISMS implementation) program. Define ISMS scope - what businesses, business units, departments and/or systems are going to be covered by your I nformation S ecurity M anagement S ystem Inventory your information assets - although not esential, a reasonable inventory or list of information systems, networks, databases, data items, documents etc . will be used in various ways e.g. to confirm that the ISMS scope is appropriate, identify business-critical and other especially valuable or vulnerable assets etc . Conduct an information risk assessment - ideally using a recognised formal method but a custom process may be acceptable if applied methodically. Prepare a S tatement o fA pplicability - according to ISO/IEC 27000 , the SoA is a “documented statement describing the control objectives [now known as purposes] and controls that are relevant and applicable to the organisation’s ISMS”. Which of the control purposes and controls from ISO/IEC 27002 are applicable to your ISMS, and which are irrelevant, not appropriate or otherwise not required? Document these management decisions in your SoA; and in parallel … Prepare a R isk T reatment P lan - ISO/IEC 27000 describes the RTP as “a plan that identifies the appropriate management actions, resources, responsibilities, timeliness and priorities for managing information security risks”. Develop ISMS implementation program - given the scale, it is generally appropriate to think in terms of an overall program of individual projects to implement various parts of ISO/IEC 27002 , for example one project for each of the main sections of the standard. Which resources can you call upon, direct, use, borrow or persuade to build or supplement your core ISMS implementation team? You will probably need experienced information security professionals (particularly a team leader) and support from related functions such as Internal Audit, Risk Management, Legal/compliance, HR, Finance and Marketing, not just IT. You are advised to plan the work in risk-priority-order where possible i.e. tackle the biggest risks early so that, whatever happens to your program of work in practice, it has had a good go at knocking down the main issues and can demonstrate real progress, even if it then falters for some reason. Also, early wins are a source of helpful positive feedback: this is an important aspect to the program which as to be seen to be effective by management, as well as actually being effective. If all the program does is interfere with business, annoy managers and cost a packet, it is hardly going to be on the shortlist of “things we really must keep doing next year”! Execute the ISMS implementation program - through the individual project plans, the implementation team sets to work to implement the controls identified in the RTP. Conventional program and project management practices are required here, meaning proper governance, planning, budgeting, progress reporting, project risk management and so forth. If the program is large, seek professional program management assistance. Operate the ISMS - as each project in the program fills in part of the ISMS, it hands over a suite of operational security management systems and processes, accompanied by a comprehensive set of policies, standards, procedures, guidelines etc . Operating the ISMS has to be an ongoing routine activity for the organisation: this is not a one-shot project! The Information Security Management function needs to be established, funded and directed, and many other changes are likely to be required throughout the organisation as information security becomes part of the routine. Collect ISMS operational artefacts - the ISMS comprises your framework of security policies, standards, procedures, guidelines etc ., and it routinely generates and uses security logs, log review reports, firewall configuration files, risk assessment reports etc . ... all of which need to be retained and managed. These artefacts are crucial evidence that the ISMS is operating correctly. You need to build up sufficient artefacts to prove to the auditors that the system is operating, stable and effective. Audit the ISMS - internal auditing of the ISMS will be a routine part of it. The idea is to have competent and independent reviewers (ideally trained and experienced IT auditors) take a good look at the ISMS, review the evidence (ISMS operational artefacts plus other documentation such as information security policies and procedures), consider that in relation to the risks and opportunities to the organisation, and make recommendations. Conformity with the formal requirements of ISO/IEC 27001 (see step 11) may be a major part of the audits but a competent internal audit function will generally be more interested in how well the ISMS meets the organisation’s requirements as a whole: gaining an ISO/IEC 27001 certificate is probably just one of several business reasons for implementing the ISMS and investing in information security management. Identifying and addressing the organisation’s information risks in a structured, systematic, comprehensive, prioritised and coherent manner is the bigger goal. Check conformity - are you actually doing what you said you were going to do? ISO/IEC 27002 covers conformity with internal requirements (corporate policies etc .) and compliance with mandatory obligations (such as laws and industry regulations). The ISMS itself needs to incorporate assurance activities generating reports and (often) incident reports and corrective actions. Undertake corrective actions - to improve the ISMS and address risks. The ‘management system’ part of the ISMS should result in continuous alignment between business requirements, information risks and capabilities for information security. As with quality management systems, the idea is to give management a means of controlling information security management processes systematically such that they can be continually monitored and improved, not least because perfect security is an unattainable goal in any real-world situation. Conduct a pre-certification assessment - when the ISMS has stabilised, an accredited certification body or other trusted, competent and independent advisor is invited by management to check whether the ISMS is functioning correctly. This is largely an assessment of the ISMS documentation and readiness to be audited fully. It is a golden opportunity for your organisation to identify and tie off any remaining loose ends before the actual certification audit. It’s also a low-stress way to get to know the auditors. Certification audit - an accredited body conducts a conformity assessment (certificaiton audit), checking that the ISMS complies fully with ISO/IEC 27001 . The auditors will check evidence such as the SoA, RTP, operational artefacts etc . and will attempt to confirm that the ISMS (a) is suitable and sufficient to meet the organisation’s information security requirements in theory i.e. it is correctly specified; and (b) actually meets the requirements in practice i.e . it is operating as specified. Party party - seriously, getting certified marks the end of the implementation phase, a substantial milestone for the team and the organisation so celebrate your success. You’ve earned it! More than that, your ISO/IEC 27001 certificate is a valuable asset. The organisation should be proud of what it has achieved, knowing of course that information security is never really “done” ... Operate the ISMS - it should be business as usual now. Other things to consider as your ISMS settles becomes routine and gradually matures include (1) taking a good look at the information risks and security arrangements in place elsewhere in your business network: are your suppliers, partners and customers also certified? Are they certifiable? Do they need your encouragement? (2) Using and maturing your security metrics to continue identifying and making improvements. (3) If you haven’t already done so, please join the ISO27k Forum to share your experience with others and participate in the global community. Annual surveillance audits – your certification auditors keep an eye on the ISMS to make sure the certificate remains valid and to remain familiar with it, leading to … 3-yearly full recertification – essentially another full certification audit (conformity assessment) takes place after 3 years. What does ISO 27001 certification involve? What happens? Who does what and when? Like exams, certification audits get more familiar if not easier with practice. Various reviews and assessments, ISMS internal audits and certification audits are all opportunities to learn about the process as well as sources of information about areas needing improvement. During and after the process, talk to managers and others involved in the process about how things are going, and share any good news. We’d love to hear how it went on the ISO27k Forum for instance! Treated sensibly, these are all valuable opportunities to confirm that your ISMS is and remains effective, and to pick up benchmarking tips from the consultants and auditors with experience of other organisations. The ISO/IEC 27001 conformity assessment and certification process is very similar to ISO 9001 and other ISO management systems. It is an external audit of the organisation’s ISMS (I nformation S ecurity M anagement S ystem) in three main phases: Pre-audit - having engaged an accredited certification body, they will request copies of your ISMS documentation (SoA, RTP, policy etc .) and may request a short on-site visit to introduce themselves and identify contacts for the next phase. When you are ready, the certification audit will be scheduled by mutual agreement - typically a few weeks later. Certification audit - this is the audit fieldwork. One or more auditors from the accredited certification body will come on site, work their way systematically through their audit checklists, checking things. They will check your ISMS policies, standards and procedures against the requirements identified in ISO/IEC 27001 , and also seek evidence that people follow the documentation in practice (i.e . the auditors’ favourite “Show me!”). They will gather and assess evidence including artefacts produced by the ISMS processes (such as records authorising certain users to have certain access rights to certain systems, or minutes of management meetings confirming approval of policies) or by directly observing ISMS processes in action, and by interviewing relevant people. Post-audit - having analysed and considered the findings, the results of the audit will be reported formally to management. Depending on how the audit went and the auditors’ standard audit processes, they will typically raise the following (in increasing order of severity): Observation or O pportunity F or I mprovement - these are niggles, minor concerns or potential future issues that management is well advised to consider; Minor N on-C onformity - these are more significant concerns that the organisation has to address at some point as a condition of the certificate being granted. The certification body is essentially saying that the organisation does not follow ISO/IEC 27001 in some way, but they do not consider that failing to be a significant weakness or flaw in the ISMS. The certification body may or may not make recommendations on how to fix them. They may or may not check formally that minor nonconformities are resolved, perhaps relying instead on self-reporting by the organisation. They may also be willing to agree a timescale for resolution that continues beyond the point of issue of the certificate, but either way they will almost certainly want to confirm that everything was resolved at the time of the next surveillance or certification audit; Major N on-C onformity - these are the show-stoppers, significant issues that mean the ISO/IEC 27001 certificate cannot be awarded until/unless they are resolved . The certification body may suggest how to resolve them and will require positive proof that such major issues have been fully resolved before granting the certificate. The audit fieldwork may even be suspended if a major NC is identified in order to give the organisation a chance to fix the issue before continuing. They will also issue your certificate of course, assuming you passed the test! Following the initial certification there are annual follow-ups (“surveillance audits” pr “C ontinual A ssessment V isits”). Conformity certificates are valid for three years so there is a full recertification every three years, with two smaller check-ups in between. There is more information about this in the ISO27k and other standards ... or you can simply ask the auditors, or Google, or turn to the ISO27k Forum ... We are already secure! Aren't our existing controls sufficient to be certified? Look for alignment between internally-driven information security requirements (particularly those that directly support business and risk management objectives) and those imposed by compliance obligations such as SOX, PCI-DSS, privacy laws etc. Unlikely ... unless your organisation already has a full suite of mature good practice information security controls, successfully mitigating all the in-scope information risks that need to be mitigated, supporting a conformant I nformation S ecurity M anagement S ystem: that's the key bit that gets certified. ISO/IEC 27001 formally specifies the 'management system' (a governance and management framework), while certification confirms that the organisation's ISMS satisfies the standard's requirements. The ISMS, in turn, handles the organisation's unique information security arrangements according to its particular information risks. The standard gives generic guidance in this area but management decides what security controls and other approaches are necessary. Therefore, pre-existing controls won’t be wasted but may need improvements (typically documentation concerning their design and operation). Additional controls may be appropriate to cover all applicable information risks. Identifying and initiating any necessary security improvements is an important step towards a self-sustaining ISMS. This continual security improvement or refinement will gradually become a routine part of your ISMS. Is ISO 27001 status binary: compliant vs. noncompliant? Experienced auditors know the standards well and see many organisations struggling with various aspects, so they can often spot issues and maybe even suggest solutions that the organisations themselves may fail to see. There are ‘degrees of compliance’ (or rather conformity) with ALL laws, rules, regulations and standards ... but not as far as the laws, rules, regs and standards themselves, and perhaps the authorities normally behind them, are concerned. ISO/IEC 27001 for instance is worded as if organisations absolutely must without any dispute or doubt fully comply with all the mandatory requirements concerning the management system . The intention was to leave no wiggle-room, no subjectivity. When certifying an organisation in practice, however, the certification auditors will accept all the management system elements or processes that fully conform with the standard, and will consider and discuss with management any aspects that are not quite so clearly or fully conformant, before making a decision as to whether or not to issue the certificate. More likely, they will specify what must be addressed (“major N on-C onformities”) and verified before they will issue the certificate, plus other things that should be addressed (“minor NCs ” and niggly “observations ” or "opportunities for improvement"). At the end of the day – which may be some weeks after the certification audit once they are satisfied that all major NCs are fixed - the certification auditors must decide whether the standard’s requirements are satisfied sufficiently to issue or renew a conformity certificate. It is natural to focus on whichever aspects of the standard are most challenging. The auditors may probe more deeply into those same areas if there are concerns, but occasionally organisations are tripped up by things that seem relatively straightforward: this is where the auditors’ independence, competence and empathy come into play. Who can certify us? Find your national accreditation body or bodies through the IAF . Contact an accreditation body for details of the CBs they have accredited that cover your part of the world. Almost anyone. You can even do it yourself! However, the certificate only has real meaning and value to third parties if it is issued by a recognised C ertification B ody (known as registrars etc . in some countries), which in practice means a CB that has been accredited by a recognised accreditation organisation. “Accredited” means their certification practices have been checked to ensure that the conformity assessment processes, and hence the certificates issued, are sound, legitimate, trustworthy and meaningful. If certificates were issued by anyone who felt like it, the certificates and potentially ISO27k as a whole would soon lose value and be discredited. The formality in the process builds and maintains confidence and trust. The accreditation process (i.e . checking that CBs are competent and suitable to assess clients against ISO/IEC 27001 ) is itself the subject of ISO/IEC 27006 and is run by the I nternational A ccreditation F orum – a global industry body independent of ISO and IEC. Aside from CBs, individual auditors may be accredited by bodies such as the I nternational R egister of C ertificated A uditors . They generally work for large consultancies or system integrators, though some are self-employed or work in small companies. How do we choose a certification body? Be sure the contract with your chosen CB incorporates a suitable nondisclosure, confidentiality or privacy clause. An ISMS CB can hardly object to you taking an interest in their information security arrangements ... and they might just give you credit for asking! Identifying potential CBs is straightforward using Google and checking who issued certificates to others in your industry or locale. Choosing a CB is much like selecting any service supplier, so you should follow your standard vendor selection, procurement and contracting practices. In short, figure out what you want (your criteria), review available service offerings on the market against the criteria, select the best fit and then make the purchase (negotiate and contract for their services). Criteria that may be important: Vendor quality or standing, in particular whether they are duly accredited (see below) and have a solid reputation with a track record of success in this niche; General vendor selection criteria such as their ethics, policies and practices for health and safety, equality, corporate responsibility, environment etc .; Technical competence, qualifications and experience of the ISMS auditors to be assigned to the job (does the CB specialise both in your industry and in ISO/IEC 27001? Are their auditors qualified, competent and experienced? If your organisation has adopted multiple ISO management systems, does the CB cover all of them, and would they be willing to conduct multi-standard audits in parallel?); Their working practices, procedures etc . (e.g . will they permit your ISMS internal auditors to shadow and support their auditors? Are they willing to be flexible on the timing if you are uncertain of being ready in time? How soon after the audit is successfully completed will they issue the certificate?); The quality, breadth and utility of their reports and other outputs (aside from the formal certificate, you may for example find value in the completed assessment checklists or improvement suggestions and advice from the CB auditors if they will share them with your management or ISMS internal auditors); Value for money (there’s more to this than price! Check the details of the services they offer, the pricing/charging terms, and the overall value promise); Availability e.g. timescales within which they can complete the job; Past performance e.g. in previous jobs for your organisation, credible customer references, or suggestions from industry peers, local contacts or other auditors and trusted advisors; Their information security and privacy arrangements; Other factors - develop your own unique criteria. Check the vendors’ marketing and sales collateral for differences in their proposed approaches, and consider the overall package on offer. The accreditation status of your chosen CB is important if you are expecting your ISO/IEC 27001 certificate to be credible to, and hence trusted by, third parties such as your suppliers and business partners. Third parties who plan to rely on the certificate normally insist on certificates issued by CBs that are independent, competent and trustworthy. In practice, this means the CB must have been properly accredited by trustworthy accreditation bodies such as the UK A ccreditation S ervice or others recognised by the I nternational A ccreditation F orum . To be accredited by recognised accreditation bodies, CBs are formally assessed or audited against applicable, internationally recognised standards regarding their competence, impartiality and capability. Accreditation reduces the possibility of selecting an incompetent CB, and substantially increases the value of the certificate. Oh and by the way, don’t forget to confirm their actual accreditation status with the accreditation body and check that the accreditation body is recognised by the IAF , as anyone may claim to have been accredited. It’s a jungle out there. ISO/IEC 17021 lays out the principles and requirements for the competence, consistency and impartiality of the audit and certification of management systems of all types (such as management systems for quality, environmental protection and information security), while ISO/IEC 27006 offers additional, more specific advice for ISMS CBs. Information security should be one of your CB selection criteria. It is not unreasonable to assume that ISMS auditors should have the professional knowledge and expertise to protect your sensitive information, but since they will be given privileged access to your organisation's ISMS (and perhaps to the facilities and other assets) you need to assess the information risks and treat them in the normal way. It’s up to your management to determine whether these risks are material in relation to the information risks associated with other suppliers, business partners, customers etc ., and various other business risks, and so whether and how to treat them. Legitimate, accredited ISO/IEC 27001 CBs are forbidden from auditing customers of their ISMS-related consultancy services in order to avoid the obvious conflict of interest. Your ISMS implementation consultants and advisors may, however, be able to help you find and select suitable CBs if you wish. 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 bugblattered 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.

Get in touch with the backstage crew of 1 - questions, improvement ideas and complaints are all as welcome as compliments and other feedback. What can I do for you? How can I help? Connect Something to say or ask about the ISO27k standards? Comments on the new-look website? Improvement ideas and requests? Go ahead! First name* Last name* Email* Write a message Submit