Search Results

Back Up Next ISO/IEC TS 27022 ISO/IEC TS 27022:2021 — Information technology — Guidance on information security management system processes (first edition) Up Abstract ISO/IEC TS 27022 "defines a process reference model (PRM) for the domain of information security management, which is meeting the criteria defined in ISO/IEC 33004 for process reference models (see Annex A). It is intended to guide users of ISO/IEC 27001 to: incorporate the process approach as described by ISO/IEC 27000:2018, 4.3, within the ISMS; be aligned to all the work done within other standards of the ISO/IEC 27000 family from the perspective of the operation of ISMS processes; support users in the operation of an ISMS. [ISO/IEC TS 27022] is complementing the requirements-oriented perspective of ISO/IEC 27003 with an operational, process-oriented point of view.” [Source: ISO/IEC TS 27022:2021] Introduction The standard (a T echnical S pecification) “provides a process reference model (PRM) for information security management, which differentiates between ISMS processes and measures/controls initiated by them ... [and] describes the ISMS processes implied by ISO/IEC 27001.” The standard is based on a PhD thesis . Scope The standard lays out, in some detail, a P rocess R eference M odel comprising a generic suite of ISMS processes that organisations may wish to use as a basis for designing custom processes within their own ISMS. The standard “is intended to guide users of ISO/IEC 27001 to: incorporate the process approach as described by ISO/IEC 27000:2018 clause 4.3 within the ISMS be aligned to all the work done within other standards of the ISO/IEC 27000 family from the perspective of the operation of ISMS processes support users in the operation of an ISMS – the document will complement the requirements oriented perspective of ISO/IEC 27003 with an operational, process oriented point of view.” This advisory standard does not add or modify the ISMS requirements in ISO/IEC 27001 . Structure The ISMS processes described fall into 3 “categories” (types or groups) i.e. : Governance activities (confusingly titled ‘management processes’) - direction and oversight for the ISMS; Core operations e.g. information risk and security management, policy management, incident management, internal audits ...; and Support e.g. records management, communicating with interested parties about the ISMS, managing relationships with ISMS ‘customers’ ... The processes are each laid out in an Appendix, first as a table specifying: Process “category” denoting the type of process A brief description Objective/purposes Input[s] and Output[s] Activities/functions i.e. a few words for each of the main steps in the process Informative references. The table is followed by a flowchart summarising each process on one side or less. Status The current first edition was published in 2021 . An amendment updating references to ISO/IEC 27001:2022 and other ISO27k standards was in preparation in 2024 but the proposed revision of the standard was dropped due to lack of expert support. Commentary Mature organisations may already have processes for: Asset management; Audit management, both internal and external; Business continuity management (see ISO 22301: ISO/IEC 27001 is limited to continuity of information security operations during major incidents); Change management plus configuration management and version control; Continuous improvement and maturity management; Database [security] management; Exemption management (management-approved nonconformity with policies); Facilities management including power and other services for the computer room; Identity, access rights and user account management; Incident management including incident investigation and forensics; Information management in general; Information [security] risk management (partly covered by ISO/IEC 27005 ); Information security management (covered by ISO/IEC 27001 , 27002 , 27003 and others); IT! Internal audits and certification audits; Key management, plus the rest of cryptography; Log management, plus alarms and alerts; Metrics and management information management (partly covered by ISO/IEC 27004 ); Monitoring and oversight of the risk management and security arrangements; Patching, including emergency arrangements for urgent fixes; Performance and capacity management; Personnel/HR management including “onboarding” and “offboarding” (nasty neologisms!); Preventive and corrective actions; Quality management, especially quality assurance; Service management [organisations that are heavily process-oriented may be using ITIL/ISO 20000, in which case ISO/IEC 27013 is applicable]; Supplier/vendor relationship management, including telecomms, Internet and cloud services, outsourced development, contract security guards, maintenance/servicing, professional services (consulting, contracting, accounting, tax advising) etc. ; System and network [security] management; System/software development and testing ... ... and more. Providing generally-applicable advice without imposing further constraints is challenging. The processes need to be described without losing the flexibility to cater for myriad differences between organisations. In particular, the processes need to be valuable (cost-effective) in practice to justify their existence, for instance by: Removing unnecessary bureaucracy, rationalising and justifying whatever remains; Facilitating or encouraging process automation and innovation where applicable; Facilitating or encouraging use of existing processes, adapting them where necessary; Perhaps re-using effective ISMS processes elsewhere in the organisation; Managing the processes themselves e.g. management processes for monitoring, reviewing, evaluating and maintaining the ISMS processes, responding to changes, identifying and exploiting improvement opportunities etc . It would be unfortunate if ISMS processes were perceived as distinct from normal operations, rather than being integral to the organisation’s routine activities. The process for managing an information security or privacy incident, for example, is essentially the same as that for managing any other incident, hence it is generally unnecessary to create an alternative incident management process if the existing one (perhaps with a few tweaks) is effective. Up Up Up This page last updated: 11 February 2026

