Untangle a risk register row

Objectives

A risk register arrives with the row: risk = "we are not SOC 2 compliant", control = "train staff on security", rating = "high because the auditor said so".

None of those three fields contains what its column is for. Rewrite the row so the risk is an event with a consequence, the control is the enforcement that already exists, and the compliance reference points at a requirement rather than a framework name.

Concern raised: contractors sometimes reach the production console
with a password alone; one did so last quarter from an unmanaged laptop.

Mitigation already live: the SSO tier refuses any console login that
has not completed an MFA challenge. It blocks the attempt itself.

Rating scale in use: low | medium | high | critical
Framework identifiers seen in this programme: CC6.6, A.5.17, IA-2
Control types: preventive | detective | corrective

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

1. Step 1

   Re-read the brief and name the trap

   Three vocabularies are collapsed into one row: risk (what might happen), control (what we do about it), compliance (who requires it). Each field belongs to exactly one of them.

   The starter is what that collapse looks like in a real register.

2. Step 2

   Rewrite the risk as cause and consequence

   A usable risk statement names an event that could occur and what follows if it does. Test yours by asking whether it could still be true in a company that has never heard of SOC 2.

   Use a connective that makes the consequence explicit rather than implying it.

   Risk is an event with a consequence

3. Step 3

   Rate on the scale, not on authority

   "Because the auditor said so" is provenance, not a rating. The fixture gives you the four permitted values; both likelihood and impact must be one of them, on their own.

   Justification belongs in a separate field or in the risk statement, not inside the rating value.

   Likelihood and impact use the rating scale

4. Step 4

   Point at the control that exists

   The register should reference the live enforcement, not a wish. Give it the same kind of stable uppercase identifier the rest of the programme uses so a pipeline can join risks to controls.

   Training is an activity; it is not the thing standing between the contractor and the console.

   Control id is a stable identifier

5. Step 5

   Classify by behaviour

   Ask when the control acts relative to the event: before it, after it, or to clean up. The fixture describes the mitigation with a verb that answers this unambiguously.

   Control type matches how the control behaves

6. Step 6

   Reference a requirement, not a brand

   "SOC 2" names an audit, not an obligation. Pick one identifier from the fixture's list, the one about authentication, so the row can be traced to a testable requirement.

   Compliance reference is a requirement id

Rules summary

• XP on pass

  35 bonus XP the first time every check goes green.

• Paid hints

  2 available. Each costs 25% of the lab XP (about 9 XP).

• Reveal solution

  Scores 0 XP and unlocks only after 3 check runs.

• Attempt cap

  60 check runs per learner. The runner warns you in the last 10.

• Drafts

  Your editor content is saved in this browser, so a reload will not lose work.

• Walkthrough

  Always free and never penalised: use it before spending a hint.