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 TS 27100 ISO/IEC TS 27100:2020 — Information technology — Cybersecurity — Overview and concepts (first edition) Up Abstract ISO/IEC TS 27100 "provides an overview of cybersecurity. [It]: describes cybersecurity and relevant concepts, including how it is related to and different from information security; establishes the context of cybersecurity; does not cover all terms and definitions applicable to cybersecurity; and does not limit other standards in defining new cybersecurity-related terms for use.” [Source: ISO/IEC TS 27100:2020] Introduction According to this T echnical S pecification: “[ISO/IEC TS 27100] defines cybersecurity, establishes its context, and describes relevant concepts, including how cybersecurity is related to and different from information security. Cybersecurity concerns managing information security risks when information is in digital form in computers, storage and networks. Many of the information security controls, methods, and techniques can be applied to manage cyber risks.” Scope Overview of cybersecurity: the standard explains various terms and concepts relating to cyber security and cyber risk management, contrasting them against information risk and security management. "Cybersecurity is a broad term used differently through the world ... Cybersecurity focuses on the risks in cyberspace, an interconnected digital environment that can extend across organizational boundaries, and in which entities share information, interact digitally and have responsibility to respond to cybersecurity incidents." [Source: ISO/IEC TS 27100:2020] Structure Main clauses: 4: Concepts 5: Relationship between cybersecurity and relevant concepts 6: Risk management approach in the context of cybersecurity 7: Cyber threats 8: Incident management in cybersecurity Annex A: A layered model representing cyberspace Status The current first edition of this T echnical S pecification was published in 2020 and confirmed unchanged in 2024. Commentary See ISO/IEC 27032 . It seems to me two ‘cyber’ worlds coexist on parallel planes: Critical national infrastructure: within the realm of government and defence, a significant concern is to protect the nation’s water, power, comms, financial systems, food supplies etc. from substantial attacks by highly capable and determined foreign powers, terrorists or whatever through the Internet. Scary stuff! Those nations that are actively developing offensive capabilities in this area have a vested interest in other nations not developing their defensive capabilities ... hence I suspect some may be deliberately spreading confusion and frustrating attempts to bring clarity to this area among potential targets (through this international standard, for instance). It could be a delaying tactic. However, I may be a semi-paranoid conspiracy theorist. Plain old IT security, network security and Internet security in particular : protecting digital data in general against deliberate attacks. This is the everyday world, a subset of information security in fact. Move along please, nothing much to see here. Rather than clarifying the concepts and terminology, advancing the field, the standard muddies the waters - possibly the desired outcome of #1 above. Thankfully, it is just 17 pages and I suspect is destined to become a little-known cul de sac off the information superhighway, despite the project team’s desire for ISO to promote it as a substantial contribution. They claimed “cybersecurity is simply an evolution of information security” and that the standard “provides much needed explanation in the environment of general confusion about the differences and similarities between cybersecurity and information security”: ‘in the environment of general confusion’ is a curious way of putting it. Ironic, that, for a standard that was meant to clarify things ... Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27010 ISO/IEC 27010:2015 — Information technology — Security techniques — Information security management for inter-sector and inter-organisational communications (second edition) Up Abstract "ISO/IEC 27010:2015 provides guidelines in addition to the guidance given in the ISO/IEC 27000 family of standards for implementing information security management within information sharing communities. This International Standard provides controls and guidance specifically relating to initiating, implementing, maintaining, and improving information security in inter-organizational and inter-sector communications. It provides guidelines and general principles on how the specified requirements can be met using established messaging and other technical methods. This International Standard is applicable to all forms of exchange and sharing of sensitive information, both public and private, nationally and internationally, within the same industry or market sector or between sectors. In particular, it may be applicable to information exchanges and sharing relating to the provision, maintenance and protection of an organization's or nation state's critical infrastructure. It is designed to support the creation of trust when exchanging and sharing sensitive information, thereby encouraging the international growth of information sharing communities." [Source: ISO.com page about ISO/IEC 27010] Introduction ISO/IEC 27010 provides guidance on sharing information about information risks, security controls, issues and/or incidents between industry sectors and/or nations, particularly those affecting critical infrastructure . Sometimes it is necessary to share confidential information regarding information-related threats, vulnerabilities and/or incidents between or within a community of organisations. For example, when private companies, governments, law enforcement and CERTs collaborate on the investigation, assessment and resolution of serious pan-organisational and often international cyberattacks. Since such information is often highly sensitive, it typically needs to be restricted to certain individuals within specified recipient organisations. Information sources may need to be kept anonymous. Such information exchanges typically happen in a highly charged and stressful atmosphere under intense time pressures - hardly the most conducive environment for establishing trusted working relationships and agreeing on suitable information security controls. The standard lays out common ground-rules for information security within communities of interest. The standard provides guidance on methods, models, processes, policies, controls, protocols and other mechanisms for the sharing of information securely with trusted counterparties on the understanding that important information security principles will be respected. Scope ISO/IEC 27010 provides guidance on information security interworking and communications between industries in the same sectors, in different industry sectors and with governments. It applies both in times of crisis affecting critical infrastructure and under normal business circumstances to meet legal, regulatory and contractual obligations. The standard has the style of a 'sector-specific' elaboration on or augmenting ISO/IEC 27002, recommending a few additional/modified information security controls to protect information risk and security information shared within communities of interest. Structure Main clauses: 4: Concepts and justification 5: Information security policies 6: Organization of information security (no additional guidance beyond ISO/IEC 27002:2013) 7: Human resources security 8: Asset management 9: Access control (no additional guidance) 10: Cryptography 11: Physical and environmental security (no additional guidance) 12: Operations security 13: Communications security 14: Systems acquisition, development and maintenance (no additional guidance) 15: Supplier relationships 16: Information security incident management 17: Information security aspects of business continuity management 18: Compliance Annex A: Sharing sensitive information Annex B: Establishing trust in information exchanges Annex C: The traffic light protocol - based on ENISA's red, amber, green and white levels Annex D: Models for organizing an information sharing community - TICE and WARP The standard reflects the structure of ISO/IEC 27002:2013, pre-dating the restructuring of controls into 4 'themes' for the 2022 edition. Status The first edition was published in 2012 . The current second edition was published in 2015 and confirmed unchanged in 2021. Commentary While the actual information risks arising from the sharing of information concerning information security incidents etc . between disparate organisations will of course depend on the specifics of the particular situation at hand (e.g. the nature of the incidents, the protagonists, the victims and the organisations involved), the following generic list of potential information risks and security issues in this area exemplifies the broad range of matters that may need to be taken into account in practice: Addressing information security aspects of the process (e.g . writing and implementing policies and procedures along with training and awareness activities for those involved in the process, and conceivably independent assessment or audits to confirm that the arrangements conform to ISO/IEC 27010 and/or other applicable ISO27k standards such as ISO/IEC 27001 , ISO/IEC 27002 and ISO/IEC 27005 ); Disclosing initial information and knowledge about the situation at hand prior to formalizing the arrangements, in order to prompt the recipient/s to consider their role and for disclosing parties to consider the risks involved in disclosing further information; Building trusted relationships between the organisations directly concerned, communicating and collaborating; Trust relationships with other organisations that may also be involved (e.g . if communications are routed through some sort of agency) or are somehow drawn-in to the situation, including business partners and those that may have to be informed or engaged in the process as a statutory or other duty; Determining and declaring or defining specific information security requirements (implies some form of information risk analysis by the disclosing parties for sure, and perhaps by the receiving parties); Communicating information risks and security control requirements, obligations, expectations or liabilities unambiguously (e.g . using a mutually-understood lexicon of terms based on ISO27k, and comparable information classifications); Assessing and accepting security risks and obligations (e.g . in some form of contract or agreement, whose existence and contents may also be confidential); Communicating information securely (e.g. using suitable cryptographic controls), preventing it from being sent to the wrong counterparties, intercepted, deleted, spoofed, duplicated, repudiated, damaged, modified or otherwise called into doubt deliberately by some third party or through inadequate controls and errors; Version controls and appropriate authorization for both disclosure and acceptance of valuable information; Risks and controls relating to the collection, analysis, ownership, protection and onward disclosure of information regarding the situation at hand by the recipient parties engaged in an investigation (e.g. limitations on using the information for purposes not directly associated with the incident at hand); Adequately protecting the information and perhaps others assets entrusted to the recipient organisations and individuals; Compliance and where appropriate enforcement activities such as imposition of penalties etc . if promises are broken, trust is misplaced or accidents happen; Unacceptable delays or other constraints on the communication of important information due to the risk assessment, security and related activities; The possible effects on collection, handling, storage, analysis and presentation of forensic evidence; Any limitations on post-incident disclosures such as incident management reporting, public press-releases, legal action etc .; Systematic process improvement, leading to greater mutual trust and stronger security arrangements for future situations. The published standard doesn’t cover these aspects explicitly, unfortunately. I feel it would have been more comprehensive and valuable if it had. Up Up Up This page last updated: 19 August 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 27050-1 ISO/IEC 27050-1:2019 — Information technology — Security techniques — Electronic discovery — Part 1: Overview and concepts (second edition) Up Abstract “Electronic discovery is the process of discovering pertinent Electronically Stored Information (ESI) or data by one or more parties involved in an investigation or litigation, or similar proceeding. [ISO/IEC 27050-1] provides an overview of electronic discovery ...” [Source: ISO/IEC 27050-1:2019 ] Introduction The fundamental purpose of the ISO27k digital forensics standards is to promote good practice methods and processes for forensic capture and investigation of digital evidence. While individual investigators, organisations and jurisdictions may well retain certain methods, processes and controls in compliance with local laws, regulations and established practices, it is hoped that standardization will (eventually) lead to the adoption of similar if not identical approaches internationally, making it easier to compare, combine and contrast the results of such investigations even when performed by different people or organisations and potentially across different jurisdictions. Scope Part 1 gives an overview of eDiscovery, defines the terms, concepts, processes etc . (such as E lectronically S tored I nformation), and introduces this multi-part standard. Structure Main clauses: 5: Overall structure and overview of the ISO/IEC 27050 series 6: Overview of electronic discovery 7: E lectronically S tored I nformation (ESI ) 8: Electronic discovery process 9: Additional considerations Status The first edition was published in 2016 . The current second edition was published in 2019 . Commentary This multi-part standard concerns the discovery phase, specifically the discovery of E lectronically S tored I nformation, a legal term-of-art meaning (in essence) forensic evidence in the form of digital data. Electronic discovery (eDiscovery) involves the following main steps: Identification: ESI that is potentially relevant to a case is identified, along with its locations, custodians, sizes/volumes etc. This can be more complex than it may appear, for instance involving information assets belonging not just to the individual suspects but also their employers, friends and other organisations such as phone companies and the suppliers of services such as email and Internet access (ISPs), even social media. Operational/online data, backups and archives may all contain relevant data. Often, this phase is time-critical since potential evidence (especially ephemeral operational data) may be spoiled or destroyed before it has been captured and preserved; Preservation: the identified, potentially relevant ESI is placed under a legal hold, starting the formalized forensic process designed to ensure, beyond doubt, that they are protected through the remaining steps against threats such as loss/theft, accidental damage, deliberate interference/manipulation and replacement/substitution, any of which might spoil, discredit and devalue the data, perhaps resulting in the ESI being ruled inadmissible or simply becoming unusable. The legal hold is essentially a formal obligation on the custodian not to interfere with or delete the ESI. Note: this may have implications on live systems since their continued operation may spoil the ESI; Collection: the ESI is collected from the original custodian, typically by physically removing the original digital storage media (hard drives, memory sticks and cards, CDs, DVDs, whatever) and perhaps associated physical evidence (such as devices, media storage cases, envelopes etc . that might have fingerprints or DNA evidence linking a suspect to the crime) into safe custody. In the case of Internet, cloud or other dispersed and ephemeral data including RAM on a running system, it may be impracticable or impossible to secure the data by capturing physical media, hence the data rather than the media may need to be captured directly in a forensically sound manner. Note: the original evidence may later be produced in court hence all subsequent forensic analysis must be performed in such a way that there is no credible possibility that it might have been spoiled e.g. by analysing bit-copies made with suitable forensic tools and methods rather than the original evidence itself. Note also that physically removing systems and media into the custody of a third party could itself be classed as an information security incident with clear implications on the confidentiality, integrity and availability of the information, particularly since, at this stage, the case is not proven: in other words, liabilities may be accumulating; Processing: forensic bit-copies are stored in a form that allows them to be searched or analysed for information that is relevant to the case, using suitable forensic tools and platforms. Sifting out the few vital bits of data from a much larger volume typically collected is the crux of this step; Review: forensic bit-copies are searched or analysed for information that is relevant to the case; Analysis: the information is further analysed and assessed as to its relevance, suitability, weight, meaning, implications etc. Useful information is gleaned from the selected data; Production: relevant information from the analysis, plus the original storage media etc. , is formally presented to the court as evidence. This inevitably involves demonstrating and explaining the meaning of the evidence in terms that make sense to the court. Hopefully, something along the lines of “I state, under oath, that we complied fully with ISO/IEC 27050” will, in future, side-step a raft of challenges concerning the eDiscovery processes! Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27566-2 ISO/IEC 27566-2 — Information security, cybersecurity and privacy protection — Age assurance systems — Part 2: Technical approaches and guidance for implementation [Draft] Up Abstract ISO/IEC 27566 part 2 "describes different technical approaches suitable in different ecosystems for age assurance systems and guidance for their implementation.” [Source: Draft] Introduction ISO/IEC 27566 part 2 "provides technical guidance for implementing age assurance systems in a consistent and modular manner. It supports the practical application of the framework defined in Part 1 by identifying technical components, implementation approaches, and context-specific trade-offs. This enables privacy-respecting, effective, and policy-aligned age assurance across diverse digital and physical environments." [Source: P reliminary W ork I tem] Part 2 bridges the foundational concepts from part 1 to the analytical approaches in part 3 . Scope ISO/IEC 27655 part 2 “ includes guidance for considering the characteristics of various approaches and for making trade-offs when selecting approaches for different users, actors and use cases. The document describes different technical approaches suitable in different ecosystems for the implementation of age assurance systems or of age assurance components” [Source: P reliminary W ork I tem] Structure Main clauses [from the initial draft]: 5: Principles carried forward from part 1 6: Relating context of use to implementation choices 7: Major contexts of use 8: Selecting components 9: Specifying requirements for procurement 10: Documenting operational practice statements and evidence Annex A: Commonalities of age assurance methods and interaction models Annex B: Common concerns related to common sub-contexts of use Annex C: Enrolment , user account management, and wallet management Annex D: Relationship to part 3 Annex E: Examples of trade-off choices during design of age assurance systems Annex F: Examples of practice statements Status The PWI was approved in February 2025. Part 2 is at W orking D raft stage. Commentary 'Context of use' refers - I think - to the particular business situation in which some form of age assurance is needed. SInce these vary, the standard explains how to identify, determine and evaluate relevant requirements and parameters driving the design of the age assurance approach e.g. how important is assurance to verify a person's true age? It then offers guidance on how to go about satisfying the requirements by selecting and implementing appropriate age assurance methods and technologies. Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27033-5 ISO/IEC 27033-5:2013 Information technology — Security techniques — Network security — Part 5: Securing communications across networks using Virtual Private Networks (VPNs) (first edition) Up Abstract ISO/IEC 27033 part 5 “gives guidelines for the selection, implementation, and monitoring of the technical controls necessary to provide network security using Virtual Private Network (VPN) connections to interconnect networks and connect remote users to networks.” [Source: ISO/IEC 27033-5:2013] Introduction ISO/IEC 27033-5 revised ISO/IEC 18028 part 5. It extends the IT security management guidelines of ISO/IEC TR 13335 by detailing the specific operations and mechanisms needed to implement network security safeguards and controls in a wider range of network environments, providing a bridge between general IT security management issues and network security technical implementations. It provides guidance for securing remote access over public networks. Scope The standard guides network administrators and technicians who plan to make use of this kind of connection, or who already have it in use and need advice on how to set it up securely and operate it securely. Structure Main clauses: 6: Overview 7: Security threats 8: Security requirements 9: Security controls 10: Design techniques 11: Guidelines for product selection Status ISO/IEC 27033-5 revised and replaced ISO/IEC 18028-5 . The current first edition of part 5 was published in 2013 and confirmed unchanged in 2019 and again in 2025. Commentary Gives a high-level, incomplete assessment of the threats to VPNs i.e. it mentions the threats of intrusion and denial of service ... but not unauthorized monitoring/interception, traffic analysis, data corruption, insertion of bogus traffic, various attacks on VPN end points, malware, masquerading/identity theft, insider threats etc ., although these are mentioned or at least hinted-at later under security requirements. Introduces different types of remote access including protocols, authentication issues and support when setting up remote access securely. Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27040 ISO/IEC 27040:2024 — Information technology — Security techniques — Storage security (second edition) Up Abstract ISO/IEC 27040:2024 "provides detailed technical requirements and guidance on how organizations can achieve an appropriate level of risk mitigation by employing a well-proven and consistent approach to the planning, design, documentation, and implementation of data storage security. Storage security applies to the protection of data both while stored in information and communications technology (ICT) systems and while in transit across the communication links associated with storage. Storage security includes the security of devices and media, management activities related to the devices and media, applications and services, and controlling or monitoring user activities during the lifetime of devices and media, and after end of use or end of life. Storage security is relevant to anyone involved in owning, operating, or using data storage devices, media, and networks. This includes senior managers, acquirers of storage products and services, and other non-technical managers or users, in addition to managers and administrators who have specific responsibilities for information or storage security, storage operation, or who are responsible for an organization’s overall security programme and security policy development. It is also relevant to anyone involved in the planning, design, and implementation of the architectural aspects of storage network security. [ISO/IEC 27040:2024] provides an overview of storage security concepts and related definitions. It includes requirements and guidance on the threats, design, and control aspects associated with typical storage scenarios and storage technology areas. In addition, it provides references to other international standards and technical reports that address existing practices and techniques that can be applied to storage security.” [Source: ISO/IEC 27040:2024] Introduction Information deserves to be adequately protected while in storage, as well as when created, communicated, processed, used and disposed of. The standard guides the purchasers and users of data storage technologies to determine and treat the associated information risks. Scope The standard concerns the security of data storage devices and media, security of management activities related to the devices and media, applications/services, and end-users, in addition to security of the information being transferred across the communication links associated with storage. The standard describes information risks associated with data storage, and security controls to mitigate unacceptable risks, using the same controls structure as ISO/IEC 27002 . It aims to: Draw attention to common risks associated with the confidentiality, integrity and availability of information on various data storage technologies; Encourage organisations to improve their protection of stored information using suitable information security controls; and Improve assurance, for example by facilitating reviews or audits of the information security controls protecting stored data. The information security issues associated with backup/disaster recovery locations and cloud storage are covered, as well as those associated with primary/local storage on a variety of data storage technologies, media and subsystems (e.g. DAS, SAN, NAS, CAS, FC and OSD). Media sanitisation (destruction of data stored on various computer storage media) is also covered. The standard is unusually detailed. It mentions a number of specific storage technologies which is also unusual for the ISO27k standards that are mostly generic and hence timeless. Structure Main clauses: 6: Overview and concepts 7: Organizational controls for storage 8: People controls for storage 9: Physical controls for storage 10: Technological controls for storage Annex A: Storage security controls summary Status The first edition was published in 2015 . The current second edition was published in 2024 . Commentary Resilience aspects of digital storage are covered in the standard - an important information security concept that (in my considered opinion) deserves much more emphasis throughout ISO27k . After all, information security involves protecting the availability of important and valuable information, information technologies and information services, right? Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27005 ISO/IEC 27005:2022 — Information security, cybersecurity and privacy protection — Guidance on managing information security risks (fourth edition ) Up Abstract ISO/IEC 27005 "provides guidance to assist organizations to: fulfil the requirements of ISO/IEC 27001 concerning actions to address information security risks; [and] perform information security risk management activities, specifically information security risk assessment and treatment ...” [Source: ISO/IEC 27005:2022] Introduction The ISO27k standards are overtly risk-aligned, meaning that organisations are supposed to identify and assess risks to their information (called “information security risks ” in the ISO27k standards, despite that term being undefined) as a prelude to dealing with (“treating ”) them in various ways. Dealing with the most significant information risks as priorities makes sense from the practical implementation and management perspectives. Turning that on its head, failing to prioritise addressing the most significant risks represents a governance failure, arguably negligence or mismanagement. Scope The standard guides organisations interpreting and fulfilling ISO/IEC 27001 ’s requirements to address (identify, evaluate and treat) their information [security] risks. The approach is generic, flexible and not specific to an ISO/IEC 27001 I nformation S ecurity M anagement S ystem. It could be used, for instance, in conjunction with NIST's C yber S ecurity F ramework or SP800-53 , GDPR , NIS2 or SOC2 , or (with minor adaptations) to guide the proactive management of business risks, safety risks, supply chain risks etc . Structure Main clauses: 5: Information security risk management - introduces the concept of strategic (long term) and operational (short term) cycles, plus ad hoc responses to changes 6: Context establishment - determining stakeholders (e.g. risk owners), their objectives or requirements (e.g . risk appetite) and risk management methods 7: Information security risk assessment process - lengthy clause lays out the process of systematically identifying, analysing, evaluating and prioritising risks. 8: Information security risk treatment process - decide what to do, document it and do it. 9: Operation assessing and treating risks - short clause mentions that information [security] risks and treatments should be reviewed regularly or when changes occur. 10: Leveraging related ISMS processes - basically a re-hash and amplification of ISO/IEC 27001 , offering implementation advice in a similar style to ISO/IEC 27003 . Annex A: Examples of techniques in support of the risk assessment process - risk matrices/heat-maps and risk modelling. Status The first (2008 ), second (2011 ) and third (2018 ) editions are ancient history. The current fourth edition was published in 2022 . ISO/IEC JTC 1/SC 27/WG 1 is preparing to revise ISO/IEC 27005:2022 by considering various approaches or options, such as whether a multi-part standard might be worthwhile. Its deliberations will presumably flow into a scope for the revision project in due course. Commentary Given that ISO27k is risk-based, identifying, evaluating and treating information risks is obviously fundamental to the approach. Each organisation is expected to consider the relevance and significance of its unique set of risks, tailoring its response to suit its business situation or context. With the fourth edition, ISO/IEC 27005 tackles the thorny issue of how to use ISO/IEC 27001 Annex A . The annex is described as an incomplete set of possible controls to be checked for relevance to mitigate the organisation’s identified information [security] risks - in other words, a controls-based approach to information risk management, supplementing the risk-, scenario-, event- and asset-based approaches mentioned elsewhere. There are advantages in exploring information risks from different perspectives. The standard primarily concerns using information security controls to ‘modify’ (mitigate or maintain) information [security] risks. Other equally valid risk treatment options (risk avoidance, sharing and acceptance) are barely even mentioned, heavily biasing the entire approach. ISO’s Technical Committee for Risk Management looks likely to review/clarify the definition of ‘risk’ in ISO 31000 (“effect of uncertainty on objectives”) and may also offer guidance on ‘opportunities’. It is possible the two terms will be distinguished, rather than being portrayed as flip sides as at present. I hope that will eventually make things easier for ISO27k and the other management systems standards, but it may stir the already muddy waters. Up Up Up This page last updated: 19 August 2026

