Search Results

Back Up Next ISO/IEC 27033-1 ISO/IEC 27033-1:2015 — Information technology — Security techniques — Network security — Part 1: Overview and concepts (second edition) Up Abstract ISO/IEC 27033 part 1 “provides an overview of network security and related definitions. It defines and describes the concepts associated with, and provides management guidance on, network security. (Network security applies to the security of devices, security of management activities related to the devices, applications/services, and end-users, in addition to security of the information being transferred across the communication links.) ... Overall it provides an overview of this International Standard and a 'road map' to all other parts.” [Source: ISO/IEC 27033-1:2015] Introduction Part 1 revised and replaced ISO/IEC 18028 part 1. It provides: A roadmap and overview of the concepts and principles underpinning the remaining parts of ISO/IEC 27033. A glossary of information security terms specific to networking. Guidance on a structured process to identify and analyse network security risks and hence define network security control requirements, including those mandated by relevant information security policies. An overview of the controls supporting network technical security architectures and related technical controls, as well as non-technical controls plus other technical controls that are not solely related to network security (thus linking to ISO/IEC 27001 , ISO/IEC 27002 and ISO/IEC 27005 plus other ISO27k standards as they are released). Scope Extends the security management guidelines provided in ISO/IEC TR 13335 and ISO/IEC 27002 etc . by detailing the specific operations and mechanisms needed to implement network security controls in a wider range of network environments, providing a bridge between general information security management issues and the specifics of implementing largely technical network security controls (e.g . firewalls, IDS/IPS, message integrity controls etc .) Structure Main clauses: 6: Overview 7: Identifying risks and preparing to identify security controls 8: Supporting controls 9: Guidelines for the definition and implementation of network security 10: Reference network scenarios - risks, design techniques and control issues 11: 'Technology ' topics - risks, design techniques and control issues 12: Develop and test security solution 13: Operate security solution 14: Monitor and review solution implementation Annex A: Cross-reference between ISO/IEC 27001 Annex A and ISO/IEC 27002 network security-related controls and ISO/IEC 27033-1 Annex B: Example template for a SecOPs document Status ISO/IEC 27033-1 revised and replaced ISO/IEC 18028-1, which in turn superceded ISO/IEC TR 13335-5. The first edition was published in 2009 . The current second edition was published in 2015 and confirmed unchanged in 2021. An extended scope for the ISO/IEC 27033 network security standards is under consideration to catch up with recent and emerging technologies such as cloud computing, zero trust, IoT and AI. Consequently the initial routine standards revision project was stopped and restarted at P reliminary W ork I nstruction stage in 2025. Commentary Part 1 mentions requirements such as non-repudiation and reliability in addition to the classical CIA triad (confidentiality, integrity and availability). It provides a reasonably technical overview of network security despite barely any reference to the OSI or TCP/IP network stacks! At present, the ISO/IEC 27033 standards are largely (entirely?) concerned with digital data networks, but there are other kinds of networks - such as business networks, social networks, professional networks, criminal networks and socio-political/cultural networks - all with differing risks and security concerns. So, should the ISO/IEC 27033 set be extended to cover those too? If so, how? It is not exactly obvious what kinds of guidance might usefully be offered in these other areas - in fact, formally speaking, it is not even entirely clear what ‘networks’ are. Anyway, that’s something to bear in mind. SC 27, meanwhile, tends to stick to the knitting i.e. IT/cyber security, in accordance with its defined scope. Furthermore, I feel the information risk and security aspects of industrial shop-floor O perational T echnology networks are inadequately covered by current ISO/IEC 27033 standards, a significant omission. The networking protocols, risks and controls vary, while the gradual convergence of IT and OT is bound to affect network security in both domains. Up Up Up This page last updated: 23 February 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 in 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 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, so part 2 is officially 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: 13 February 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: 13 April 2026

