Informational How the addition of "Risk" will affect ISO 9001:2015

[pldey42]

Marc's earlier post said:

Also notice opportunities in 6.1 a)

?The organization shall plan:
a) actions to address these risks and opportunities, and
b) how to:
1) integrate and implement the actions into its quality management system processes (see 4.4), and
2) evaluate the effectiveness of these actions.​

For me, this is the equivalent of the old preventive action requirement, but now (assuming it stays in something like this form) explicitly basing preventive actions on risk assessments.

For someone to say that the new ISO 9001 requires no preventive action is, I think, misleading.

While some may indeed use RM to dodge difficult contract conditions, I don't think that's the intent. I do think it's trying (perhaps with clumsy wording, but RM is an ill-defined art) to capture what responsible organisations have been doing all along, with process capability measures, risk-based supply chain management, FMEA and so forth.

For software I think this will be helpful. Very few software orgs in my experience use FMEA even though it's common in manufacturing. Now, they'll have to do something like it. The same will be true , I think, of services industries.

The Quality Digest article does raise the possibility of attracting legal problems by documenting risks and that could, perhaps, be a minefield. Yet public companies already have to disclose risks to shareholders, so I'm not sure that it's a real problem.

I think there are some precedents for this being set in ISO 27001, information security management. It's often used as a contractual condition to safeguard sensitive data, especially when it's personal information which is governed in the UK by the Data Protection Act and governed by a regulator called the Information Commissioner. My understanding is that the information commissioner does not expect perfect security, nor zero risk. Rather, as the standard requires, proportionate controls and risk mitigations are expected. ISO 22301, business continuity, is similar.

The problem BP had in the Gulf was an extreme example of doing it wrong, and not in the spirit called for. They were drilling deeper than ever before, and despite having done risk assessments, they had no meaningful risk mitigation plan. So they wrote to the relevant US regulator and said, "We have no risk mitigation plan, as required by the regulations. Can we start drilling anyhow please?" The regulator wrote back: "Yeah, ok." Both BP and the regulator (which at that time also collected taxes due on oil revenues, and has since been relieved of that duty by the Obama administration) wanted the money more than the risk mitigation.

So yes, I agree, in the wrong hands it'll go wrong. But the wrong hands will always find a way.

For those organizations that want to keep their promises, I can only see RM as a good thing for increasing their chances of doing so in an uncertain world. For example, some organizations are using business continuity and its risk-based approach to maintain on-time delivery schedules despite disruptive events like losing electric power, flooding and so forth - especially important when they're saving money by manufacturing in places where labour is cheap, and infrastructure is weak.

Pat

 

[Sidney Vianna]

While some may indeed use RM to dodge difficult contract conditions, I don't think that's the intent. I do think it's trying (perhaps with clumsy wording, but RM is an ill-defined art) to capture what responsible organisations have been doing all along, with process capability measures, risk-based supply chain management, FMEA and so forth.

I think it is critical to realize that ISO 9001:2015 will have has no requirements for risk MANAGEMENT, but, and instead, RISK BASED THINKING, something that, while hugely desirable, seems to be extremely challenging from an auditability perspective. As I said a couple of times already, RISK BASED THINKING, in my opinion, would have been much better placed as another QMS principle in ISO 9000, and not as a "requirement" in 9001. The hyperlinked ISO paper above has some interesting information.

 

[Stijloor]

RBT is too ambiguous and not auditable.

 

[Jen Kirley]

My question, as always, will be "What does that look like?"

I feel sure many people are already doing this but not writing it down. Despite appearances, most of us really don't blunder along with our eyes closed. We are just going to ask for evidence to show it's happening.

 

[Sidney Vianna]

My question, as always, will be "What does that look like?"

I feel sure many people are already doing this but not writing it down. Despite appearances, most of us really don't blunder along with our eyes closed. We are just going to ask for evidence to show it's happening.

what does that look like? If I were an auditee I would not know how to answer that question. If it is happening, what is the value of documenting it? Just to appease an external auditor?

Let me throw this scenario for your consideration: imagine you are auditing Boeing Commercial Airplanes in early 2013. Their flagship program, the 787, was finally getting under control, after a 3+ years of delayed deliveries. 3 + years. Did Boeing do a bad job of managing the risks associated with the 787 development? Would you write BCA for not having RISK BASED THINKING? You, as an auditor spending a week on site can determine if the thousands of meetings associated with the program were not risk based managed?

I am concerned that the challenge associated with effectively implementing and auditing preventive actions will be nothing compared with RISK BASED THINKING.

And, if at the end of the day, the external auditor accepts anything the organization presents as evidence of RBT, what is the point?

 

[John Broomfield]

It seems to me that TC176 members were influenced more by the banks failure to manage risk than what is widely accepted as good quality management practices.

Specifying use of failure modes analysis to drive preventive action in the design of services, products and their processes would have been better than attempting to replace preventive action with risk based thinking.

And making sure that opportunities and risks are assessed as part of planning to fulfill those opportunities may have more closely represented the well-established standards-making process...

...never to lead the way, always to spread good practice.

 

[pldey42]

ISO Guide 73:2009 defines risk management as "systematic application of management policies, procedures and practices to the activities of communicating, consulting, establishing the context, and identifying, analysing, evaluating, treating, monitoring and reviewing risk."

