Search Results

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

Back Up Next ISO/IEC 27031 ISO/IEC 27031:2025 — Cybersecurity — Information and communication technology readiness for business continuity (second edition) Up Abstract “ISO/IEC 27031 provides guidance on ensuring that information and communication technology (ICT) is prepared to support business continuity. It outlines a framework for ICT readiness that aligns with broader business continuity objectives, helping organizations to prevent, respond to and recover from ICT-related disruptions that could impact critical operations. In today’s digital world, organizations rely heavily on ICT systems to operate, deliver services and maintain trust with stakeholders. Disruptions to these systems — from cyberattacks to system failures — can have severe consequences. ISO/IEC 27031 helps organizations build ICT resilience by integrating readiness planning into business continuity and information security practices. It ensures that ICT services can be restored within agreed timeframes, protecting operations, reputation and customer trust. This readiness is not only about internal systems but also extends to dependencies on third-party services such as cloud providers. Benefits: Supports uninterrupted business operations during ICT disruptions Strengthens alignment between ICT, security and continuity strategies Reduces recovery time and data loss after incidents Enhances organisational resilience and stakeholder confidence Integrates smoothly with ISO/IEC 27001 and ISO 22301 practices” [Source: ISO.org summary page ] Introduction ISO/IEC 27031 provides guidance on the concepts and principles behind the role of I nformation and C ommunication T echnology in ensuring business continuity. The standard: Suggests a structure or framework (a coherent set or suite of methods and processes) for any organisation – private, governmental, and non-governmental; Identifies and specifies all relevant aspects including performance criteria, design, and implementation details, for improving ICT readiness as part of the organisation’s ISMS, helping to ensure business continuity; Enables an organisation to measure its ICT continuity, security and hence readiness to survive a disaster in a consistent and recognized manner. Scope The standard encompasses all events and incidents (not just information security related) that could have an impact on ICT infrastructure and systems. It therefore extends the practices of information security incident handling and management, ICT readiness planning and services. I CT R eadiness for B usiness C ontinuity [a general term for the processes described in the standard] supports B usiness C ontinuity M anagement “by ensuring that the ICT services are as resilient as appropriate and can be recovered to pre-determined levels within timescales required and agreed by the organisation.” ICT readiness is important for business continuity because ICT is prevalent and vital: many organisations’ critical business processes (including those involved in managing incidents plus the related business continuity, disaster and emergency responses) are highly dependent on ICT. Therefore, BCM would be incomplete without adequately considering the need to protect availability and continuity of the ICT. ICT readiness encompasses: Preparing the organisation’s ICT (i.e. the IT infrastructure, operations and applications), plus the associated processes and people, against unforeseeable events that could change the risk environment and impact ICT and business continuity; Leveraging and streamlining resources among business continuity, disaster recovery, emergency response and ICT security incident response and management activities. ICT readiness should of course reduce the impact (meaning the extent, duration and/or consequences) of information security incidents on the organisation. The standard incorporates the cyclical P lan-D o-C heck-A ct Deming-style approach, extending the conventional business continuity planning process to take greater account of ICT. It incorporates ‘failure scenario assessment methods’ such as F ailure M ode and E ffects A nalysis, with a focus on identifying ‘triggering events’ that could precipitate more or less serious incidents. The SC 27 team responsible for ISO/IEC 27031 liaised with ISO Technical Committee 233 on business continuity, to ensure alignment and avoid overlap or conflict. Structure Main clauses: 6: Integration of IRBC into BCM 7: Business expectations for IRBC 8: Defining prerequisites for IRBC 9: Determining IRBC strategies 10: Determining the ICT continuity plan 11: Testing, exercise, and auditing 12: Final MBCO 13: Top management responsibilities regarding evaluating the IRBC Annex A: Comparing RTO and RPO to business objectives for ICT recovery Annex B: Risk reporting for FMEA Status The first edition was published in 2011 . The revision project ran into trouble and was cancelled in 2020, then rebooted. The standard was revised to cover the need for ICT support for business continuity arising from both deliberate and accidental incidents. The current second edition was published in 2025 . Commentary The value of this standard is unclear, given that ISO 22301 does such a good job in this general area while ISO/IEC 24762 covers ICT D isaster R ecovery specifically. This standard could usefully be extended beyond the ICT domain since: The ISO27k standards concern risk and security to information, not just “ICT” (a clumsy and unnecessary amplification of good old “IT” which in common usage has included comms for, oh at least 50 years); O perational T echnology (such as I ndustrial C ontrol S ystems running manufacturing plant, and assorted facilities management systems providing power, cooling etc .) is not mentioned, not even once - neither included nor excluded, just completely ignored; Information in forms or formats other than computer data can be just as important for business continuity, just as valuable and just as much at risk. For example, the loss of a critical knowledge worker, perhaps even an entire high-perfoming team of professionals, can devastate the operational capability of any department. Think September 11th, or COVID, or defection to/poaching by a competitor or startup. However, the standard remains entirely ICT-focused, tech-centric. Furthermore, to avoid any hint of overlap or conflict with the ISO 22300 -series standards, ISO/IEC 27031 does not replace a B usiness C ontinuity M anagement S ystem. That said, the standard orbits around “IRBC” (I CT R eadiness for B usiness C ontinuity) ... which is essentially a systematic way to manage the IT elements of business continuity, supplementing the BCMS as a whole. Although the issued standard mentions ICT resilience to - as well as recovery from - disastrous situations, the coverage on resilience (the ability for critical processes and systems to withstand as well as recover from serious incidents) is limited. It is similarly light on contingency . Contingency planning involves developing the organisation’s flexibility, capability, resources and dogged determination to cope with whatever situations actually eventuate, preparing for the uncertainties and challenges ahead. What will actually happen following an incident is contingent on the situation that occurs, its significance (reflecting its scale, nature, timing, implications for the business etc .) and the resources available (surviving!) at that point. The standard only refers once to ‘contingency’, as a convoluted and ineptly-phrased note to the definition of [ICT] readiness. Up Up Up This page last updated: 12 February 2026

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-conforming ISO/IEC 27001 ISMS in operation, then the ISMS (not the ISO27k standards, nor the auditors) should 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, depenging on the continual improvement elements of the ISMS to drive through the remaining controls. The vital concern is that, through the ISMS, the organisation should have information risk and security under management control, proactively directing and systematically improving it. The certifications auditors will 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. They will seek evidence that various ISMS processes are operating correctly as documented and in some cases that will involve confirming that specific security controls are, in fact, 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, full conformance”, 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, ask them which clause allegedly states the requirement and study it carefully). 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 the standard (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 substantially more significant than for internal audits, far more than for internal management reviews or informal 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 CISA-qualified auditors. 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 naturally 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. I've heard that auditors may insist that certain Annex A controls are 'necessary'. Is that so? For bonus marks, write-up this situation as a case study or example for use in your risk workshops and awareness materials concerning risk management, assurance, conformity/compliance, certification, incident management and governance. For extra kudos, tell the ISO27k Forum about your experience and any learning points worth sharing. It might be true, or it may be just an urban myth - possibly just a misunderstanding on the part of the auditor or auditee about particular concerns, or perhaps the result of an inept, incompetent or ignorant auditor failing to appreciate the true purpose of Annex A and the associated formal requirements in ISO/IEC 27001 . Anyway, if you honestly feel there is a risk of being pulled-up by the auditor for not adopting the Annex A controls, then analyse and treat it. It's just another information risk after all. You have at least a dozen risk treatment options: Studying the standard/s and fulfilling the formal requirements, avoiding the more serious risk of nonconformity; Choosing competent, well-trained and qualified auditors from a properly-accredited certification body, ideally one recommended by trustworthy colleagues, and checking their credentials; Explicitly contracting with them "to assess and certify conformity with the formal requirements of ISO/IEC 27001:2022" (using a form of words approved by your Procurement pros and lawyers); Actively managing the audit assignment and process (including the stage 1 pre-audit) such that the auditors are crystal clear from the outset about their conformity assessment role and your explicit requirements and expectations in that regard, as stated in the contract; Gathering evidence about the audit process, findings, concerns, issues, auditor statements etc ., providing factual materials to consider and address if there are issues (auditing the auditor!); Informing, readying/pre-warning and engaging your own management to help deal with any issues that may arise, perhaps seeking their advice if they have experience in this area; Raising an incident report - using your ISMS process - to deal with a dubious audit finding, nonconformity or other issue; Appealing/escalating/complaining to the certification body's management in case of disputes with incompetent, inept, ignorant or over-assertive/aggressive auditors; Appealing/escalating/complaining to the accreditation body if the certification body is incompetent and ; Complaining to the professional bodies who trained and certified incompetent auditors, including those responsible for any claimed qualifications (such as CISA from ISACA, or Lead Auditor courses from numerous training companies); Doing nothing - accepting the risk, winging-it, taking a chance to pursue the opportunity; Some combination of the above, or something else e.g . can you share the risk with the certification body by raising and discussing your concerns during the contracting process? The underlying message of those bullets is that you have choices. You should consider the risk, decide which risk treatment options you feel are most appropriate, and implement them. 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 practices - 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 some of 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 the organisation's identified, evaluated and unacceptable information risks). ISO/IEC 27001 lays out a formal specification for an Information Security Management System . The management system element of an ISMS is more easily specified in a generic yet formal way than the information security controls which differ substantially between organisations and industries and vary over time, 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 audits and certification 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 with an 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 is a catalogue of information security controls; ISO/IEC 27005 explains the process of managing 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 sufficient attention to the need for security 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. Hint: if management flatly declares 'No!' at this point, be sure your warnings, recommendations and funding requests are explicit and confirm their refusal (obtaining and retaining written evidence) and, aside from reviewing whatever you have said, 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 ISMS. A great way to start is to raise management’s awareness of some of the key current information risks and good practice controls (perhaps drawn from ISO/IEC 27002 ) that are not yet in place, 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 essential, 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, nominate their owners 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 f A 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 or two projects 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 should be retained and managed. These artefacts are crucial evidence that the ISMS is operating correctly. 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 technology 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 the next step) may be a major part of the audits but a competent tech auditor will generally be more interested in how well the ISMS meets the organisation’s business 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, for instance, post-incident reports and corrective actions arising. 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 (certification audit), checking that the ISMS fully satisfies the mandatory requirements in the main-body clauses of 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 and documented. 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 business 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, leading to … 3-yearly full recertification – essentially another 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 other ISO management systems such as ISO 9001. 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 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 conformity certificate cannot be issued until 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 issuing 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 assessment! Following the initial certification there are annual follow-ups (“surveillance audits” or “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 standards ... or you can simply ask the auditors, or Google, or turn to the ISO27k Forum ... 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 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 fully satisfy all the mandatory requirements for the management system . The intention was to leave no wiggle-room, no subjectivity, no doubt about it. 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 "O pportunities f or I mprovement"). 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 sufficiently satisfied 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 accreditation body through the IAF . Contact the accreditation body for details of the CBs they have accredited for ISO/IEC 27001 that cover your part/s 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 or scheme (i.e . checking that CBs are competent and suitable to assess clients against ISO/IEC 27001 ) is the subject of ISO/IEC 27006 . For more info, see the website for the I nternational A ccreditation F orum – a global industry body independent of both 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 locales. 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). Here are some criteria to consider: 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, at reduced cost?); 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 schedule and 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. 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. 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 TS 17021-1 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. Legitimate, duly-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

