Search Results

Up Up Up ISO/IEC 27021 ISO/IEC 27021:2017 — Information technology — Security techniques — Competence requirements for information security management systems professionals (first edition) Up Abstract “ISO/IEC 27021:2017 specifies the requirements of competence for ISMS professionals leading or involved in establishing, implementing, maintaining and continually improving one or more information security management system processes that conforms to ISO/IEC 27001.” [Source: ISO/IEC 27021:2017] Introduction To help stabilise and standardise the global market for training and certifying professionals for ISO27k implementation and audit work, this standard lays out the competence expected of ISMS professionals. Scope The standard concerns the competences (meaning the combination of knowledge and skills) required or expected of professionals managing an ISMS in accordance with ISO/IEC 27001 , ISO/IEC 27002 , ISO/IEC 27005 and ISO/IEC 27007 . Note : the standard does NOT specify a personal certification or qualification scheme as such, but in effect serves as a reference for the organisations that run such schemes. Note : the standard does NOT cover auditor competence. Structure The standard starts by explaining that an ISMS is just one form of Management System, requiring a combination of competences in general business management (e.g. leadership and communication, planning and budgeting) plus information security/ISMS management (e.g. scoping the ISMS). The competences roughly mirror the clauses in the main body of ISO/IEC 27001 , except that most of the general management competences are not directly related to specific clauses. Each competence is described quite succinctly in four ways: Relevant ISO/IEC 27001 clause (where applicable) Intended outcome: what this part of the role entails and is expected to achieve Knowledge required: things the ISMS professional should know about Skills required: things the ISMS professional should be able to do Status The first edition was published in 2017 . Additional references to ISO/IEC 27001 clauses were added to plug gaps in the competencies table through an amendment in 2021: ISO/IEC 27021:2017/Amd1:2021 Information technology - Security techniques - Competence requirements for information security management systems professionals - Amendment 1: Addition of ISO/IEC 27001:2013 clauses or subclauses to competence requirements . Commentary Although the title of this standard includes the reserved word ‘requirements’, that should not be taken to imply this is a certifiable standard. A revision to the title should avoid any conflict with CASCO . The four standards listed in the scope section above may be the ‘core standards’ but they represent just a fraction of the growing ISO27k suite . It could be argued that several others are nearly as important - ISO/IEC 27003 and ISO/IEC 27004 for examples - which begs questions about the breadth and depth of knowledge and competencies truly expected of information security managers. Another aspect is that (ISO27k notwithstanding) information security management is materially different in different types/sizes of organisation, so perhaps there is a need for different levels or tiers of qualification (or practitioner maturity, you could say), from entry-level basics up to subject matter experts? A tiered scheme would also encourage career development and lifelong learning. Since the standard is intended to guide those developing courses and qualifications, it might make sense to incorporate or build the standard around a matrix listing the skills and competencies on one axis and the levels or tiers on another, indicating in the body of the matrix which items people at that level/tier are expected to know about and be competent to perform. The idea of a tiered scheme was agreed in principle by the project team, with e-CF and e-QF schemes (whatever they are!) being mentioned in comments: maybe this suggestion will be revisited when the standard is next revised. The standard incorporates the idea of a B ody o f K nowledge defined in the standard to cover the core aspects of governing and managing an ISMS, but extendable by organisations to address their specific additional requirements in this area. Up Up Up This page last updated: 19 November 2025

Up Up Up ISO/IEC 27034-6 ISO/IEC 27034-6:2016 — Information technology — Security techniques — Application security — Part 6: Case studies (first edition) Up Abstract ISO/IEC 27034 part 6 “provides usage examples of ASCs for specific applications. NOTE Herein specified ASCs are provided for explanation purposes only and the audience is encouraged to create their own ASCs to assure the application security.” [Source: ISO/IEC 27034-6:2016] Introduction Part 6 provides examples of how A pplication S ecurity C ontrols might be developed and documented. Scope Part 6 concerns the handling of application security in the course of software development. Structure Main sections: 5: Security guidance for specific applications Annex A: XML examples for case studies in 5.2 Status The current first edition of part 6 was published in 2016 and confirmed unchanged in 2022. Commentary Case studies demonstrate the feasibility of this highly structured, formal approach that is being used successfully by some major software developers. Up Up Up This page last updated: 19 November 2025

