Category Archives: Risk Management

Source-to-Pay+ Part 9: Cyber

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), in Part 5 we laid the foundation for Supply Chain Risk (Generic), in Part 6 we addressed the first major supply chain risk: in-transport, followed by the second major supply chain risk: lack of multi-tier visibility in Part 7. In our last article, Part 8, we discussed the baseline Analytics that should be part of all of the different risk systems we covered in Parts 3 through 7, as well as a control centre.

Today, in Part 9, we move onto Cyber Risks. In today’s hyperconnected SaaS world, nearly half of an organization’s data breaches originate in the cloud (see this recent article by Illumio on Cyber Magazine, for example). So cyber security is important, but not just for your organization — for your entire supply chain.

Note that we are not going to dive deep, there are plenty of security firms that will do that for you. We’re just going to highlight key points of risk that must be covered in your cyber security plan.

Internal Cyber Risk Monitoring and Prevention System
Risks that must be addressed.

Risk Description
E-mail Plenty of risks come in through e-mail. The biggest one you are likely aware of is fraudlent requests for payment from fraudsters posing as fake suppliers / service providers / consultants or new employees in a remote office asking you to approve an emergency payment. However, since fraudsters blast these far and wide (as it takes less work to create them), the most common fraudulent emails are usually phishing/ransom attempts where you have to click an email and enter your system login information to retain access to your email account (or another system you use). (Then they use those credentials you freely gave them to login to your systems, lock you out of them, and demand payment to unlock your account.)

Your email system needs to do more than identify an external sender. It, or the security plug in, needs

  1. to verify the originating domain of the email (since most fraudsters can’t mask the domain they send from),
  2. to identify the domain and location of the first intermediate server the message hits (since that can’t be masked unless they’ve hacked that) as well as if it matches the locale of the domain the email purports to come from, and
  3. to identify the domain of each embedded link and the company it belongs to (as fraudsters are great at registering domains just ONE letter of an actual domain and cloning the contents of the faked domain; e.g. chaEse.com vs chase.com … one is your bank, one will soon be scooped up by a fraudster who will skim account logins for a day during a “maintenance window”, then drain all the accounts dry (or at least to the transfer limits) the next day and wire the money to a foreign account in a jurisdiction with no extradition or banking treaties with the US, then empty the account the day after that, and then disappear never to be seen again …
Hacking Hackers will constantly be trying to penetrate your firewalls, the web servers and underlying operating systems of machines in the DMZ, the applications you are running, and the underlying security systems you use for monitoring and detection (but these are likely the most secure, especially if you are having them maintained and monitored by a professional, big name, IT security firm); You need to be monitoring for unusual activity, (D)DoS attacks, repeated login failures or access abandonments at particular ports or in particular application logs, and so on; You also need a few attractive honeypots that emulate the systems the hackers would want to access most, and if you don’t understand this, or why, talk to your security guru.
Ransomeware Hackers want to access your systems for two reasons, to steal money and IP or lock you out of them (if they can’t access any IP worth stealing or you don’t use any finance systems capable of [authorizing] payments) so you will pay them to get back into your systems. You need to be very careful to not only detect hacking attempts, but the installation of new software that is unrecognized / not authorized by security. This is because you could be totally screwed and have no choice but to pay the ransomware even if you do complete, incremental, daily backups across all systems because smart hackers will install the ransomware, let it sit for a few weeks or so, and then activate when you can’t roll back to a backup because you’d lose weeks or months of data (as you’d have to roll back to just before the ransomware was installed because the majority of backup systems would not be able to identify the actual file changes and there’s no way you could do a restore and not restore the ransomeware after the ransomware was discretely installed).
Infected Websites Your users love to surf, surf, surf the web and go where the hidden links take them. You can’t expect they will all keep their browsers up to date, keep the underlying OS up to date, and, simply put, not be careless. You need to enforce security software on their machine, and check for it, before that machine accesses your network and that the security software is up to date because if they visit the right infected website (from a fraudster’s point of view), it can be an instant hack and/or backdoor for the automatic installation of ransomware on their machine and/or your network.

External Cyber Risk Monitoring and Prevention System
Risks that must be addressed.

Risk Description
Compromised Supplier Site If a supplier site or system is compromised, and you engage with that system in any way, then your system could be compromised. You need a system that monitors for supplier system/site/cloud risks as well as (known) supplier breaches.
Compromised Data All of your systems run off of data. Compromised data is the easiest way to compromise a system. If an email gets intercepted and altered in-transit with a man in the middle account and the hacker changes bank account information, you’re paying a fraudster and not the supplier. If the third party risk metrics are adjusted, your system can be tricked to diverting all business to a single, new, supplier which, while a legal entity, was setup by the founder to take your money and run. And so on.
Compromised Identities Identity theft is on the rise, and it’s often the easiest way for a fraudster to get funds from a business. You need to track all known cases of identify theft associated with all individuals associated with all businesses associated with your business as you will need to do extra verifications on requests from those individuals.
Web-Based Vulnerabilities You need to be aware of where the biggest web-based vulnerabilities are in your suppliers and partners, make sure your suppliers and partners monitor and address those, and make sure you lock down your security to the max when you have to interact with their systems that are classified as high risk for vulnerability.

And more. There’s a lot of risk in cyberspace thanks to the fact that the information and financial worlds have merged, and your organization needs to be on top of it. Identify appropriate providers, or you will need very good luck to not fall victim to a significant cyber-based threat.

Source-to-Pay+ Part 8: Analytics / Control Center

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), in Part 5 we laid the foundation for Supply Chain Risk (Generic), in Part 6 we addressed the first major supply chain risk: in-transport, followed by the second major supply chain risk: lack of multi-tier visibility in Part 7.