Back Up Next ISO/IEC 27033-7 ISO/IEC 27033-7:2023 Information technology — Network security — Part 7: Guidelines for network virtualization security (first edition) Up Abstract ISO/IEC 27033 part 7 "aims to identify security risks of network virtualization and proposes guidelines for the implementation of network virtualization security. Overall, [ISO/IEC 27033-7] intends to considerably aid the comprehensive definition and implementation of security for any organization’s virtualization environments. It is aimed at users and implementers who are responsible for the implementation and maintenance of the technical controls required to provide secure virtualization environments.” [Source: ISO/IEC 27033-7:2023] Introduction Network virtualization was defined in ISO/IEC TR 29181-1:2012 as "technology that enables the creation of logically isolated network partitions over shared physical network infrastructures so that multiple heterogeneous virtual networks can simultaneously coexist over the shared infrastructures. Note 1 to entry: Network virtualization allows the aggregation of multiple resources and makes the aggregated resources appear as a single resource." For context, the same 2012 standard concerned "Future Network", defined as "network of the future which is made on clean-slate design approach as well as incremental design approach; it should provide futuristic capabilities and services beyond the limitations of the current network, including the Internet". Scope Within the multipart network security standard ISO/IEC 27033, part 7 addresses information risks and security controls applicable to network virtualisation. Structure Main clauses: 5: Overview 6: Security threats 7: Security recommendations 8: Security controls 9: Design techniques and considerations Annex A: Use cases of network virtualization Annex B: Detailed security threat description of network virtualization Status The current first edition of part 7 was published in 2023 . Commentary Whereas the standard outlines some “security threats” or “security issues” - generic examples of types of incident (such as “Insider attacks: an administrator tampers image or changes security configurations”) - it does not explain which information security controls address the identified “security threats/issues”, nor conversely which information risks the suggested information security controls are intended to mitigate: there is no cross-referencing between the two, hence it is unclear how users are meant to identify, select or prioritise whichever controls are most appropriate for their situations. So much for the “implementation guidelines”! Up Up Up This page last updated: 23 February 2026

Back Up Next ISO/IEC 27566-3 ISO/IEC 27566-3 — Information security, cybersecurity and privacy protection — Age assurance systems — Part 3: Approaches to analysis or comparison [DRAFT] Up Abstract ISO/IEC 27566 part 3 "establishes considerations for analysing, comparing or differentiating the characteristics of age assurance systems or components. The document includes metrics, elements and indicators of effectiveness for age assurance systems or components." [Source: C ommittee D raft] Introduction Part 3 concerns assurance regarding the accuracy of age verification approaches through techniques to measure, analyse and compare approaches - for example when adult website or application designers are considering various ways to distinguish children from adult users. Scope Measuring relevant characteristics and analysing them in order to assess the suitability of various age assurance approaches. Structure Main clauses (so far - in the 2nd C ommittee D raft): 5: Approaches to analysis or comparison 6: Indicators of effectiveness 7: Analysis considerations 8: Characteristics and measurements for age assurance components 9: Reporting of analysis results Annex A: Effectiveness analysis Annex B: Example analysis report Annex C: Indicative effectiveness banding Status The standard development project set off in 2023. This was originally destined to become part 2, then shifted to part 3. Part 3 is at C ommittee D raft stage. Commentary See also ISO/IEC 27566-1 and ISO/IEC 27566-2 . Up Up Up This page last updated: 2 April 2026

