Design of cybersecurity strategy and operating model

Context

Organisation

A government investment and supervision authority — a state financial institution managing public investment programmes and supervising their execution.

Environment

The institution oversaw several large-scale programmes, some of them dependent on substantial IT systems and databases, and worked in daily contact with the local financial supervision authority and with government oversight bodies. Its supervisory obligations extended considerably beyond those carried by a private equivalent of comparable size.

Problem

Situation

The organisation processed large databases of personal data alongside highly confidential financial information, and did so with a headcount considerably smaller than the scope of those obligations would suggest. A new programme was about to begin that would raise the volume and sensitivity of processed data in a step rather than an increment. The reassessment of security posture was undertaken ahead of it, to prepare an environment able to carry the increased exposure under control.

Boundaries

Governance and risk management had to conform to internal standards already in force.

The environment was heavily formalised, with a number of functions existing specifically to compensate for the influence of individual incentives on decision-making. Considered purely in terms of efficiency, these control layers consume capacity a small team has little to spare, and any additional capability had to be designed with that overhead already accounted for.

Confidentiality requirements meant that most security, risk and governance functions could not be outsourced. Whatever was designed had to be operable by internal staff, permanently.

Constraints

The framework had to satisfy GDPR, the national transposition of the NIS Directive, and the security requirements of the local financial supervision authority across internal security, GRC operations, data management, cloud security and third-party management.

The engagement ran across the turn of 2020 and 2021. The revision that later became NIS2 had been published as a proposal in December 2020: a signal about direction rather than an obligation, and treated as such in the design.

Objective

• Assess the scope of existing security, governance and risk capabilities, and their operational maturity.

• Identify and prioritise compliance gaps and areas of elevated exposure.

• Establish, with the board, the level of exposure the institution was in fact prepared to carry.

• Based on the identified current state, risk appetite and expected change in risk exposure, design a security strategy that would let the organisation pursue its future goals under an adequate level of control over its IT environments.

• Design the target security operating model, high-level security architecture, alignment of risk and governance functions, together with an implementation plan for the capability improvement programme.

Solution

My role

Project lead and security architect, responsible for strategy development and for advisory to the board. Managing a team of four consultants supporting the assessment workshops and the design of selected components of the target architecture. Delivered as part of a third-party engagement.

Reasoning

A control baseline derived from compliance frameworks is calibrated principally against attackers with financial motives. Data whose value is political is not resold or encrypted for ransom — it pays out when it is disclosed, and the shortest route to disclosure runs through someone who already holds legitimate access. That shifts weight onto internal actors, and onto whoever is in a position to apply pressure to them. The baseline was extended in that direction rather than adopted as drawn.

The implementation plan was sequenced on two variables rather than one: severity, and how quickly an item could be closed. Work began where exposure was significant and the fix was fast, moving to slower items once the early ones were complete. In an organisation already carrying substantial control overhead in a small team, visible early completion carries practical weight beyond the exposure it closes, since it sustains the confidence on which a long programme depends for continued funding and staffing.

The design process was run with the client’s security, governance, audit and IT teams inside it, to establish clear ownership and transfer as much know-how as possible during the engagement. A team that holds the reasoning can defend a requirement against a later trade-off; a team that holds only the recommendation cannot.

Reframe

In institutions of this type the declared appetite for risk tends towards zero, since the cost of documenting an accepted exposure falls on the individual who signs it while the benefit accrues to the institution. Risk decisions continue to be taken regardless — dispersed across the organisation, undocumented, and made by whoever sits closest to a given problem at the time.

The board sessions therefore could not be run as elicitation, since the only appetite on record was a nominal zero, and nothing can be designed against it. They were run instead as a construction exercise: specific exposures, the cost of each were it to materialise, the range of available responses, and the consequences of leaving each unaddressed. Much of the material was drawn from matters the institution was working through at the time, so positions were taken against live decisions rather than hypothetical ones.

The notes from those sessions accumulated into something the engagement had not started with — a documented set of requirements, known problems, and exposures the board had agreed to carry. That, more than any individual control, is what made the rest of the design defensible.

Result

Outcome

A documented security strategy, an accompanying draft of the target security operating model integrated with governance and change management functions, and a high-level draft of the security architecture.

Alongside the documents, standing advisory to the board members involved in the project, including on operational issues they were handling at the time.

Each handover was preceded by a workshop in which every decision and the shape of every recommendation were justified in full, and challenged by the leadership of the IT, security, governance and audit functions. The target plan was accepted and the team proceeded to implementation. My role ended at that point.