Study Guide
Third-Party and Supply-Chain Risk
How organisations inherit risk through suppliers, services and software, what the British Airways Magecart example shows, and how supplier risk is managed from selection to exit.
Lesson 5.7 Governance, Risk & Compliance
No organisation runs entirely on its own systems. It relies on cloud services, software written by others, support companies and scripts loaded into its web pages. This lesson works out how each of those can bring risk in, and how an organisation keeps control of risks that sit partly outside its walls.
Stage: Think
A spare key
Think it through
Your house has strong locks, but a cleaning company has a spare key, which it keeps in an unlocked drawer at its office. How secure is your house now?
- Hint 1: Who else can now open your front door?
Show what happens
Only as secure as the weakest way in, and one of those ways now runs through someone else’s drawer. Organisations face the same problem with every supplier they give access, data or trust to.
Think it through
Show the answer
Answer: B. The one with administrator access.
The one with administrator access. The scrutiny a supplier needs grows with the access, data and trust it is given.
Stage: Predict
Inheriting risk from others
The central point is that organisations can inherit cybersecurity risk through third-party suppliers, services and software. Even if an organisation protects its own systems well, a weakness in a supplier or dependency can still create an attack path.
Think it through
Name as many ways as you can that a supplier could bring risk into an organisation.
- Hint 1: Think about access, data, software and web pages.
Show what happens
By having access to its systems, by holding its data, by supplying software it builds in, or by providing content its web pages load. The table gives an example of each.
Third parties affect risk in several different ways:
| Relationship | Example | How it can create risk |
|---|---|---|
| Suppliers with access | An IT support company with remote access to staff laptops. | A compromised supplier account can become a route into the organisation. |
| Suppliers holding data | A cloud service storing learner records. | A breach at the supplier can expose the organisation’s information. |
| Software and components | A code library built into the organisation’s website. | A vulnerable or maliciously altered component is inherited by everything that uses it. |
| Content loaded from elsewhere | Analytics or chat scripts on a web page. | The script runs in every visitor’s browser with the same access as the page itself. |
The same supplier can fall into more than one group, and the risk grows with the access, data and trust the organisation gives it. Attack Surfaces and Attack Vectors looks at the same dependencies as part of an organisation’s attack surface.
Stage: Predict
Example: British Airways and Magecart
A web page is not only text and pictures. It also carries scripts: small programs, written in a language called JavaScript, that the page tells your browser to run. Scripts are what make a page respond when you click or type. A page often loads some of them from other companies, for example to count visitors or to offer a chat box.
Think it through
A payment page loads a chat script from another company. If someone altered that script, whose browsers would run the altered version, and what could it see?
- Hint 1: Where does a script run: on the company’s server or in the visitor’s browser?
Show what happens
Every visitor’s browser would run it, with the same access as the page itself, so it could see whatever customers type, including card details.
The British Airways Magecart incident is an example of how a malicious script can be used to interfere with web pages and capture information entered by users. It shows why supply-chain and third-party dependencies belong in an organisation’s wider risk assessment.
Magecart is a name given to groups carrying out web skimming. Such an attack generally works like this:
- A payment page loads scripts. Some come from the organisation’s own servers; others may come from suppliers.
- An attacker alters one of them. This might happen on the organisation’s own systems or at a supplier whose script the page loads.
- Every visitor’s browser runs the altered script, because the browser trusts whatever the page tells it to load.
- The script copies what customers type, such as card details, and sends a copy to a server the attacker controls.
- The page keeps working normally, so neither customers nor the organisation necessarily notice.
Check your understanding
Show the answer
Answer: A. The page keeps working normally.
Because the page keeps working normally: the copy goes to the attacker silently, while the payment goes through as usual.
An attack that reaches an organisation through something it depends on from a supplier, as this one does, is called a supply-chain attack.
Those five steps describe web skimming in general. The UK Information Commissioner’s Office published a penalty notice setting out what happened in the British Airways case itself.
Defences include keeping an inventory of every script a payment page loads, restricting which sources the page may load scripts from, checking that scripts have not changed unexpectedly, and monitoring payment pages for tampering. PCI DSS v4.0.1, covered in Security Frameworks and Standards, includes requirements for managing scripts on payment pages.
Stage: Predict
Managing supplier risk across the relationship
Think it through
A supplier passed every check when the contract was signed three years ago. What might have changed since, and what will need doing when the contract ends?
- Hint 1: Is a supplier the same company three years later?
Show what happens
Its staff, systems, ownership or its own suppliers may have changed, and it may have had incidents, so it needs monitoring. At the end, its access must be removed and data returned or deleted.
Supplier risk is not assessed once at signing and then forgotten. The lifecycle has five stages:
An original educational sequence, one stage at a time. The depth of each stage should match how much access, data and business dependency the supplier has.
Identify
Step 1 of 5: Know who and what
Know which suppliers exist, what each one can access and which business activities depend on it.
Assess
Step 2 of 5: Before contracting
Ask for evidence proportionate to the risk. A Cyber Essentials or ISO/IEC 27001 certificate is useful evidence, but only for the scope it covers.
Contract
Step 3 of 5: Write the requirements in
Set security requirements, prompt incident notification, rights to information or audit and, for personal data, the terms a controller needs from a processor.
Monitor
Step 4 of 5: Watch for change
Review performance, changes, incidents and the supplier’s own suppliers. A supplier that was sound at signing can change.
Exit
Step 5 of 5: End it cleanly
Remove access, recover or securely delete data and check that nothing still depends on the supplier.
Check your understanding
Show the answer
Answer: C. Monitor
Monitor: a supplier that was sound at signing can change, and the lifecycle watches for that.
Proportionality matters. A supplier delivering printer paper needs little security scrutiny; a supplier with administrator access to every system needs a great deal. Spending the same effort on both wastes time on one and gives too little to the other.
Go deeper Kinds of agreement named in the Security+ objectives
The Contract stage can involve several different documents. The Security+ objectives name these.
| Agreement | What it does |
|---|---|
| Service-level agreement (SLA) | States the measurable level of service the supplier promises, such as how much of the time the service will be available and how quickly faults will be fixed. |
| Memorandum of understanding (MOU) | Records what two parties intend to do together. It is usually a statement of intent and not a binding contract. |
| Memorandum of agreement (MOA) | More specific than an MOU: it sets out what each party has agreed to do. |
| Master service agreement (MSA) | The overall terms that apply to all the work between two parties, agreed once. |
| Work order or statement of work (WO/SOW) | The details of one particular piece of work under the master agreement: what will be delivered, by when, for how much. |
| Non-disclosure agreement (NDA) | A promise to keep specified information confidential. |
| Business partners agreement (BPA) | How partners in a joint venture share responsibilities, costs and profits. |
A right-to-audit clause is a term in any of these that lets the customer inspect, or have inspected, how the supplier is meeting its security obligations.
A fictional training organisation wants an online service that lets learners book and pay for courses.
- Identify what it will touch. The service will hold learners’ names and contact details and take card payments, and the organisation’s website will load its booking script.
- Assess proportionately. Because it handles personal and payment data, the organisation asks for evidence of the provider’s security and payment-card compliance, and checks what each certificate actually covers.
- Contract. The provider will be handling learners’ personal information on the organisation’s behalf, which data-protection law calls being a processor, and the law requires particular terms in the contract for that. The agreement includes them, together with a duty to report incidents promptly and the right to request security information.
- Monitor. The organisation reviews the provider each year and watches for changes, such as the script being loaded from a new source.
- Plan the exit. It records how learner data would be returned or deleted if the service ended.
The provider handles the payments, but the organisation still chose it, still owns the relationship with its learners and remains accountable.
Stage: Predict
Accountability stays with the organisation
Think it through
Show the answer
Answer: B. No: it remains accountable.
No. It chose the supplier, owns the relationship with its learners and remains accountable for overseeing the supplier.
Using a supplier can transfer some work and some financial consequences. It does not transfer accountability:
- Treating Risk explains that transferring a risk does not remove the organisation’s accountability or the underlying weakness.
- Data Protection explains that a controller using a processor remains responsible for choosing it carefully and setting the right terms.
- Assurance and the Limits of Penetration Testing explains why a supplier’s certificate is evidence about its scope at a point in time, not a guarantee.
A simple supplier inventory answers most early questions: who each supplier is, what they can access, what data they hold, who owns the relationship and when they were last reviewed. Organisations are often surprised by how many suppliers have access they had forgotten about.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: C. The exit stage was missed.
The exit stage was missed. Remove the access now, check whether it has been used, and fix the process so that ending a contract removes access.
Apply it
Show the answer
Answer: A. Limit where scripts may load from.
Restricting which sources a payment page may load scripts from, together with an inventory and checks that scripts have not changed.
Apply it
Show the answer
Answer: B. Effort is not matched to risk.
The effort is not proportionate: too much for the sandwich firm, and possibly too little for a supplier holding payroll data.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Inherited third-party risk: a supplier weakness can create an attack path even when the firm protects its own systems well.
Organisations can inherit cybersecurity risk through third-party suppliers, services and software, and that a supplier or dependency weakness can create an attack path even when the organisation protects its own systems. The compromised account leads straight to the firm’s laptops, so the risk is the firm’s concern. That is why supply-chain and third-party dependencies belong inside the wider risk assessment, not after an incident.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record)
Show answer
Answer: The British Airways Magecart example, which showed malicious JavaScript interfering with web pages and capturing what users entered.
The British Airways Magecart incident shows how malicious JavaScript can interfere with web pages and capture the information that users enter, and why supply-chain and third-party dependencies belong in the wider risk assessment. Scripts running on a page are part of its security, whoever provides them. The other examples make different points: Shodan shows exposure, the MOT analogy concerns the limits of assurance, and a CVSS score describes the severity of one vulnerability.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record)
Show answer
Answer: It is evidence only for its stated scope, so the hosting service needs its own proportionate assessment.
A certificate is evidence only for the scope it covers, and supplier assessment should be proportionate to the access, data and dependency involved. This certificate says nothing about the hosting service, which would hold personal data, so the college needs evidence about that service. Certificates remain useful within their scope. Using a supplier also does not transfer accountability: the college remains responsible for choosing and overseeing it.
Revision sources: Third-Party and Supply-Chain Risk (Supplementary Study Guide explanation)
Show answer
Answer: Remove the supplier’s remote access and accounts.; Recover the charity’s data or confirm it has been securely deleted.; Check that no system still depends on the supplier.
The supplier lifecycle runs from identification, proportionate assessment and contract to monitoring and exit. Exit means removing access, recovering or securely deleting data and checking that nothing still depends on the supplier. Dormant supplier accounts remain a way in, and the charity’s risk does not end simply because a contract does.
Revision sources: Third-Party and Supply-Chain Risk (Supplementary Study Guide explanation)
Show answer
Answer: True
True. The supplier lifecycle includes monitoring after the contract is signed: reviewing performance, changes, incidents and the supplier’s own suppliers, because a supplier that was sound at signing can change. The underlying point is that organisations inherit risk through suppliers, services and software, so that risk has to be tracked rather than assessed once.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record) · Third-Party and Supply-Chain Risk (Supplementary Study Guide explanation)
Show answer
Answer: Browsers run the altered script with the page’s own access, so it can copy what customers type and send it on.
The British Airways Magecart incident shows how malicious JavaScript can interfere with web pages and capture what users enter. The general mechanism: the browser runs the scripts the page loads, with the same access as the page, so an altered script can copy form entries and send them to a server the attacker controls while checkout carries on normally. HTTPS protects the connection, not what code inside the page can read, and no database breach or interception is needed. The shop is fictional, and no detail of the real incident is assumed beyond what is described here.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record) · Third-Party and Supply-Chain Risk (Supplementary Study Guide explanation)
Show answer
Answer: Keep an inventory of every script the payment page loads.; Restrict which sources the payment page may load scripts from.; Check that the page’s scripts have not changed unexpectedly.
The defences that act on the page’s scripts are to keep an inventory of every script a payment page loads, restrict which sources it may load scripts from, check that scripts have not changed unexpectedly and monitor payment pages for tampering. HTTPS protects the connection, not whether a supplier’s script was altered before the browser received it, and patching only the server ignores the supplier route altogether.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record) · Third-Party and Supply-Chain Risk (Supplementary Study Guide explanation)
Study and revision
Practise supplier risk through the Risk Management topic and web skimming through the Web & Application Security topic. Questions cover inherited supplier risk and the Magecart example, and, from this lesson’s supplementary explanation, certificate scope, the supplier lifecycle, how web skimming works and its controls. They are learning-only.
Stage: Consolidate
What to remember
- Organisations inherit risk through suppliers, services, software and content loaded from elsewhere.
- Web skimming alters a script a payment page loads, so every visitor’s browser copies what they type to the attacker.
- Supplier risk runs from identification and assessment, through contract and monitoring, to exit.
- Scrutiny should match the access, data and dependency a supplier has.
- Using a supplier transfers some work and costs, never accountability.
Key terms
- Third-party risk
Risk an organisation inherits through its suppliers, service providers and the software or services it depends on.
- Supply-chain attack
An attack that reaches its target through a supplier, service or software component the target trusts.
Common misunderstandings
A supplier’s weakness can create a route into the organisation or expose its data, however strong its own controls are.
A certificate covers a defined scope at a point in time. It is evidence to weigh, not a guarantee.
The organisation remains accountable for choosing and overseeing its suppliers.
Lesson sources and acknowledgements
Sources and scope
- Taught in Session 2 (see the Session 2 Learning Log): organisations inheriting risk through third-party suppliers, services and software; supplier and dependency weaknesses creating attack paths; the British Airways Magecart incident as an example of malicious JavaScript capturing information entered on web pages; supply-chain dependencies as part of wider risk assessment.
- Not checked here: the five steps describe web skimming in general. The precise details of how the British Airways attack was carried out go beyond this summary and would need to be checked against official sources, such as the ICO’s published penalty notice, before being relied on.
- Supplementary explanation: what a script is, the “Go deeper” table of agreement types, the ways third parties affect risk, how web skimming generally works, the controls against it, the supplier lifecycle, proportionality, the booking-provider example, the accountability links, the practical note and the misunderstandings.
- Not covered: the detailed facts of the British Airways incident beyond the classroom summary, which would need checking against official sources.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the spare-key opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. The training organisation and its booking provider are fictional. I have not assessed a supplier.
Every point where an attacker could interact with, or try to get into, an organisation, system or application.
Meeting applicable legal, contractual and internal requirements.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
The organisation that determines the purposes and means of processing personal data.
The UK’s independent regulator for data protection and information rights, to which notifiable personal data breaches are reported.
The payment-card industry security standard for environments that store, process or transmit payment-card data. It does not replace data-protection law.
An organisation that processes personal data on a controller’s behalf.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
An attack that reaches its target through a supplier, service or software component the target trusts.
Risk an organisation inherits through its suppliers, service providers and the software or services it depends on.
Altering a script on a web page so that it secretly copies information users enter, such as card details, and sends it to an attacker.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.