Search Results

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

Back Up Next ISO/IEC 27554 ISO/IEC 27554:2024 — Information security, cybersecurity and privacy protection — Application of ISO 31000 for assessment of identity-related risk [first edition] Up Abstract ISO/IEC 27554 "provides guidelines for identity-related risk, as an extension of ISO 31000:2018. More specifically, it uses the process outlined in ISO 31000 to guide users in establishing context and assessing risk, including providing risk scenarios for processes and implementations that are exposed to identity-related risk. [ISO/IEC 27554] is applicable to the risk assessment of processes and services that rely on or are related to identity. [ISO/IEC 27554] does not include aspects of risk related to general issues of delivery, technology or security.” [Source: ISO/IEC 27554:2024] Introduction This standard facilitates the application of the ISO 31000 risk management guidelines to identity management , supporting or supplementing various identity management standards. It applies the ISO 31000 risk management process to establish the context and assess risk, suggesting some risk scenarios for the processes and implementations specifically involving identity-related risk. Scope The standard applies to the assessment, specifically, of risks associated with ‘services and transactions’ that rely on or are related to identity management, excluding risks arising generally from delivery, technology or security. It can be used in conjunction with other standards concerning controls to protect identity information. The standard succinctly explains identity-related risk definition, context and impacts. It covers the central part of the classical ISO 31000-style risk management process, excluding risk monitoring and review, and risk communication and consultation. Structure Main sections: 4: Principles - simply refers to the ISO 31000 principles 5: Framework - refers to the ISO 31000 approach 6: Process - refers to the ISO 31000 risk management process 7: Identity-related risk assessment 8: Identity-related context establishment 9: Identity-related risk identification 10: Identity-related risk analysis 11: Identity-related risk evaluation 12: Identity-related risk treatment - refers to ISO 31000 ... with appendices on related standards on risk and identity management, and “risk impact assessment”. Status The current first edition was published in 2024 . Commentary ISO 31000 remains useful, along with ISO/IEC 27005 ... begging questions about the value of another standard in this area, especially one so naively and narrowly focused. In my jaundiced opinion, the standard misrepresents the probability element of risk, equating it to the amount of control applied rather than the predicted rate of occurrence. Conflating risk and control could be seen as a fundamental problem with the approach, confusing inherent (pre-treatment) and residual (post-treatment) risk. Language/terminological issues (e.g. “B.1 Assessing the degree of impact of a consequence”) beg further questions. Rewriting this standard in plain English might help bring such issues into the disinfecting glare of sunlight. The use of ‘degrees’, ‘levels’, ‘scales’ and ‘categories’ of risk, and ‘strength’ of identity-related processes (presumably controls?) indicates a subjective and qualitative approach ... and yet the standard suggests “collapsing the distinct indicators into a single combined value” at one point and for unexplained reasons presents numeric values in a ‘Plot matrix’ ... at which point I’m afraid I completely lost the plot. Repeat after me: Ordinary arithmetic is inappropriate for ordinal numbers. Ordinary arithmetic is inappropriate for ordinal numbers. Ordinary arithmetic is inappropriate for ordinal numbers. ... Up Up Up This page last updated: 26 January 2026

Back Up Next ISO/IEC TR 27563 ISO/IEC TR 27563:2023 — Security and privacy in artificial intelligence use cases — Best practices (first edition) Up Abstract ISO/IEC TR 27563 "outlines best practices on assessing security and privacy in artificial intelligence use cases, covering in particular those published in ISO/IEC TR 24030. The following aspects are addressed: an overall assessment of security and privacy on the AI system of interest; security and privacy concerns; security and privacy risks; security and privacy controls; security and privacy assurance; and security and privacy plans. Security and privacy are treated separately as the analysis of security and the analysis of privacy can differ.” [Source: ISO/IEC TR 27563:2023 ] Introduction This T echnical R eport analyses and elaborates on the information security and privacy aspects of the 132 use cases for A rtificial I ntelligence/M achine L earning systems published in ISO/IEC TR 24030:2021 “Information technology - Artificial Intelligence (AI) - use cases”, and provides four additional use cases developed specifically for this TR. Scope The standard offers information security and privacy best practice guidance following analysis of ISO/IEC 24030 ’s use cases. Structure Main clauses: 5: Analysis of security and privacy 6: Templates for analysis 7: Supporting information Annex A: Additional use cases The information security and privacy implications for related groups of AI/ML use cases have been systematically analysed. The results are summarised in bar charts, followed by tables elaborating on the analyses in a standard format. Status The current first edition was published in 2023 . Commentary Cue tumbleweed ... Up Up Up This page last updated: 12 February 2026