Back Up Next ISO/IEC 27002 ISO/IEC 27002:2022 — Information security, cybersecurity and privacy protection — Information security controls (third edition) Up Abstract ISO/IEC 27002 "provides a reference set of generic information security controls including implementation guidance. [ISO/IEC 27002] is designed to be used by organisations: (a) within the context of an information security management system (ISMS) based on ISO/IEC27001; (b) for implementing information security controls based on internationally recognized best practices; [and] (c) for developing organisation-specific information security management guidelines.” [Source: ISO/IEC 27002:2022] Introduction ISO/IEC 27002 is a popular international standard describing a generic selection of ‘good practice’ information security controls, typically used to mitigate unacceptable risks to the confidentiality, integrity and availability of information. It was based on British Standard BS 7799 in the mid-1990s, itself based on an oil company's proprietary information security manual. ISO/IEC 27002 is an advisory document, a guideline or recommendation rather than a formal specification such as ISO/IEC 27001 . Organisations are advised to identify and evaluate their own information risks, selecting or designing and applying suitable information security controls to mitigate unacceptable risks using ISO/IEC 27002 and other relevant standards and sources for guidance. Scope Like governance and risk management, information security management is a broad topic with ramifications for all organisations. Information security, and hence ISO/IEC 27002, is relevant to all types of organisation including commercial enterprises of all sizes (from one-man-bands up to multinational giants), not-for-profits, charities, clubs, government departments and quasi-autonomous bodies - in fact any organisation that handles and depends on information. The specific information risks and hence control requirements differ in detail between organisations but there is a lot of common ground, for instance most organisations need to address information risks relating to their employees plus contractors, consultants and third party suppliers of various information and IT services such as networking and cloud computing. The standard is explicitly concerned with information security, meaning the security of all forms of information (e.g. computer data, documentation, knowledge and intellectual property) - not just IT/systems/network/cyber/digital security. It includes those, of course, but there's more to secure. Structure The standard lays out a ‘reference set’ of 93* generic information security controls with guidance, categorised into 4 main clauses or ‘themes’: 5: Organisational controls - a large and misleadingly-named catch-all group of 37* controls that don’t fit neatly into the following themes; 6: People controls - 8* controls involving or relating to people e.g. individuals’ behaviors, activities, roles and responsibilities, terms and conditions of employment etc .; 7: Physical controls - 14* tangible controls to secure tangible information assets; 8: Technological controls - 34* controls involving or relating to technologies, IT in particular. The 93* controls are each tagged with one or more values for each of 5 attributes so they can be grouped, selected or filtered in other ways too. The attributes and attribute values are: Control type : preventive, detective and/or corrective - relating to stages of incidents at which the controls act; Information security properties : confidentiality, integrity and/or availability - which of these information characteristics they protect; Cybersecurity concepts : identify, protect, detect, respond and/or recover - a more detailed breakdown of the incident timeline; Operational capabilities : governance, asset management, information protection, human resource security, physical security, system and network security, application security, secure configuration, identity and access management, threat and vulnerability management, continuity, supplier relationships securit, legal and compliance, information security event management, and information security assurance - reflecting the structure used in the previous edition of this standard; Security domains : governance and ecosystem, protection, defence and resilience - another way to classify controls. The control attribute tagging reflects these complexities: A given control may have several worthwhile applications (e.g. backups help protect against malware, hacks, bugs, accidents, mechanical breakdowns, fires etc. , and can include deputies and multi-skilled replacements for critical people, and alternative suppliers/sources of necessary information services, as well as data backups); An unacceptable risk typically requires several controls (e.g. malware can be mitigated using backups, awareness, antivirus, network access controls plus IDS/IPS, authentication, patching, testing, system integrity controls etc ., while avoiding infection can be a powerful approach if bolstered with controls such as policies and procedures, blacklisting etc .); Many of the ‘controls’ identified in the standard are not atomic, being composed of several smaller elements or pieces (e.g. backups involve strategies, policies and procedures, software, hardware, testing, incident recovery, physical protection of backup media etc. ). Some of the themes and attributes are arbitrarily assigned: for example, a commercial card access lock on a building entrance may fall into any, arguably all four of the themes listed above, but if it and other such controls were covered several times, the standard would become unwieldy. More likely, it would be categorised as - primarily - a physical control, possibly with references to other elements. Organisations can usefully define and use their own attributes as well. ISO/IEC 27028 will soon provide guidance on that. * Note: there are 21 fewer control clauses in the third edition than the second despite adding 11 new ones since several second edition control clauses were updated or merged. Each clause is in fact comprised of or incorporates numerous ‘atomic’ controls at a more detailed level of analysis. ISO/IEC 27002 notes or implies hundreds of detailed information security controls , in fact, way more than the nominal and often-stated total of “93”. Status The first edition was published in 2005 . The second edition was published in 2013 . The completely restructured and updated third edition was published in 2022 . A P reliminary W ork I tem will explore the need for a revision of ISO/IEC 27002, assessing the relevance and applicability of the current set of controls and supporting guidance and perhaps new. The intent is to reflect changes "in organizational practices, business, operations, technology and cyber-risks". The committee is also considering offering guidance on information security controls tailored for small organisations. A PWI will clarify the scope and purpose of such an SME infosec guideline, if indeed it gets enough support. Commentary In my considered opinion, one of the most distinctive, innovative and valuable features of the original Shell policy manual, the UK DTI Code of Practice/DISC standard PD003 and British Standard BS 7799 was that they explicitly addressed information security, recommending approaches and controls to secure information in any form - not just computer data, systems, apps, networks and technologies. The focus was clearly on protecting the intangible, vulnerable and valuable information content. Over the decades since ISO/IEC adopted it as an international standard, it has gradually evolved into a tech-centric IT, ICT or cyber-security standard. The third edition of ‘27002 continues along the same trajectory. The third edition misses numerous opportunities to encourage users to consider their “information risks” in order to determine whether various controls are even needed to avoid or mitigate the risks, and if so what controls are appropriate, taking account of their effectiveness, costs, value, reliability etc . It is as if the controls laid out in the standard are not merely good practices worth considering under various circumstances, but required or mandatory to the extent that not implementing them might perhaps be considered inept, unprofessional or bad practice. There is a subtle presumption that most if not all the controls should be employed by all organisations, regardless of the diversity of organisations in scope and their differing information risks. This is misleading, and has remained an issue for several years. I miss the ‘control objectives ’ from BS 7799: these succinctly explained what the controls were expected to achieve, giving them a business-related purpose that was readily interpreted in the particular context of an individual organisation. If management accepted that an objective was valid, the controls were worth considering not in the sense of being obligatory or even recommended, so much as examples of the kinds of things that could be put in place to achieve the objective. In the third edition, the risk-based control objectives have become watered-down and often self-serving ‘purposes’, with little to no explicit reference to the organisation’s information risks that the suggested controls are supposed to mitigate - a retrograde step as far as I’m concerned ... potentially presenting an opportunity to fill in the gaps (watch this space!). However, some experts complained of ‘challenging conversations’ between auditors and management: I suspect the underlying issue there was a failure to understand the true nature of information risk and risk treatment options. While the restructured third edition is readable and usable on paper, the tagging and cross-linking strongly of controls favours database applications (even something as simple as Excel) allowing users to filter or select and sort the controls by whatever criteria or questions they pose - for instance, “Which physical security controls are relevant to privacy?” or “What preventive controls do not involve technology?”. Given a suitable database application, the sequence is almost irrelevant compared to the categorisation, tagging and description of the controls. It will be interesting to see how this turns out. I am dismayed that the standard has been infected with the “cyber” virus, begging questions about definition and interpretation. Some contributors wanted the standard to cover both information security and cybersecurity controls, implying that they consider those to be distinct domains, while others first want to understand the differences before classifying controls ... and I must say I‘m in the second group. What is the true meaning and scope of “cybersecurity”, in fact ? Similarly, the committee hoped to resolve confusion over the meaning of “policy” in the second edition by distinguishing three variants or hierarchical levels in the third : “Information security policy ” refers to the overall, high-level corporate policy at the peak of the classical policy pyramid, approved by ‘top management’. ‘Strategy’ might have been a better term for this, at the risk of creating yet more confusion, but the ISO management systems standard boilerplate requires 'policy', so 'policy' (singular) it is; “Topic-specific policy ” refers to mid-level policies e.g. topic-specific policies on access control and clear desk and clear screen” (the latter sounds, to me, more like a rule than a mid-level policy ... and indeed, as expressed by the project team, the topic-specific policy concept includes guidelines and rules, making this layer a blend, transition or link between the upper and lower levels). These are aligned with and support the high level policy, approved by ‘the appropriate management level’, and [within reason] may be adapted/interpreted locally by departments, business units etc . where their specific contexts (information risks, security requirements, business situations, locations etc .) differ from the overall corporate context; “Rule ” is the lowest, most detailed/specific level, defined as an “accepted principle or instruction that states the organisation’s expectations on what should be done, what is allowed or not allowed” (I’m not sure an organisation, per se , can ‘expect’ anything, or should have expectations on rather than of something: in a corporate context, rules are generally imposed by management on behalf of the organisation and its stakeholders ... but this definition was a bone of contention within SC 27 so a compromise is needed). Up Up Up This page last updated: 14 April 2026

