What do organisations get wrong about cybersecurity and sustainability?

They often treat sustainability as a facilities or reporting issue and security as a separate technical layer. In connected environments, outage duration, access scope, and device governance directly affect waste, continuity, and safety. The control model needs to join those concerns instead of measuring them in isolation.

Why This Matters for Security Teams

Organisations often talk about sustainability as energy efficiency, carbon reporting, or hardware refresh cycles, while treating cybersecurity as a separate governance stream. That split hides operational risk. A compromised building system, unmanaged endpoint, or overbroad access model can increase downtime, device churn, and recovery work, all of which create waste and continuity loss. Security decisions therefore affect environmental outcomes as well as resilience, especially in connected estates where availability matters as much as confidentiality.

The practical mistake is assuming that a greener architecture is automatically safer, or that stronger security always means heavier consumption. Current guidance suggests the better question is whether controls reduce unnecessary exposure and unnecessary operational effort at the same time. CISA cyber threat advisories show how real-world incidents often spread through weakly governed systems, which is why the sustainability conversation cannot be separated from detection, patching, and recovery planning.

In practice, many security teams encounter sustainability impacts only after an outage, mass replacement, or incident response cycle has already increased cost and waste, rather than through intentional control design.

How It Works in Practice

The most useful approach is to treat sustainability as an outcome of resilient security operations, not as a parallel programme. That means measuring the environmental cost of repeated incidents, emergency replacements, and inefficient estate design alongside traditional security metrics. If a control reduces breach likelihood, shortens restoration time, or extends asset life, it can support both domains. If it creates brittle complexity, excessive manual work, or unnecessary hardware turnover, it may undermine both.

In practical terms, teams should map security controls to asset longevity, service continuity, and governance of connected devices. This is especially relevant in buildings, industrial systems, and remote operations where access control, patch cadence, and monitoring have direct energy and maintenance implications. Identity controls matter here too. Overprivileged accounts, unmanaged secrets, and weak service identity governance can force broad resets, shorten platform lifecycles, and increase operational waste. The same is true when software supply chain risks drive urgent rebuilds rather than planned maintenance.

• Use asset inventories to identify which systems create the largest security and sustainability blast radius when they fail.
• Prioritise least privilege and segmented access to limit incident scope and avoid unnecessary shutdowns.
• Align patching, firmware management, and replacement decisions with both risk reduction and equipment lifecycle planning.
• Track restoration time, device disposal, and rework as operational indicators, not just facilities metrics.

Where AI-driven operations are involved, model governance also matters. If a tool is used to automate maintenance, monitoring, or incident response, its outputs must be validated and its access constrained. The Anthropic report on the first AI-orchestrated cyber espionage campaign is a reminder that autonomy without governance can amplify both security and operational damage, while the MITRE ATLAS adversarial AI threat matrix helps teams think about manipulation of AI-enabled workflows. These controls tend to break down when sprawling legacy estates, weak ownership, and inconsistent telemetry make it impossible to connect incident impact to asset and energy decisions.

Common Variations and Edge Cases

Tighter security controls often increase short-term operational overhead, requiring organisations to balance resilience gains against energy use, maintenance burden, and lifecycle cost. That tradeoff is real, but it is not a reason to keep the two domains separate.

There is no universal standard for this yet. Some organisations are focused on data centre efficiency, while others are concerned with buildings, manufacturing, logistics, or endpoint fleets. The right control set depends on which assets create the greatest combined risk. In high-availability environments, a security change that causes frequent rollback, replacement, or manual intervention can be worse for sustainability than a simpler control with stronger operational discipline.

Edge cases also arise when sustainability claims are driven by reporting rather than engineering. Best practice is evolving toward evidence-based control design, where organisations can explain why a change reduces exposure, extends service life, or lowers recovery waste. For AI-heavy environments, the same principle applies to model governance: if automation cannot be audited, constrained, and recovered cleanly, it can create hidden resource use and incident drag rather than operational efficiency.

In connected estates, the question is not whether security and sustainability are related. The real issue is whether organisations are willing to manage them through the same asset, identity, and resilience decisions.

Related resources from NHI Mgmt Group

• What do organisations get wrong about breach defence and cybersecurity frameworks?
• What do organisations get wrong about cybersecurity training APIs?
• What do organisations get wrong about segregation of duties in federated environments?
• What do organisations get wrong about automated data classification?