General info about the ISO27k standards as a whole - their scope and objectives, the core standards, that sort of thing Previous Back to FAQ summary Next ISO27k standards What use is ISO27k for my organisation? For more on this, see the free ISMS business case template , part of the ISO27k Toolkit . Organisations that use the ISO27k standards gain worthwhile business benefits such as: Protecting valuable information : more specifically, information security enhances the confidentiality, integrity and/or availability of the information content, plus the associated processes, IT systems, networks, services etc ., without imposing excessive security that would prevent it being exploited for legitimate business purposes. Reducing losses : cost-effective security controls minimise the probability and severity of incidents caused deliberately (e.g. hacks, frauds, disinformation) or accidentally (e.g . floods, equipment failures, misconfigurations, inadvertent disclosures). Increasing assurance and trust : conformity with ISO/IEC 27001 and ISO/IEC 27701 demonstrates the organisation’s commitment towards good practices for information security and privacy respectively, plus more broadly support for compliance, ethics etc . to interested parties such as its customers, employees, partners, investors and the authorities. Achieving and maintaining compliance : various laws, regulations and contractual terms impose requirements relating to information security, privacy, accuracy, completeness, timeliness etc. Enhancing resilience : adequately protecting the information, IT systems and processes that are vital to important operational activities and business objectives reduces the possibility of costly disruptive incidents, adverse publicity, customer defections etc. Bolstering brands : aside from merely claiming to protect information, certified conformity with ISO/IEC 27001 and ISO/IEC 27701 enhances the organisation’s reputation. It is increasingly being expected or demanded by discerning customers, partners, investors and regulators - in other words, it confers competitive advantage. To be clear, there are costs associated with sound governance, risk management, security, privacy, assurance, incident management and so on ... but the business benefits outlined above substantially exceed the costs. The risks and costs involved in not taking security and privacy seriously can be existential, as is clear from the news headlines : serious hacking, ransomware and fraud incidents have devastated companies such as Sony Pictures Entertainment, Travelex and Barings Bank. Government institutions, defence, charities and healthcare organisations are far from immune. With such limited resources, S mall to M edium-sized E nterprises stand little chance if targeted, or if mistakes are made in their accounting and tax processes, IT systems and networks. Protecting and exploiting computer data and other forms of information is critically important for business and vital for human safety. There's no need to design a completely bespoke approach for your particular organisation. ISO27k constitutes a suite of internationally-recognised good security practices to suit any organisation, a stable platform on which to build. Are these IT security (cybersecurity) standards? When assessing and treating information risks, focus primarily on risks affecting critical business activities and information - the organisation's crown jewels'. The related computer systems, services and data play a secondary, supporting or enabling role, but don't forget the associated processes, people and relationships. Yes, largely, but they are not limited to IT. The ISO27k standards are about protecting and exploiting valuable information in all forms, not just computer systems, services, networks and data. Aside from computer data, 'information' includes: Printed or written information such as completed forms, signed contracts and rough notes; Information expressed verbally and visually at meetings, videoconferences, phone calls, briefings, seminars, even casual water-cooler or corridor conversations; Policies, procedures and work instructions; Shared corporate culture expressed through attitudes, priorities and ethics, plus personal angles such as body language, prejudices and bias; Knowledge and expertise in workers' heads, plus concepts, ideas, strategies, thoughts ...; Proprietary, business, personal, shared and public information; Intellectual property such as trade secrets, patents, trademarks and copyright information. Various business units, departments and teams generate or acquire, use and benefit from valuable information. IT Department is a custodian for much but not all of it. People throughout the business are accountable for both protecting and (legitimately) exploiting information in support of the organisation’s strategic objectives, with the guidance and assistance of IT, risk, security and other specialists. Suppliers of telecommunications and cloud services, plus utilities such as power and water, all have parts to play in maximising the value of information, while information is an integral and important part of the organisation's products supplied to customers, partners and the authorities (e.g. company accounts and tax reports). Where can I obtain [name any ISO27k standard]? Google and shop around for the best deal. Published ISO27k standards may be purchased directly from the ISO store or from the various national standards bodies and commercial organisations (agents). A few popular ISO27k standards are available through Amazon and other retailers. It is worth checking for localised/national versions of the standards. Several national standards bodies release translated versions of the standards in their own languages. They go to great lengths to ensure that the translations remain true to the originals, although naturally this takes time. ISO27k standards can be purchased as electronic documents or printed hardcopies. In addition to single-user PDFs, standards bodies may license electronic versions of the standards for multi-user internal corporate use, making the definitive standards readily available to workers on the intranet. Are there qualifications for ISO27k professionals? Hands-on ISO27k ISMS implementation and audit experience, ideally with several organisations, is by far the best ‘qualification’ in the field. General information security and technology audit qualifications (such as CISSP, CISM and CISA) can help, and business/management qualifications (such as MBAs) are well worthwhile. Not exactly, but there are certifications or designations. Unlike some IT certifications, ISO27k certifications lack a universally-recognized governing body. Common designations include ISO/IEC 27001 Lead Auditor (LA) , with various paths from formal training and audits to experience-based qualification, and ISO/IEC 27001/27002 Lead Implementer (LI) , which focuses on implementing the ISO27k standards. However, the value of such course-completion certificates is questionable. Demonstrable experience and competence are worth far more. Refer to ISO/IEC 27021 for guidance on “Competence requirements for information security management systems professionals”. Where else can I find answers on ISO27k and information security? Whatever your current state of expertise, actively engaging in study and debate gets you onto the personal development fast-track. Besides the ISO27k standards themselves, consider participating in professional social groups such as: ACM SIG SAC CSA ISC2 ISACA ENGAGE ISO27k Forum ISSA LinkeDin OWASP What is ISO/IEC? “ISO” is not an abbreviation but is in fact derived from the Greek word isos meaning equal. ISO primarily coordinates, facilitates and encourages collaboration between the national standards bodies, driving global standardisation. ISO is the name of the Swiss-based standards body known in English as the International Organization for Standardization . IEC is an abbreviation for the I nternational E lectrotechnical C ommission, another international standards body working closely with ISO on electrical, electronic and related technical standards. Standards developed jointly with ISO are prefixed “ISO/IEC” although in casual terms, we often shorten it to plain “ISO”. ISO/IEC also collaborate with other international organisations (both governmental and private sector) such as the ITU, the I nternational T elecommunication U nion. The ITU is primarily a trade body coordinating telecoms organisations and practices to enable worldwide communications. It allocates radio frequencies, for example, to minimise co-channel interference and encourage the manufacture of radio equipment that can be sold and used internationally. What are all those other obscure abbreviations? The processes are regimented - highly structured and consequently s-l-o-w. At several stages during the development of a standard, national standards body members are invited to vote and comment formally. The following abbreviations are used by the committee developing ISO27k standards: AG - A dvisory G roup AMD - Am end ment ARO - A pproved R S O riginator BRM - B allot R esolution M eeting CB - [IEC] C ouncil B oard CD - C ommittee D raft (1st CD, 2ndCD etc. , a quality-control phase, addressing editorial matters and typoos *) CDV - [IEC] C ommittee D raft for V ote COR - Technical Cor rigendum CS - [ISO] C entral S ecretariat DAM - D raft Am endment DCOR - D raft Technical Cor rigendum DIS - D raft I nternational S tandard (nearly there, down to proofreading, hold your breath *} DoC - D isposition o f C omments DR - Defect Report DTR - Draft Technical Report DTS - Draft Technical Specification FCD - F inal C ommittee D raft (ready for final approval (voting), but rarely used *) FDAM - Final Draft Amendment FDIS - F inal D raft/D istribution I nternational S tandard (just about ready to publish, final tweaks, pinch your nose and count to 100 *) HoD - H ead o f D elegation ICT - I nformation and C ommunications T echnology IEC - I nternational E lectrotechnical C ommission IPR - I ntellectual P roperty R ights IS - I nternational S tandard (published! Yay!) ISO - International Organization for Standardization ITTF - I nformation T echnology T ask F orce ITU - I nternational T elecommunication U nion ITU-R – ITU - R adiocommunications Sector ITU-T – ITU - T elecommunication Standardization Sector JCG - J oint C oordination G roup JTAB - J oint T echnical A dvisory B oard JTC 1 – [ISO + IEC] J oint T echnical C ommittee 1 JWG - J oint W orking G roup MB - (ISO) M ember B ody NB - N ational B ody NC - (IEC) N ational C ommittee NP - N ew P roject (the formal scoping phase, clarifying the proposal and formally seeking approval to proceed with the standards development project *) NWI - N ew W ork I tem OWG - O ther W orking G roup PAS - P ublicly A vailable S pecification PC - P roject C ommittee PDAM - P roposed D raft Am endment PDTR - P roposed D raft T echnical R eport PDTS - P roposed D raft T echnical S pecification PT - P roject T eam PWI - P reliminary W ork I tem - initial feasibility and outline scoping activities PWI - P reliminary W ork I tem RER - R eferencing E xplanatory R eport RG - R apporteur G roup RS - R eferenced S pecification SC - S ubC ommittee SD - S tanding D ocument - now known as Committee Document SG - S tudy G roup SMB - (IEC) S tandardization M anagement B oard SP - S tudy P eriod (preparing the NWIP …) SWG - S pecial W orking G roup TAG - (ISO) T echnical A dvisory G roup TC - T echnical C ommittee TMB - T echnical M anagement B oard TR - T echnical R eport (published! See next Q&A) TS - T echnical S pecification (published! See next Q&A) WD - W orking D raft (1st WD, 2ndWD etc . - content development “preparatory” drafting phase WG - W orking G roup Aside from international standards, what are TRs and TSs? See the ISO DIrectives for even more detail. ISO/IEC publishes a range of different types of standards, as well as covering a number of different subjects: An I nternational S tandard (IS) is the most common form of ISO/IEC standard, including product/technical standards, test methods, ‘codes of practice’ (good practices) and management standards. An IS “provides rules, guidelines or characteristics for activities or for their results, aimed at the achievement of the optimum degree of order in a given context”. Most aim to describe the final objective without prescribing the method of getting there (although they don’t all meet that aim!). The review cycle is 5 years (maximum). A T echnical S pecification (TS) is a standard on an immature subject that is still being developed, and is not quite ready to become a full IS. Feedback is encouraged in order to drive further development leading, eventually, to the release of an IS. Internally within the committee, final drafts are called PDTS P roposed D raft T echnical S pecifications. A T echnical R eport (TR) is informative rather than providing firm guidance. It may draw on surveys and reports, and may attempt to describe the state of the ar’. Final drafts of these are called PDTR P roposed D raft T echnical R eports. A P ublicly A vailable S pecification (PAS) responds to an urgent need to drive consensus on some emerging topic. Alternative and perhaps incompatible views may be expressed by parallel PASs from different expert streams. A PAS is supposed to be replaced by a TS or IS, or withdrawn, within 6 years. An I nternational W orkshop A greement (IWA) is a PAS produced outside of the ISO/IEC world - for example by some technical or industry body. It too has a maximum life of 6 years. What is JTC 1/SC 27 and what are WGs? Once you have ISMS experience, consider getting involved with SC27's standards work by contacting your national standards body and volunteering. ISO/IEC JTC 1/SC 27 is the J oint T echnical C ommittee 1 /S ubC ommittee 27 responsible for numerous information security, privacy and technological standards, including ISO27k series. SC 27 is spread across five W orking G roups focused in particular areas: · WG1 for I nformation S ecurity M anagement S ystems; · WG2 for cryptography; · WG3 for security evaluation; · WG4 for security controls and services; · WG5 for identity management and privacy technologies. How can I keep up with ISO27k? If you have ISO27k news, please share it with the user community via the ISO27k Forum. An easy way to keep in touch with developments is to bookmark this very website and call back every so often to see what's new. Another option is to Google ISO 27001 news or related terms. Professional information security-related organisations such as ISSA and ISACA often carry content on ISO27k. There are a few ISO27k groups on LinkeDin and other social media, of variable quality. Unfortunately most of them (other than the ISO27k Forum) are infested with spammers and well-meaning but inept commentators. Previous Up Next