Back Up Next ISO/IEC 27035-1 ISO/IEC 27035-1:2023 — Information technology — Information security incident management — Part 1: Principles and process (second edition) Up Abstract ISO/IEC 27035 part 1 “is the foundation of the ISO/IEC 27035 series. It presents basic concepts, principles and process with key activities of information security incident management, which provide a structured approach to preparing for, detecting, reporting, assessing, and responding to incidents, and applying lessons learned. The guidance on the information security incident management process and its key activities given in [ISO/IEC 27035-1] are generic and intended to be applicable to all organizations, regardless of type, size or nature. Organizations can adjust the guidance according to their type, size and nature of business in relation to the information security risk situation. [ISO/IEC 27035-1] is also applicable to external organizations providing information security incident management services.” [Source: ISO/IEC 27035-1:2023 ] Introduction Information security controls are imperfect in various ways: controls can be overwhelmed or undermined (e.g. by competent hackers, fraudsters or malware), fail in service (e.g. authentication failures), work partially or poorly (e.g. slow anomaly detection), or be more or less completely missing (e.g . not [yet] fully implemented, not [yet] fully operational, or never even conceived due to failures upstream in risk identification and analysis). Consequently, information security incidents are bound to occur to some extent, even in organisations that take their information security extremely seriously. Managing incidents effectively involves detective and corrective controls designed to recognize and respond to events and incidents, minimize adverse impacts, gather forensic evidence (where applicable) and in due course ‘learn the lessons’ in terms of prompting improvements to the ISMS, typically by improving the preventive controls or other risk treatments. Information security incidents commonly involve the exploitation of previously unrecognised and/or uncontrolled vulnerabilities, hence vulnerability management (e.g. applying relevant security patches to IT systems and addressing various control weaknesses in operational and management procedures) is part preventive and part corrective action. The ISO/IEC 27035 standards concern managing information security events, incidents and vulnerabilities, expanding on the information security incident management section of ISO/IEC 27002 . The standards describe a 5-phase process: Prepare to deal with incidents e.g. prepare an incident management policy, and establish a competent team to deal with incidents; Identify and report information security incidents; Assess incidents and make decisions about how they are to be addressed e.g. patch things up and get back to business quickly, or collect forensic evidence even if it delays resolving the issues; Respond to incidents i.e. contain them, investigate them and resolve them; Learn the lessons - more than simply identifying the things that might have been done better, this stage involves actually making changes that improve the processes. Scope Part 1 outlines the concepts and principles underpinning information security incident management and introduces the remaining part/s of the standard. It describes an information security incident management process consisting of five phases, and says how to improve incident management. Structure Main clauses: 4: Overview 5: Process Annex A: Relationship to investigative standards Annex B: Examples of information security incidents and their causes Annex C: Cross-reference table of ISO/IEC 27001 to the ISO/IEC 27035 series Annex D: Considerations of situations discovered during the investigation of an incident Status The first edition of ISO/IEC 27035 was published as a single standard in 2011 , replacing ISO TR 18044. It was subsequently split into four parts ... The first edition of part 1 was published in 2016 . Having been revised for ISO/IEC 27002:2022 the current second edition was published in 2023 . Commentary Information security incident management is described overall, and then as a process with five phases: Plan and prepare: establish an information security incident management policy, form an I ncident R esponse T eam etc. Detect and report: someone has to spot and report “events” that might be or turn into incidents; Assess and decide: someone must assess the situation to determine whether it is in fact an incident; Respond: contain, eradicate, recover from and forensically analyse the incident, where appropriate; Learn lessons: make systematic improvements to the organisation’s management of information risks as a consequence of incidents experienced. Annexes give examples of information security incidents and cross-references to eForensics and ISO/IEC 27001 standards. In addition to actual events and incidents, we should be systematically exploring and learning from near-misses i.e. situations that thankfully caused little if any impact on the business, such as: An alert worker noticing and reporting a phishing or B usiness E mail C ompromise attack; An infection by defective/nonfunctional malware or scareware; A colleague spotting confidential papers left on someone’s office desk after they have gone home, and tidying them away; A manager casually disclosing a commercially-sensitive detail in conversation with a supplier or competitor who appears not to have noticed it; A neighbouring office being ram-raided, burgled, vandalised, burnt or flooded; A competitor, business partner, customer or supplier suffering a noteworthy incident; Any incident from which the organisation successfully recovered e.g. by restoring backups; Incidents that, by sheer good fortune, were trivial (incidental!), and could easily have been much worse e.g. if they had occurred at a different time or day or point in the business cycle, in other circumstances, or if they had not been spotted so soon. Although, in the absence of significant impacts and with finite resources already stretched by other priorities, it is tempting for management simply to ignore close-shaves and minor incidents, they present opportunities to: Identify and study information risks (threats, vulnerabilities, exposures, impacts ...) that might otherwise have remained unrecognised or ignored; Evaluate the risk management approach, particularly the associated decisions and controls; Tease out and address specific or indeed general weaknesses with the approach, making improvements; Gain assurance on the aspects that worked well, or at least went to plan; Generate case study materials for awareness and training purposes, and information to feed into future risk assessments, including statistics/metrics. We might not be quite so lucky next time! The aviation industry is a shining example of this approach, with a comprehensive no-blame strategy to identify, report, address and improve as a result of [literal and figurative] near-misses. Notwithstanding the title, the ISO/IEC 27035 standards specifically concern incidents affecting IT systems and networks although the fundamental principles apply also to incidents affecting other forms of information such as paperwork, knowledge, intellectual property, trade secrets and personal information. Unfortunately (as far as I’m concerned), the language is almost entirely IT-related. That, to me, represents an opportunity squandered: ISO27k covers more than IT/cybersecurity. How are organisations meant to handle incidents such as fraud and piracy where the IT elements are incidental to the business? Explicitly describing the information risks that the incident management process addresses would enhance this standard, I feel. Since it is literally impossible to detect and respond to every single incident, a proportion of the risk has to be accepted (e.g. ‘low and slow’ attacks fly under the radar, while many hacks and malware attacks involve deliberately evading or neutralising both detective and preventive controls), while some might be shared with third parties (e.g. business partners and insurers) or avoided (e.g. by putting even more emphasis on preventive controls). Also, the response to a major incident may well involve invoking business continuity arrangements, hence this standard should in my opinion integrate with or properly cite ISO 22301 etc. Up Up Up This page last updated: 23 February 2026

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

Back Up Next ISO/IEC 27041 ISO/IEC 27041:2015 — Information technology — Security techniques — Guidance on assuring suitability and adequacy of incident investigative method (first edition) Up Abstract “ISO/IEC 27041:2015 provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are "fit for purpose". ...” [Source: ISO/IEC 27041:2015] 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, 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 The primary focus of this standard is on assurance for the forensics processes and tools used in the investigation of digital evidence. Credibility, trustworthiness and integrity are fundamental requirements for all forensics methods: this standard promotes the assurance aspects of investigating digital evidence. The standard offers guidance on assuring the suitability and adequacy of the forensic methods used to investigate digital evidence, describing methods through which all stages of the investigation process can be shown to be appropriate (proper and suitable in themselves, and correctly performed). Structure Main clauses: 5: Method development and assurance 6: Assurance models 7: Production of evidence for assurance Annex A: Examples Status The current first edition was published in 2015 and confirmed unchanged in 2021. 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. This standard 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. ISO/IEC 27043 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 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. [ISO/IEC 27090] 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. [ISO/IEC 27090] 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 F inal 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 have limited intelligence, so systems utilising A rtificial I ntelligence don’t always react or behave as they should, or as expected. Furthermore, there are numerous potential threats in the operating environments, presenting numerous risks. Since smart systems provide their AI capabilities using conventional computer systems and networks, the AI-related risks add to those already present - the usual gamut of information c onfidentiality, i ntegrity and a vailability concerns, plus risks relating to the way the 'systems' (as a whole) are designed, developed, tested, implemented (integrated into existing infrastructures and processes), used, monitored, managed, maintained and eventually decommissioned. There are governance, management and procedural aspects to this with strategic, tactical and operational implications, aside trom the CIA/technical ones. Bottom line: AI security is complex and difficult! Scope ISO/IEC 27090 will guide organisations on addressing [some] security threats to A rtificial I ntelligence systems. It will: Discuss the potential organisational consequences of security threats that might compromise AI systems at various points in their lifecycles, drawing on ISO/IEC 22989 and ISO/IEC 5338 *; and Explain how to detect and mitigate such threats (risks), drawing on ISO/IEC 42001 and ISO/IEC 38507 *. * Several other references are noted in the text, reflecting the huge amount of interest in this area and the proliferation of guidance. Structure The main clauses are likely to be: 5: Application of information security 6: Threats to AI systems 7: Mitigations and their interactions with threats and other mitigations Annex A: Mapping attack to AI system life cycle and to assets Annex B: AI-specific versions of conventional attacks The standard will cover at least a dozen AI 'threats' (scenarios or types of incident involving deliberate attacks) 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 or prompt 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, such as the model itself plus its training data and inputs/prompts; Prompt injection and output injection - downstream attacks exploiting vulnerabilities in operational AI systems. For each 'threat', the standard will offer about a page of advice: Describing/characterising 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 ISO and non-ISO standards. Status ISO/IEC JTC 1/SC 27/WG 4 started developing this standard in 2022. The standard is now at F inal D raft I nternational S tandard stage, likely to be published later in 2026. Commentary Unfortunately it appears that the published standard will make imprecise, unclear and sometimes inappropriate use of terminology relating to information risk and security. For example, are ‘security failures’ vulnerabilities, control failures, events, incidents or compromises maybe? Are ‘threats’ attacks, information risks, threat agents, incidents, scenarios, some sort of blend of those or something else entirely? Detecting ‘threats’ (which generally refers to impending or in-progress attacks) is a focal point for the standard, perhaps implying that security controls cannot respond to undetected attacks ... which may be generally true for active responses but not for passive, general purpose controls. As so often with ‘cybersecurity’, the standard is primarily concerned with active, deliberate, malicious, focused attacks on AI systems by motivated and capable adversaries , largely disregarding the possibility of natural and accidental threats such as design flaws, bugs and power issues, and threats from within i.e. insider threats within the organisations developing and using AI systems. 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 of publicly-accessible generative AI systems such as ChatGPT during 2023 put a rather different spin on this area. The scope excludes ‘robot wars’ where AI systems are used to attack and exploit 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 not considered in this standard: the whole thing is quite pessimistic, focusing on the negatives, the problems associated with AI. However, the hectic pace of progress in the AI field is clearly a factor. This standard contributes to the field, complementing other AI security standards. We can expect updates as AI matures. Experience of actual AI-related incidents is already starting to accumulate and our knowledge concerning the risks is improving all the time. Up Up Up This page last updated: 11 March 2026