In almost every article to date, we’ve highlighted that a key aspect of every risk management system is good analytics, and, in particular, a good control centre to manage the data, the analytics, and the insights gained from the analytics (as well as the plans created around those insights).

Capability Description
Graph (Analytics) Support Standard analytics based on numeric data is not enough. As we have illustrated through this series, risk is more than numbers, roll ups of numbers, and trends on numbers. Risk is relationships, risk is connections, risk is propagation, risk is feedback. You have to be able to track the impacts across chains that span entities, geography, and time.

The risk application must natively support graphs, graph algorithms, and graph analytics. It must be able to count the number of impacted nodes up and down a BoM, multiple BoMs, a chain, and multiple chains. From this, it must be able to calculate an impact of a delay, a shortage, and a catastrophic failure based on BoM requirements, production times, costs, and margins.
Multi-level Metrics and Trend Analysis Even though graph analytics is key for supply chain risk analysis, good old fashioned metrics and KPIs are still key for analyzing risk potential at a point in time, and over time based on changes (and comparison to past trends that have led to risk and failure). For example, an increase in delivery times in every shipment, decreasing raw material supplies going into a source supplier that provides a refined version of that raw material, increasing failure in key components, etc. all indicate increased risk.

The application must support the definition of metrics based on arbitrary formulas, roll ups, and drill downs. It should also support basic trend analysis, allowing for comparison between time periods, similar trends, and historical trends of interest. it should also be capable of projecting the trend for an arbitrary time period in the future based upon the current trend progression and the most likely continuation based upon correlation with similar and historical trends.
Real-time Data Monitoring & Automation The application needs to integrate with third party data feeds, get (near) real-time updates, update all of the metrics the data relates to, monitor the changes against alerts, update the trends, and determine if any updates indicate trends of interest, significance, or concern. This all needs to happen automatically.

The application must support an open API, support standard data formats, be aware of standard data records used in direct supply chain, integrate with third party data feeds for all types of supply chain (risk) data out of the box, and be able to normalize all of this data into a standard data store (warehouse, lake, lakehouse, etc.). It must support rules-based alerts, integrations, monitors, and workflows to allow for appropriate automation support.
Mitigation Plans The platform must support the definition of mitigation plans, with individual actions, objectives, and impacts. Mitigation plans should support multiple stages, actions should support detailed definitions and expected outcomes, objectives should support a metric-based definition, and impacts should support detailed cost definitions.

It should be easy to instantiate an instance of a plan when a risk event is detected or defined by a user, track updates in real time as new data comes in or users define new data, track the impact of a recovery action (if it decreases the time to recovery, etc.), and auto-generate progress reports on a regular basis, as well as roll up all of the impacts, and recoveries, for users who need it. It should also support the creation of what-if scenarios to calculate the potential impacts of a potential action (in a given timeframe), and allow for cost vs impact vs margin/profit improvement calculations to help an organization determine if the action could be worth it, especially if the associated chance of success is limited.
Surveys The platform also needs to support the creation of surveys that can be distributed to multiple parties up and down the chain to collect data for analysis purposes.

