Digital Transformation and Artificial Intelligence

Software Supply Chain Security and Third-Party Risk Management

A practical programme in software supply chain security for professionals who are accountable for results, not just awareness.

  • 5training days
  • 4modules
  • 8sessions
  • 32topics
Software Supply Chain Security and Third-Party Risk Management
5days

About the programme

Course Overview

Vendors sell software supply chain security as a product; it behaves in practice as a change programme. Boards are asking for measurable returns from chain security, not demonstrations. Moving the digital and data-driven work capability from written policy into daily practice is not achieved by a single decision. Participants gain a clear basis for measuring what software supply chain security has actually achieved. It is pitched for practitioners with responsibility for this aspect of digital and data-driven work, not for observers of it. The programme uses small-group work so that each participant's treatment of chain security is examined, not just described. Mature organisations treat software supply chain security as a standing capability rather than a project that finishes. Participants leave with a method for chain security, not a set of opinions about it. The programme ends where implementation begins, with the practice within digital and data-driven work broken into steps someone can start on Monday.

Expected Learning Outcomes

  • Set retention, lineage and deletion rules for the data flowing through software supply chain security.

  • Establish monitoring that detects model or service degradation in chain security before users report it.

  • Assess whether software supply chain security should be built in-house, bought, or delivered through a partner.

  • Handle the trade-offs in chain security between speed, cost and assurance explicitly rather than implicitly.

  • Map the regulatory obligations that apply to software supply chain security in each market of operation.

  • Assess the current state of chain security against a structured set of criteria rather than impressions.

  • Define the scope and boundaries of software supply chain security so that responsibility for it is unambiguous.

Who Should Attend

  • Operations staff who encounter the consequences of software supply chain security directly.

  • Consultants and advisers supporting clients on chain security.

  • Solution architects designing how software supply chain security fits the existing estate.

  • Product owners prioritising the roadmap for chain security.

  • Risk and compliance staff assessing the controls around software supply chain security.

  • Operations managers whose processes are changed by chain security.

Course Modules

Open any module to see its sessions and topics.

01

Software supply chain security: governance, ethics and explainability

2 sessions · 8 points

Session 1Keeping software supply chain security alive after the initial push

  • Classify the data in software supply chain security and apply access controls that match the classification.
  • Specify the fallback path when chain security is unavailable.
  • Design the pilot for software supply chain security so that a negative result is still useful.
  • Verify that chain security still performs when input volume doubles unexpectedly.

Session 2The governance chain security needs and the governance it does not

  • Record the rationale for each significant choice made about software supply chain security.
  • Measure the current quality of the data feeding chain security before assuming it is usable.
  • Plan how software supply chain security is versioned and how a bad release is rolled back.
  • Decide what will be stopped to create capacity for chain security.
02

Chain security: business case, scope and the data it depends on

2 sessions · 8 points

Session 1Where chain security typically breaks, and why

  • Confirm that contractual obligations around software supply chain security are understood.
  • Arrange the handover of chain security so capability survives staff changes.
  • Build the internal briefing that explains software supply chain security to those affected.
  • Set the review interval for chain security and who attends.

Session 2The data question everyone skips at the start of chain security

  • Agree who is on call for software supply chain security outside working hours.
  • Remove steps in chain security that add effort without adding assurance.
  • Confirm the retention and deletion rules applied to data inside software supply chain security.
  • Assess the regulatory obligations chain security triggers in each jurisdiction.
03

Chain security: people, skills and the change that follows

2 sessions · 8 points

Session 1Testing chain security before relying on it

  • Agree the indicators that will show whether software supply chain security is improving.
  • Prepare the summary of chain security that senior management will read.
  • Build the user briefing that explains what software supply chain security does and does not decide.
  • Test chain security against edge cases drawn from real historical records.

Session 2Making software supply chain security secure without making it unusable

  • Plan the sequence in which improvements to software supply chain security will be introduced.
  • Check that chain security still works when volumes rise unexpectedly.
  • Set out the decisions in software supply chain security that require sign-off and by whom.
  • Define the exit route from the supplier supporting chain security.
04

Chain security: vendor selection and avoiding lock-in

2 sessions · 8 points

Session 1Proving chain security paid for itself

  • Set the metrics that will show whether software supply chain security is drifting from its intended behaviour.
  • Identify the skills the team lacks to operate chain security independently.
  • Define the service level software supply chain security must meet and what happens when it is missed.
  • Benchmark the organisation's chain security against comparable operations.

Session 2Where chain security touches systems nobody wants to change

  • Decide which legacy process software supply chain security retires, and set the date.
  • Distinguish symptoms from causes when chain security underperforms.
  • Define acceptance criteria for software supply chain security in advance.
  • Agree what will be standardised in chain security and what will not.

Choose the package that suits you

Silver Package

At least 3 people

USD1,250
  • Workshop or Program Participation
  • Airport Transfers
  • Customized Badge
  • Expert Mentorship (Private Sessions)
  • Supervision & Secretarial Services
  • Accredited Certificate of Participation
  • Complete Training Kit
  • Coffee Break
  • Closing Ceremony

Gold Package

At least 3 people

USD1,850
  • 5-night stay in a 5-star hotel
  • Workshop or Program Participation
  • Airport Transfers
  • Customized Badge
  • Expert Mentorship (Private Sessions)
  • Supervision & Secretarial Services
  • Accredited Certificate of Participation
  • Complete Training Kit
  • Coffee Break
  • Closing Ceremony

Complete your registration

We will contact you within one business day to confirm.

Share this course

✆