Chapter 21 — Security governance, risk and compliance: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Integration"]
N2["21.2 Changes and incidents"]
N3["21.3 Tickets as evidence"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Integration"]
N2["21.2 Changes and incidents"]
N3["21.3 Tickets as evidence"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Integration]
|
v
[21.2 Changes and incidents]
|
v
[21.3 Tickets as evidence]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) integrate GRC with IT service management; (2) link changes and incidents to risk; (3) use tickets as evidence.
21.1 Integration
Riverton's IT team uses a ticketing system for requests, incidents and changes. Priya proposes integrating governance tasks into it: control tests become scheduled tickets, risk treatments become tracked work items and exceptions become tickets with expiry dates. She learns that integrating with existing service management reduces duplicate effort and ensures governance work is visible to the people who do it, rather than living in a separate spreadsheet. Exception tickets with expiry dates, for example, make the deviation register from chapter 8 something the IT team sees daily.
21.2 Changes and incidents
Priya links changes and incidents to risks. A change that alters clinic networks must reference the network segmentation risk and be checked against the standard design. An incident involving a misdirected email updates the likelihood of that risk. She learns that this linkage turns daily IT activity into evidence about risk and control effectiveness, helping governance stay current between formal reviews. Linking the misdirected email incident to its risk, for instance, gives the next register review real evidence about likelihood.
21.3 Tickets as evidence
Auditors can sample tickets to verify controls. A scheduled backup test ticket includes the date, steps, result and attached test record. Priya defines required fields so tickets contain enough information to serve as evidence. She learns that evidence built into normal work is more reliable and less burdensome than evidence assembled shortly before an audit, which often reveals gaps that cannot be fixed retrospectively. Required fields such as the attached test record make a ticket usable by an auditor without asking the IT lead to explain it.
Worked example
Priya integrates control tests, treatments and exceptions into the ticketing system and defines evidence fields.
Synthetic case. The ticketing setup is synthetic.
Errors and limits
Ticket fields get skipped. Linkages need discipline.
Exercises
- EX061 — Exceptions as tickets. How are exceptions handled in the ticketing system? Rubric: 3 = as tickets with expiry dates;; 2 = expiry;; 1 = vague;; 0 = none.
- EX062 — Incident linkage. How does a misdirected email incident affect the register? Rubric: 3 = it updates the likelihood of that risk;; 2 = update;; 1 = vague;; 0 = none.
- EX063 — Evidence timing. Why is evidence built into normal work better? Rubric: 3 = more reliable and less burdensome than pre-audit assembly;; 2 = built-in;; 1 = vague;; 0 = none.
Synthesis
Integrating GRC with service management makes daily work produce governance evidence.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →