Chapter 15 — Security governance, risk and compliance: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Provider assurance"]
N3["15.3 Planning for failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Provider assurance"]
N3["15.3 Planning for failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Dependencies]
|
v
[15.2 Provider assurance]
|
v
[15.3 Planning for failure]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) identify dependencies on external providers; (2) check provider assurance; (3) plan for provider failure.
15.1 Dependencies
Fenwick depends on providers: the online shop platform, the payment gateway, the cloud email service and a support company for branch networks. Amina lists what each provides, what data it handles and what happens if it fails. The shop platform and payment gateway are critical; if either fails, online sales stop. She learns that dependencies on providers are part of Fenwick's risk, even though Fenwick does not run those systems. Ms. Bell asks what happens if the cloud email service fails, and Amina notes that orders and supplier messages would stop although sales would continue.
15.2 Provider assurance
Amina checks what assurance each provider offers. The payment gateway publishes its PCI DSS compliance status. The shop platform provides a SOC 2 report under non-disclosure. The support company has no formal assurance. She records these and recommends that the support company's contract include security requirements, such as removing temporary rules after work. She learns that assurance varies widely and that contracts can fill gaps where formal reports do not exist. For the support company, a contract clause requiring removal of temporary rules would have prevented the remote desktop exposure she found earlier.
15.3 Planning for failure
For critical providers, Amina helps plan responses to failure. If the shop platform fails, Fenwick will post a notice and take phone orders. If the payment gateway fails, branches can still take cards through terminals with a separate connection. She learns that dependency planning makes outages less damaging and that simple manual fallbacks can keep a business running while providers recover. Each fallback should also be tested, since terminals with a separate connection only help if that connection actually works.
Worked example
Amina lists four provider dependencies, records their assurance and plans fallbacks for the shop and payment gateway.
Synthetic case. Providers and plans are synthetic; PCI DSS and SOC 2 are real.
Errors and limits
Assurance reports have limited scope. Fallbacks need practice.
Exercises
- EX057 — Critical providers. Which providers are critical for online sales? Rubric: 3 = shop platform and payment gateway;; 2 = two;; 1 = email;; 0 = none.
- EX058 — Missing assurance. Which provider had no formal assurance? Rubric: 3 = the network support company;; 2 = support company;; 1 = vague;; 0 = none.
- EX059 — Contract gap fill. How can contracts help where formal reports are missing? Rubric: 3 = include security requirements such as removing temporary rules;; 2 = contracts;; 1 = vague;; 0 = none.
- EX060 — Shop fallback. What is the fallback if the shop platform fails? Rubric: 3 = post a notice and take phone orders;; 2 = manual;; 1 = vague;; 0 = none.
Synthesis
Provider dependencies need assurance checks, contract terms and practical fallbacks.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →