Where cyber-GRC ends and operational governance begins¶
The boundary between oversight and operations¶
A genuine dispute lands on your desk in week three. Site Alpha's modern line is fitted with industrial sensors (IIoT) that stream data to the cloud ERP. Site Beta runs fifteen-year-old SCADA controlling the presses. Two questions arrive together: who governs the security of the IIoT sensors, and who governs the SCADA?
Your instinct, fresh from the mandate in the last Lesson, is "I do, it is all in scope." But you cannot stand on the Beta factory floor deciding when a press controller is safe to take offline, and you do not have the process engineering to judge what a sensor firmware change does to the line. Yet if the answer is "the operations team handles it" with no involvement from you, you recreate the governance gap at Beta: systems that answer to no security function at all. Neither extreme is right. This is the boundary problem, and it is not black-or-white. The job is to draw the line deliberately rather than leave it to drift.
The three-lines model is the tool that draws the line¶
This is exactly what the three-lines model from Lesson 2.2.A is for. It does not ask "is this the CISO's job, yes or no?" It splits the job into three kinds of work and assigns each to a different line.
- First line (operational governance): own and operate the risk. The system owner decides how to run the system safely and does the work: the Alpha IT manager for the IIoT, the Beta operations director for the SCADA. They make the operational calls (when to patch, when a press can be taken offline) and they live with the consequences.
- Second line (cyber-GRC): set the bar and check it. You define what good looks like (the policy and standards the system must meet), monitor whether it is met, challenge when it is not, and report. You do not operate the system.
- Third line (audit): assure independently. Someone independent checks that the first two lines are actually doing their parts.
So the boundary is not a wall between "your systems" and "their systems". It runs through every system: cyber-GRC owns the standard and the oversight; the operational owner owns the decision and the doing. For the Beta SCADA, you set the standard ("remote access individually authenticated, logged and reviewed; no unsupported system exposed to the internet without a recorded risk acceptance") and check it is followed. The Beta operations director decides how to meet it on real equipment, and owns the residual risk. Neither of you is doing the other's job, and nothing is unowned.
Technical explainer (read & discuss, don't build): why the owner has to make the operational call
A cyber-GRC standard might say "critical systems must be patched within 30 days." On Beta's SCADA that can be impossible: the software is unsupported, and a patch (or the reboot it needs) could stop a press mid-cycle and damage tooling or product. Only the operational owner, who understands the process, can judge what is safe and when. The second-line job is not to overrule that judgement from a spreadsheet; it is to require that the gap is handled (compensating controls, a recorded, time-bound risk acceptance, a plan) rather than ignored. You set the requirement and hold the owner to handling it; the owner decides the safe technical path. That division is the boundary in action.
The cost of leaving the line undefined¶
Leaving the boundary vague fails in one of two predictable directions, and Scaldimet contains a live example of each.
Overreach (the CISO tries to be the first line). If you treat "all in scope" as "all mine to operate", you become the bottleneck for decisions you are not equipped to make, you do not scale beyond your own hours, and operational owners stop taking responsibility for those activities: "leave it, the CISO will sort the OT." The work then collapses the moment you are busy or absent, because nothing was ever truly theirs.
Abdication (no one takes the first line). This is Site Beta today. The standard is unwritten, the operations team has never been asked to own security, and you are not involved, so the SCADA and the contractor's access answer to no one. The cost is the gap you inherited: unsupported, unsegmented systems with unmonitored third-party access and no named owner of the risk.
The two Scaldimet systems show the boundary drawn well in two different starting positions. Alpha's IIoT is the easy case: a capable IT manager already exists to be the first line, so your work is mostly to set the standard (segment the IIoT, monitor it, control the cloud link) and check it. Beta's SCADA is the hard case: a competent first line barely exists, so part of your second-line job is to get one built, by securing a named operational owner (Lesson 2.2.A) and the resourcing for them, then setting the standard and overseeing it. In both, you stay in the second line. What changes is how much first-line capacity you have to help create.
The boundary, written down for Scaldimet
| System | First line (owns & operates) | Second line (cyber-GRC sets & checks) | Third line |
|---|---|---|---|
| Alpha IIoT | Alpha IT manager: runs and patches the sensors, manages the cloud link | You: standard for segmentation, monitoring and the cloud connection; oversight | Audit assures both |
| Beta SCADA | Beta operations director: decides safe maintenance, runs the line | You: standard for access, exposure and risk acceptance; oversight; help build first-line capacity | Audit assures both |
Writing this table is the act of drawing the boundary. The dispute that landed on your desk dissolves once each cell has a name.
Application: draw the boundary¶
For each of Alpha's IIoT and Beta's SCADA, write one decision that belongs to the first line and one that belongs to the second line, then name who holds each. Do it before reading the model.
Model answer (open after you've drafted yours)
Alpha IIoT, first line: the IT manager decides which firmware version to run and when to apply it. Second line: you set the requirement that IIoT traffic is segmented from the office network and the cloud link is monitored, and you check it. Beta SCADA, first line: the operations director decides whether and when a controller can be safely taken offline for maintenance. Second line: you set the requirement that no unsupported system is internet-exposed without a recorded, time-bound risk acceptance, and you review those acceptances. In every case, the second line owns the standard and the scrutiny; the first line owns the operational decision and its consequences.
Key takeaway
The boundary between cyber-GRC and operational governance is not a wall between separate systems; it runs through every system, and the three-lines model is the tool that draws it: the second line (you) owns the standard and the oversight, the first-line owner owns the operational decision and the doing, and audit assures both. Leaving the line undefined fails two ways: overreach (you become a bottleneck and owners stop owning) or abdication (no one owns it, which is Beta today). Alpha's IIoT and Beta's SCADA differ only in how much first-line capacity already exists; in both you stay in the second line. The table makes the responsibilities explicit.