InsightsTechnology Delivery/7 min read

Delivery confidence comes from the operating model.

Technology programs fail for predictable reasons: unclear decision rights, diffuse accountability, architecture that cannot support the delivery pace, and teams that are disconnected from the business outcomes they are supposed to produce.

Why programs fail

The post-mortem of a failed technology program almost always identifies the same set of causes.

Decision rights and delivery pace

The single most common cause of delivery failure is not technical.

Architecture and delivery pace

Architecture is not a constraint on delivery pace. It is a determinant of it.

The accountability gap

Technology programs frequently suffer from what might be called the accountability gap.

International delivery teams

Many technology programs rely on teams distributed across multiple locations.

Connecting strategy to execution

The most persistent failure mode in technology delivery is the disconnection between strategic intent and operational execution.

Questions for leadership

Before committing to a significant technology program, leadership should be able to answer.

Delivery confidence is designed, not hoped for

Delivery confidence is not a property of a team or a technology. It is a property of an operating model.

LinkedIn X

SwissShore

Discuss this perspective

Bring the delivery challenge in front of you. We will help clarify what matters next.

Start a conversation

InsightsCybersecurity & Resilience/6 min read

Resilience begins before the incident.

A mature resilience strategy connects technology decisions to operating reality, governance and the organization's capacity to respond. This article examines the distinction between compliance, security and resilience — and what it takes to build the third when the first two are already in place.

Three disciplines, one question

Compliance, security and resilience are related but distinct disciplines. Conflating them is one of the most common and most costly mistakes in enterprise risk management.

Compliance answers the question: do we meet the requirements? It is backward-looking, standards-based and binary. An organization is either compliant or it is not. Compliance is necessary — it establishes a baseline and provides evidence of due diligence — but it does not guarantee protection.

Security answers the question: are we protected? It is forward-looking, threat-based and probabilistic. An organization's security posture is a function of its controls, its threat landscape and the effectiveness of its detection and response capabilities. Security is necessary — it reduces the likelihood and impact of incidents — but it does not guarantee continuity.

Resilience answers the question: can we continue? It is operational, scenario-based and tested. An organization's resilience is its demonstrated capacity to maintain critical functions, respond to disruption and recover to normal operations within acceptable timeframes. Resilience is the discipline that determines whether the organization survives an incident that its security controls did not prevent.

Why resilience is built before the incident

The most important characteristic of resilience is that it cannot be created in response to an incident. The capabilities, processes and governance structures that enable an organization to continue operating under pressure must be in place before the pressure arrives.

This seems obvious. In practice, it is frequently ignored. Organizations invest heavily in prevention — in the security controls that are supposed to stop incidents from occurring — and underinvest in the response and recovery capabilities that determine what happens when prevention fails.

The assumption underlying this investment pattern is that good security makes resilience unnecessary. That assumption is wrong. No security posture eliminates the possibility of a significant incident. The question is not whether an incident will occur but whether the organization will be able to continue operating when it does.

The components of operational resilience

Operational resilience is not a single capability. It is a combination of capabilities that must work together under conditions of stress.

Detection: the ability to identify that something has gone wrong, quickly enough to limit the impact. Detection capabilities that work in normal conditions may not work under the conditions of an active incident, when systems are degraded and teams are under pressure.

Response: the ability to contain the impact of an incident and prevent it from spreading. Response requires pre-defined playbooks, clear decision rights and teams that have practiced the response under realistic conditions.

Recovery: the ability to restore critical functions within acceptable timeframes. Recovery requires tested backup and restoration procedures, clear prioritization of which functions to restore first, and the organizational capacity to execute the recovery plan while managing the ongoing incident.

Communication: the ability to maintain appropriate communication with customers, regulators, employees and other stakeholders throughout an incident. Communication failures during an incident can cause as much damage as the incident itself.

IT and OT: a combined resilience challenge

For organizations that operate both information technology (IT) and operational technology (OT) environments — manufacturers, utilities, healthcare providers, critical infrastructure operators — resilience is a combined challenge that requires a combined approach.

IT and OT environments have historically been managed separately, with different governance structures, different risk frameworks and different security approaches. As these environments converge — as OT systems become connected to IT networks and to the internet — the security and resilience risks of each environment affect the other.

An attack that enters through the IT environment can propagate to OT systems, affecting physical operations. An OT failure can affect IT systems that depend on operational data. The resilience strategy must address both environments and the interfaces between them.

Testing as a governance discipline

The most reliable indicator of an organization's actual resilience is the quality and frequency of its testing. Organizations that test their resilience capabilities regularly — through tabletop exercises, simulation exercises and live recovery tests — know what they can and cannot do. Organizations that do not test are operating on assumptions.

Testing should be treated as a governance discipline, not a technical exercise. The results of resilience tests should be reported to the board and executive team, with clear accountability for addressing the gaps they reveal. Testing that identifies gaps but does not result in remediation is not governance. It is documentation.

The scenarios used for testing should be realistic — based on the organization's actual threat landscape and the incidents that have affected similar organizations — rather than theoretical. Testing against scenarios that are unlikely to occur provides false confidence. Testing against scenarios that have already occurred elsewhere provides actionable insight.

Business continuity and the operating model

Business continuity planning is the discipline of ensuring that critical business functions can continue during and after a significant disruption. It is closely related to resilience but distinct from it: resilience is about the capacity to continue; business continuity planning is about the decisions and preparations that create that capacity.

Effective business continuity planning requires a clear understanding of which business functions are critical — in the sense that their interruption would have material consequences for customers, operations or regulatory standing. It requires realistic recovery time objectives that have been tested rather than assumed. And it requires the organizational capacity to execute the continuity plan under the conditions of an actual incident, when normal processes are disrupted and key personnel may be unavailable.

Questions for leadership

Leadership should be able to answer the following questions about the organization's resilience posture:

What are our critical business functions, and what is our tested recovery time for each? The emphasis is on 'tested' — recovery time objectives that have not been tested are aspirations, not capabilities.

When did we last test our response and recovery capabilities under realistic conditions? What did we learn, and what have we done about it?

Who is accountable for resilience — not security, not compliance, but the organization's capacity to continue operating under pressure? Is that accountability clear?

How does our resilience posture compare to the threats we actually face? Are we investing in the capabilities that matter most for our specific risk profile?

Resilience as an operating capability

The organizations that manage significant incidents well are not those that were lucky enough to avoid them. They are those that treated resilience as an operating capability — something to be built, tested, maintained and governed with the same rigor as any other critical business capability.

Resilience is not a project. It is not a compliance exercise. It is not something that can be purchased from a vendor or certified by an auditor. It is the product of deliberate decisions, sustained investment and regular testing. And it begins long before the incident that will eventually test it.

LinkedIn X

SwissShore

Discuss this perspective

Bring the resilience question in front of you. We will help clarify what matters next.

Start a conversation

The questions that surface real technology risk.

The problem with technology risk reporting

Questions about operational dependency

Questions about technical debt

Questions about cybersecurity and resilience

Questions about AI and emerging technology

The discipline of asking

Discuss this perspective