Up Up Up ISO/IEC 27034-3 ISO/IEC 27034-3:2018 — Information technology — Security techniques — Application security — Part 3: Application security management process (first edition) Up Abstract ISO/IEC 27034 part 3 "provides a detailed description and implementation guidance for the Application Security Management Process.” [Source: ISO/IEC 27034-3:2018] Introduction Part 3 defines the processes of managing the security of an application processing critical information. Scope Part 3 "provides a detailed description and implementation guidance for the Application Security Management Process. Structure Main sections: 5: Application Security Management Process 6: ASMP steps 7: ANF elements Annex A: Guidance text related to the ASMP step: (6.4) Realizing and operating the application Status The current first edition of part 3 was published in 2018 . Commentary Part 3 describes “the overall process for managing security on each specific application used by an organisation”. As such, this may be the most broadly applicable and useful part of this standard. Up Up Up This page last updated: 19 November 2025

Up Up Up ISO/IEC 27559 ISO/IEC 27559:2022 — Information security, cybersecurity and privacy protection — Privacy-enhancing data de-identification framework (first edition) Up Abstract ISO/IEC 27559 "provides a framework for identifying and mitigating re-identification risks and risks associated with the lifecycle of de-identified data.” [Source: ISO/IEC 27559:2022] Introduction This standard proposes a ‘principles-based’ framework/structure for identifying and mitigating privacy-related risks such as re-identification of supposedly de-identified data. It advises on properly de-identifying (anonymising) personal data in order to build trust with data subjects and comply with applicable privacy laws and regulations. Scope As data analytics increasingly relies on sharing and combining data sets containing supposedly de-identified (anonymized) data, the risks of re-identification are growing more significant. This standard provides guidance on the principles involved in recognizing and mitigating those risks. It stops short of the specific technologies and their implementation. Structure Main sections: Context assessment : essentially, determining the general concerns and hence main requirements in this area, using analytical approaches such as threat modelling. Understanding the business situations in which personal data are shared both within and without the organisation suggests the possibility of procedural and administrative controls (such as contracts and agreements) to be applied by data custodians. Data assessment : understanding the data structures to identify possible ‘attacks’ (unauthorised/inappropriate attempts to obtain personal information that would compromise privacy). Identifiability assessment and mitigation : understanding how personal information might be gleaned from available/accumulated data that (whether individually or as a whole) has been inadequately anonymized, and mitigating the risks (e.g. applying the de-identification techniques described in ISO/IEC 20889) to an acceptable level (not necessarily zero!). De-identification governance : directing and controlling the people involved in maintaining privacy, for example by determining and assigning appropriate roles and responsibilities, defining policies and procedures, managing and mopping-up after privacy breach incidents. Status The current first edition was published in 2022 . Commentary As our personal information is increasingly obtained and shared both within and among organisations, this standard has a valuable role in setting the ground rules. It specifies how to do so without unnecessarily compromising the privacy of the individuals concerned, or exposing personal data to compromise by various means (e.g. data aggregation and inference attacks). As such, it facilitates the process by increasing the level of trust between providers and acquirers of personal information, supporting privacy arrangements in general. Up Up Up This page last updated: 19 November 2025

Up Up Up 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 sections: 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: 19 November 2025

