Governance, Risk & Compliance for IT/OT

Every faculty member who has toured a plant notices the same organizational oddity: the security team that manages the corporate network answers to the CIO, and the team that manages the control system down the hall answers to a plant manager or VP of Operations — and the two rarely share a budget line, a ticketing system, or a boss short of the CEO. That split is not a mistake. IT and OT optimize for different things — IT typically ranks confidentiality first, OT typically ranks safety and availability first — and a reporting structure that reflects that difference is doing its job. The problem shows up the moment a single risk, like an unpatched substation firewall, needs a decision that both towers have to sign off on, and neither one is quite sure whose ticket it is.

This lesson is about the paperwork that makes that decision possible anyway: the risk register that both towers can read, the POA&M that tracks a finding until it is actually fixed, the audit evidence that proves the fix happened, and — because none of this pays for itself — the regulation, NERC CIP, that turns "should fix" into "must fix by this date or the organization is fined." By the end, you will have drafted a short charter that assigns ownership of each of these artifacts across an IT/OT boundary.

Learning objectives

By the end of this 4-hour session, you will be able to:

1. Explain why IT and OT security functions in the same organization often report through different executives, and how that split affects decision rights over a shared risk.
2. Identify the required fields of a risk register entry and construct one from a described asset and threat scenario.
3. Differentiate a risk register from a POA&M and describe how a finding moves from one artifact to the other.
4. Compare audit evidence expectations under a voluntary framework against a mandatory regulation such as NERC CIP.
5. Evaluate a completed risk register and POA&M for completeness and defensibility, given the enforcement stakes NERC CIP attaches to certain findings.
6. Design a one-page cross-organizational governance charter that assigns ownership of GRC deliverables between IT and OT stakeholders.

Governance is the set of decisions, policies, and assigned responsibilities that determine how an organization manages risk — who is allowed to accept a risk, who must approve an exception, and who is accountable when something goes wrong. In a plant or a utility, governance almost always splits along the same line: a CIO or CISO governs the business network, the ERP, email, and endpoint security, while a VP of Operations, plant manager, or director of engineering governs the control system — the PLCs, RTUs, protective relays, and the network that connects them. Each side has its own policies, its own change-control board, and its own tolerance for downtime, and neither reports to the other short of the CEO.

This is not dysfunction to be corrected. IT security policy is usually built around confidentiality first, because a leaked customer database is the worst plausible day. OT security policy is built around safety and availability first, because an unplanned trip on a transmission line or a stopped production line is the worst plausible day — and a control that protects confidentiality by locking an operator out of a screen during an emergency can itself cause harm. A single organization-wide policy that pretends these priorities are the same produces a document nobody on either side actually follows.

Worked example — Ironwood Precision Manufacturing

Ironwood Precision Manufacturing (fictional) machines aerospace fasteners and holds a subcontract that requires it to protect federal contract information under CMMC. Its CIO owns the corporate domain, email security, and the ERP system that schedules orders. Its Director of Manufacturing Engineering owns the CNC line controllers, the plant floor network, and a small SCADA system that tracks tool wear. When an auditor flags an unpatched Windows box, the first governance question is not "how do we fix it" — it is "whose box is this, and who has authority to schedule the downtime to fix it?" That question has to be answered before the technical fix, or the finding sits open for months while two departments wait on each other.

A risk register is a living inventory of identified risks, each scored for likelihood and impact, assigned an owner, and tracked to a treatment decision. It is not a list of vulnerabilities — a scanner produces those automatically. A risk register turns a vulnerability into a business decision by attaching consequence, ownership, and a plan. The starting input to any risk register is an asset inventory: you cannot score the risk to a device you have not written down.

A defensible risk register entry needs, at minimum: an asset, the threat and vulnerability being assessed, likelihood, impact, the resulting risk score, an assigned owner (a named role, not a department), a treatment decision (accept, mitigate, transfer, or avoid), and a status. Miss the owner field and the entry becomes exactly the kind of finding that sits open for a year because nobody's name is attached to it.

Worked example — Cascade Summit Electric, Substation 12

Cascade Summit Electric (fictional) operates a transmission substation. Its OT engineering lead and its IT security analyst jointly maintain one risk register for the site. A short excerpt:

Notice that the owner column mixes titles from both towers on the same page. That is the entire point of a shared register: it is the one document where "whose risk is this" gets answered in writing, with a name, instead of argued about in a hallway.

A POA&M (Plan of Action & Milestones) is a tracked remediation plan for a specific finding: what will be done, who will do it, what resources it needs, the target completion date, and the current status. Where a risk register entry says this risk exists and here is how bad it is, a POA&M says here is exactly how and when it stops being true. Not every risk register entry needs a POA&M — an accepted risk, like HIST-CORP above, does not — but every risk marked "mitigate" should generate one.