Back Up Next ISO/IEC 27043 ISO/IEC 27043:2015 — Information technology — Security techniques — Incident investigation principles and processes (first edition) Up Abstract “ISO/IEC 27043:2015 provides guidelines based on idealized models for common incident investigation processes across various incident investigation scenarios involving digital evidence. ...” [Source: ISO/IEC 27043:2015] Introduction The fundamental purpose of the digital forensics standards ISO/IEC 27037 , ISO/IEC 27041 , ISO/IEC 27042 , ISO/IEC 27043 and ISO/IEC 27050 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, it is hoped that standardisation 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, even across multiple jurisdictions. Scope The standard concerns the principles behind, and the forensic processes involved in, investigating digital incidents. Structure Main clauses: 5: Digital investigations 6: Digital investigation processes 7: Readiness processes 8: Initialization processes 9: Acquisitive processes 10: Investigative processes 11: Concurrent processes 12: Digital investigation process model schema Annex A: Digital investigation processes: motivation for harmonization Status The current first edition was published in 2015 and confirmed unchanged in 2020. It was due for periodic review again in 2025 ... and looks likely to be confirmed as-is. Commentary I am puzzled why SC 27 publishes and maintains several distinct forensics standards covering different aspects of forensics, when they are in reality complementary parts of the same process: ISO/IEC 27037 concerns the initial capturing of digital evidence. ISO/IEC 27041 offers guidance on the assurance aspects of digital forensics e.g. ensuring that the appropriate methods and tools are used properly. ISO/IEC 27042 covers what happens after digital evidence has been collected i.e. its analysis and interpretation. This standard covers the broader incident investigation activities, within which forensics usually occur. ISO/IEC 27050 (in 4 parts) concerns electronic discovery ... which is pretty much what the other standards cover. British Standard BS 10008 “Evidential weight and legal admissibility of electronically stored information (ESI), Specification.” may also be of interest. A multi-part standard would make more sense to me, with a “part 1” overview explaining how the jigsaw pieces fit together. Up Up Up This page last updated: 22 February 2026