Back Up Next ISO/IEC 27561 ISO/IEC 27561:2024 — Information security, cybersecurity and privacy protection — Privacy operationalisation model and method for engineering (POMME) ( first edition) Up Abstract “This guidance document [ISO/IEC 27561] describes a model and method to operationalize the privacy principles specified in ISO/IEC 29100 into sets of controls and functional capabilities. The method is described as a process that builds upon ISO/IEC/IEEE 24774. [ISO/IEC 27561] is designed for use in conjunction with relevant privacy and security standards and guidance which impact privacy operationalization. It supports networked, interdependent applications and systems. [ISO/IEC 27561] is intended for engineers and other practitioners developing systems controlling or processing personally identifiable information.” [Source: ISO/IEC 27561:2024] Introduction The standard presents a systematic approach for engineering IT systems to satisfy privacy and personal data protection requirements, drawing on the 11 privacy principles expressed in ISO/IEC 29100 privacy framework plus ISO/IEC TR 27550 and ISO/IEC TR 27555 privacy engineering for system lifecycle processes. Scope The standard is intended to help ‘privacy engineers’ (or system architects or technical managers) interpret and satisfy the privacy requirements expressed in policies etc . plus those that emerge in the course of further analysis and development. It lays out a structured analytical method and model based on OASIS, emphasising functional architecture and practical implementation of privacy engineering. The process involves elaborating on privacy risks and designing controls, capabilities required plus the functions and mechanisms to deliver them. Structure Main clauses: 5: Context of privacy operationalization - background to the model and approach. 6: Initial information inventory process - an iterative personal information inventory process including determination of the domains, processes, systems and data flows. 7: Privacy controls, privacy control requirements, capabilities, risk assessment and iteration process - determination and documentation of the required controls, functions, mechanisms etc. 8: Privacy capabilities - essentially the governance arrangements for addressing privacy. Annex A: Mapping of the privacy principles from ISO/IEC 29100 to POMME capabilities. Annex B: Lifecycle process example involving a PII controller and a solution provider. Annex C: POMME capability functions and mechanisms in a consumer application use case. Status The current first edition was published in 2024 . Commentary Despite the contrived title and nasty neologism ‘operationalization’, the standard’s systematic, structured approach should prove useful for privacy specialists. Up Up Up This page last updated: 12 February 2026

