Jeff Lowder

Incorporating ISO 31050's emerging risk identification process ensures your organization is not only reacting to risks that have already surfaced but is also prepared for those that might emerge in the future. This proactive, systematic scanning and validation process provides critical foresight, enabling more informed and agile decision-making. By staying ahead of risks, organizations can better safeguard their operations, assets and reputation, while also identifying new opportunities to capitalize on. In the context of ISO 31050, identifying emerging risks is about proactively spotting potential threats or opportunities before they become fully realized. Here's how to approach it:- 1. Run scheduled horizon scanning workshops with cross-functional subject matter experts (SMEs) - Horizon scanning is about identifying signals that could indicate future risks or opportunities. By organizing regular workshops with SMEs from different parts of the organization, you get a diverse, well-rounded perspective on potential emerging risks. These sessions help to build a comprehensive risk radar across all relevant domains. Encouraging open dialogue and fostering an environment where no idea is too far-fetched. 2. Use structured techniques such as PESTLE, STEEP and Delphi - Structured risk identification techniques provide a systematic approach to detecting and analyzing emerging threats. - PESTLE (Political, Economic, Social, Technological, Legal, and Environmental): A framework to assess external factors that could affect your organization. - STEEP (Social, Technological, Economic, Environmental and Political): Similar to PESTLE, but often with a more future-focused angle. - Delphi Method: Involves expert panels to provide consensus views on future risks or trends. 3. Capture signals in a central register with date, source, confidence level, and potential impact areas - A centralized risk register helps you track and document emerging signals, ensuring nothing falls through the cracks.This structured record keeping allows you to monitor the evolution of risks and assess their significance over time. 4. Validate signals through SMEs and external experts where needed -The world of emerging risks is complex and constantly changing and sometimes internal expertise may not be enough. By reaching out to subject matter experts (SMEs) and external experts, you can validate the signals you've captured and gain an even more nuanced understanding. Validation adds credibility to your findings, helping to avoid false positives or overestimating certain threats. External validation could include industry specialists, academic professionals or even consultants who bring a fresh perspective. Engaging with these experts helps expand your knowledge base and improve decision-making. Follow for more in this learning sequel post. Credits: ISO 31050: 2023 #securityriskmanagement  #emergingrisks #ISO31050 #ISO31000 #continuouslearning

32

10 Comments

This is a briefing for business leaders who need to understand the operational and strategic implications of AI-driven malware, and chart a path forward that goes beyond compliance checklists and penetration tests.

1

CMMC Compliance Deadline: Are You Ready for October 1st?   The DoD’s latest update to 48 CFR Part 204.75 makes it official: CMMC certification is mandatory for contractors starting October 1, 2025. If your organization handles Federal Contract Information (FCI) or Controlled Unclassified Information (CUI), you must be certified to bid, renew, or extend DoD contracts. 🎯 Don’t risk disqualification. As a CMMC Registered Practitioner Organization (RPO), Concertium helps defense contractors like you: * Assess and close compliance gaps * Build cybersecurity policies and procedures * Train your team and prepare for certification ⏳ Time is running out. Let’s get you ready before Phase 1 begins. 📅 Book your free consultation today: concertium.com/cmmc-rpo

10

🔍 Why NIST SP 800-18 Revision 2 Matters More Than Ever Public comments are open until July 30, 2025—a key opportunity for professionals to shape the future of digital risk governance. The newly released draft of NIST SP 800-18 Rev. 2 is more than just an update—it's a strategic leap forward in how organizations manage security, privacy, and cybersecurity supply chain risks. 🚀 NIST has released the initial public draft of SP 800-18r2: “Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems.” This update provides unified guidance for creating system security plans, privacy plans, and supply chain risk management plans—helping organizations document controls, responsibilities, and risk management practices more consistently and efficiently. Key highlights: Integrates security, privacy, and supply chain risk management into system planning Supports automation and alignment with the NIST Risk Management Framework Includes supplemental resources like plan outlines and roles/responsibilities templates Here’s why this matters: ✅ Unified Risk Management: The draft consolidates system security, privacy, and supply chain risk management plans into a single, cohesive framework—streamlining oversight and decision-making. ✅ Alignment with Key Frameworks: It integrates guidance from the NIST Risk Management Framework, Privacy Framework, and SP 800-161r1, ensuring consistency across enterprise and mission-level risk strategies. ✅ Automation-Ready: With support for GRC tools, the draft encourages automation in plan development and maintenance—boosting efficiency and reducing human error. ✅ Clarity on Roles & Responsibilities: Updated outlines and templates help organizations clearly define who’s accountable for what, improving governance and accountability. ✅ Critical for Supply Chain Security: In an era of increasing third-party risks, the emphasis on Cybersecurity Supply Chain Risk Management (C-SCRM) is a timely and essential addition. Access the draft and comment instructions here: [NIST SP 800-18r2 Draft](https://lnkd.in/gdViq3XD) #NIST #Cybersecurity #Privacy #SupplyChainRisk #RiskManagement #securitybites #saurabhjain

9

CISA just released updated guidance for its Software Bill of Materials (SBOM) Minimum Elements, and they're looking for public comment! ✍️ This is a great opportunity to help shape the future of cybersecurity. An SBOM is a critical tool for identifying vulnerabilities and managing risks in software. Key Details: What: Updated guidance on SBOM Minimum Elements. Why: To reflect advancements in tooling and implementation since 2021. What's new: Refined data fields, automation support, and operational practices. How to contribute: Provide your feedback via the Federal Register or CISA's anonymous survey by October 3, 2025. https://lnkd.in/d58ts98t Sharing your expertise can help make SBOMs more scalable, interoperable, and comprehensive for everyone. Let's contribute to a more secure digital world! 🌎 #cybersecurity #CISA #SBOM #infosec #riskmanagement

1

I spend a lot of time with manufacturers and product teams who aren’t questioning whether they must comply with the Cyber Resilience Act (CRA) they’re stuck on the how. The CRA is clear on the obligations, but in practice the hard part is interpretation: software distributed online, products that depend on cloud back-ends, continuous updates, open-source components, product families, legacy models… This is exactly what the European Commission is trying to address now. The Commission is preparing a Communication (a guidance document) to explain how the CRA should be applied in real situations and to support a consistent approach across the EU. It’s not a new Regulation and it’s not “binding law” in itself but it matters because it clarifies how key provisions are expected to be understood and implemented in practice. https://lnkd.in/etm43Utx What I like in this draft is that it turns the CRA into practical “rules of the road”, especially on: • Software scope & “placing on the market” (including iterative releases) • What counts as the “product” when hardware depends on apps/drivers/software delivered separately • Open-source (FOSS): when it’s out of scope vs when it becomes a commercial activity, and the steward concept • Updates vs “substantial modifications”: focus on risk/attack surface/intended purpose, not release size • Support period: 5 years is a minimum, and how this works with versioned software/upgrade paths • Cloud / remote processing: what’s part of the product vs general IT infrastructure • Risk assessment & due diligence: manufacturers keep responsibility, including for third-party components The draft is open for feedback for a limited period, and comments are expected in a structured template (so they can consolidate input). If you build products that will fall under CRA, this is a very good moment to stress-test your assumptions and flag the parts that are unclear, unrealistic, or could lead to unintended consequences. I’m sharing the draft guidance here because, from what I see, the companies that will move fastest are the ones that turn these interpretations into concrete internal rules: scope mapping, update governance, support period policy, OSS governance, and evidence-ready documentation.

32