Most quality managers I talk to can recite clause 6.1 from memory. Far fewer can tell me what their organization actually does differently because of it. That gap is the real subject of this article. Risk-based thinking is one of the most widely cited requirements in the ISO world and one of the most inconsistently implemented, and the reason is simple: ISO never told anyone exactly how to do it.
That was deliberate. Annex SL, the harmonized structure that now underlies nearly every modern management system standard, built risk-based thinking into the DNA of ISO 9001, ISO 14001, ISO 45001, ISO 27001, and ISO 42001 without prescribing a single method for satisfying it. The standards tell you to identify risks and opportunities and to act on them. They don't tell you which tool to use, how deep to go, or what a "good" risk assessment looks like. That flexibility is a gift if you understand the underlying logic, and a trap if you don't.
I want to walk through what risk-based thinking actually requires, how it shows up differently across the standards you're most likely to hold, and how to build one risk framework that satisfies all of them instead of running five parallel spreadsheets nobody trusts.
What Risk-Based Thinking Actually Means
ISO 31000:2018, the umbrella risk management standard, defines risk as "the effect of uncertainty on objectives." That definition matters more than it looks like it does. It means risk isn't just the bad outcome you're trying to avoid. It's the gap between what you planned and what might actually happen, in either direction. A supplier shortage is a risk. So is a sudden spike in demand you're not staffed to meet. Both are uncertainty acting on your objectives.
Risk-based thinking is the practical, embedded version of that idea. Instead of a standalone risk management program run by a specialist, it's a habit built into how you plan, review, and make decisions at every level of the quality system. ISO 9001:2015 made this explicit by removing the standalone "preventive action" clause that existed in the 2008 revision and replacing it with clause 6.1, "Actions to address risks and opportunities." That wasn't a cosmetic edit. It was ISO saying that preventive action shouldn't be a separate procedure you dust off twice a year. It should be how you think, all the time, about everything the system touches.
In my view, that's the single most misunderstood change in the last major ISO 9001 revision. Auditors still occasionally ask for "the preventive action log," and the honest answer is that it doesn't exist anymore, by design. What exists instead is a pattern of risk consideration woven through context of the organization, planning, operational control, and management review.
Where Risk Shows Up in Each Standard
Every Annex SL standard carries a version of clause 6.1, but the flavor of risk each one cares about is different, and that difference is where organizations get tripped up when they hold more than one certification.
ISO 9001:2015 treats risk broadly and lets you scale the rigor to your context. A ten-person job shop and a thousand-person contract manufacturer can both be compliant with very different levels of formality. There's no mandated methodology, no required risk matrix, and no obligation to maintain a documented risk register, though most organizations end up keeping one anyway because it's the easiest way to demonstrate the thinking actually happened.
ISO 14001:2015 applies the same 6.1 structure but points it at environmental aspects and compliance obligations. The risk lens here is aimed outward, at what the organization does to the environment and what environmental conditions could do to the organization, including things like regulatory change and resource scarcity.
ISO 45001:2018 is where risk-based thinking gets teeth. Clause 6.1.2 requires a formal hazard identification and OH&S risk assessment process, because the consequence of getting it wrong isn't a nonconformance, it's an injury. ISO 45001 replaced OHSAS 18001 in March 2018, and organizations certified under the older standard had a three-year migration window that closed in March 2021, which tells you how seriously the certification bodies treated the shift toward a more rigorous, worker-participation-driven risk model.
ISO/IEC 27001:2022 demands the most structured risk approach of the group. Clause 6.1.2 requires a documented information security risk assessment methodology with consistent criteria, and clause 8.2 requires you to actually perform and re-perform that assessment on a planned cadence. The 2022 revision also restructured Annex A from 114 controls across 14 categories down to 93 controls across 4 themes, and the selection of which controls apply to your organization is itself a risk-driven decision, formalized in the Statement of Applicability.
ISO 13485:2016 takes a different route entirely. Rather than building its own risk clause from scratch, it points directly to ISO 14971, the dedicated medical device risk management standard, and requires risk management to run across the entire product lifecycle, from design input through post-market surveillance. This is risk-based thinking with a specific, mature methodology already built for you. You don't get to invent your own approach the way you can under ISO 9001.
ISO/IEC 42001:2023, the newest of the group, brought risk-based thinking into AI governance. Clause 6.1.2 requires an AI-specific risk assessment, and clause 6.1.4 goes further, requiring an AI system impact assessment that considers effects on individuals and groups, not just the organization. It's the first management system standard to formally require an organization to assess how its own product could harm the people who use it, which is a meaningfully different question than "could this process fail."
Here's how the risk requirements stack up side by side.
| Standard | Governing Risk Clause | Core Risk Focus | Formal Methodology Mandated? |
|---|---|---|---|
| ISO 9001:2015 | 6.1 | Risks and opportunities to quality objectives | No — organization defines its own approach |
| ISO 14001:2015 | 6.1 | Environmental aspects, compliance obligations | No |
| ISO 45001:2018 | 6.1.2 | Occupational health and safety hazards | Yes — hazard identification and risk assessment process required |
| ISO/IEC 27001:2022 | 6.1.2, 8.2 | Information security threats and vulnerabilities | Yes — documented risk assessment methodology required |
| ISO 13485:2016 | 4.1.2(b), via ISO 14971 | Product safety across the device lifecycle | Yes — ISO 14971 methodology required |
| ISO/IEC 42001:2023 | 6.1.2, 6.1.4 | AI system risk and impact on individuals/society | Yes — AI risk assessment and impact assessment required |
Notice the pattern. The standards governing physical safety, information security, medical devices, and now AI systems all mandate a specific methodology, because the cost of an inconsistent, ad hoc approach is too high to leave to organizational discretion. The standards governing broader quality and environmental management leave the method open, because the risk landscape is too varied across industries to standardize.
The Mistake Most Organizations Make
The most common failure I see isn't a missing risk register. It's a risk register that exists purely to satisfy an auditor and never touches an actual decision. Someone fills it out once a year before the surveillance audit, scores everything a 2 out of 5, and files it away. That's not risk-based thinking. That's risk-based paperwork, and auditors have gotten much better at telling the difference, particularly since risk-based thinking became a named requirement rather than an implied one.
A real risk-based approach shows up in places an auditor wouldn't have to ask about. It shows up in why you chose to dual-source a critical component. It shows up in why a particular product line gets more frequent internal audits than another. It shows up in the agenda of your management review meeting, where risks and opportunities should be a standing item with actual discussion attached, not a slide that says "no significant risks identified" quarter after quarter. If your risk register never changes, that's not evidence of stability. It's usually evidence that nobody is looking at it.
I've also seen the opposite failure: organizations that build an enormously sophisticated risk matrix with weighted scoring across a dozen criteria, apply it to everything from a client complaint to a five-year strategic decision, and then can't sustain it because the overhead outpaces the value. Risk-based thinking should scale to the actual stakes involved. A missed calibration on a low-criticality gauge doesn't need the same rigor as a design change to an implantable device. Matching the depth of analysis to the consequence of being wrong is itself a risk-based decision, and it's one organizations skip surprisingly often.
Building One Risk Framework Across Multiple Standards
If you hold more than one ISO certification, the efficient move is to build a single risk framework with standard-specific overlays, not five separate systems. Most organizations I've worked with land on a structure like this: one integrated risk register with a column for which management system domain the risk touches (quality, environmental, safety, security, AI), a consistent likelihood and severity scale used everywhere, and standard-specific risk assessment attachments only where the standard requires them, such as an ISO 14971 file for a medical device product line or a Statement of Applicability for ISO 27001.
This does two things. It keeps your integrated management system genuinely integrated instead of five audits' worth of separate paperwork, and it lets you point to one coherent story when an auditor asks how risk feeds your decision-making, rather than five disconnected answers depending on which clause number they cited. Clause 6.1 across every Annex SL standard is asking the same underlying question in different accents: what could go wrong, what could go right, and what are you actually doing about either one. Build the answer once and translate it, rather than answering it five separate times.
Frequently Asked Questions
What is risk-based thinking in ISO standards? Risk-based thinking is the requirement, built into every Annex SL management system standard including ISO 9001, that an organization identify risks and opportunities affecting its objectives and take proportionate action on them as part of normal planning and operation, rather than through a standalone preventive action procedure.
Does ISO 9001 require a documented risk register? No. ISO 9001:2015 clause 6.1 requires the organization to determine and address risks and opportunities, but it does not mandate a specific tool, template, or documented risk register. Most organizations keep one anyway because it's the clearest way to demonstrate the requirement is being met.
How is ISO 31000 different from ISO 9001's approach to risk? ISO 31000 is a standalone guidance standard dedicated entirely to risk management principles and frameworks, and it isn't certifiable. ISO 9001 embeds a lightweight version of that same thinking into a certifiable quality management system through clause 6.1, without requiring the full ISO 31000 framework.
What's the difference between risk-based thinking and formal risk management? Risk-based thinking is a mindset embedded throughout everyday planning and decision-making. Formal risk management, like the process required under ISO 14971 for medical devices or ISO 27001 for information security, is a defined, documented methodology with specific steps, criteria, and records. Some standards require the latter; all of them require at least the former.
If I hold multiple ISO certifications, do I need a separate risk assessment for each one? Not necessarily. You can and generally should build one integrated risk framework that covers all the domains your certifications touch, with standard-specific methodologies layered in only where a standard like ISO 45001 or ISO 13485 mandates a particular approach.
If you're building or auditing a multi-standard risk framework and want a second set of eyes on whether it will hold up under a certification body audit, our team at Certify Consulting works through this exact integration question with clients across quality, safety, security, and now AI governance systems. If AI risk is the piece you're least confident about, our ISO 42001 AI governance consulting work is built specifically around clause 6.1.2 and 6.1.4 impact assessments.
Last updated: 2026-08-08
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.