Back Up Next ISO/IEC 27038 ISO/IEC 27038:2014 — Information technology — Security techniques — Specification for digital redaction (first edition) Up Abstract “ISO/IEC 27038:2014 specifies characteristics of techniques for performing digital redaction on digital documents. It also specifies requirements for software redaction tools and methods of testing that digital redaction has been securely completed. ISO/IEC 27038:2014 does not include the redaction of information from databases.” [Source: ISO/IEC 27038:2014] Introduction Digital data sometimes have to be revealed to third parties, occasionally even published to the general public, for reasons such as disclosure of official documents under Freedom of Information laws or as evidence in commercial disputes or legal cases. However, where it is deemed inappropriate to disclose certain sensitive data within the files (such as the names or locations of people or sources who must remain anonymous and various other personal or proprietary information that must remain strictly confidential), those must be securely removed from the files prior to their release. ‘Redaction’ is the conventional term for the process of denying file recipients knowledge of certain sensitive data within the original files. Given that redaction is usually relevant to the protection of highly confidential information, failures in the process that lead to inappropriate data disclosure are almost bound to be serious and in the worst cases can be grave. Redaction failures have led to incidents such as identity theft, disclosure of confidential security matters, privacy breaches and compromising the identities of undercover agents and informants, while disclosure of trade secrets could prove extremely costly in a commercial context. At the very least, redaction failures are embarrassing to those deemed responsible. Information risks associated with digital redaction include: Making bad decisions about the data to be redacted, the technical methods or process to be used and/or the suitability (primarily competency and diligence) of those tasked to do it; Failing to identify correctly all the sensitive data that must be redacted (both the individual data items and the files); Failing to render the redacted data totally unrecoverable, for example: Using inappropriate or ineffective technical methods for redaction, such as crudely modifying rather than permanently deleting the sensitive data using methods that can be completely or partially reversed (for example simply reformatting or overlaying redacted text to appear invisible, or applying readily-reversed mechanistic transformations or tokenization of textual identifiers); Accidentally leaving one or more copies of the sensitive data completely or partially unredacted (perhaps releasing multiple, independently and differently redacted versions of a sensitive document, enabling it to be reconstructed directly or by inference); Partially deleting the sensitive data, leaving data remnants or sufficient information (such as the editing journal or cached copies) enabling the data to be restored from the redacted file; Relying excessively on pixellation, blurring or similar methods of obfuscation to obscure parts of images (typically for personal privacy reasons), whereas deconvolution and other more or less advanced image manipulation/transformation techniques may restore enough of the original image to permit recognition; Neglecting to redact sensitive metadata (e.g . in document properties or reviewer comments, GPS data on digital images, or alternate data streams); Failing to distinguish all redacted from non-redacted data, consistently and accurately, such that recipients know unambiguously which parts are no longer original; Excessive or inappropriate redaction, removing more than just the specific sensitive items that were supposed to have been redacted or doing so clumsily (which raises the prospect of having to justify redaction decisions and activities to a trustworthy intermediary or authority); Inappropriately or inadvertently altering the meaning of the remaining data as a result of contextual issues (e.g. deleting selected data records may invalidate statistical analysis of the remainder), or by causing collateral damage to the file structure (such as file integrity issues and inappropriate formatting changes) during the redaction process; Leaving sufficient data in the file to enable recipients to infer sensitive information, perhaps in conjunction with other available information sources (e.g. replacing people’s names with anonymous labels in a redacted file but separately disclosing the relationship between labels and names; disclosing anonymous statistical data on known small populations; disclosing the number of characters redacted, and perhaps even giving clues to the most likely characters by dint of their printed size; applying data mining, correlation and inference techniques to glean sensitive data from redacted or anonymized content); Placing excessive reliance on redaction, believing it sufficient to keep sensitive data totally confidential under all circumstances whereas technical and process failures are possible and incidents sometimes occur in practice; conversely, placing zero reliance on redaction, believing it to be totally incapable of protecting sensitive information (these are governance and assurance risks); Information security issues that are incidental or peripheral to the redaction process itself such as: Sending the original files, redaction instructions, redacted content or indeed the redacted files to the wrong recipients; Failing to secure information relating to the redaction process, such as the original files or detailed redaction instructions, while in transit, during processing and in storage (e.g . interception of sensitive content in clear on the network); Accidentally disclosing unredacted versions of the file, whether at the same time and through the same disclosure mechanism or separately; Deliberate disclosure or ‘leakage’ of unredacted versions of the file without permission or inappropriately (e.g. to Wikileaks); Accidentally or deliberately disclosing the redacted information by some means other than by releasing the digital data (e.g. by releasing the redaction instructions, or being overheard discussing sensitive matters); Damaging the integrity and/or availability of the original unredacted files (e.g . overwriting them with the redacted versions); Use of redaction to conceal illegal or inappropriate activities; Use of AI/ML/NLP to surmise the redacted content based on linguistic principles and the surrounding context, plus broader analysis of related materials; Various other risks (the risk analysis implied here is generic and not comprehensive : it does not necessarily reflect any specific situation). [Thanks to colleagues on CISSPforum for contributing to this long list.] Scope The standard formally defines redaction as “permanent removal of information within a document” where document is formally defined as “recorded information which can be treated as a unit”. The definitions are important because, in other contexts and general use, these terms often mean other things ... and indeed later in the standard, redaction is expanded to include not just the removal of confidential content but also, if appropriate, indicating where content has been removed. The standard “specifies characteristics of techniques for performing digital redaction on digital documents [... and ...] requirements for software redaction tools and methods of testing that digital redaction has been securely completed [... but ...] does not include the redaction of information from databases.” Databases qualify as ‘units of recorded information’ but redaction of databases is specifically excluded from the scope of the standard. Even though this standard has a restricted scope, the risks it covers are significant and many of the associated controls are technically and procedurally complex. Like other ISO27k standards , it does not attempt to cover all the vagaries of the redaction process in great detail but provides sound if rather generic and high-level guidance. Structure Main clauses: 4: General principles of digital redaction - an introduction 5: Requirements - an overview of the redaction process 6: Redaction processes - such as printing and physically redacting content, editing the original documents in various ways, dealing with metadata (such as document properties and change records) and, in the case of ‘enhanced’ redaction, considering the broader context as well as the specific content (e.g. the possibility of guessing, inferring or reconstructing redacted content from other content in redacted files, or by using other sources) 7: Keeping records of redaction work - in order to be able to explain or justify redaction decisions and actions 8: Characteristics of software redaction tools - a core, generic set of functional requirements 9: Requirements for redaction testing - five simple if basic ways to check whether the redaction has been successful Annex A: Redacting of PDF documents Status The current first edition was published in 2014 and confirmed unchanged in 2019 Commentary The title uses the keyword ‘specification’ which, in ISO-speak, implies a formal definition against which organisations may be independently audited and certified compliant. Whereas ISO specification standards normally use the key-word “shall” exclusively to indicate mandatory requirements, the DIS version also used “should” in places, providing guidance above and beyond the formal specifications. In practice, this makes the standard easier for users to understand and apply, but harder to audit and certify against, if indeed that was ever intended. The standard doesn’t say much about the governance or overall management of the redaction process (e.g. identifying what has to be redacted, why, how and by whom, nor about analysing and treating the risks in a given redaction situation), nor on the security controls that ought to be applied to or associated with the process (e.g. to prevent the inappropriate release of unredacted content or explicit redaction instructions). There is room here for further implementation guidance. Up Up Up This page last updated: 19 August 2026