Running the programme: training, communication, reporting and RACI

Why this matters

Objective 1.2 is the one that looks least like security work and is the one most likely to decide whether a real programme succeeds. It is also disproportionately answerable, because its scenarios turn on a small number of distinctions that can be learned in an afternoon: who is accountable versus who is responsible, what a phishing click rate actually measures, and what a board can do with a report.

The exam angle is consistent. CAS-005 presents a programme that is technically sound and organisationally failing — controls implemented, incidents still mishandled — and asks what to fix. The answer is almost never another control. It is a training gap aimed at the wrong audience, an unassigned accountability, or reporting that nobody can act on.

There is a career angle too, and it is the reason this objective exists at the SecurityX level rather than at Security+. At this level you are expected to be the person who designs the programme, not the person who executes a part of it, and programme design is mostly about people and information flow.

The lesson

Security, privacy and phishing training as three different programmes with three audiences

Organisations habitually collapse these into one annual module, and the collapse is the finding a scenario is describing when it mentions "mandatory annual training" alongside a recurring incident type.

• Security awareness training is broad and universal. Its goal is a workforce that recognises and reports the common attack patterns, knows the acceptable use rules, and knows how to reach the security team. Its audience is everyone, its cadence is periodic, and its measure is reporting behaviour rather than test scores.
• Privacy training is about a different body of obligation — lawful basis, data subject rights, retention, cross-border transfer, breach notification timelines. Its natural audience is anyone who handles personal data, which is narrower than everyone and wider than the privacy team. Collapsing it into security awareness reliably produces staff who know not to click links and do not know that a data subject request has a statutory clock.
• Phishing simulation is not training at all; it is a measurement instrument with a training follow-up. Its audience is everyone, its output is data, and its value depends entirely on what happens after a click.

Two more audiences appear in scenarios and are worth naming because they are frequently missing. Role-based training targets people whose job creates specific risk — developers on secure coding, administrators on privileged access, procurement on supplier due diligence. And executive briefing is a distinct format for people who make funding and risk-acceptance decisions and have no time for a module.

When a question describes a control failure caused by a specific role doing something reasonable-but-wrong, the answer is usually role-based training, not more awareness training for the whole organisation.

Phishing simulation: what the click rate does and does not tell you

This is the most commonly misread metric in the objective, and it is worth being precise.

A click rate measures how many recipients interacted with one particular simulated message on one particular day. It is strongly affected by things unrelated to security capability: the plausibility of the pretext, the time of day it was sent, whether the sender name resembled an internal system, and whether an unrelated real change was happening that week.

Consequently a falling click rate over time is weak evidence, because the simulations are not comparable to each other. A programme that reports steadily improving numbers while running easier and easier simulations has measured nothing at all.

The metric that carries more signal is the reporting rate: how many recipients used the reporting mechanism, and how quickly the first report arrived. That measures the behaviour you actually want — not "nobody clicked", which is unachievable, but "somebody told us within minutes". A mature programme tracks the ratio of reports to clicks, and the time to first report, and treats a high click rate with fast reporting as a better outcome than a low click rate with silence.

Two design rules follow and both appear in scenarios. Simulation must not be punitive, because a workforce afraid of being blamed stops reporting, which removes the only useful signal. And the follow-up must be immediate and specific — a short explanation at the moment of the click, naming what in that message was detectable — because delayed generic training does not change behaviour.

A RACI matrix that survives contact with a real incident, and the ambiguity it removes

RACI assigns four distinct relationships to each activity, and the examinable content is the difference between the first two.

• Responsible — does the work. Can be several people.
• Accountable — answerable for the outcome, approves the result. Exactly one, always. If a scenario shows two accountable parties for one activity, that is the defect being described.
• Consulted — provides input before the work is done, two-way.
• Informed — told the outcome, one-way.

The single-accountable rule is what the matrix exists to enforce. Ambiguity about accountability is invisible during normal operations and becomes the dominant failure during an incident, when the question "who decides whether we take this offline" has to be answered in minutes.

A RACI that survives a real incident has three properties beyond correct letters. It covers decisions, not only tasks — declaring an incident, authorising containment that will cause an outage, approving external communication, deciding to involve law enforcement. It names roles rather than people, so it does not go stale when someone changes job. And it has a named deputy for every accountable role, because incidents do not wait for somebody to come back from leave.

The common scenario is an incident that was detected promptly and contained late. The RACI answer is that containment required an outage, nobody was unambiguously empowered to authorise one, and the delay was consultation masquerading as process.

Reporting upward: what a board needs from a security report and what it cannot use

Boards make three kinds of decision: funding, risk acceptance, and escalation to regulators or customers. A security report is useful to the extent that it supports those, and useless to the extent that it does not — regardless of how accurate it is.

What does not work, and shows up in scenarios as the thing being criticised: counts of blocked events, volumes of alerts, numbers of patches applied, and technical severity scores without context. These describe activity. A board cannot act on activity, because there is no decision attached to a larger or smaller number.

What does work:

• Risk expressed against appetite. Which risks currently exceed the organisation's stated tolerance, what it would cost to bring each inside, and what the residual would be. This directly supports funding and acceptance.
• Trend against a target, where the target was agreed in advance. "Critical vulnerabilities on internet-facing assets: 41, against a target of under 10, down from 96" is actionable in a way that "we remediated 55" is not.
• Obligations and their status. Which regulatory or contractual commitments are met, which are at risk, and the date each becomes material.
• The two or three things that would change the picture, each with an owner and a decision required.

Two presentation rules recur. Report the same small set of measures every period, because a changing dashboard prevents the trend that gives the numbers meaning. And separate what happened from what we want you to decide — a board paper that buries a funding request inside an incident narrative usually gets neither read properly.

Communication planning before an incident, because during one is too late to draft it

Incident communication fails predictably, and every one of its failure modes is prevented by work done beforehand.

A communication plan specifies, per audience, who speaks, what is said at each stage, and through which channel:

• Internally, staff need to know what is happening, what they must do differently, and what they must not say externally. Silence here reliably produces speculation that escapes.
• Executives need decisions framed, not updates streamed.
• Customers and partners need factual, timely notice; most of the reputational damage in real incidents comes from the gap between discovery and disclosure rather than from the incident.
• Regulators have statutory clocks measured in hours or days, and the clock starts at awareness rather than at confirmation. Knowing which obligations apply to which data is domain 1 work done in advance.
• Law enforcement and insurers have their own notification requirements, often contractual.

Three preparations do most of the work. Pre-drafted holding statements for the two or three plausible incident classes, approved by legal in advance, so the first external message is a review rather than a draft. An out-of-band channel, because the plausible incidents include ones where corporate email and chat are compromised or unavailable, and a plan that assumes them is a plan that evaporates exactly when needed. And a single named spokesperson with a deputy, which is the same single-accountable rule from the RACI applied to speech.

The scenario to recognise: an organisation that handled an incident competently, disclosed late, and suffered more from the disclosure than from the breach. The control that was missing is a communication plan, not a technical one.