The surveys must be capable of collecting numeric, type-valued, and open-valued data, as required.

Source-to-Pay+ Part 7: Multi-Tier Risk

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), in Part 5 we laid the foundation for Supply Chain Risk (Generic), and then in Part 6 we addressed a major supply chain risk: in-transport.

As part of (generic) supply chain risk, we highlighted multi-tier risks that arise when multiple suppliers need to process materials, make sub-components, build components from those sub-components, and then assemble those components to make your product. When it takes 10,000 suppliers to make your product (which is the case with some complex electronics products), the risks are beyond what most minds can comprehend. Multi-tier risk management systems for direct supply chains must address a number of specific requirements outlined in Part 5.

Capability Description
Connections & Relationships It is incredibly important to keep track of all of the connections in the supply chain, not just the links that represent the paths of raw materials from the source into the products that your tier 1 suppliers supply you. You need to know who else your suppliers supply, any risks that poses to you (if your competitors have more influence and can steer the direction, process, and quality of the supplier); who supplies your suppliers, any risk that poses to them, and thus to you; who owns your suppliers, and any risk that creates to your organization in different countries of operations due to sanction lists; and who your suppliers contract out too, and any risks that may pose.

It is thus critical that a multi-tier supply chain risk management solution support connection graphs that can be re-oriented around any entity at any time for a quick inspection of risks posed by that entity and all entities it may in turn affect. It is also critical that the solution support drill-in at each entity for deep insights and analysis.
Bill-of-Materials The platform must support multi-level bill of materials (BoM) support. You can’t track the full supply chain if you can’t track the full product inputs all the way down to the raw material inputs for each component, sub-component, and primary part. You also need to be able to trace any product with an issue down to the supplier who made the part/sub-component/component with the issue.

The platform must make it easy to define, maintain, alter, and otherwise work with the bill of materials. It shall be easy to instantiate an instance for each supplier of a product and trace all the way down to the mine or fields the raw materials come from, or the recovery/recycling plants if the materials are being re-used in a sustainable fashion.
Manufacturing Visibility The visibility doesn’t stop at the BoM. It begins at the BoM. For each product you buy from each supplier, you need to track the supplier’s production capacity at the plant, as well as how that capacity is influenced by other products, and switchover time. (If you buy multiple products that use the same production line, then you can’t get full capacity of both.) It must be easy to see all manufacturing information related to a plant of a supplier, how many products it is associated with, and what tradeoffs are in effect when you order a specific product from a supplier.

The platform must be capable of calculating the units per hour/day/week, the switchover time, and how many units of each could be produced given a requirement for one product. (And the same must hold true for three or more different products/configurations.)

It’s critical that the platform allow for easy definition and manipulation of BoM instantiations, supplier plant nodes, manufacturing details, production line capability, and associated timings.
Public vs. Private Differentiation The platform must be able to maintain the distinction between public and private entities, specific to the countries the entities are located/headquartered in, as well as the different types of information the organization needs to keep on both from a risk perspective. In some countries, public entities are more rigorously regulated and in other countries, private entities could be more heavily regulated. The platform needs to allow a buying organization to ensure that the entities are acting appropriate to their type. Also, investments and sanctions can sometimes work differently depending on entity type.

The platform must be capable of tracking entity type, associate the entity with the relevant regulations and requirements based on the type, and alert the organization if anything changes with respect to the type or any change that could impact the type classification.
Predictive Sub-Tier Mapping A supplier may not always disclose it’s sub-tiers. In such a situation, the platform must predict which sub-tier suppliers are being used based on product type, raw material, raw material availability, available transport networks, and so on.

The platform must contain an adaptive algorithm that learns as new information becomes available, continuously updates its knowledge from market data feeds (import/export logs are often public information), and integrates with third party (commodity) markets that can predict changes over time.

Source-to-Pay+ Part 6: (In) Transport Risk

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), and then in Part 5 we laid the foundation for Supply Chain Risk (Generic).

As part of supply chain risk, we highlighted transport mapping and tracking as a key risk that the system should track, but noted that a generic supply chain risk management system would generally not be a full featured transport risk management system because such a system would also monitor and mitigate risks of goods in-transport. (Not just risks at nodes.) Such a system has a number of specific requirements beyond the basics outlined in our last article. In this article, we are going to discuss a number of those specific requirements.

