The key takeaway from our ISO 27001 recertification audit was to shift from bottom-up to top-down risk management.

Recently, we underwent our ISO 27001 recertification audit — that’s what needs to happen if you want to keep your ISO 27001 certification.

And if you’re a company like Yonder, you’re not doing ISO 27001 certification for fun, but because your enterprise customers mandate you to be certified.

So we got started with ISO 9001/27001 certification back in 2020. As usual for entrepreneurs, we started something out of nothing. We used our own software to document our processes, and built up our risk and asset management in JIRA. Believe it or not, but the articles on our JIRA risk and asset management are by far my most-read articles:

Building an ISO 9001 Compliant Risk Management Tool Using JIRA

Building An ISO 27001 Compliant Asset Management Tool Using JIRA

As I am not a friend of discussing things forever, we just started with risk and asset management. And this meant that we built those tools from the bottom up. We added every little risk and every little asset to the risk and asset management.

Fast forward a few years. Over time, we have amassed quite a respectable number of risks and assets, and have been managing and mitigating them diligently.

“Take It To The Next Level”

And then came the recertification audit. For the first time in my life, I enjoyed being audited. The audit was not done in a checklist-like form but as a constructive discussion between professionals.

When the topic of risk management came up and I presented the status of our JIRA risk management, the auditor said:

“I think it would be beneficial to take the risk management to the next level. You started building it from the bottom up, and now you should start to look at it from the top down.”

This was an eye-opener. So far, for example, we have listed every security vulnerability that we detected through automated security screenings as a separate risk, then classified it, and then mitigated it.

So what will we do now?

Finally Understanding “Interested Parties”

When we started our ISO 9001 certification process back in 2020, I never really understood what the norm meant with “interested parties”. We always neglected this subject somehow, just writing something into our QMS document for the sake of completeness.

Looking at the risks from the top down however, it becomes clear why “interested parties” are important: For every risk, we can ask who will be interested in mitigating the risk, and who will be interested in escalating the risk.

And here is the thing: Nobody is interested in a single outdated package version of a backend component. But somebody might be interested in breaking into your application because you have too many outdated package versions. So the true risks are a missing process to update package versions in due time, an application design that doesn’t allow easy patching, and too many people knowing that you have many outdated packages (that’s a true risk when many customers run their own security scans of your application, sometimes even without your knowledge).

This high-level approach doesn’t just work for security vulnerabilities but for all the risks in a company. It will yield a smaller number of risks, but a more holistic view of which parties are interested in a specific risk. Still, to get risks mitigated, a bottom-up view of individual tasks to mitigate the risk is required.

Conclusion

Audits need to certify that certain standards are met, but their true value-add is that they help you reduce your blind spot.

Returning to the risk example mentioned above, our blind spot was that we looked at many small risks from the bottom up, losing the forest view for the tree view.

Time and money well invested, I would say.