Controls, frameworks and where findings hang

Why this matters

Objective 2.4 asks about control types, risks and compliance — the vocabulary that connects a technical finding to the governance structure that funds and judges the security programme.

It is the least technical material in Domain 2 and it is reliably examined, because the categories are precise and easy to write unambiguous questions about. It also matters in practice: an analyst who can say which control failed, and which framework requirement it maps to, gets findings acted on far faster than one who can only describe the flaw.

The lesson

Preventive, detective, corrective and compensating

Controls are classified by function — what they do relative to an incident in time.

• Preventive controls stop the event occurring. Firewall rules, access control, input validation, MFA, patching, encryption of data at rest.
• Detective controls identify that it occurred or is occurring. Logging, SIEM rules, IDS, file integrity monitoring, audits, the whole of Domain 1.
• Corrective controls restore after the event. Backups and restoration, patching in response, removing malware, rebuilding a host, failover.
• Deterrent controls discourage an attempt. Warning banners, visible cameras, published sanctions. Weak against determined attackers, meaningful against opportunistic insiders.
• Compensating controls provide comparable protection when the primary control cannot be used — the honest option from lesson 23, legitimate when it genuinely breaks the attack path and is verified.
• Directive controls instruct behaviour: policies, standards, procedures, training.

Two distinctions the exam probes:

A control can be more than one, depending on deployment. An IPS in detect-only mode is detective; inline and blocking, it is preventive. The function is about what it does, not what it is called.

Compensating is not a synonym for "we did something else". It has to be comparable in effect. A compensating control is a reasoned substitution, not a consolation prize, and the test from lesson 23 applies — does it break this specific attack path, and has anyone verified that.

Technical, administrative and physical

Controls are also classified by type — the mechanism, independent of function. The two classifications are orthogonal, and combining them is the exam's favourite move: give an example of a detective administrative control (a log review procedure, or an audit).

• Technical (sometimes logical) — implemented in hardware or software. Access control lists, encryption, antivirus, authentication systems.
• Administrative (managerial and operational) — implemented through people and process. Policies, standards, risk assessments, background checks, security awareness training, change management, separation of duties.
• Physical — implemented in the physical world. Locks, fences, guards, badge readers, cameras, environmental protections.

Worked combinations to have ready:

The point of the taxonomy is not the naming. It is that a gap in one type is rarely fixed by adding more of another. An organisation with excellent technical controls and no process for reviewing access accumulates privilege until someone leaves with it, and no additional firewall changes that.

Mapping findings to a framework

Frameworks give a structured set of expected controls. The ones to recognise:

• NIST Cybersecurity Framework — organised around functions (Identify, Protect, Detect, Respond, Recover, and Govern in version 2.0). Widely used for describing a programme's shape to executives.
• NIST SP 800-53 — a detailed control catalogue, heavily used in US government contexts.
• ISO/IEC 27001 and 27002 — an information security management system and its control set; certifiable, common in commercial procurement.
• CIS Critical Security Controls — prioritised, practical, with implementation groups sized to organisation maturity. The most immediately actionable for a small team.
• PCI DSS — mandatory where card data is handled, prescriptive, with specific scanning and remediation timeframes.
• MITRE ATT&CK — not a control framework but a behaviour catalogue; covered in lesson 27.

Why mapping a finding to a framework helps an analyst in practice:

• It changes the conversation from opinion to obligation. "This is bad" is arguable. "This is a gap against a control we are certified to" is not.
• It aggregates. Forty findings mapping to one control is a control failure, not forty tickets — the root-cause grouping from lesson 20 again, expressed in governance language.
• It finds systemic gaps. Mapping your detections against ATT&CK shows the techniques you cannot see at all, which is the coverage analysis from lesson 14.
• It reuses evidence. Work done for one framework usually satisfies parts of another, since the controls substantially overlap.

Regulatory drivers an analyst actually meets

You are not expected to be a lawyer. You are expected to know which regimes change what you do.

• GDPR and equivalent privacy law — personal data protection, with breach notification to a supervisory authority typically within 72 hours of becoming aware, and to affected individuals where risk is high. The 72-hour clock is the detail that reaches the analyst, because it starts on awareness, which is a determination someone has to make from your evidence.
• PCI DSS — card data. Prescriptive requirements including regular vulnerability scanning, quarterly external scans by an approved vendor, and remediation of high findings.
• HIPAA — US health information, with breach notification obligations.
• SOX — financial reporting integrity, driving access control and change management evidence.
• Sector rules — financial services regulators, critical infrastructure directives such as NIS2 in the EU, and national reporting schemes, several of which now impose notification windows measured in hours.

What an analyst should take from this:

• Notification clocks start early, often on awareness rather than confirmation, which makes your timeline and your evidence legally significant.
• Data location and classification matter to which rules apply.
• The determination is not yours. Legal and privacy decide whether an incident is notifiable; you supply the facts that let them decide, accurately and quickly. Lesson 1's boundary, in its highest-stakes form.

Evidence a control is operating, not just present

The distinction that separates real assurance from paperwork, and a genuinely good exam theme.

A control that exists appears in a policy or a console. A control that is operating effectively demonstrably does its job, now, on the current estate.

Examples of the gap:

• MFA is enabled — and 340 accounts are excluded, including four administrators.
• Logging is configured — and the log source stopped reporting six weeks ago with nobody watching, per lesson 5.
• Backups run nightly — and nobody has restored one this year, so nobody knows whether they work.
• A vulnerability SLA exists — and the median critical is open 94 days.
• EDR is deployed — and coverage is 71% against an inventory nobody reconciles.
• A WAF protects the application — and it is in monitoring mode.

What operating evidence looks like: coverage percentages against an independent denominator, test results with dates, sampled records, exception lists with owners and expiry, and metrics with trends rather than point-in-time claims.

This is the same idea the entire course has circled, now in governance vocabulary. A detection nobody has watched fire is a hypothesis. A scan that failed to authenticate is not a clean result. A control nobody has tested is a claim. In each case the artefact looks identical whether it works or not, and only a deliberate test tells them apart — which is precisely why the evidence, not the existence, is what you report.

Topics this lesson owns

• [x] Preventive, detective, corrective and compensating
• [x] Technical, administrative and physical
• [x] Mapping findings to a framework
• [x] Regulatory drivers an analyst actually meets
• [x] Evidence a control is operating, not just present