Capability Description
Modal-Specific Support Cargo can travel by land, rail, sea, or air. As a result, an in-transport platform has to recognize each of these modes, the differences between them, the data that needs to be tracked, and the data that can be obtained from carriers providing each mode.

Such a platform should integrate with industry standard data feeds from TMS (Transport Management Systems), data feeds from major carriers, GPS systems, and other systems that provide data on your shipments, where they are, and when they are expected to get to the next location if the current leg of transport does not have a real-time GPS feed.
Cold Chain/Hazardous Not all cargo can travel dry at room temperature. Some has to travel wet, some has to travel refrigerated or frozen, and some has to travel with special precautions for hazardous materials. It’s critical that such a platform be able to tag items with these tags, these transport requirements, and assess the risks associated with the transport based on carrier, route, geolocation, etc.

Such a platform must be able to detect when a risk materializes or escalates, such as the delivery time estimate being pushed forward by a week when the cargo was only expected to have a shelf-life of six (6) days when delivered, extreme weather phenomena suddenly materializing in the region of the transport vehicle, or dangerous (man-made) accidents occurring as a result of a leak, accident, or failure in transport.
Manifests/Bills of Lading The system should be capable of accepting bills of lading and cargo / shipping manifests and ensuring that the bill of lading exactly matches the shipment that is expected from the supplier, the cargo/shipping manifest exactly matches the bill of lading, and the inventory at the dock/yard matches the cargo manifest. This is the only way to minimize the chance of theft and fraud during transport. And by fraud, we don’t just mean your goods disappearing, we mean your containers and your company being used to smuggle goods into one or more countries where the goods are prohibited in those countries.

The system should also be capable of identifying carriers who have had incidents in the past, the carriers who are most at risk due to the regions they operate in, and the carriers who are most at risk due to the products they are carrying, both for you and for others (based on public manifests).
Ports The system will track detailed information on the ports that are used in the supply network. It will maintain information on port capacities / throughput, the carriers that go in and out, the equipment, the security at the dockyards, and so on. It will maintain information on the labour situation (last strike, the date the contract ends, likelihood of a strike/slowdown, etc.) as well as the available workforce.

The system should be capable of tying in weather information, local geopolitical information, economic information, and other disruptions that could affect the port, as well as any other risk-based factors that are relevant.
Canals/Straits A lot of the world’s goods flow through canals (primarily the Panama and Suez) and straits to ports that are off of lakes and seas and not on the Atlantic or Pacific Ocean. While there are the risks of natural disasters just as there are on the high seas, there are also the geopolitical risks associated with all of the countries that border the canal or strait. (Especially if they are unfriendly to the country of origin, destination, or registration of the ship.)

The system must track all of the risks specific to the canals and ports that the organization, and its carriers, use in the ocean-based transport of goods.
Warehouses/Cross-Docks Most goods procured by an organization will live in multiple warehouses in their journey through the supply chain. The suppliers, the shipper’s local cross-dock, the port warehouse, the railroad cross-dock, your primary warehouse, and the regional warehouses that supply your local retail centers or manufacturing plants, as appropriate. These docks all pose a security risk.

The system should support all of the third party risk capabilities that are relevant for the owner/operator of the warehouse, the locale the work force is in, the third parties that provide the workers, and any other risks that can be identified and monitored for.
In-Yard (Rail/Dock) Sometimes the goods are in a warehouse, and sometimes they are just in a yard at the dock or the (rail)yard waiting to be loaded on a truck or a train to be taken to a cross-dock or warehouse. The risk will be a blend of warehouse/cross-dock and port/rail risks, tailored to the relevant locale.

The system should support all of the associated third party risk capabilities that are relevant, and, as with the warehouse/cross-dock, support risks that can be identified and monitored for.
Airports/ Some goods will go by sea, some by rail, some by land, and some by air. Airports have their own class of risks — which can include hijackings, crashes, and way too many carriers and personnel in and out of shared warehouses.

Similar monitoring to in-yard, but expanded to meet the specific need of airports servicing your cargo.
Driver/Conductor/Captain The biggest risks in transport are often not the third party carriers you deal with, but the people — are they appropriately vetted, trained, certified, and monitored? Who are they associated with? Can those associates pose risks? Do they need to be monitored? If so, when and how?