Four artifacts, one lifecycle

Students often blur these four documents together. Each one answers a different question, and each hands off to the next:

Each card is a button: press Enter or Space to flip it. All four definitions also print in full.

Worked example — turning the RTU-22 entry into a POA&M

The risk register entry for RTU-22 above ("mitigate — add DNP3 Secure Authentication gateway; Q3") becomes a tracked POA&M with its own milestones:

An audit is an independent examination of whether an organization's stated controls actually operated as claimed, over a specific period, with evidence to prove it. Students moving from IT into OT (or the reverse) are often surprised that auditors do not primarily read policy documents — they sample a handful of specific control instances and ask for dated proof. "Show me your patch management policy" is a five-minute conversation. "Show me the evidence that this specific patch decision for this specific asset in March was made and documented the way your policy says it should be" is the actual audit.

Good audit evidence shares four traits: it is dated (a screenshot with no timestamp proves nothing), it is attributable to a specific person or system, it is retained for the required period, and it matches the claim being made — a ticket showing a patch was scheduled is not evidence that it was applied.

Worked example — the evidence that satisfies, and the evidence that doesn't

Every framework discussed elsewhere in this course — IEC 62443, NIST SP 800-82, NIST CSF, ISO/IEC 27001 — is voluntary. An organization adopts one because it decides to, and nobody outside the organization enforces it with a fine. NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection standards) is different: it is a mandatory, enforceable set of reliability standards, developed by NERC and approved by the Federal Energy Regulatory Commission (FERC), that applies to owners and operators of the Bulk Electric System (BES). Non-compliance carries real financial penalties — historically up to roughly $1 million per violation per day — assessed after a Regional Entity audit. That single fact is why a utility's OT security budget exists at a scale a similarly sized manufacturer's rarely does: the utility has a treaty with teeth.

• CIP-002 — Identify and categorize BES Cyber Systems by impact (high, medium, low). This is the gate: everything else in the CIP standards only applies to systems this step identifies.
• CIP-004 — Personnel & training: background checks, cybersecurity training, and access revocation records for anyone with authorized access.
• CIP-005 — Electronic Security Perimeter(s): every external routable connection into a BES Cyber System must cross a defined, monitored perimeter.
• CIP-007 — System security management: patch evaluation on a fixed cadence, port/service management, malicious code prevention, and security event logging.
• CIP-010 — Configuration change management and periodic vulnerability assessments, with a documented baseline for every in-scope system.
• CIP-013 — Supply chain risk management: vendor security requirements written into procurement, including vulnerability disclosure obligations.

Ironwood Precision Manufacturing, from the worked example in section 1, faces a parallel but distinct obligation: as a subcontractor handling federal contract information, it is subject to CMMC (Cybersecurity Maturity Model Certification) requirements now codified at 32 CFR Part 170. CMMC is not NERC CIP — it applies to a different sector, is assessed differently, and does not carry a per-day fine in the same way — but it plays the same governance role: it is the enforceable floor that turns "we should probably do this" into "we must do this to keep the contract." Manufacturers without a defense contract, by contrast, usually have no equivalent forcing function, which is exactly why their OT security programs often stay smaller regardless of actual risk.

Where they genuinely overlap

Both towers need an asset inventory, a way to score risk, a way to track remediation to closure, and evidence they can hand an auditor. The fields on a risk register and a POA&M are identical whether the asset is a laptop or a relay. What differs is who fills in the owner column, how fast the target date can realistically be, and whether a regulator is reading over anyone's shoulder.

⚠ Simulation only — no live equipment, no network traffic, no real plant data.

This builder models six assets at the fictional Cascade Summit Electric, Substation 12. For each asset, choose a likelihood and an impact rating, then choose Evaluate my register. The tool computes a risk score, sorts the register by priority, and flags findings a real reviewer would raise — including which items NERC CIP's timelines would treat as urgent. There is more than one defensible scoring, and the findings are prompts for discussion, not a grade.

A governance charter is the short document that answers, in writing, the question this whole lesson keeps circling back to: when a risk crosses the IT/OT boundary, who decides what? Without one, every cross-boundary finding gets negotiated from scratch.

Standards and framework pages

Downloadable documents

• 📄 Download: NIST SP 800-82 Rev. 3 — background on OT control tailoring referenced when discussing why OT risk scoring differs from IT defaults.
• 📄 Download: CIP Reliability Audits Lesson Learned — real (anonymized) findings from past CIP audits; a useful case-study companion to Section 4.
• 📄 Download: CMMC CFR Part 170 — the codified CMMC rule referenced in Section 5 as the manufacturing-sector parallel to NERC CIP.