Back Up Next ISO/IEC 27565 ISO/IEC 27565 :2026 — Information technology, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero knowledge proofs [First edition] Up Abstract ISO/IEC 27565 "provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing the risks associated with the sharing or transmission of personal data between organisations and users by minimizing information disclosure. It includes several ZKP functional requirements relevant to a range of different business use cases, then describes how different ZKP models can be used to meet those functional requirements securely.” [Source: ISO/IEC 27565:2026] Introduction Z ero K nowledge P roofs are mathematical techniques (families of cryptographic protocols) allowing someone (the prover) to prove to someone else (the verifier) that they are in possession of a secret, without actually disclosing the secret to the verifier or to some trusted third party. The secret is often a credential used for authentication (such as a password, biometric or personally identifiable information) but could equally be some other piece of sensitive/valuable information which is to remain confidential/private during the verification process, such as the person's age. The process involves the prover (who knows the secret) convincing the verifier (who needs to check it) that the verifier’s statement/s or assertion/s concerning the secret (e.g. “The person is older than 18 years”) are either true or false, without disclosing additional information (e.g. their birthday). At the same time, the process substantially prevents malicious interference such as replay attacks (e.g. repeating a previous age-verification sequence that applied to a different person) and collusion between the parties. Scope This standard principally concerns the use of ZKP for privacy protection (e.g . someone checking the claimed identity or age of a person known to an authority, without the authority having to disclose or reveal that personal information), although other use cases are noted (e.g . digital wallets). Examples in the annexes demonstrate the techniques in use. Structure Main clauses: 5: Introduction to zero-knowledge proofs* 6: Considerations of implementing ZKPs for attribute verification 7: Use cases of ZKPs 8: Privacy preservation using zero-knowledge proofs 9: Functional use cases 10: Business use examples Annex A: Factors facilitating or hindering ZKP developments Annex B: Subject binding Annex C: Example of a consistency check between two documents Annex D: Example of ZKP for selective disclosure Annex E: Examples of slective disclosure without using ZKPs Annex F: Example of secure comparison of two numbers Annex G: Implementing digital credentials with ZKP * Clause 5, the introduction, is included in the free sample/preview of this standard on the ISO.org website . Status The standard development project set out in 2021. The first edition was published in February 2026 . Commentary 27 specialist terms are defined in the standard - a clue as to the technical complexity of ZKP. This is a cutting-edge technique of value for privacy and other purposes. Up Up Up This page last updated: 16 February 2026

FAQ answers and pragmatic tips on implementing the ISO27k standards as a means to improve security, manage information risks, make the organisation more resilient .... oh and perhaps be certified if you like (it's optional). Previous Up Next Implementation How do we engage our management? Brainstorm with your team to come up with ideas along these lines, then select the few that you are actually going to pursue this month or next. Focus! Learn as you go! Start by raising management's awareness. Collaborate with internal contacts, especially in risk management, legal/compliance and IT departments, and demonstrate how the ISMS supports business strategies. Secure adequate resources by working with finance and understanding business priorities. Map management relationships to tailor communication and identify blockers. Engage your team, use metrics to show progress, and resolve existing security issues. Provide regular briefings and workshops, address audit findings, and expand the security awareness program to the rest of the organisation. Consider calling in external experts for events and consultation, but manage their engagements carefully to avoid becoming unduly dependent (a risk!). Should we aim for conformity, certification, compliance or what? Stopping short begs obvious questions: why don’t you have the certificate? What are you hiding? Yes! Implementation: indicates you are making progress … but how much? How much further to go? Why would you not go the whole hog i.e. certification of your ISMS? Conformity: presumably means using the ISO27k standards sensibly but, without assurance, that’s still just a claim, an assertion. Certification: formal certification by a properly-accredited conformity assessment and certification body verifies that the ISMS fulfils all the mandatory ISO/IEC 27001 requirements. Their accreditation gives the certificate meaning and value for others. Compliance: satisfying applicable mandatory legal, regulatory or contractual obligations is non-negotiable. The ISMS can help achieve that in specific areas but is not its prime focus. The key benefit of an ISMS arises through reducing the number and severity of security incidents, getting a grip on the organisation's information risks. Noncompliance with, say, privacy laws is the kind of business risk that management needs to tackle, head-on. How long will it take to implement ISO 27001? Check out the free implementation project estimator - a simple spreadsheet tool provided in the ISO27k Toolkit . The timeline varies greatly according to factors such as: Management support : senior and middle management buy-in is crucial. Start here or regret it later. Team expertise : experience and project management skills matter, particularly for the ISMS implementation project manager/team leader and their boss. Security maturity : affects both the starting point and the rate of progress. Is continual improvement a thing in your organisation, or just a dream? Risk profile : a community college faces markedly different challenges to a missile silo. Compliance and conformity : experiences and challenges make a difference. Cross-functional support : genuine collaboration and support from IT, HR, legal, operations and other departments can move things apace – or cause logjams if missing. Strategic alignment : how well does the ISMS fit business objectives and strategies? Obstacles : internal or external resistance or barriers will s l o w things down. Resource availability : funding, personnel, priorities, commitment and attention all matter. ISMS scope : is the implementation enterprise-wide or just a small part? Do we need a CISO? Competent, experienced, trustworthy information security professionals are hard to come by. A significant ISMS implementation is a fabulous learning and career development opportunity if only you can find someone suitable and willing to give it a go ... with oodles of support. Not necessarily a "C hief I nformation S ecurity O fficer" as such. Although ISO/IEC 27001 doesn't literally demand it, a manager or leader is indispensible if your ISMS is to achieve anything truly meaningful and valuable for the business, in a reasonable yet realistic timeframe. Here are the personal qualities, qualifications and experience ideally required: Personal integrity, high ethical standards, beyond reproach, entirely trustworthy; Clear passion and enthusiasm for information risk and security management; Professional technical/technological background e.g. IT, OT, engineering; Project and personnel management experience; Excellent communication and strong negotiation skills; Business management experience & expertise e.g. budgeting and financial management, planning and prioritising, spotting and responding appropriately to risks and opportunities; Technology audit skills, awareness or experience; Hands-on experience with an ISMS or similar structured approach, preferably at management level but operational experience is a start; Process- and quality-oriented, highly organised, structured and self-motivated - “driven” even; Pragmatic, adaptable, resilient and responds well to stress; Solid knowledge of the ISO27k standards , plus other standards, methods, laws, regulations etc .; Experience with training and awareness, security administration, security architecture, physical security, risk management, compliance, conformity etc. - more than cybersecurity! An SME may have little option but to settle for a part-timer, preferably a suitable manager but a contractor, consultant or fractional CISO may suffice, at least for now - especially if the assignment explicitly includes mentoring an insider to step into their shoes. To whom should our CISO/ISMS leader report? Working with HR, help senior management understand the issues, and negotiate the role, goals/objectives, seniority, reporting lines etc. to suit your organisational context. This is patently a corporate governance matter. They should preferably be part of the C-suite or executive team, at the highest level of management. Information security is a strategic, organisation-wide, business concern, not just a technology issue. Reporting to a lower-level function such as the Head of IT limits their scope, influence, independence and capability to manage the organisation's information risks. Senior management is accountable for sound risk management, including information risk and security management. Delegating this important task to too junior a level would be irresponsible. Must we involve the business or can we keep the ISMS within IT? Rather than deliberately restricting the ISMS scope, consider making it a “pilot implementation”. If successful, build on the pilot and the experience gained by expanding the scope wherever it makes the most sense for the business. ISO/IEC 27001 expressly concerns information security management. While IT/cyber security is essential, the ISO27k standards address risks to all forms of information including non-digital information assets such as: Business strategies and cunning plans, including those not even written down by management and perhaps vehemently denied if challenged by 'investigative journalists'; Trade secrets; Brands - not just the fancy logos, but the collection of characteristics that differentiate your organisation and its products from competitors; Physical information assets such as wills and contracts; Knowledge, understanding and expertise - whether consumed by voracious AI systems and robots or still in the brains of your remaining workers; Trust and trustworthiness - a broad yet invaluable and vulnerable asset; Business relationships, including historical interactions that enhanced or damaged trust; Corporate values, attitudes and culture - things that make your organisation an attractive employer, partner, supplier, customer, neighbour, a beacon of virtue. These are business assets that the business needs to both exploit and protect. Furthermore, aside from the challenge of securing technologies, implementing an ISMS is tricky due to: Complexity : information security incidents can affect everyone who uses, depends upon information or has an interest in its protection and exploitation. That includes business partners, customers and other stakeholders such as staff and managers, owners and regulatory authorities, using all manner of information in myriad ways; and Dynamics : ever-changing risks require agile responses. Serious incidents can blow up seemingly out of nowhere, dramatically changing the situation ... while we cannot afford to ignore more gradual, evolutionary changes such as ever-increasing automation. Whereas it is possible to narrow the ISMS scope, that reduces the benefits of an enterprise-wide ISMS and creates risk and security concerns at the scope boundary, meaning additional hidden costs e.g. incorporating explicit security requirements in Service Level Agreements and contracts, along with assurance measures. ISMS scope? What's that? How do we define it? Collaborate with business colleagues on this, particularly supportive senior managers. If you don't have any of those, yet, work on raising management's awareness and understanding first. Short answer: see ISO/IEC 27001 Clause 4.3 plus the rest of Clause 4. Scoping the ISMS appropriately is an important strategic decision for the organisation that should be made by senior managers. To help them decide, research and lay-out a strategy, business case or proposal: Explain the ISMS's business value (benefits less costs); Discuss the strategic objectives in busines terms; Address management's concerns about necessity, alternative approaches or options (including the do-nothing straw-man), resourcing, priorities and hidden benefits (e.g. assurance, compliance, efficiency); Consider aspects such as competitive advantage, implementation risks, required skills and resources, and the timeline (e.g . maturation through continual improvement over a number of years). Define the ISMS's boundaries (which parts of the organization are included or excluded) and applicability (what it protects, usually just 'information'), perhaps discussing, comparing and choosing between a set of scope options. Ideally, outline the costs and benefits over the entire lifecycle of the ISMS, several years at least, to enable their pros and cons to be assessed realistically. Must we risk assess all our information assets? From the conformity and business perspectives, it is perfectly acceptable to move ahead with an inventory that is “good enough for now” since the ISMS incorporates the review and update processes as part of continuous improvement. Aside from being largely pointless, it is literally impossible to risk-analyse everything in depth ... so consider instead a multi-phase process: Focus on the information assets clearly within scope of the ISMS. You defined the scope for a reason, and this is part of it. Undertake a broad but shallow (high-level) risk assessment to categorise your most valuable in-scope information assets (the crown jewels), distinguishing those that deserve more in-depth risk analysis from those that will be adequately covered by baseline or general information security controls; Conduct more detailed risk analysis on individual higher-risk assets or groups of related assets to tease out the specific security concerns and hence control requirements. Document 'everything important' including management's criteria and decisions about the categorisation. Avoid analysis paralysis by remembering that information is a fluid asset, continually in flux. Even if you were theoretically able to cover absolutely everything today, the position would be slightly different tomorrow and substantially different within a few weeks, months or years. Don't forget the variety of information assets worth protecting: some workers' business or technical knowledge and expertise, for instance, is invaluable, perhaps irreplaceable: isn't that a risk? 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, using an I nformation S ecurity M anagement S ystem as specified in ISO/IEC 27001 : 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 mandatory 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 mitigate all unacceptable 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 control [X] mandatory? Joking aside, this FAQ betrays a lack of understanding of the ISO27k way . Information security requirements are risk and context-dependent, hence the control requirements are determined by the organisation’s management examining its risks as best it can, determining its best options for dealing with whatever risks it identifies, and making investment decisions. Before this FAQ was published, this question was so frequent that, to save time and effort, we invite you to select one of the following answers: Yes, you need X because it is a basic security control that everyone needs. You'd be silly/negligent/risking the farm not to have it. No, X is not needed because we don't have it, therefore we consider it neither good practice nor best practice nor recommended. That depends - I'm a consultant with lots of letters after my name but you'd have to pay me $$$$ to answer your question. No, X is unnecessary because it is more costly than the incidents it prevents. Unless we are really unlucky anyway. Do ya feel lucky, punk? You tell me: have you assessed the information risks and identified a troubling risk that control X might mitigate? Have you decided that it would be better to implement X than some other risk treatment (avoid the risk, share the risk, accept the risk)? Is X the most cost-effective control in this situation? Does X adequately mitigate the risk and, ideally, others too yet without making the situation worse through additional complexity, procurement/management costs or whatever? Is X feasible? Yes because NIST/COBIT/SOX/NIS2/DORA/a little bird says so. Yes No Yes because it is “mandatory”, according to [name some authority figure here]. No because it is “optional” and/or was not explicitly listed in black and white as absolutely mandatory by [name some authority figure here too] Yes because it's the law [in country Y]. Only if your policies, plans, strategies, technical architecture, or internal standards say so. Yes if there is a positive R eturn O n S ecurity I nvestment, no if the ROSI is negative or if someone has seeded “reasonable doubt” or if there is something sexier on management's agenda this afternoon. Yes, absolutely - I am a vendor selling X. X is all you need. X is better than sliced bread. I'd sell both my kidneys to buy X ... Yes because we will get a bad audit report and/or grief from HQ if we do not have X. Yes because I've hears rumours that certification auditors expect or insist on it. Yes if X is one of several administrative, governance, management, process or assurance control requirements specified in the main body clauses. Aha! Yes if your management has determined that X is 'necessary', and you'll be sanctioned severely if you dare to countermand the edict, policy, instruction, demand or whatever it is. Not necessarily now but it will definitely be required in the future. Trust me. No because we cannot afford it at the moment. No because if you have it, then we have to have it too, else we will appear behind the times and that is BAD . Yes because we have it and you are Behind The Times. Do you even have to ask? Doh! OK OK enough already. While there may be an element of truth in all of them, the most correct, appropriate and sound answer is (arguably) #5. You will no doubt have spotted that it is the longest answer ... which poses a load more questions. The ISMS specified in ISO/IEC 27001 allows management to decide which information security controls are necessary for the organisation, based on their assessment of the information risks. If they have done the analysis, understood the risks and made a management decision, it is their right. However, any competent ISMS auditor would probably be concerned at the nature of the risk analysis that led to the decision to exclude commonplace controls, and would want to explore the documentation. The Annex A controls are confusing. Any advice? Unless you are a wizard, seek professional help with the ISMS implementation program management, planning and execution. Information security controls are not entirely self-evident and mistakes can be costly, terminal maybe. Do you have a project office? ISO/IEC 27002 expands on the succinct single-sentence control summaries in ISO/IEC 27001 Annex A with about a page of explanation and guidance per information security control. To be honest, even ISO/IEC 27002 leaves a lot unsaid, so to fill in the gaps we recommend asking Google, the ISO27k Forum , competent peers, perhaps even a trustworthy AI LLM (good luck finding one of those!). Consult specialists within or available to your organisation: most people are flattered simply to be asked their professional opinion. Furthermore, it pays to re-use (or at least check out) existing approaches, processes, tools, forms etc . where possible if information security is to become truly embedded in the corporate culture. Do we need all the Annex A controls? Take care when determining which information security controls are 'necessary' to mitigate unacceptable information risks in scope of the ISMS. As information security professionals, we tend to want to include and manage all the security controls, but management is likely to be most concerned about a smaller subset, implying a focus that can help prioritise whatever elements are most important to the business. Probably not. While demonstrable conformity with all the main body requirements of ISO/IEC 27001 (the bits concerning the management system) is mandatory for certification, the controls in annex A are discretionary. Organisations choose whichever of those security controls they deem relevant and necessary to mitigate their information risks. Additional or alternative controls may be appropriate, perhaps those from other standards, laws, regulations and good practices. It’s a flexible approach that caters for quite different organisations and risks. Strictly speaking, certification does not even depend on the organisation fully implementing all the security controls that it has selected, so long as the management system satisfies the requirements of ISO/IEC 27001 . It is presumed that a compliant ISMS will successfully ensure that the information risks are in hand and will be treated due course, and indeed this is in the organisation's interests, regardless of certification, since failing to do so implies a failure to mitigate unacceptable risks – a governance issue. However, ISO/IEC 27001 clause 4.4 prompts certification auditors to check that the ISMS is in fact operational, not merely a paper tiger. Do we need any Annex A controls? Remember: the primary purpose of implementing an ISMS is to support or enable achievement of business objectives relating to the protection and exploitation of valuable information. Conformity and certification are subsidiary concerns. Maybe not, depending on precisely what you mean by 'Annex A controls'. Various information security controls (such as backups) are almost universally applicable: it would be very unusual (but not inconceivable) for management to determine that backups are unnecessary ... but they may well decide that the precise control wording in ISO/IEC 27001 Annex A is not quite right. Control A.8.13 on "Information backup" says "Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. " It's reasonably obvious what that control wording is getting at but, studying it intently, word-by-word (like a lawyer, jobsworth auditor or anally-retentive infosec consultant), there are a number of concerns e.g .: 'Backup copies' is plural. A single backup copy may be adequate for some readily-replaced or recreated information. In fact, some information is ephemeral or of negligible value, with no need for backups at all. Control A.8.13, as literally worded, doesn't allow for such situations. 'Information' is an imprecise term. 'Software' is merely an example of a type of information, and 'systems' hints at computer systems and data, implying an IT or technology context ... but what about other forms of information, such as knowledge and intellectual property: must those also be backed up? What about information services and sources: do those need backups too? If so, how? What is the exact meaning of 'maintained' in control A.8.13? What about 'tested'? These are also imprecise, vague terms. Might a certification auditor doggedly insist on seeing details about backup testing, test reports etc . if this Annex A control is identified as necessary in the organisation's S tatement o f A pplicability? 'The agreed topic-specific policy on backup' begs further questions about what it means to 'agree' a policy, what 'topic-specific' means, plus the origin and content of such a policy. Yes, that's a peculiar and unhelpful take on a commonplace control but it illustrates the problem of describing information security in a generic standard, since so many details are context - or implementation - specific. Management might therefore decide to rewrite the control wording to suit the organisation's particular situation, perhaps restructuring and simplifying the control statement, elaborating on certain aspects (such as applicability) or clarifying it to allow for necessary variations in practice, replacing control A.8.13 with one or more 'custom controls'. Although not explicitly stated as such, this is perfectly acceptable, fully in accord with ISO/IEC 27001 Clause 8 and a perfectly reasonable, sensible, conformant interpretation of the standard. But why stop there? Management can legitimately determine that every Annex A control, as literally worded in the standard , is 'unnecessary', instead slecting a full set of custom controls that truly reflect the organisation's actual information risks and security requirements. That said, don't be surprised if certification auditors spot the lack of such commonplace controls as A.8.13 backups from the SoA and ask pointed questions about ensuring the availability of information! How can the ISMS Implementation Project Manager ensure success? Learn from other initiatives, both internal and external to your organisation and whether entirely successful or not. Seek out and adopt good ideas from all quarters. We can’t guarantee success but here are some trade secrets from the little black books typically maintained by experienced ISMS PMs: Become familiar with the business you serve. Get to know the department heads and the challenges they face. Try to see information risks and controls from their business perspectives, and look hard for situations in which strong, reliable information security is taken for granted or presents opportunities for new business activities that would otherwise be too risky. Cultivate business champions for information security in key areas, for example by talking to Sales people on how they win business and what would help them be more successful, asking the R&D boffins about the importance of keeping research secrets from commercial rivals, and checking how Finance department identifies and satisfies the accounting and tax obligations. Make friends with colleagues in related functions such as Risk Management, Legal/Compliance, Internal Audit, Site Security/Facilities and IT. Make time to explain to them how an ISMS will support what they do (which means exploring points of common interest), and garner their explicit support for the implementation project. Such people are often influential with senior management as well as their respective teams. Present ISO27k as a practical solution to current and future business problems rather than an academic set of controls. Solutions are more palatable than controls. Focus on the business outcomes of the ISMS rather than the ISMS itself. Continue to sell the ISMS as a solution to business needs and encourage other managers involved with security to adopt a similar business-focused attitude. Seek out and exploit strategic alignments. Remember that if the business is to adopt ISO27k and take on board a culture change, it should be perceived as empowering and enabling not restrictive and disabling. Tone down the technobabble and learn business-speak. Remember, IT is only part of the ISMS albeit an important one. Make a special effort to reach out to, inform and engage senior management up to board level: their understanding and support for the ISMS will facilitate the numerous changes necessary to business processes and systems as they are secured, and conversely their active or passive resistance will make your job much harder. Consider starting your management-level security awareness activities early in the ISMS implementation - even before your project is proposed and approved. Celebrate successes. Take every opportunity to write-up and share situations in which information security helps the organisation mitigate risks. Case studies and direct quotations from managers or staff who appreciate the value of the ISMS all help to spread the word: security is as much about saying “Yes!” as “No!” Oh boy! Isn't there just a simple checklist? There are about a dozen published security guidelines, advisories or standards for S mall to M edium-sized E nterprises, offering simplified guidance and, often, checklists ... but even they need to be interpreted and applied sensibly for any given SME. Read the Adaptive SME Security paper in the ISO27k Toolkit for more. Not really, at least not within ISO27k . It's just not that easy. Protecting valuable information is a complex challenge with many factors to address e.g .: Numerous possible threats, vulnerabilities and impacts; A large number and variety of information assets to protect; Questions about the meaning of 'protection' e.g. to what extent? How much assurance is appropriate? Who actually determines what protection is needed anyway, and how? Finite resources and other priorities and objectives, aside from infosec; Dynamics: nothing stays still for long in this field. An effective ISO/IEC 27001 ISMS using a comprehensive suite of controls drawn from Annex A, ISO/IEC 27002 and other sources or security standards such as NIST SP 800-53 , should satisfy and in fact exceed conformity expectations or compliance obligations, while simultaneously generating additional business benefits by satisfying the organisation's specific business requirements. So, wise up! Take a step back to consider the broader business context within which information security exists, and the myriad issues at stake. Think about the practicalities of attempting to identify and protect all your information assets against all significant security risks. If you examine the costs and benefits honestly, investing in an ISO/IEC 27001 ISMS or a similar 'framework' is an effective way to deal with this. You can limit the effort by deliberately restricting the scope, reducing the problem space somewhat. That may give you the chance to establish and gain experience with the management system ... but it also limits the potential benefits and is not necessarily the best long-term solution. You can also be smart about designing and implementing the ISMS to align closely with and support business objectives, especially concerning the organisation's information risks. Previous Up Next

Back Up Next ISO/IEC 27036-2 ISO/IEC 27036-2:2022 — Cybersecurity — Supplier relationships — Part 2: Requirements (second edition) Up Abstract ISO/IEC 27036 part 2 “specifies fundamental information security requirements for defining, implementing, operating, monitoring, reviewing, maintaining and improving supplier and acquirer relationships. These requirements cover any procurement and supply of products and services, such as manufacturing or assembly, business process procurement, software and hardware components, knowledge process procurement, build-operate-transfer and cloud computing services ... To meet the requirements, it is expected that an organization has internally implemented a number of foundational processes or is actively planning to do so [such as] business management, risk management, operational and human resources management, and information security.” [Source: ISO/IEC 27036-2:2022 ] Introduction The controls recommended in part 2 cover various aspects of governance and business management (e.g. operations, HR management, IT management, relationship management, metrics) as well as information risk management (e.g. information risk analysis and treatment, security controls specification, security architecture/design, strategy). Scope Part 2 specifies fundamental information security requirements pertaining to business relationships between suppliers and acquirers of various products (goods and services). It helps them reach a common understanding of the associated information risks, and treat them accordingly to their mutual satisfaction. The introduction explicitly states that part 2 is not for certification despite having “Requirements” in the title and “shall” in the content [these are normally reserved words in ISO-land]. Structure Main clauses: 6: Information security in supplier relationship management 7: Information security in a supplier relationship instance Annex A: Correspondence between ISO/IEC/IEEE 15288 and this document Annex B: Correspondence between ISO/IEC 27002 controls and this document Annex C: Objectives from Clauses 6 and 7 Status The first edition of part 2 was published in 2014 . Following changes in ISO/IEC 15288 , the current second edition was published in 2022 . Commentary Although this is not intended to be a certifiable standard with formally-specified requirements that are mandatory for certification, wording along the lines of “The following minimum activities shall be executed by the acquirer to meet the objective defined at [a specific clause] ” leaves little latitude for organisations to interpret, adapt and apply the standard according to their particular business situations and needs, despite an explanatory note: ”The user of [ISO/IEC 27036-2] needs to correctly interpret each of the forms of the expression of provisions (e.g. “shall”, “shall not”, should” and “should not”) as being either requirements to be satisfied or recommendations where there is a certain freedom of choice.” It comes down to the business and legal arrangements in place between supplier and acquirer as to how much ‘freedom of choice’ there is in interpreting and applying this standard. In the absence of explicit, perfectly worded, unambiguous and binding contractual clauses, lawyers smile wryly and rub their hands together, their cartoon eyes rolling like an old fashioned cash register ... Up Up Up This page last updated: 22 February 2026

Back Up Next ISO/IEC 27504 ISO/IEC 27504 — Privacy protection of user avatar and system avatar interactions in the metaverse [DRAFT] Up Abstract ISO/IEC 27504 "provides requirements for protecting personally identifiable information(PII) during interactions between user avatars and system avatars in the metaverse. This document identifies and classifies the PII generated and used by user avatars and system avatars and addresses privacy threats in the spaces where the respective avatar operates during the interactions between the user avatar and the system avatar." Source: ISO.org page on the W orking D raft Introduction ?? Scope ISO/IEC JTC 1/SC 27/WG 5 intends to offer guidance on addressing the privacy challenges associated with the metaverse as people increasingly engage with virtual worlds through personal avatars projecting various aspects of their personality. Structure ?? Status The standard development project commenced in 2025. Publication is planned for 2028. It is currently at W orking D raft stage. Commentary This is an innovative, forward-looking proposal to prepare privacy guidance at this early, formative stage in the lifecycle of the metaverse. There’s an opportunity to explore and address the privacy implications as an integral and supportive part of the ongoing developments in the field, from the outset, hopefully avoiding the difficulties and costs of having to retro-fit privacy controls to already-established norms later on. Up Up Up This page last updated: 2 April 2026