This system should integrate with an employee/contractor certification and monitoring systems to at least make sure all employees/contractors assigned to the organization’s cargo have appropriate licenses, certifications, training, and insurance.

And, of course, an In-Transport Risk Management system will also need a host of generic analytics/planning/monitoring capabilities, but since many of these are common, and since stand alone risk-focussed analytics applications are also part of the plethora of offerings out there, instead of discussing these generic features in this and every other article, as we noted in our coverage of Corporate Risk, we will instead discuss these capabilities in an article dedicated to Risk Analytics and Monitoring.

Source-to-Pay+ Part 5: Supply Chain Risk (Generic)

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” (or should we say “Uncertainty”) Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk and then in Part 4 we took on Third Party Risk (in Part 4A and 4B).

But there’s much more to risk than just the (internally focused) corporate risks and the third party (supplier) risks. There are also supply chain risks. Today we are going to discuss the basic supply chain risks that an organization can expect to keep track of with a generic supply chain risk management application.

Capability Description
Multi-tier Mapping A good supply chain risk management system will map the organization’s known supply chain and allow them to track what facilities are located where, at least to the extent that they supply a higher tier that eventually leads to a good or service being delivered to a company location. This will include the tier 1 suppliers, the tier 2 suppliers they use, the known locations of the suppliers they use, all the way down to the raw materials. It will include intermediate warehouses, ports, (cross)-docks, rail yards, and FTZs used by the organization.

The organization will be able to search by product, and see the known supply chain. Search by location, see the suppliers who are there, and then see all the products that flow through those suppliers at that location.
Geo-Political Tracking For ever region the organization does business in, the platform tracks news and events related to the geo-political climate. Government decisions, labour unrest, increases in crime, terrorist activity, man-made disasters and other, related, events will be tracked. Government stances on issues, local business preferences, likely election outcomes, and anything that could cause a change in the political climate will also be tracked.

For each government decision, labour unrest, terrorist activity, man-made disaster, closure, etc, the platform will associate it with all affected suppliers and supply chain network nodes (warehouses, ports, etc.) in the network. In addition, any news or events that may turn into an event of interest will also be referenced.
Economic Tracking For every region the organization does business in, the platform will track the local economics. How is the currency trading against the primary currencies used by the organization and is it increasing or decreasing in value. How is the local job market, is unemployment decreasing or increasing? How is local consumer spending?

All of the above are indicators of the local economy. The organization is interested in not only how much it will cost for the goods now and tomorrow, but, if they are selling in the local economy, how likely it is the local market will (continue to) be able to afford the products, and how likely the supplier will be able to attract and retain the workforce it needs to serve the organization.
Natural Disasters For every region, and every region between every region the company sources from and every region they sell in, the organization tracks natural disasters, their impacts, and, if recovery is necessary, the state of recovery. It also tracks natural disaster risk, and any nearby (weather) events that could turn into a disaster (hurricanes forming over the ocean, tremors that could signal an earthquake, lava flows that could signal a volcanic eruption, etc.).

In addition to tracking the disasters that have happened, might happen, and will happen again, it also tracks the impact a disaster will have for every day a supplier’s operation is disrupted. The platform will contain the ability to model the cost of a disruption at every tier 1 node and propagate that down the chain.
Disruption Tracking The platform will also contain the ability to track arbitrary disruptions, track the recovery status, model the potential impact, and track the actual impact.

This will normally form the foundation of a control centre, which will be integrated with the analytics and monitoring capability (which, as we noted in our last three parts, will be covered in a separate article), and allow the organization to centrally track, manage, and mitigate organizational risks.
Transport Mapping & Tracking As noted above, the platform will track every region, and every region between every region, that the company operates in and use this information to map and track the organization’s transport networks. Every node used by every carrier will be tracked, every lane will be mapped, and every route monitored to the extent possible by the application.

This normally won’t be a full fledged transport risk management platform, which will be something we cover in another article, but will provide enough foundations that a third party application can be linked in or data feeds imported.

Moreover, a Generic Supply Chain Risk Management Application will also contain a host of generic analytics/planning/monitoring capabilities, but since many of these are common, and since stand alone risk-focussed analytics applications are also part of the plethora of offerings out there, instead of discussing these generic features in this and every other article, as we noted in our coverage of Corporate Risk, we will instead discuss these capabilities in an article dedicated to Risk Analytics and Monitoring.