Back Up Next ISO/IEC TS 27115-3 ISO/IEC TS 27115-3 — Information security, cybersecurity and privacy protection — Cybersecurity of system of systems — Part 3: Security profiles [DRAFT] Up Abstract ?? Introduction Using concepts and terms in the style of the C ommon C riteria such as T arget O f E valuation and security profile, part 3 intends to explain how to evaluate a complex system against the security architecture. Scope [ISO/IEC TS 27115-3] provides a framework to describe security profiles based on ISO/IEC TS 27115-1 and ISO/IEC TS 27115-2 . The framework uses basic architecture concepts to enable the definition of architecture-based security profiles and composition of profiles. Structure ?? Status Part 3 is due out in 2029. It is currently at W orking D raft stage. Commentary TBA Up Up Up This page last updated: 2 April 2026

Back Up Next 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) often require collaboration and coordination between the I ncident R esponse T eams of several organisations, often in different countries. In addition to those diectly affected, Internet and cloud service providers, law enforcement and maybe the security services may be involved. 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 clauses: 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 Exercises are an excellent way to plan, practice, prove and improve the coordinated interactions required in an actual incident - from the ground floor operations through the specialist and management levels to the executives in the penthouse suite, among all the participants. Stress levels relating to the ongoing incident are obviously lower in a simulation compared to reality, but stresses relating to the processes being exercised may be higher due to their unfamiliarity: better to get a grip on them now than just wing-it in an actual crisis. Modelling is another useful technique, perhaps using AI-enhanced "digital twins" to simulate the individuals, teams and organisations responding. Finally, I'll point out that suppliers of cloud, Internet, forensics, insurance and other business services have more opportunities than most to gain competence and expertise in this area as they support multiple clients through various crises, learning by doing. That's potentially a valuable and hence marketable commercial advantage. Up Up Up This page last updated: 22 February 2026