Up Up Up ISO/IEC TS 27570 ISO/IEC TS 27570:2021 — Privacy protection — Privacy guidelines for smart cities (first edition) Up Abstract ISO/IEC TS 27570 "takes a multiple agency as well as a citizen-centric viewpoint. It provides guidance on: smart city ecosystem privacy protection; how standards can be used at a global level and at an organisational level for the benefit of citizens; and processes for smart city ecosystem privacy protection. ...” [Source: ISO/IEC TS 27570:2021] Introduction Smart cities’ are emerging from the confluence of public wireless networks, mobile/portable devices, the I nternet o f T hings (both industrial and consumer), automation, cloud computing, smart devices with advanced automation and artificial intelligence/machine learning, big data and more. As disparate ICT system are increasingly and dynamically communicating within our cities, both opportunities and risks are opening up for individuals plus the commercial and governmental agencies providing various services (such as communications, energy, transportation, healthcare and law enforcement). Scope Although the guideline briefly mentions information security aspects such as safety and resilience, the guideline specifically concerns privacy in the context of smart cities including ‘smart city ecosystem privacy protection’. Rhetorical questions include: To what extent is it appropriate for individuals to be identified, tracked and monitored through their ICT devices and digital interactions as they go about their business in the city? Since privacy requirements and expectations vary between the authorities, businesses and individuals, how should those tensions be managed? Even though the collection, processing and disclosure of personal data may be restricted on privacy grounds, what (if anything) can/should be done to restrict correlation and inference being used as large quantities of information become available for sharing and analysis? Is it even feasible to support (an appropriate degree of) anonymity if individuals so desire, without excluding them and denying them the advantages of interaction between smart devices? There are social/societal aspects to this, as well as the technological and personal. Given the rapid pace of change in this area, the guideline cannot fully address all the issues at this time but instead seeks to establish a reference (conceptual) framework as a basis for the development of future standards. Structure Main sections: 5: Privacy in smart cities 6: Guidance on smart city ecosystems privacy protection 7: Guidance on standards for smart city ecosystems privacy protection 8: Guidance on processes for smart city ecosystem privacy protection Annex A: Example of ecosystem privacy plan structure Annex B: Using video cameras in smart cities The guideline provides conceptual diagrams and explanations, emphasizing other applicable standards. Status The current first edition was published as a T echnical S pecification in 2021 and confirmed unchanged in 2024. Commentary This visionary, conceptual, innovative and remarkable standard was conceived way back in 2015. The issues it covers are still barely even recognised as such at this point, at least not outside the specialism. Better to influence the thinking and direction on privacy, governance and related matters now than to complain about constraints later on when it may be too late to achieve fundamental change. If only SC 27 had taken such a proactive stance on IoT security way back when it was in its infancy! Speaking as a former biologist and current pedant, frequent use of “ecosystem” (a contraction of eco logical system ) catches my beady eye. The standard is not talking about living organisms interacting with the natural environment, but conceptual linkages between IT systems, networks, organisations and individuals in the technology context. Surely there is a more accurate and appropriate term than ‘ecosystem’ - ‘technosystem’, perhaps, contracting techno logical system ? Up Up Up This page last updated: 19 November 2025

Up Up Up 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 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 sections: An introduction to the general principles of digital redaction and anonymization of data; Redaction requirements - actually an overview of the redaction process; 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); Keeping records and notes in order to be able to explain or justify redaction decisions and actions; Software redaction tools - a core set of functional requirements; Redaction testing - five simple if basic ways to check whether the redaction has been successful; and An informative annex about redacting PDFs. 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 November 2025

