3.5.A Managing a Compliance Programme ~50 min Module 3 · Compliance

Managing a compliance programme¶

What you'll be able to do in this chapter

Define the scope of a compliance programme and do a gap analysis against the chosen baseline.
Distinguish reference controls from applied controls, and write an applied control that is scoped, owned and testable.
Explain what counts as evidence that a control operates.
Build a risk-prioritised roadmap.

From choosing to operating¶

Scaldimet has chosen its baseline (Chapter 3.1) and understands the frameworks (Chapters 3.2 to 3.4). None of that has yet protected a single system. A compliance programme is the work that turns a chosen framework into operating controls (its applied controls, defined next) and the evidence that they operate. It has four moving parts: scope, gap analysis, evidence and a roadmap.

Reference controls and applied controls¶

A framework gives you reference controls: generic requirements, such as CyFun's ID.AM-08.2 (keeping software updated and patched across its life cycle) or an ISO Annex A access-control clause. A reference control is not yet a real control; it is an instruction to have one. A compliance programme turns each reference control into one or more applied controls: the same requirement implemented for a specific scope, with enough detail that someone could operate it and someone else could test it. A single reference control usually produces several applied controls, one per scope it must cover.

An applied control is only useful if it specifies six things. A line that says "we patch our systems" is not an applied control; it is a hope. A real one states:

Reference control — which framework requirement it implements, so the link back to the socle is explicit (here, CyFun ID.AM-08.2).
Scope — the exact perimeter it applies to: which sites, systems or asset group. Vague scope is the most common failure; "the servers" is not a scope, "the internet-facing servers at Site Alpha" is.
Implementation — how the control is actually realised: the concrete mechanism, tool or procedure, not the intention. This is what turns a requirement into an operating control.
Frequency — for anything recurring, the cadence and any time limits (scan monthly, patch criticals within N days). A control with no cadence cannot be said to operate.
Owner — the single accountable role (Lesson 2.4), not a team and not a named individual on a standing list.
Evidence and test — what proves it operates and how its effectiveness is verified (Lesson 3.6.A: design versus operating, by inspection or re-performance), and how often that test runs.

Get these right and the applied control becomes auditable, testable and defensible; leave any of them vague and the control may be difficult to operate, test or audit.

One reference control, one well-written applied control

Reference control: CyFun ID.AM-08.2 (under ID.AM-08 — systems, hardware and software are managed throughout their life cycle), the requirement to keep software updated, patched and supported.

Applied control — Patching of internet-facing servers at Site Alpha - Implements: ID.AM-08.2.

Scope: all internet-facing servers at Site Alpha (web, VPN gateway, mail relay). Excludes Beta's OT, which is a separate case (below).
Implementation: patches taken only from vendor repositories; critical and high vulnerabilities (CVSS ≥ 7) remediated within 14 days, the rest in the next monthly cycle; every change deployed through the standard change process with a tested rollback; end-of-life software flagged for decommissioning.
Frequency: monthly patch cycle; critical-patch limit 14 days; scope reviewed quarterly.
Owner: the Alpha IT manager.
Evidence: a monthly authenticated vulnerability scan report, the change tickets showing deployment dates, and a log of any host missed within its limit.
Test: twice a year, internal audit re-runs one month's scan against the change records to confirm the reported patches were truly applied and the limit met (inspection plus re-performance, Lesson 3.6.A).
Status: in place (VPN gateway partial, closing next cycle).

The same reference control, ID.AM-08.2, produces a different applied control for Beta's OT: the unsupported SCADA cannot be patched and is past its supported life, so its applied control is not "patch monthly" but a recorded exception (Lesson 2.3) with compensating controls, segmentation, monitored access, a shorter review cycle, plus a decommissioning-or-replacement plan. One reference control, two applied controls, because scope changes what "implemented" means.

A note on terminology

This reference-to-applied distinction is standard, even if the words vary. NIST and OSCAL call the applied side a control implementation (done by component for each scope). This course uses applied control, which is also the term the CISO Assistant tool uses; treat the two as synonyms when you meet "control implementation" elsewhere.

Scope: draw the boundary first¶

