Search Results

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

Back Up Next ISO/IEC 27034-7 ISO/IEC 27034-7:2018 — Information technology — Security techniques — Application security — Part 7: Assurance prediction framework (first edition) Up Abstract ISO/IEC 27034 part 7 ”describes the minimum requirements when the required activities specified by an Application Security Control (ASC) are replaced with a Prediction Application Security Rationale (PASR). The ASC mapped to a PASR define the Expected Level of Trust for a subsequent application. In the context of an Expected Level of Trust, there is always an original application where the project team performed the activities of the indicated ASC to achieve an Actual Level of Trust. The use of Prediction Application Security Rationales (PASRs), defined by [ISO/IEC 27034-7], is applicable to project teams which have a defined Application Normative Framework (ANF) and an original application with an Actual Level of Trust. Predictions relative to aggregation of multiple components or the history of the developer in relation to other applications is outside the scope of [ISO/IEC 27034-7].” [Source: ISO/IEC 27034-7:2018] Introduction Part 7 specifies a framework to deliver the assurance necessary to place trust in a computer program’s security arrangements, for example: When one program (such as an application) relies on another (e.g. a database management system, utility, operating system or companion program) to perform critical security functions (such as user authentication, logical access control or cryptography), or When an organisation updates or patches a trusted program. Scope Specifies minimum requirements when the required activities specified by an A pplication S ecurity C ontrol are replaced with a P rediction A pplication S ecurity R ationale. The ASC mapped to a PASR defines the Expected Level of Trust for a subsequent application. The use of PASRs is applicable to project teams which have a defined A pplication N ormative F ramework and an original application with an Actual Level of Trust. Structure Main clauses: 5: Prediction concepts 6: Predictions 7: Substantial changes 8: Confidence 9: Prediction application security rationale 10: PASR audit 11: PASR verification 12: PASR implementation 13: Expected level of trust report Annex A: Expected level of trust assurance case Annex B: Comparison of ASC to PASR Status The current first edition of part 7 was published in 2018 and confirmed unchanged in 2023. Commentary The language in part 7 is decidedly formal and stilted (e.g. “An application security claim is a claim that the application team implemented certain security controls and those controls mitigate specific security risks to an acceptable level. A security prediction is the transfer of confidence in the original claim to a claim that the same security controls are also present in a subsequent version of the application and mitigate, to the same acceptable level, the same specific security risks.” - got that?). It falls a long way short of ISO’s guidance on plain English . Up Up Up This page last updated: 23 February 2026