Up Up Up ISO/IEC 27404 ISO/IEC 27404:2025 — Cybersecurity — IoT security and privacy — Cybersecurity labelling framework for consumer IoT [first edition] Up Abstract ISO/IEC 27404 "defines a cybersecurity labelling framework for the development and implementation of cybersecurity labelling programmes for consumer IoT products. It provides requirements and includes guidance on the following topics: Risks and threats associated with consumer IoT products; Stakeholders, roles and responsibilities; Relevant standards and guidance documents; Conformity assessment; Labelling issuance and maintenance; Mutual recognition. [ISO/IEC 27404] is limited to consumer IoT products, such as: IoT gateways, base stations and hubs to which multiple devices connect; smart cameras, televisions, and speakers; wearable devices; connected smoke detectors, door locks and window sensors; connected home automation and alarm systems; connected appliances, such as washing machines and fridges; smart home assistants; and connected children’s toys and baby monitors. Products that are not intended for consumer use are excluded from this standard. Examples of excluded devices are those that are primarily intended for manufacturing, healthcare and other industrial purposes. [ISO/IEC 27404] is applicable to consumers, developers, issuing bodies of cybersecurity labels and conformity assessment bodies.” [Source: ISO/IEC 27404:2025] Introduction Although cybersecurity is seldom promoted as a feature of consumer-oriented IoT devices (things ), it can be important. Inconsistent and unclear cybersecurity labelling does not help consumers appreciate their security and privacy objectives, nor evaluate and select things accordingly. Standardising the cybersecurity labelling of things is intended to improve consistency across the global market, increase consumer awareness and promote better cybersecurity designs. Scope The standard concerns consumer-grade (retail) things - as opposed to business, industrial, engineering, medical, scientific or mil-spec things (since their cybersecurity requirements and features/capabilities are more likely to be specified in detail). It covers cybersecurity and privacy but excludes safety aspects. Structure Main sections: 5: Overview of cybersecurity labelling for consumer IoT 6: International alignment through a cybersecurity labelling framework 7: Requirements and guidance for the components of the cybersecurity labelling framework for consumer IoT 8: Requirements and guidance for labelling issuance and maintenance for consumer IoT Annex A: types and features of cybersecurity labels Annex B: illustrative examples of multi-level labelling schemes Annex C: illustrative examples of binary labelling schemes Annex D: determination of equivalency among labelling schemes Annex E: examples of cybersecurity baseline provisions Annex F: examples of secure-by-design provisions Annex G: examples of privacy assessment requirements Status The current first edition was published in 2025 . Commentary Singapore standard TR 91:2021 Cybersecurity labelling for consumer IoT formed the original basis for this standard, with editorial changes to suit the more formal ISO/IEC style. Up Up Up This page last updated: 19 November 2025

Up Up Up ISO/IEC 27035-4 ISO/IEC 27035-4:2024 — Information technology — Information security incident management — Part 4: Coordination (first edition) Up Abstract ISO/IEC 27035 part 4 “provides guidelines for multiple organizations handling information security incidents in a coordinated manner. It also addresses the impacts of external cooperation on the internal incident management of an individual organization and provides guidelines for an individual organization to adapt to the coordination process. Furthermore, it provides guidelines for the coordination team, if it exists, to perform coordination activities supporting the cross-organization incident response. The principles given in [ISO/IEC 27035-4] are generic and are intended to be applicable to multiple organizations to work together to handle information security incidents, regardless of their types, sizes or nature. Organizations can adjust the guidance given in [ISO/IEC 27035-4] according to their type, sizes and nature of business in relation to the information security risk situation. [ISO/IEC 27035-4] is also applicable to an individual organization that participates in partner relationships.” [Source: ISO/IEC 27035-4:2024 ] Introduction Whereas managing routine information security incidents typically involves several departments or teams within an organisation, exceptional/major incidents (such as botnet or phishing attacks) require collaboration and coordination between the I ncident R esponse T eams of several organisations, often in different countries. They may be affected or involved in various ways e.g . Internet and cloud service providers, plus law enforcement, plus the targeted organisation/s. Scope Part 4 is about coordinating responses to major incidents with other implicated, involved or support organisations, such as cloud and network suppliers. Structure Main sections: 4: Overview 5: Coordinated incident management process 6: Guidelines for key activities of coordinated incident management Annex A: Examples of information security incident management coordination Status The current first edition was published in 2024 . Commentary Part 4 "provides guidelines for multiple organizations handling information security incidents in a coordinated manner. It also addresses the impacts of external cooperation on the internal incident management of an individual organization and provides guidelines for an individual organization to adapt to the coordination process. Furthermore, it provides guidelines for the coordination team, if it exists, to perform coordination activities supporting the cross-organization incident response. The principles given in this document are generic and are intended to be applicable to multiple organizations to work together to handle information security incidents, regardless of their types, sizes or nature. Organizations can adjust the guidance given in this document according to their type, sizes and nature of business in relation to the information security risk situation. This document is also applicable to an individual organization that participates in partner relationships." Up Up Up This page last updated: 19 November 2025

