OpenCyber Academy
Engineering · Chapter 34 · English
Course code: OCA-120Chapter 34: OCA-120-C034

Chapter 34 — Security governance, risk and compliance: integration

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 34 published. Map, example, EX100.

flowchart TD
  N0["Learning outcomes"]
  N1["34.1 Enterprise risk"]
  N2["34.2 Common language"]
  N3["34.3 Aligned processes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX100"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["34.1 Enterprise risk"]
  N2["34.2 Common language"]
  N3["34.3 Aligned processes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX100"]

[Learning outcomes]
    |
    v
[34.1 Enterprise risk]
    |
    v
[34.2 Common language]
    |
    v
[34.3 Aligned processes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX100]

Learning outcomes

You will (1) integrate GRC with enterprise risk management; (2) connect security risk to financial and operational reporting; (3) align processes across departments.

34.1 Enterprise risk

Ardwell already has an enterprise risk register covering financial, operational, regulatory and safety risks. Security risks lived in a separate register, so the board saw them in isolation. Nadia helps integrate them, mapping security risks to enterprise categories and using common scales for likelihood and impact. ISO 31000:2018 promotes integrating risk management into all organisational activities, and COBIT 2019 links IT goals to enterprise goals. Integration lets the board compare cyber risk with other risks on equal terms. Once both use the same scales, a ransomware scenario can be ranked against a financial or safety risk on the board's single register.

34.2 Common language

Integration requires a shared language. Security teams spoke of vulnerabilities and threats; finance spoke of losses and provisions. Nadia drafts a glossary and translation table. A ransomware scenario becomes an operational disruption risk with a financial impact range and a regulatory reporting obligation. She learns that translation is not simplification but connection: each audience keeps its precision while seeing how the risk relates to things it already manages, such as insurance cover and reserves. The ransomware translation, for example, gives finance a loss range it can compare with insurance cover.

34.3 Aligned processes

Nadia aligns calendars so security risk reviews feed the quarterly enterprise risk report, internal audit plans consider security findings and procurement checks supplier security before contracts. Each department keeps its own process, but handoffs are defined. She learns that integration fails when it means one team taking over another's work, and succeeds when interfaces are clear. Prof. Brenner notes that this is an application of systems engineering's emphasis on interfaces, which she studied earlier. Procurement checking supplier security before contracts is one such defined handoff, owned by procurement but informed by security.

Worked example

Nadia maps security risks into enterprise categories, builds a translation glossary and aligns review calendars across departments.

Synthetic case. Registers and processes are synthetic; ISO 31000:2018 and COBIT 2019 are real.

Errors and limits

Common scales can blur distinctions. Integration takes political effort.

Exercises

Synthesis

Integrating GRC with enterprise risk needs common scales, translation and clear handoffs.

Continue studying — chapter 34 of 50

← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →

Worked answers

EX100. Compare cyber risk with other enterprise risks on equal terms.

EX101. As an operational disruption risk with a financial impact range and a regulatory reporting obligation.

EX102. When it means one team taking over another's work instead of defining interfaces.