Join the global self-help community of >5,000 ISO27k/infosec professionals, lurk and chip-in if you feel inspired. It's FREE! The ISO27k Forum The Forum is a Google Group/email reflector for ISO27k practitioners, a supportive global community of peers-helping-peers. The back story Since its launch back in 2006, the ISO27k Forum has grown steadily into a supportive and friendly global community of more than 5,000 information security professionals, most of whom are actively using the ISO/IEC 27000-series standards and willing to share their experience, expertise and wisdom freely with others. Membership of the Forum is free for those with a genuine professional interest in the ISO27k standards , particularly those with practical implementation experience and knowledge they are willing to share with the community. We also welcome students and newbies taking their first baby steps, studying and in time maybe adopting the standards. The Forum and this website demonstrate our support for the liberal social principles on which the Web was founded - our way to give a little back to the online world that gives us so much. Purpose and vision This is a practitioners’ group with a practical focus, where (almost!) every contribution is treasured and every member valued. We mostly discuss matters of interest and concern to those interpreting and applying the ISO27k standards in genuine real-world situations (see the typical topics ). Typical ISO27k Forum members: Are generally interested in information security standards; May have relevant professional qualifications, having completed ISO/IEC 27001 Lead Auditor or ISO27k Lead Implementer training, CISSP, CISM, CISA, CRISC, GIAC and similar; May be CISOs, ISMs, CROs, Compliance Managers, Cybersecurity Managers, Infosec Consultants, IT Security Specialists, Security Analysts or whatever; May be students, academic researchers and teachers; Would like more information about applying the standards in real life, beyond that available on this website and elsewhere; Are planning to implement, actively implementing, fully conformant with or simply using the ISO27k standards , or are auditing organisations against the standards, or are advising others about the standards; May work for organisations that have been certified conformant with ISO/IEC 27001 or are working towards that point; Would like to help promote the standards more widely; May be involved in the standards bodies and committees responsible for developing the standards, or have an interest in this aspect; Wish to discuss information security management standards, practices, methods etc. with the community of professional peers; Are here to give and to take, to contribute knowledge and learn new stuff. Sharing is important to us. As a member put it, “We are a TEAM - T ogether E veryone A chieves M ore”. Sign me up! Our favourite topics The Forum is a low-volume high-quality group. We discuss anything and everything ISO27k-related, such as: Assurance - ISMS internal audits, management reviews, certification, surveillance, accreditation, supplier security audits, trust centres ...; B usiness C ontinuity M anagement including resilience, recovery and contingency planning, and ISO 22301; Business cases : reasons to embrace the ISO27k standards in furtherance of business objectives, going beyond mere conformity, and gaining executive/board-level support; Concepts and terms-of-art in risk and security e.g. threats, vulnerabilities, probabilities, impacts, exposure, incidents, CIA, preventive, detective, corrective controls, people, process, physical, technology controls, inherent and residual risks, risk appetite, risk tolerance, risk vs opportunity, protecting and exploiting information ...; Control attributes - using the parameters, characteristics or features to select and make the most of security controls; Documentation - mandatory vs discretionary, audiences, purposes, content, document controls ...; Governance of information, information risk, information security etc ., including organisation structures, reporting lines, direction, oversight, monitoring and conformity, management support and involvement, integrating management systems; How to implement the standards - pragmatic advice from those who have been there, done that; Information risk management methods such as B usiness I mpact A nalysis, threat intelligence, risk modelling; Information security controls for software, system, network and service development, provision and acquisition, for cloud, privacy, safety, IT, OT, AI, IoT ...; I nformation S ecurity M anagement S ystems, of course, plus viable strategies, implementation plans, resourcing, timescales, priorities, options, shortcuts, tips; Metrics for measuring information risk and security, for monitoring, reporting and management; News about ISO27k and related standards; Policies , procedures, rules, guidelines, laws and regulations, content, structure, purpose and value, compliance, conformity, enforcement and reinforcement; Preventive and corrective actions , continual improvement, maturity, post-incident reviews ... and incident management; Privacy , data protection, safety, quality and other obligations; Risk analysis tips e.g. common information security threats to consider, methods and tools, ‘where to start’ advice; Scope , S tatement o f A pplicability and R isk T reatment P lans - what they are, how they differ, what they do, what they are supposed to contain ...; Security awareness - why it’s needed, how to do it, making it cost-effective; 'The ISO27k way ' - a systematic, structured, information risk-driven approach underpinning all the ISO27k standards; Tools and resources supporting busy CISOs, ISMs, SOCs, analysts, trainers, documenters and consultants. This is just a potted selection to give you a flavour of the discussion. As well as the FAQ , we have accumulated a huge amount of worthwhile content in the group’s archive so it's worth getting to grips with Google’s search syntax . Projects Occasionally, ISO27k Forum members collaborate in crowdsourcing topical issues, such as drafting new materials for the ISO27k Toolkit. We have also contributed to the promotion and further development of the ISO27k standards. Privacy If you join the ISO27k Forum, you will obviously receive ISO27k-related emails. We will not exploit, sell or give away your email address or other personal information. If you post a message to the Forum, your email address is shown in the message header. Other members may email you directly rather than the entire group. We actively discourage anyone from overtly advertising on the Forum or pestering members but vendors may contact you directly/off-list if you express an interest in their products. Feel free to create a unique email address solely for the Forum and please let us know if you receive spam. We utterly detest and actively fight spam. Any Forum members who spam other members will be fed limb-by-limb, organ-by-organ to the ravenous bugblatter beast of Traal or, under our environmental policy, may be gently composted back into mother Earth. Forum tips and etiquette (important!) Guidelines to keep the ISO27k Forum on track, and benefit the whole community: Please be professional and respectful at all times. The Forum is deliberately non-commercial: No advertising or promoting your organisations and products, no commercial offers, no vacancy notices etc. Definitely no spamming! Conventional email signatures are fine though. Just be discreet. Take commercial matters off-line with individuals, not via the Forum.. Add your name to your postings: what should we call you? The Forum’s primary language is plain English. Be considerate. Browse the archives (using the Google Groups search ) before posting. Glance back a few weeks at least to see where current threads arose. Read the ISO27k FAQ . Stay on-topic! This Forum is exclusively about the ISO/IEC 27000-series standards and closely related matters. Take a moment to explain your context: Why are you writing? Why does it matter? What have you already done in an attempt to find an answer? What type of organisation do you represent? Industry? Size? Location? How mature is your ISMS? What stage are you at? When responding to a post, don’t change the subject line unless you are deliberately heading off at a tangent. Gmail and other mailers string related messages into threads by the subject line. For further advice on asking questions intelligently, see here and here . Manage your subscription via the Google Groups web interface: Receive each message individually or as regular digests. Suspend Forum emails temporarily or permanently (access online instead). Change your email address. Unsubscribe and leave the Forum.. File Forum emails automatically in your email software. All emails contain “[ISO 27001 security]” in the subject line: set up a rule to move emails with that subject string into a suitable folder to browse, search and read at your leisure. Respect intellectual property rights and laws: Do not circulate copyright materials (such as ISO/IEC standards!) on the ISO27k Forum unless you are the copyright owner or have the copyright owner’s express permission. This is a hard and fast rule, no exceptions, no second chances. Don't risk the Forum's existence as well as prosecution. It is generally OK to share URLs for materials legitimately published on the Web, rather than sharing the content. Respect the copyright of Forum members too. Don't share Forum postings elsewhere without first getting the authors’ agreement. Finally, if you are unclear about the rules, bothered about recent exchanges or wary of posting something inappropriate, email the Forum Admin . If you have a keen interest in the ISO27k standards and intend to participate actively in the community, apply to join the ISO27k Forum . Membership is FREE but please make your case briefly when you apply to join: in just a few short words, persuade us that you are qualified and willing to share. If you ignore this request and leave the application blank, don’t be surprised if your application is rejected just as rudely. Aside from excluding spambots, we like to know what brought you here and what interests you.

Back Up Next ISO/IEC 27400 ISO/IEC 27400:2022 — Cybersecurity — IoT security and privacy — Guidelines (first edition) Up Abstract ISO/IEC 27400 "provides guidelines on risks, principles and controls for security and privacy of Internet of Things (IoT) solutions.” [Source: ISO/IEC 27400:2022] Introduction The standard provides guidance on the principles, [information] risks, and the corresponding information security and privacy controls to mitigate those risks associated with the I nternet o f T hings. Insecure things can impact security and privacy in ways that differ from more conventional IT systems (e.g. desktops, laptops and servers). Therefore, appropriate security and privacy controls are needed to mitigate unacceptable risks. Things can be considered both as discrete electronic devices, and as components in larger, more complex ‘ecosystems’ potentially including: The operating systems and applications they run, delivering various services; The network infrastructure (personal, local and wide area networks); The physical world with which they interact through sensors and actuators; The people who specify, acquire, configure, use and manage them; The organisations that design and manufacture, use/operate and manage them; Society at large since things are ‘everywhere’. Challenges and information risks in the context of IoT include: Huge variety, innovation and ubiquity with things penetrating ever deeper into our businesses, homes, vehicles and lives; Vulnerabilities in the systems, applications and networks, plus the associated processes and activities (e.g. simply compiling, let alone maintaining and using, an inventory of things is tricky and costly - as we discovered during the Y2k crisis); Threats, both deliberate (e.g. hackers and malware) and natural (e.g . adverse physical operating conditions, power cuts, static discharge, design flaws, bugs/coding errors, user accidents and ineptitude); Impacts, potentially including safety hazards and property damage as well as the usual information security and privacy incidents (e.g . data corruption, disclosure, loss); Lifecycle implications (e.g. cheap, disposable, unmanaged and/or deeply embedded things may hang around for years and are unlikely to be supported or patched, ever); Ordinary users may not have an interest in or understand the security and privacy of their things , while even IT professionals may not have the time, leaving fit-and-forget things largely unmanaged, unmonitored and unmaintained; Concerns around interoperability, interaction and dependencies between things, and with other networked devices; Individually, most things have limited functionality, accessibility (e.g. minimalist human-machine interfaces) and computing performance (e.g. little processing and storage capacity); Mobility, dynamics and complexity verging on chaos and anarchy; Applications/use cases and situations may not have been anticipated by their designers/manufacturers (e.g . when things are re-purposed, combined or customised for novel applications); Things may change hands over time, affecting the context and raising the possibility of insecure configurations and inappropriate disclosure of stored information (e.g . when casually sold-on, lost or discarded). IoT designers/manufacturers and users, both individuals and organisations, may be oblivious to the information risks and appropriate/necessary controls, hence the standard (and this website!) has a role in raising awareness and trustworthiness, driving up maturity on both the supply (vendor) and the demand (customer) sides. Scope The standard is specific to IoT, covering both information security and privacy. Structure Main clauses: 5: IoT concepts 6: Risk sources for IoT systems 7: Security and privacy controls Annex A: IoT monitoring camera sample risk scenario Status The current first edition was published in 2022 . It was proposed to change this standard into a “horizontal deliverable” spanning several ISO/IEC committees with common interests in IoT, becoming a foundational standard defining the underlying concepts or principles. [I don’t know if that was accepted.] Commentary The standard strikes me as idealistic - a stretch goal for the IoT market as a whole, a reasonable strategy for an international standard. It may get traction in the area of industrial and safety-critical IoT. As to consumer grade things, it’s hard to predict much progress on security and privacy given the cost constraints and present lack of demand for security and privacy - a classic example of the need for pragmatic standards. The standard identifies some generic ‘risk sources’ and ‘risk scenarios’ relevant to IoT, essentially a selection of examples for consideration. I have some concerns about the selection and the wording, and the lack of direct linkages between the IoT security controls recommended elsewhere in the standard and the identified risks that they are presumably intended to mitigate. However, discussing relevant [information] risks in an ISO27k standard is, I feel, a positive move in its own right. Most ISO27k standards leap directly to recommending a bunch of information security controls, barely even mentioning the information risks. This standard goes a step beyond the “Just do this:” style, albeit a small step. It’s a start, a prompt for users of the standards to identify, consider and evaluate the information risks in their own contexts. I hope the information risk-aligned approach will spread to all the ISO27k standards in due course ... although so far I have seen no hint of strategic intent expressed by SC 27 along these lines, and such a change would undoubtedly take decades. Up Up Up This page last updated: 12 February 2026

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