Up Up Up ISO/IEC 27090 ISO/IEC 27090 — Cybersecurity — Artificial Intelligence — Guidance for addressing security threats and compromises to artificial intelligence systems [DRAFT] Up Abstract ISO/IEC 27090 “addresses security threats and compromises specific to artificial intelligence (AI) systems. The guidance in this This document aims to provide information to organizations to help them better understand the consequences of security threats specific to AI systems, throughout their life cycle, and descriptions of how to detect and mitigate such threats. This document is applicable to all types and sizes of organizations, including public and private companies, government entities, and not-for-profit organizations, that develop or use AI systems.” [Source: ISO/IEC 27090 D raft I nternational S tandard] Introduction The rampant proliferation of ‘smart systems’ means ever greater reliance on automation: computers are making decisions and reacting or responding to situations that would previously have required human beings. Currently, however, the tech smarts are limited, so the systems don’t always react or behave as they should. Scope The standard will guide organisations on addressing security threats to A rtificial I ntelligence systems. It will: Help organisations better understand the consequences of security threats to AI systems, throughout their lifecycle; and Explain how to detect and mitigate such threats. Structure The standard will cover at least a dozen threats such as: Poisoning - data and model poisoning e.g. deliberately injecting false information to mislead and hence harm a competitor’s AI system; Evasion - deliberately misleading the AI algorithms using carefully-crafted training inputs; Membership inference and model inversion - methods to distinguish [and potentially manipulate] the data points used in training the system; Model stealing - theft of the valuable intellectual property in a trained AI system/model. For each threat, the standard will offer about a page of advice: Describing the threat; Discussing the potential consequences of an attack; Explaining how to detect and mitigate attacks. An extensive list of references will direct readers to further information including relevant academic research and more pragmatic advice, including other standards. Status ISO/IEC JTC1 SC27 Working Group 4 started developing this standard in 2022. The standard is now at D raft I nternational S tandard stage, due for publication in mid-2026. Commentary It will be disappointing if Imprecise/unclear use of terminology in the draft persists in the published standard. Are ‘security failures’ vulnerabilities, control failures, events, incidents or compromises maybe? Are ‘threats’ attacks, information risks, threat agents, incidents or something else? Detecting ‘threats’ (which generally refers to impending or in-progress attacks) is seen as a focal point for the standard, hinting that security controls cannot respond to undetected attacks ... which may be generally true for active responses but not for passive, general purpose controls. As usual with ‘cybersecurity’, the proposal and drafts focused on active, deliberate, malicious, focused attacks on AI systems by motivated and capable adversaries, disregarding the possibility of natural and accidental threats such as design flaws and bugs, and threats from within i.e. insider threats. The standard addresses ‘threats’ (attacks) to AI that are of concern to the AI system owner, rather than threats involving AI that are of concern to its users or to third parties e.g. hackers and spammers misusing AI systems to learn new malevolent techniques. The rapid proliferation (explosion?) of publicly-accessible AI systems during 2023 put a rather different spin on this area. The scope excludes ‘robot wars’ where AI systems are used to attack other AI systems. Scary stuff, if decades of science fiction and cinema blockbusters are anything to go by. The potentially significant value of AI systems in identifying, evaluating and responding to information risks and security incidents is also out of scope of this standard: the whole thing is quite pessimistic, focusing on the negatives. However, the hectic pace of progress in the AI field is clearly a factor: this standard will provide a starting point, a foundation for further AI security standards and updates as the field matures. Up Up Up This page last updated: 4 December 2025