A programme without a defined scope can expand beyond what the organisation can manage effectively. Scope says what the baseline applies to: which sites, which systems, which data. The temptation, familiar from the mandate in Lesson 2.1, is to exclude the hard parts from scope (Beta's OT) and certify the easy ones. Resist it for the same reason: a baseline that excludes the riskiest systems is a baseline that does not reduce the risk that matters, and a certificate scoped to exclude what the customer cares about is close to worthless. Scaldimet's scope is both sites, IT and OT, including the customer design data and the production systems.

Gap analysis: current versus target¶

Gap analysis is the central part of the programme. You take the target (CyFun Important, mapped to ISO 27001 and NIS2) and, for each reference control and each scope it must cover, ask whether an applied control is in place, partial, or absent. The output is a list of gaps. Crucially, you do not then address the gaps in list order or easiest-first. You prioritise by risk: a gap that leaves Beta's OT reachable by an unmonitored contractor outranks a gap in, say, a documentation formality, even though the formality is quicker to close. The framework defines the control set; risk determines the order in which the gaps should be addressed.

Evidence: the difference between claiming and proving¶

A control is not "done" because someone says so or because a policy mentions it. It is done when there is evidence that it operates: an access-review record with dates and names, a test-restore log proving a backup works, a configuration showing the OT network is segmented. Evidence is what a Stage 2 auditor (Lesson 3.3.B), a regulator, or your own internal audit (Lesson 3.6) will ask for. Controls without evidence leave the organisation unable to demonstrate that they operate. Build evidence collection into the control from the start, rather than having to reconstruct it the week before an audit.

Roadmap: a risk-ordered plan with owners and dates¶

The roadmap turns the prioritised gaps into a sequenced plan: what gets closed, by whom (the owners from Module 2), by when, and against which deadline (the OEM contract, the CCB's expectations). It is a living document reviewed by the security committee (Lesson 2.4). A good roadmap is realistic about pace: it does not promise everything at once, it addresses the highest-risk gaps first, and it uses the exception process (Lesson 2.3) for the gaps that cannot be closed quickly, such as Beta's unsupported SCADA.

Application: a mini gap analysis and roadmap¶

Here are five real gaps at Scaldimet: no asset inventory; Beta's flat, unsegmented OT network; the contractor's unmonitored remote access; backups that have never been test-restored; and Beta's unsupported SCADA controllers. On paper:

For each gap, note its current state (absent, partial, in place), the one risk it leaves open, and what evidence would prove the control operates once it is closed.
Put the five in the order you would close them on a risk-ordered roadmap, and write one sentence defending your top choice.
Identify the one gap that cannot simply be closed, and say how the programme handles it rather than leaving it open.
For your top-priority gap, write the applied control that would close it, using the six attributes (reference control, scope, implementation, frequency, owner, evidence and test).

Model answer (open after you've drafted yours)

1. State, risk left open, and evidence once closed:

No asset inventory — partial (Alpha is known, Beta patchy). Risk: you cannot protect or patch what you do not know exists. Evidence once closed: a maintained inventory, dated and reconciled against the network.
Beta's flat, unsegmented OT network — absent. Risk: an intrusion in IT (or via the contractor) reaches the production line unobstructed. Evidence: the firewall and VLAN configuration, plus a connectivity test showing OT is unreachable from IT and the internet.
Contractor's unmonitored remote access — absent. Risk: a trusted third party can act on Beta's OT with no record. Evidence: per-session logs tied to a named individual, and a dated log-review record.
Backups never test-restored — partial (backups run, restores unproven). Risk: a ransomware hit becomes a closed business rather than a bad day. Evidence: a dated, successful test-restore report.
Beta's unsupported SCADA — absent / cannot be closed normally. Risk: unpatchable, exploitable controllers running the line. Evidence: a signed, time-bound exception with its compensating controls and review dates.

2. Risk-ordered roadmap, top choice defended: Beta's unsegmented OT and the contractor's unmonitored access come first, because together they let an outsider reach the production line unobserved, ahead of the asset inventory even though the inventory is quicker and more satisfying to tick off. Untested backups rank next, since they decide whether a ransomware hit is survivable. The asset inventory is real work but lower on risk. The rule the ordering shows: the framework defines the gaps to examine; risk determines their priority.

3. The gap that cannot simply be closed: Beta's unsupported SCADA. It cannot be patched, so it does not go on the roadmap as "patch it"; it goes through the exception process of Lesson 2.3 — a time-bound exception with compensating controls (segmentation, monitored access), an owner and a review cycle, plus a decommissioning-or-replacement plan. It is treated openly, not silently dropped.

4. A written applied control for the top-priority gap (segmenting Beta's OT):

Implements: CyFun PR.IR-01 (network integrity: segregation and segmentation).
Scope: Beta's production (OT) network — the SCADA and PLC segment.
Implementation: zones and conduits (Lesson 3.2.B); OT placed in its own zone with a single, monitored conduit to IT and no path from the internet; default-deny between zones.
Frequency: configuration reviewed quarterly and after any network change.
Owner: the Beta operations director.
Evidence and test: the firewall and VLAN configuration, plus a semi-annual connectivity test, re-performed by internal audit, confirming OT is unreachable from IT and the internet (Lesson 3.6.A).
Status: planned (highest priority on the roadmap).

Notice how the same discipline that ordered the gaps now produces a control that is scoped, owned and testable, not a line that merely says "segment the network".

Key takeaway

A compliance programme operates the socle through four parts: scope (drawn to include the risky systems, not just the easy ones), gap analysis (current versus target, the EBIOS Workshop 1 compliance approach), evidence (proof a control operates, not a claim that it does), and a roadmap (gaps sequenced by risk, with owners and dates). The binding rule governs throughout: the framework says what to check, risk says what to do first.

Next: Chapter 3.6 · Control design, testing and audit →