Back Up Next ISO/IEC 27037 ISO/IEC 27037:2012 — Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence (first edition) Up Abstract “ISO/IEC 27037:2012 provides guidelines for specific activities in the handling of digital evidence, which are identification, collection, acquisition and preservation of potential digital evidence that can be of evidential value. It provides guidance to individuals with respect to common situations encountered throughout the digital evidence handling process and assists organizations in their disciplinary procedures and in facilitating the exchange of potential digital evidence between jurisdictions. ISO/IEC 27037:2012 gives guidance for the following devices and circumstances: digital storage media used in standard computers like hard drives, floppy disks, optical and magneto optical disks, data devices with similar functions; mobile phones, Personal Digital Assistants (PDAs), Personal Electronic Devices (PEDs), memory cards; mobile navigation systems; digital still and video cameras (including CCTV); standard computer with network connections; networks based on TCP/IP and other digital protocols; and devices with similar functions as above. The above list of devices is an indicative list and not exhaustive.” [Source: ISO/IEC 27037:2012] Introduction This standard provides guidance on identifying, gathering/collecting/acquiring, handling and protecting/preserving digital forensic evidence i.e. “digital data that may be of evidential value” for use in court. 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, 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. One of the most critical issues in forensic investigations is the acquisition and preservation of evidence in such a way as to ensure its integrity. As with conventional physical evidence, it is crucial for the first and subsequent responders (defined as “Digital Evidence First Responders” and “Digital Evidence Specialists”) to maintain the chain of custody of all digital forensic evidence, ensuring that it is gathered and protected through structured processes that are acceptable to the courts. More than simply providing integrity, the processes must provide assurance that nothing untoward can have occurred. This requires that a defined baseline level of information security controls is met or exceeded. Digital forensic evidence can come from any electronic storage or communications media such as smartphones and other smart devices, computers, game consoles etc . plus online/network/cloud storage. By its nature, digital forensic evidence is fragile - it can be easily damaged or altered due to improper handling, whether by accident or on purpose. Prior to the release of ISO/IEC 27037, there were no globally-accepted standards on acquiring digital evidence, the first step in the process. Police have developed their own national guidelines and procedures for the acquisition and protection of electronic evidence. However, this creates issues when cross-border crimes are committed since digital forensic evidence acquired in one country may need to be presented in the courts of another. Evidence that may have been acquired or protected without the requisite level of security may be tainted or legally inadmissible. Scope The standard provides detailed guidance on the identification, collection and/or acquisition, marking, storage, transport and preservation of electronic evidence, particularly to maintain its integrity. It defines and describes the processes through which evidence is recognized and identified, documentation of the crime scene, collection and preservation of the evidence, and the packaging and transportation of evidence. The scope covers ‘traditional’ IT systems and media rather than vehicle systems, cloud computing etc. The guidance is aimed primarily at first responders. Every country has its own unique legislative system. A crime committed in one jurisdiction may not even be regarded as a crime in another. The challenge is to harmonize processes across borders such that cybercriminals can be prosecuted accordingly. Therefore, a means to allow and facilitate the exchange and use of reliable evidence (i.e. an international standard on acquiring digital evidence) is required. “Digital evidence”, meaning information from digital devices to be presented in court, is interpreted differently in different jurisdictions. For the widest applicability, the standard avoids using jurisdiction-specific terminology. It does not cover analysis of digital evidence, nor its admissibility, weight, relevance etc . It also does not mandate the use of particular tools or methods. Structure Main clauses: 5: Overview 6: Key components of identification, collection, acquisition and preservation of digital evidence 7: Instances of identification, collection, acquisition and preservation Annex A: Digital Evidence First Responder core skills and competency description Annex B: Minimum documentation requirements for evidence transfer Status The current first edition was published in 2012 and confirmed unchanged in 2018. Commentary This standard concerns the initial capturing of digital evidence. In addition: 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. ISO/IEC 27043 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:2008 “Evidential weight and legal admissibility of electronic information. Specification.” may also be of interest. I don’t understand why SC 27 maintains several distinct forensics standards, covering different aspects of forensics, when they are in reality complementary parts of the same process. A properly structured multi-part standard would make more sense to me, with an overview part 1 explaining how the jigsaw pieces fit together. Up Up Up This page last updated: 22 February 2026