Back Up Next 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 clauses: 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 or donor content for this standard, with editorial changes to suit the more formal ISO/IEC style. Up Up Up This page last updated: 12 February 2026

Back Up Next ISO/IEC TS 27568 ISO/IEC TS 27568 — Security and privacy of digital twins [DRAFT] Up Abstract ISO/IEC TS 27568 "provides a guidance for organizations to address security and privacy risks in digital twin systems. The guidance in this document helps organizations identify security and privacy risks throughout the digital twin systems lifecycles system lifecycle, and establishes mechanisms to evaluate the consequences of such risks and treat risks them. This document is applicable to all types and sizes of organizations, including public and private companies, government entities, academia, research institutions and not-for- profit organizations, that develop or use digital twin systems." Source: ISO.org page about the draft Introduction Digital twins are essentially digital analogues, representations or realistic models of real-world situations used for various purposes. Scope The standard (a T echnical S pecification) is intended to address the security and privacy implications of digital twins, supporting other digital twinning standards as the field develops at pace. Structure ?? Status Project set out in 2025. Publication of the T echnical S pecification is planned for 2028. Currently at W orking D raft stage. Commentary TBA Up Up Up This page last updated: 2 April 2026

Back Up Next ISO/IEC 27028 ISO/IEC 27028 — Information security, cybersecurity and privacy protection — Guidance on using information security control attributes [DRAFT] Up Abstract ISO/IEC 27028 "provides guidance on the use of information security control attributes. The guidance given in this document is generic and is intended to be applicable to all organizations, regardless of type, size, or nature.” [Source: ISO's page on ISO/IEC DIS 27028 ] Introduction In 2022, the third edition of ISO/IEC 27002 introduced a new structure for information security controls, based around ‘themes’ and ‘attributes’, noting that organisations may prefer to use their own attributes as well or instead. ISO/IEC 27028 will explain how to do that, in practice, suggesting a variety of attributes with which to classify or characterise, select or design information security controls in various ways for various information security and business management purposes. Scope The standard will expand upon the five control attributes in ISO/IEC 27002 i.e. Control type. Information security properties. Cybersecurity concepts. Operational capabilities. Security domains. It will provide practical guidance on how to use the specified attributes and how to develop additional attributes and attribute values where appropriate. ISO/IEC 27002 casually mentioned that this is possible but did not explain. Structure Main sections: 5: Overview on [of] attribute approach 6: Additional attributes Some 16 control attributes are suggested in addition to those five from ISO/IEC 27002 , and there is advice on extending the approach to other information security controls and control attributes. Status Work started on this project in 2021. It may be published as a T echnical S pecification rather than a full I nternational S tandard since the approach is innovative and not yet proven by experience ... but we will see. The first D raft I nternational S tandard was approved by SC 27 in November 2025, with comments leading to the release of a second DIS in December and votes due by early February 2026. Publication is expected towards the middle or second half of 2026. Commentary There has been significant interest and support for the control attributes concept from ISO/IEC JTC 1/SC 27 . When it is finally published, I believe ISO/IEC TS 27028 will be a valuable contribution to the field, expanding on the value and utility of ISO/IEC 27002 . Meanwhile, a free guideline explains how control attributes can be used creatively within an ISO27k ISMS, or indeed any other information risk-based framework that involves mitigating unacceptable risks using appropriate information security controls. Thinking about which attributes or characteristics of controls are relevant, plus the importance of the corresponding attribute values or parameters, helps round-off the analysis and select or design appropriate controls. As usual, exploring objectives in detail generates insight that leads to a more successful outcome. Up Up Up This page last updated: 11 February 2026

Back Up Next ISO/IEC 27070 ISO/IEC 27070:2021 — Information technology — Security techniques — Requirements for establishing virtualized roots of trust (first edition) Up Abstract ISO/IEC 27070"specifies requirements for establishing virtualized roots of trust.” [Source: ISO/IEC 27070:2021] Introduction The integrity and hence value of some security functions and subsystems (particularly those relating to cryptography) relies on their being based on trustworthy foundations known as the R oot o f T rust. Special RoT security arrangements are necessary to negate threats involving low-level exploitation of data-processing chips, devices or systems, in turn compromising the higher-level firmware, device drivers, operating system and application software that build upon the RoT. Whereas trusted computing generally involves some form of H ardware S ecurity M odule (e.g. an ISO/IEC 11889 T rusted P latform M odule) providing various cryptographic functions and key storage in a physically secure tamper-resistant enclosure, that architecture is not well suited to cloud computing. In the cloud, systems are virtualised, hence they cannot readily access and rely directly upon hardware-based RoT in the conventional manner. Scope The standard specifies functional requirements and information security controls supporting the provision of trustworthy foundations for cloud computing environments, where V irtual M achines are dynamically created to provide cloud services. Structure Main clauses: 5: Functional view - describes the architecture in functional/modular terms 6: Activity view - describes how the functional modules deliver the desired level of trusted computing. Annex A: relationship between activity and functional views Status The current first edition was published in 2021 . Commentary The trust, risk and security implications of this are, frankly, above my pay grade. As my withered little old brain understands it, the standard aims to establish a rock-solid foundation on which to build the house of cards delivering cloud computing services. Regardless of all the information risks and security controls at higher levels (of which there are many), providing a sound, trustworthy platform makes RoT a fundamental security requirement. Otherwise, we’re erecting skyscrapers in the swamp. Up Up Up This page last updated: 22 February 2026