Your board is making decisions about risk
they can't fully see.

A small cybersecurity firm — fifteen people at the point this work began, with six in the R&D team — working with regulated and defence-sector clients. The majority of the organisation consisted of experienced cybersecurity consultants, many with military and government backgrounds. Trust, discretion, and operational integrity were not abstract values. They were commercial necessities.

The R&D team sat inside this organisation as a distinct unit: five people building commercial software products while the rest of the firm delivered consultancy work. The R&D team's work — its risks, its security posture, its control environment — was largely invisible to the rest of the organisation, including the CTO and security controller.

There was no CISO, no internal audit function, and no formal security governance structure for the R&D function. As the sole Business Analyst embedded in the R&D team, the visibility to see the gap and the responsibility to close it sat in the same role.

The Security Working Group did not emerge from a brief or a job description. It was the third piece of a connected body of work. The shift-left programme had addressed the control environment. The secure by design work had embedded security into the commercial product. What was missing was the governance layer that made all of it visible, continuous, and accountable to the people who needed to act on it.

Four purposes shaped the decision to build it.

That last point matters. This was not a reaction to an existing requirement. It was an anticipation of one that did not yet exist.

The absence of engineering risk visibility created three categories of organisational exposure — none of which were being tracked or reported.

The Security Working Group was established in parallel to the shift-left controls remediation programme. The logic was straightforward: implementing controls was necessary but not sufficient. Someone needed to track whether those controls were working, whether residual risk was changing, and whether the organisation's leadership understood what was happening inside the R&D function.

Nobody asked for this structure to be created. The need was identified, the format designed, the agenda set, and the first meeting convened. The initiative was self-directed from start to finish.

The working group brought together three senior stakeholders, each with a distinct relationship to the risk being reported. Understanding what each person needed — and translating the same underlying risk picture into the right language for each — was central to the meeting's effectiveness.

The format was deliberately lean. Meetings ran 15 to 30 minutes depending on the severity of active control implementations. Attendance was selective — the product manager was only included when agenda items were directly relevant to her decisions. Time was treated as a resource to be managed, not consumed.

Building the working group report required judgement before it required writing. Every session started with the same question: what was material enough to escalate, what could wait, and what needed to be reframed before it reached a senior audience. The engineers reported on remediation status. The working group reported on risk. Those are not the same thing, and the translation between them was the work.

This work was self-directed and built proportionately for a small, early-stage organisation without a formal security governance structure. The following is an honest assessment of its limitations and what a more mature organisation would do differently — alongside a distillation of how the work was driven without formal authority.