Answers to common questions and concerns about managing information risks and security controls under ISO27k Up Up Up Information risks What are 'information risks'? Simply put, information risk is 'risk pertaining to information' . Breaking it down: Information is the valuable meaning or knowledge that we derive from data, the content of computer files, paperwork, conversations, expertise, intellectual property and so forth. Risks , in this context, are the uncertain prospect of harmful incidents. So, stitching it back together, information risk can be laboriously defined as 'Uncertainty involving or affecting information, normally the deliberate, incidental or accidental action of threats exploiting exposed vulnerabilities, causing harmful impacts'. To put that more succinctly, I define information risk as 'risk pertaining to information' . While the ISO27k standards neither define nor use 'information risk', and 'information security risk' is not actually defined, two notes to the definition of 'risk' in ISO/IEC 27000 mention it: 'information security risks can be expressed as effect of uncertainty on information security objectives [and] Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization'. I prefer a business perspective: reducing the number and severity of adverse business impacts to an accceptable level is the primary objective of information security. Is there a list of information risks? The suggested resources are all generic, useful reminders of the general types of risk worth considering. Pore over your organisation’s incident records and past risk assessments for further inspiration, and work with management to identify and consider information risks in your particular business context. Yes, several e.g. : IT Grundschutz Catalogue (the baseline IT protection manual) includes an extensive threat catalogue, exhausting if not exhaustive; ISO/IEC 27002 , NIST SP 800-53 and various other information security and privacy standards, laws and regulations are, in effect, incomplete information security control catalogues that may mention threats, vulnerabilities and impacts; ISO/IEC 27005 identifies a few threats and vulnerabilities in an annex; Mitre’s CVE ( C ommon V ulnerabilities and E xposures) is a useful, well-regarded catalogue of cybersecurity (meaning primarily technological/IT system) vulnerabilities. Again, not totally comprehensive but close enough for government work; Mitre’s CAPEC ( C ommon A ttack P attern E numeration and C lassification) is a structured catalog of cybersecurity ‘attacks’ i.e . how some threat agents exploit some vulnerabilities. Most information risk analysis and management support tools, systems, methods and advisories include examples or lists of stuff to consider. There are books, websites and articles on this topic. And finally, don't forget Google and AI. What is information risk management? This is a complex, busy process, liable to go badly wrong. ISO27k provides a sensible management structure or framework to help keep it on-track. ' Management' indicates someone proactively addressing information risks on an ongoing basis, along with related governance aspects such as direction, control, authorisation and resourcing of the processes. The first stage is to Identify potential information risks. Several factors or information sources feed-in to that: Vulnerabilities are the inherent weaknesses within our facilities, technologies, processes (including information risk management itself!), people and relationships, some of which are probably unrecognised or not fully appreciated; Threats are the external actors and natural events that might cause incidents if they acted on vulnerabilities causing impacts [Note: malicious, fraudulent, inept, coerced or misled insiders can present threats: we are not purely concerned about evil hackers, malware and terrorists roaming the Interwebs!]; Assets are, specifically, information assets - valuable information content plus, to a lesser extent, the associated storage media, computer hardware devices etc. ; Impacts are the harmful effects or consequences of incidents affecting assets, damaging the organisation and its business interests, often also third parties; Incidents range in scale from minor, trivial or inconsequential events up to disasters and outright catastrophes; Advisories, standards etc. offer relevant warnings and guidance from organisations such as CERT, the FBI and NSA, ISO/IEC, journalists, bloggers and podcasters, technology vendors plus information risk and security professionals. Threat and vulnerability intelligence services can be useful, along with security advisories and patch notifications from software, hardware, service and information suppliers. Next, the evaluate risks stage involves considering all that information in order to determine the significance of various risks, which in turn drives priorities for the next stage. The organisation’s appetite for risks is a major concern here, reflecting corporate strategies and policies as well as broader cultural drivers and personal attitudes of the people engaged in risk management activities. Treat risks involves avoiding, mitigating, sharing and/or accepting them. This stage involves both deciding what to do and doing it (implementing the risk treatment decisions). Handle changes might seem obvious but it is called out due to its importance. Information risks are constantly in flux, partly as a result of the risk treatments, partly due to various other factors both within and without the organisation. The ISO27k way is risk-driven, such that the most significant risks at any point should be in hand … but there is always more to do, so this is an endless journey across shifting sands. Finally, a reminder that the organisation often has to respond to external obligations such as legal and regulatory compliance plus market pressures, customer expectations, commercial contracts etc . These also change from time to time, and should be actively monitored. What risk analysis method should we use? Determine your own risk analysis, risk management and/or governance requirements and evaluate the methods, tools, products etc. carefully. There is further advice on how to select specific methods/tools in the next FAQ. Since neither ISO/IEC 27001 nor ISO/IEC 27005 specify or require a particular risk analysis method, you can select whichever method or (better still) methods align with your organisation’s expertise and situation. Risk analysis methods are broadly categorised as quantitative (based on mathematical modelling and statistical analysis) or qualitative (experiential, subjective). ISO/IEC 27005 offers general advice on selection and use of methods in the ISMS context but does not insist on any specifics. It is perfectly acceptable, and often beneficial, to mix-n-match multiple methods. For instance, a high-level overview method might identify broad areas of concern (such as privacy), which can then be examined in detail using focused methods (e.g. privacy impact assessments). Leverage the expertise of business departments such as Internal Audit, Risk Management, Health and Safety, Finance, Project or Programme Management and Operations, as their methods can often be applied to information risks. There is no need to abandon familiar tools simply for ISO27k. However, be mindful of discrepancies in results from different methods. Avoid simplistic approaches like choosing the least costly controls or addressing only the most obvious 'key' risks. Instead, use the analyses as decision support tools for management. Managers need to determine appropriate security investments, risk appetite and improvement timelines. This requires a combination of vision, expert advice and practical judgment. Below is a very brief introduction to a number of information risk analysis and management methods, standards, guidelines and tools, plus some aimed at supporting G overnance, R isk and C ompliance and even S ecurity I nformation and E vent M anagement. Analog Risk Assessment (ARA) is a deceptively straightforward and quick method to analyse, discuss and consider risks subjectively and simplistically according to their relative probabilities of occurrence and levels of impact; Calabrese’s Razor is a method developed by Chris Calabrese to help the C enter for I nternet S ecurity prioritise technical controls in their security configuration guides. It helps evaluate and compare the costs and benefits for each control on an even footing; COBIT from ISACA is a comprehensive model guiding the implementation of sound IT governance processes/systems, including to some extent information security controls; COSO ERM (C ommittee O f S ponsoring O rganisations of the Treadway Commission's E nterprise R isk M anagement framework) is a general structured approach for managing all forms of organisational risk; Delphi is a forecasting technique involving successive rounds of anonymous predictions with consolidation and feedback to the participants between each round; DIY (D o I t Y ourself) methods offer a genuine alternative, not just a straw man. DIY involves using risk analysis methods with which you or your organisation are already familiar, perhaps home-grown methods or even those that are not normally used to examine information risks. With the same underlying principles, can your existing risk analysis methods, processes and tools be adapted for information risks?; FMEA (F ailure M ode and E ffects A nalysis) is commonly used in engineering design. It focuses on the possible ways in which a system might possibly fail, almost regardless of the causes; The UK’s IRM (I nstitute of R isk M anagement), AIRMIC (Association of Insurance and Risk Managers) and ALARM (The National Forum for Risk Management in the Public Sector) jointly released A Risk Management Standard way back in 2002, for all forms of organisational risk, not just information risk; ISO 31000 offers guidance on the principles and implementation of risk management in areas such as finance, chemistry, environment, quality, information security etc .; ISO/IEC 27005 isn’t really a risk assessment or management method as such, more of a meta-method, an approach to choosing methods that are appropriate for your organisation; Mehari is a free open-source risk analysis and management method in several European languages developed by CLUSIF (Clu b de la S écurité de l'I nformation F rançais) and CLUSIQ ; NIST SP 800-30 “Risk Management Guide for Information Technology Systems” is a free PDF download from NIST . An accompanying guideline is also available and also free; NIST SP 800-39 “Managing Risk from Information Systems - An Organisational Perspective” is another freebie from NIST; OCTAVE (O perationally C ritical T hreat, A sset, and V ulnerability E valuation) is CERT ’s risk-based strategic assessment and planning technique for security. It takes a business rather than technology-centric view of security risks. OCTAVE Allegro is a quick version of OCTAVE; Risk IT from ISACA complements their other excellent tools COBIT and ValIT ; Stochastic modelling methods using Markov chains , stochastic Petri nets , Monte Carlo simulation , Bayesian or other statistical techniques and probability theory are commonly applied to estimate uncertain risk values from incomplete data in the financial industry; Verinice is a free open-source tool supporting the BSI IT-Grundschutz standards . It’s very nice. We are not selling, recommending or endorsing any of them. We haven’t even used all of them, personally, and we don't know your requirements except in very general terms. OK, how should we select risk analysis methods? Don’t get completely hung-up on this: go with what you have and make it work for you, learning, refining, moving ahead. This is classic opportunity for 'continual ISMS improvement'. Read ISO/IEC 27005 for starters and think carefully about what you want. What do you expect the method or tool to achieve for you? Which factors and/or features are most important? Are there any things the method or tool should not do (e.g. gobble-up excessive amounts of limited resources)? Determine your requirements such as: Quantitative or qualitative : opinions vary on the relative value of quantitative versus qualitative methods. Few information security or risk management professionals would recommend truly quantitative analysis of information risks in all circumstances due to the shortage of reliable data on incidents (probabilities and impacts), although they are potentially useful in some more narrowly-defined situations. One solution to this dilemma is to use quick/simple qualitative risk assessments followed by risk analyses on selected ‘high risk’ areas using more detailed qualitative or quantitative methods; Scope : are you purely looking at “information risks” or risks in a broader sense, and what do you really understand by “information risks” anyway: are you in fact concerned about risks to information assets, or business risks that happen to involve information, or something else? Furthermore, which information assets are you concerned with? What will happen with the out-of-scope risks that could be just as significant for the organisation, especially if they remain unrecognised, unanalysed and untreated? Scalability : are you looking to support a relatively simple analysis of risks for a single process or IT system, an organisation-wide analysis, or all of the above? Will you be completing the analysis just once or repeatedly, and if so how often? Maintainability and support : some methods use AI/decision support software, whereas others are procedural or can be supported by generic tools such as spreadsheets. Clearly, therefore, they vary in the amount of technical expertise required to install, configure and maintain them. Home-grown tools can be more easily and cheaply developed and modified in light of your experiences whereas commercial tools tend to be slicker and more polished; Usability : some methods and tools lead the user through the risk analysis process a step at a time, whereas others are more free-form but arguably assume more knowledge and expertise of the users. Some attempt to reduce the information gathering phase to simplistic self-completion questionnaires for risk non-specialists, others require competent risk analysts; Value : simply put, value means the business benefits of the tool less the associated costs . Purchase price is not the only factor here. Can you explain the SoA and RTP? Don’t get hung up on the names and acronyms. Concentrate on their purpose, which is to clarify the relationship between your organisation's information risks and their treatments. Let's assume that, despite studying ISO/IEC 27001 , you are unsure. The S tatement o f A pplicability is a formal definition of the controls employed by your ISMS. There needs to be some rationale to explain your reasoning and persuade the auditors that important decisions to include or exclude controls from Annex A or from elsewhere were made not arbitrarily but rationally, according to the risks. Be ready for some robust audit discussions if you decide not to implement common controls at all, blithely accepting significant risks. Likewise, be ready for some robust management discussions if you decide to implement all of Annex A simply simply because it’s an ISO standard, not because the controls are appropriate and necessary to mitigate (reduce) unacceptable risks. The R isk T reatment P lan lists the risks identified and evaluated in your risk assessment, along with the associated treatments: unacceptable risks may be mitigated with controls listed in the SoA, or avoided, or shared with other organisations. Small risks may be willingly accepted if they fall within management’s risk appetite or if the controls would cost more than the anticipated incidents, while various other risks (such as the possibility of erroneous assumptions within, and hence decisions based upon, your risk analysis) are implicitly and necessarily accepted. How should we handle our client 's information risks? This may be an opportunity to sell your client some security/risk consultancy services! Either way, have your pet lawyer take a very careful look at any contracts or SLAs relating to third party information assets in your care, to be crystal clear about your information security obligations and liabilities. The managers of, say, commercial shared data centre services should ideally involve (key) clients directly in (part of) the risk analysis. Helping client managers understand and elaborate the information risks relating to their assets should clarify what they expect and enables the supplier to appreciate what is expected – the priorities, for example. What comes first, and why? If clients are unwilling or unable to engage fully with the risk analysis, managers should at least assess the information risks relating to the contracts and services from the supplier’s perspective, including the risk that clients may have unrealistic or inappropriate expectations about the information security services provided. A serious information security incident involving the supplier would almost certainly damage customer relations, might lead to legal arguments over the contract/SLA and could either put clients out of business or see them defect to another supplier. Similar considerations apply in other circumstances where the organisation handles information assets belonging to third parties - customers’ personal data and credit card details, for instance. What is the difference between risk assessment and audit? Challenging the status quo can be a valuable, if cathartic experience. At the end of the day, just remember that the primary aim of both activities is to improve the organisation, stimulating management to make changes for the better. These are change catalysts, opportunities to improve. Risk assessment identifies and analyses potential risks, while an audit typically evaluates the effectiveness of existing controls at keeping risks within the corporate risk appetite. Risk assessment tends to be a theoretical 'what if' exercise, often involving workshops, discussions and models to identify and explore inherent and residual risks. It is conducted by those familiar with the area, including risk managers and security experts. An audit, on the other hand, is a more practical, hands-on 'show me' activity. Among other things, auditors examine and validate the controls in place to determine if they adequately address various risks – both in theory (if they worked as designed and documented, would they be sufficient?) and in practice (are they, in fact, working as designed and documented?). A key distinction is independence: audits can only be conducted by independent auditors, providing an unbiased perspective. Auditors bring fresh eyes, challenge assumptions and identify blind spots. Compliance audits, such as ISO/IEC 27001 certification audits, specifically assess adherence to regulations and standards. They also consider the risk of non-conformity: significant issues can not only prevent certification but underline the ISMS, potentially putting the organisation’s entire approach at risk. Finally, the risk assessment process itself is auditable, while auditors must also manage audit risks, such as failing to identify, evaluate and report critical issues appropriately. Which compliance obligations are relevant to ISO27k? The obligations or rules expressed formally in legal language tend to be minimalist, meaning that compliance alone may not protect the organisation’s business interests. Compliance is necessary but not sufficient. You may prefer to handle this separately from the ISMS. The organisation's compliance with various obligations can be an important driver to implement an ISMS, not least because the ISMS can take some of the weight off management’s shoulders. Managers generally either accept the need to comply, or can be persuaded to do so in order to avoid the personal adverse consequences (typically fines, prison time and career limitations). As to which obligations are relevant, there are loads of them! Although I A m N ot A L awyer, here is an incomplete listing of the general types or categories of laws, regulations etc . that have some relevance to information, information risk, information security and thus potentially the ISMS: Building codes – structural integrity, resistance to fires, floods, earthquakes, fire exits … Business records – financial reporting, tax, credit, banking, money laundering, company accounts … Business continuity – critical infrastructure, resilience … Classified information – governmental and military, spying, official secrets, terrorism, organised crime … Commercial contracts – N on D isclosure A greements, digital signatures, maintenance and support agreements, Internet/distance selling, invoicing, credit and payment, PCI-DSS , plus various other obligations on or towards business partners, suppliers, customers, advisors, owners … Community relations – being a good neighbour, supporting the underprivileged … Consumer protection – product designs, advertising, branding, warranties, fitness for purpose, merchantability, quality and security ... Corporate governance – company structure, ownership and control, obligations of Officers, independent oversight/audits … Cryptography – standards, laws and regs e.g. restrictions on use and export of strong crypto … Defamation – libel, slander ... Employment – disciplinary process, pre-employment screening/background checks, contracts of employment, codes of conduct … Environmental – pollution, eco-friendliness, greenwashing … Ethics – morals, cultural and religious aspects e.g. Sharia law; Forensics – chain of custody, warrants and warrantless searches, admissibility ... Fraud – identity fraud, misrepresentation, embezzlement, malfeasance … Freedom of information – enforced disclosure, including ‘discovery’ in legal disputes; Hacking – malware, ransomware/coercion, denial of service, unauthorised access … Health and safety – safety-critical control systems, fire exits, building standards/codes, industrial control systems, working conditions, hazards … Industry-specifics – some industries are tightly regulated, others less so … Insurance – terms and conditions, excesses, disclosure of relevant facts ... Intellectual property – copyright, trademarks, patents, DMCA, trade secrets, publication/disclosure etc . protecting both the organisation’s IP and that of third parties; Permits – operating licenses in some industries and markets, software licenses … Pornography – paedophilia, discriminatory/offensive materials, blackmail … Privacy – data protection, personally identifiable information … Surveillance – spying, wiretapping, CCTV, monitoring, investigation, forensics … Technical – standards and interoperability e.g. ISO27k, TCP/IP, DNS, Windows compatibility … Telecommunications – networking, lawful/unlawful interception, mail fraud … Theft – of hardware and media … Trespass – right of access, right to exclude, ‘citizen’s arrest’ … International – as well as domestic laws and regulations, those in other countries might also be applicable if your business has an international presence or uses cloud and other services hosted overseas … ++ Others : speak to your Legal/Compliance team about this. By the way, beware changes to the legislation and ‘case law’ (where judges/courts interpret things in particular ways, sometimes setting legal precedents). Aside from being familiar with the obligations, someone needs to keep on top of the associated policies, contracts, agreements, standards and codes, plus awareness and training, compliance/conformity assessments and enforcement aspects. For example, do you have the policies and procedures in place for exceptions and exemptions ? Do you need to check compliance and perhaps enforce your organisation’s obligations on third parties e.g. confidentiality agreements with business partners and former employees? Warning : assuming you are an information security professional looking into this, be very wary of being expected or even perceived by colleagues and management as a legal expert. Even professional lawyers specialise because the field is too broad for anyone to be entirely competent across the board. Senior managers generally own and are accountable for corporate compliance. Don’t take on their mantle! By all means offer general advice and guidance but leave them fair and square with the compliance burden. For your and their protection, explicitly recommend that they seek the guidance of competent professionals. Once again, for good measure, IANAL and this FAQ is not legal advice. What should we do about exceptions? Key to this approach is the personal accountability of Information/Risk Owners for adequately protecting their information assets. If senior management doesn't understand or support concepts such as exceptions, exemptions, accountability, responsibility, ownership, information assets and risk, then patently the organisation has significant governance issues to address first! First understand the vital difference between exceptions and exemptions*: Exceptions are un authorised noncompliance/nonconformity with requirements, typically identified by audits, management reviews, during the system design phase when developing software and processes, or revealed by information security incidents; Exemptions are authorised noncompliance/nonconformity. Exemptions are the way to formalise risk management decisions when Information/Risk Owners explicitly accept specific identified risks on behalf of the organisation for legitimate business reasons. For example, imagine that an IT systems audit has identified that system A is configured to accept passwords of at least 6 characters, while the corporate password standard mandates at least 8 characters. This is an exception that should be brought to the attention of the Information/Risk Owner for system A. The owner then considers the situation, considers the risk to the organisation and to the information asset, takes advice from others and decides how to treat the risk. The preferred response is to bring the system into line with the policies. However that is not always possible. If instead the decision is to accept the risk, an exemption to the specific policy requirement is granted, but - and this is the important bit - the Information/Risk Owner is held personally accountable by management for any security incidents relating to that exemption by simple extension of their accountability for protecting their information assets. Exemptions should be formalised e.g. : The Information/Risk Owner should be required to sign a crystal-clear statement regarding their understanding and acceptance of the risk to their asset if the exemption is granted, acknowledging that they are personally accountable if the risk materialises; The exemption should be granted by being countersigned on behalf of management by an authoritative figure such as the CEO or CISO; Optionally, the exemption may specify compensating controls (such as explicit guidance to users of system A to choose passwords of at least 8 characters in this case); All exemptions should be formally recorded on a controlled corporate register; All exemptions should be reviewed by the owners and management periodically (e.g. every year) and, if still required and justified, renewed using the same formal process as the initial authorisation. Typically exemptions may be renewed and continue indefinitely just so long as the owner is prepared to continue accepting the risk and management is prepared to accept the situation, but some organisations may impose limits (e.g. an exemption automatically expires after one or two years and cannot be renewed without a majority vote in favour by the Board of Directors). If there are loads of exceptions and especially exemptions to what are supposedly mandatory requirements, management really ought to reconsider whether the requirements are truly mandatory. If in fact they are, any current exemptions should be set to expire at some future point, forcing owners to select risk treatments other than ‘accept the risk’. Information Security should take up the challenge to help improve conformity. If the requirements are not in fact mandatory after all, the policies etc . should be revised accordingly. * Note: organisations use different words for these two concepts, such as exceptions and waivers, or exemptions and waivers, or even exemptions and exceptions with their meanings reversed. The specific terms don’t particularly matter provided they are clearly defined, the distinction is clearly understood and they are used consistently in practice. I’m confused about ‘residual risk’ … Proactively and systematically managing residual risks indicates a mature or maturing ISMS. It suggests the organisation already has a grip on its unacceptable risks and is taking a sensible, realistic approach. Residual literally means 'of the residue' or 'left over'. So, residual risk is the left-over risk remaining once risk treatments have been applied. So, for example, suppose after risk assessment there are 3 risks (A, B and C): risk A is acceptable, B and C are not acceptable. After risk treatment, B becomes acceptable but C is still not acceptable. Which is the residual risk: just C? Or B and C? It’s a trick question. In fact, A, B and C all leave some (residual) risk behind ... Accepted risks are still risks: they don't cease to have the potential for causing impacts simply because management decides not to do anything about them! Acceptance merely means management doesn't believe they are worth reducing further. Management may be wrong (Shock! Horror!) - the risks may not be as they believe, or things may change; Mitigated or controlled or managed risks are still risks: they are reduced but not eliminated, usually, and the controls may fail in action (e.g. antivirus software that does not recognise and block 100% of all malware, or that someone accidentally disables one fateful day); Eliminated risks are probably no longer risks, but what if the risk analysis was mistaken or the risks aren’t in fact 100% totally eliminated? What if the situation changes? Avoided risks are probably no longer risks, but again the risk analysis may have been wrong, or someone may deliberately or inadvertently take the risk anyway, especially if there are weak or missing administrative controls and awareness of the decision to avoid the risk; Shared risks are reduced but are still risks, since the sharing may not turn out well in practice (e.g. if an insurance company declines a claim for some reason) and may not be adequate to completely negate the impacts (e.g. the insurance 'excess' charge, or denial of claims). Remember that the manager/s who elected to share risks are personally accountable for those decisions if it all turns to custard, goes pear-shaped or hits the fan ... Previous Up Next

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

Back Up Next ISO/IEC TS 27560 ISO/IEC TS 27560:2023 — Privacy technologies — Consent record information structure (first edition) Up Abstract ISO/IEC TS 27560 "specifies an interoperable, open and extensible information structure for recording PII principals' consent to PII processing. [ISO/IEC TS 27560] provides requirements and recommendations on the use of consent receipts and consent records associated with a PII principal's PII processing consent, aiming to support the: provision of a record of the consent to the PII principal; exchange of consent information between information systems; management of the life cycle of the recorded consent.” [Source: ISO/IEC TS 27560:2023] Introduction This T echnical S pecification specifies an interoperable, open and extensible information structure for recording and potentially sharing PII Principals' (data subjects') consent to data processing. Scope In addition to the specification, the standard provides requirements and recommendations on the use of consent receipts and consent records associated with a PII Principal’s data processing consent to support the: Provision of a record of the consent to the PII Principal; Exchange of consent information between information systems; and Management of the lifecycle of the recorded consent. The standard does not specify an exchange protocol for receipts and records, nor an exact data structure for such exchanges. Structure Main clauses: 5: Overview of consent records and consent receipts 6: Elements of a consent record and consent receipt Annex A: Examples of consent records and receipts Annex B: Example of consent record life cycle Annex C: Performance and efficiency considerations Annex D: Consent record encoding structure Annex E: Security of consent records and receipts Annex F: Signals as controls communicating PII principal's preferences and decisions Annex G: Guidance on the application of consent receipts in the context of privacy information management systems Annex H: Mapping to ISO/IEC 29184 Status The first edition was published as a T echnical S pecification in 2023 . ISO made the downloadable standard free of charge in 2025 to encourage uptake and so promote the sharing of privacy consents. See https://www.iso.org/standard/80392.html A revision project is ongoing with an expanded scope to encompass the former ISO/IEC TS 27569 project (which has presumably been cancelled). The second edition is at 2nd C ommittee D raft stage with a new title: "Structure of personally identifiable information (PII) processing records.", revised scope and updated structure. It looks set to become a full I nternational S tandard rather than a T echnical S pecification. Commentary If only ISO would release all the ISO27k infosec standards free of charge, encouraging everyone to improve security for all! Up Up Up This page last updated: 9 April 2026

Back Up Next ISO/IEC 27099 ISO/IEC 27099:2022 — Information technology — Public key infrastructure — Practices and policy framework (first edition) Up Abstract ISO/IEC 27099 "sets out a framework of requirements to manage information security for Public key infrastructure (PKI) trust service providers through certificate policies, certificate practice statements, and, where applicable, their internal underpinning by an information security management system (ISMS). The framework of requirements includes the assessment and treatment of information security risks, tailored to meet the agreed service requirements of its users as specified through the certificate policy. [ISO/IEC 27099] is also intended to help trust service providers to support multiple certificate policies ...” [Source: ISO/IEC 27099:2022] Introduction Since trustworthiness is an essential characteristic of any P ublic K ey I nfrastructure, strenuous efforts are required to minimise all risks that might lead to loss of trust in PKI. The standard describes the use of an ISO/IEC 27001 I nformation S ecurity M anagement S ystem as a PKI management framework. Scope ISO/IEC 27099: Identifies information risk and security management requirements for PKI T rust S ervice P roviders and C ertification A uthorities through C ertificate P olicies and C ertification P ractice S tatements. Facilitates the implementation of operational, baseline controls and practices through an ISMS, building on and generalising the financial services PKI standard ISO 21188:2018 plus ISO/IEC 9594-8 , ISO/IEC 19790 and RFC 3647 . Supports the lifecycle of public key certificates used for digital signatures, authentication, or encryption key establishment and exchange; Primarily concerns PKI systems used in contractual relationships between organisations but also covers open (public) and closed (corporate/internal) PKIs; Is applicable to root and intermediate CAs, not just those issuing certificates directly to users. It does not address: Attribute certificates; Authentication methods; Non-repudiation requirements; Key management protocols based on the use of public key certificates; Blockchain - at least, not explicitly. Structure The ~100-page standard has 3 main clauses and 6 informative annexes: 5: introduces PKI concepts . 6: CP, CPS and their relation to ISMS. 7: CA objectives and controls , plus other requirements concerning the operation of a CA, based on the ISO/IEC 27002:2013 structure. Annex A: Management by CP. Annex B: Elements of a CPS (mapping to RFC 3647 ). Annex C: CA key generation ceremony. Annex D: Content and use of the CA audit journal . Annex E: Certificate and PKI roles . Annex F: Changes from ISO 21188. Status The current first edition was published in 2022. Commentary As with PKIs in general, this standard defines and uses 60 obscure terms of art plus 24 abbreviations, making it tough for non-specialists to comprehend - even tougher than PKI itself and cryptography in general. It is a detailed standard on an advanced, technical topic. It would take a lot of work to adopt ISO’s version of plain English . Up Up Up This page last updated: 22 February 2026

Back Up Next ISO/IEC 27553-1 ISO/IEC 27553-1:2022 — Information security, cybersecurity and privacy protection — Security and privacy requirements for authentication using biometrics on mobile devices — Part 1: local modes (first edition) Up Abstract ISO/IEC 27553 part 1 "provides high-level security and privacy requirements and recommendations for authentication using biometrics on mobile devices, including security and privacy requirements and recommendations for functional components and for communication. [The standard] is applicable to the cases that the biometric data and derived biometric data do not leave the device, i.e. local modes.” [Source: ISO/IEC 27553-1:2022 ] Introduction This multi-part standard provides high-level requirements for biometric authentication on mobile devices, including functional components and communications. Biometrics are increasingly used for user authentication on mobile devices. They are easier to use and harder to steal or fake than conventional passwords and tokens. However, proliferating devices and approaches are fragmenting the market, hence standardization offers advantages for users and manufacturers. Scope Biometric authentication on mobile devices. Part 1 applies where the user of a mobile ICT device such as a smartphone or tablet PC biometrically authenticates directly to the device such as when logging on to unlock the device, access stored data and run mobile apps. Although the outcome of biometric authentication may be used elsewhere (e.g . in cloud or corporate server apps), this standard specifically concerns risks to and protection of the biometrics on the device itself (e.g . fingerprints). The standard references ISO/IEC 24745:2022 “Biometric information protection”. Structure Main clauses: 5: Security challenges 6: System description 7: Information assets 8: Threat analysis 9 :Security requirements and recommendations 10: Privacy considerations Annex A: Implementation example Annex B: Security issues related to communication between agents and servers for authentication using biometric on mobile devices Annex C: An example of authentication assurance and assurance levels Status The current first edition was published in 2022 . Commentary As a generic standard, part 1 addresses commonplace information risks that typically arise in relation to biometrics on mobiles. In practice, we should manage (identify, evaluate, treat and monitor) the actual information and privacy risks in real-world situations, including any that are not explicitly identified and accurately described in this standard. That is context-dependent - for instance, the information risks relating to my biometrics on my cellphone are broadly similar but not entirely the same as, say, the king’s or yours, not least because the impacts of any incidents would probably be materially different. Aside from the security and privacy implications arising, there may also be different assurance requirements relating to biometric authentication. The consequences of someone accessing my smartphone without authorisation are rather different in the case of the president's. Up Up Up This page last updated: 12 February 2026