This is the defininition of RM used in ISO 27001. Given that RBT also appears to include action as well as thinking, I don't see a material difference between RM and RBT.

But, regardless, yes, auditing risk management is fraught with difficulties.

TC 176 were influenced by Annex SL of ISO's guidance to itself on writing management system standards, previously known as Guide 83.

https://www.irca.org/en-gb/resources/Guidance-notes/Annex-SL-previously-ISO-Guide-83/

I doubt whether it's much based upon the meltdown of risk management at the banks, not least because they themselves are still in denial and appear to have learned little. I believe that Annex SL draws heavily upon established risk management practices in ISO 14000, 18000 and 27001. It also refers to the ISO 31000 series of standards on risk management.

For quality, I don't think RM is just about product and service design, although that's a large part. It's also about resilience of the supply chain, assuring on-time delivery in full, packaging, assuring continued availability of critical know-how, assuring continuity of supply despite disruptive events (e.g. switching manufacturing from one plant to another) and more. While FMEA is one valuable technique, it's not always applicable. For example, in ISO 27001, some analysis methods go into detail such as threat (what could cause an undesired event, a thief for example) and vulnerability that the threat could exploit (an open door, for example). they then plan mitigations that are proportional to the strength and determination of the threat (we need stronger defences against organized crime, if they're a real threat, than the local kids).

Which of course makes RM hard to audit - but independent review of RM is vital, because when they must document their RM activities, there is a temptation for some to under-report risks, so as to make mitigations cheaper. Not only is it hard for auditors from a time and effort perspective, but - even harder - they must do it objectively.

In the ISO 27001 world, the 2005 version of the standard made objective auditing of RM possible by demanding a documented method for risk assessment - which often looked like FMEA, but modified to take account of threats and vulnerabilities. But the 2013 version of ISO 27001 dispensed with the requirement for formal risk assessment methods (because some organisations simply employed, for example, an ex-policeman with experience of organised crime who could advise appropriate mitigations). So objective auditing of RM, I think, will rely upon either a documented method, or records of RM competency.

To the example of BCA, if mitigations fail, that's not necessarily an indicator of ineffective RM. Indeed, I think the general requirement to measure the effectiveness of processes will have to make an exception for RM - because mitigations sometimes fail, that's life. I think the test of effective RM is, when something bad happens, "hands on hearts, can we stand up in Court and say truthfully that did we do our best?" Which of course isn't auditable. But that's the reality. Suppose we determine that flood is a risk to one of our facilities, with bad consequences both for the environment when our toxic waste gets into the flood waters, and for on-time delivery because we can't manufacture. Suppose also that our mitigation is flood defences - walls, run-off areas and so forth. We build our flood defences assuming the water might rise 10 feet. But it rises 15 feet and we still get flooded. I think for auditors to write that up as ineffective is unhelpful: we got flooded, we know it didn't work. Rather, as auditors, we'd look for lessons learned - how did we get the figures wrong? Did we get the figures wrong or was this a freak? Might it happen again? What more can be done?

So yes, auditing RM will be hard and in my experience of ISO 27001 auditors do get it wrong. We're not helped either by risk assessment methods that obscure the risks by listing hundreds in abstract terms. Nevertheless, as the banks showed spectacularly, if risks aren't monitored and independently audited, avoidable trainwrecks can occur. (Sorry about the mixed metaphor.)

One consequence, then, I think is that auditors will need more time for audits, and the competency to understand RM techniques and the risk landscape applicable to the sector they're auditing.

In a world that's uncertain, where almost everything is subcontracted, often to facilities half way across the globe, I think it's a challenge to which we need to rise.

Pat

 

[John Broomfield]

Pat,

When you were talking about ISO 27001 I thought you were going to refer to its Annex A Statement of Applicability:

(broken link removed)

This makes the ISMS and the results of risk assessment very auditable.

We have no such requirement in the DIS 9001.

But we do see a requirement to design services which could include continuity of supply and on time delivery.

John

 

[Jen Kirley]

"What does that look like?" is an entry question. No, I don't expect documentation just to appease an auditor. Far from it. People can also show me outcomes, describe examples, we can review projects, etc. Unless records are required, of course. And there will be the clause requiring documentation to help control things as needed, similar to 14001 approach. I'm more comfortable with that than some auditees will be if they never worked with 14001 or 18001.

As for Boeing, my understanding is they operate to the aerospace standard, yes? I'm not an aerospace auditor but my guess is that they have project requirements like automotive does. If I was auditing the 787 project it is indeed worth looking at whether or not they applied risk based thinking. Did they just pick any old supplier or did they qualify the supplier first? Did they try to anticipate the inherent challenges of all that production outsourcing, and other issues? If they used an FMEA approach then they applied risk based thinking. As an auditor I am chartered with having enough imagination to consider whether the auditee's approach conforms to the standard, why or why not.

 

[Stijloor]

<snip>As an auditor I am chartered with having enough imagination to consider whether the auditee's approach conforms to the standard, why or why not.

You may be Jennifer, but considering how poorly many organizations and internal/external auditors have addressed the "Process Approach" (even after 14 years), I am very concerned. Unless there is a standard audit approach based on actual RBT evidence rather than auditor's opinion, I am not convinced that this RBT is a good idea.