The Group Board’s Line of Sight: Assuring Cyber Risk in Acquired Subsidiaries
Photo: UK corporate board reviewing subsidiary risk dashboard in modern boardroom, via facts.net
A group board can approve a cyber policy in an afternoon and still have little idea whether it operates in the warehouse, the software subsidiary or the logistics depot. That is not necessarily a failure of local management. It is a failure of assurance design. In UK groups, especially those that have grown by acquisition, cyber risk is often governed at the centre while the actual operating conditions sit elsewhere: local IT estates, inherited supplier contracts, devolved budgets and subsidiary management teams with their own commercial priorities.
The result is a familiar blind spot. The group board sees a single policy, a single risk register and a single set of metrics. It assumes the policy cascades. In practice, the subsidiary may be running unsupported systems, relying on a supplier contract the parent has never reviewed, or interpreting a group control in a way that suits local constraints. The gap tends to surface after an incident, when the board discovers that assurance was assumed rather than tested.
Why the cascade assumption fails
Group policy is usually written at a level of abstraction that makes sense at the centre. It says that access should be managed, suppliers should be assessed and incidents should be reported. It rarely specifies how a subsidiary with a different technology stack, a smaller security team and an inherited managed service contract should evidence those outcomes.
Acquisitions compound the problem. A parent may impose a common endpoint standard, but the subsidiary may still depend on a local line-of-business application that cannot be upgraded without disrupting operations. A group procurement team may own the largest contracts, while the subsidiary retains authority over operational technology suppliers and maintenance agreements. A devolved budget may allow the subsidiary to make local security trade-offs that the group board never sees.
None of this means the group board should start directing local IT teams. Micromanagement from the centre is neither practical nor desirable. The board’s role is to establish the conditions for credible assurance: clear ownership, tested controls and a reporting line that surfaces exceptions before they become incidents.
A fictional UK plc with three acquired businesses
Consider a fictional UK plc, Meridian Components, which has acquired three businesses over the past five years. Halden Precision is a Yorkshire manufacturer with operational technology and a long-standing local IT contractor. Cobalt Software is a Bristol-based SaaS business with its own cloud estate and engineering culture. Northline Logistics is a Glasgow transport business with a patchwork of inherited supplier contracts and depots across the UK.
At group level, Meridian has a cyber policy, a group risk register and a quarterly security report. The board reasonably believes it has oversight. But the assurance breaks down in three places. At Halden, the group endpoint standard has been deployed on office laptops but not on the production network, where change windows are tight and local engineers resist disruption. At Cobalt, the subsidiary has adopted a group incident reporting standard, but its engineering teams use a separate ticketing workflow and do not consistently classify incidents according to group definitions. At Northline, a logistics supplier contract renewed locally includes weak security obligations and no audit right, and the group procurement team has never seen it.
Each gap is understandable in isolation. Together they show why a group board needs evidence that controls operate in practice, not just confirmation that a policy exists.
An assurance model that gives line of sight
The first element is a subsidiary-level risk ownership map. For each business, the group should record who owns cyber risk locally, who reports to the group, and which decisions remain local. That map should cover technology, supplier contracts, budgets and incident escalation. It should be reviewed when leadership changes, after acquisitions and before major contract renewals.
The second element is control operation testing. The group board does not need to inspect every configuration. It does need a sampling regime that tests whether group controls actually work in each subsidiary. That might include evidence that privileged access reviews have taken place, that backup restoration has been tested, that incident reporting has been used in practice and that supplier security terms have been reviewed. The tests should be proportionate to the subsidiary’s risk profile, not applied as a uniform checklist.
The third element is an exceptions route to the board. Subsidiaries should be able to report where a group control cannot be applied, why, and what compensating measure is in place. This is more useful than a binary compliance dashboard. It gives the board a view of genuine risk decisions rather than a false sense of uniformity.
The fourth element is a reporting cadence tied to risk, not just the calendar. A quarterly report may be adequate for a stable subsidiary. A recently acquired business, or one undergoing a major cloud migration, may need closer attention. The board should ask for assurance that reflects change, not just routine confirmation.
Questions directors should ask in 2026
Group directors can test their line of sight with a small set of questions. For each material subsidiary, who owns cyber risk locally and what authority do they hold? Which group controls have been tested in operation during the past twelve months, and what did the testing show? Which supplier contracts have been inherited or renewed locally, and who reviews their security terms? Where has a subsidiary applied a compensating control because a group standard could not be met, and who accepted that risk? What would the group board learn first if a subsidiary suffered a serious incident, and how quickly?
These questions do not require the board to run local technology. They require the group to design assurance that reflects how the business actually operates. For UK groups in 2026, the subsidiary blind spot is less about missing policy and more about untested assumption. The board’s objective should be a credible line of sight: clear ownership, evidence that controls operate, and a route for exceptions to reach the centre before an incident does.