method

Core Principles of Peak Defence Method

Introduction

Security approaches often fail not because of poor implementation, but because they’re built on flawed assumptions about the nature of security itself. The Peak Defence Method is founded on a different perspective — one that acknowledges the inherent complexity and unpredictability of modern systems.

This chapter explains the philosophical foundation and core principles that guide our approach across organizations of all sizes and maturity levels. These principles inform every aspect of the methodology, from how we shape work to how we implement security controls and measure security effectiveness.

Security is inherently cross-functional - it touches every aspect of an organization and requires coordination across traditional functional boundaries. The principles in this chapter don’t just guide the security team; they provide a common language and framework for all organizational functions to contribute to security outcomes effectively.

Maturity Level Framework

The application of core principles evolves as organizations grow in size and capability. The table below illustrates how key characteristics change across maturity levels:

Characteristic	Level 1: Startup	Level 2: Scale-up	Level 3: Enterprise
Method Integration	Implicit, pragmatic application	Explicit, structured application	Comprehensive, systematic application
Resilience Focus	Basic recovery capabilities	Balanced prevention and adaptation	Sophisticated resilience architecture
People-Process-Technology Balance	Informal, people-centric	Structured, balanced approach	Formal, comprehensive integration
Cross-Functional Coordination	Direct collaboration between team members	Designated security liaisons in key functions	Formalized coordination framework with clear interfaces
Documentation	Simple principles statement	Detailed principles documentation	Enterprise security architecture

Progression Indicators

When to move from Level 1 to Level 2:

Basic security controls are consistently implemented
Security incidents require more systematic response
Multiple team members share security responsibilities
Customers or partners request formal security documentation
The organization needs to demonstrate security capabilities to external parties

When to move from Level 2 to Level 3:

Security initiatives span multiple teams, systems or geographies
Regulatory requirements demand comprehensive security documentation
The organization has specialized security teams
Security strategy requires alignment across business units
Sophisticated threats target the organization specifically

Designing for the Inevitable

“Anything that can go wrong, will go wrong” - Edward A. Murphy Jr.

Murphy’s Law serves as our philosophical foundation—a reminder that in any sufficiently complex system, unexpected events are inevitable. Rather than viewing this as pessimism, we see it as a profound insight that should guide how we approach security.

The Strategic Implications

This perspective fundamentally changes our approach to security:

Traditional Security	Resilience-Oriented Security
Focus on preventing all failures	Design for inevitable failures
Create rigid, controlled environments	Build adaptive, responsive systems
Minimize risk through strict controls	Manage risk through adaptive capacity
React to security failures	Anticipate and prepare for failures
Measure success by incidents prevented	Measure success by resilience to incidents

Applying This Principle By Maturity Level

Level 1: Startup Foundation

For startups and small organizations (5-50 employees): Garage

Focus on basics with resilience in mind
- Implement essential controls that address highest risks
- Create simple backup and recovery processes
- Document basic incident response procedures
- Establish monitoring for critical systems
Practical application:
- Build security with “graceful failure” in mind
- Ensure someone receives alerts when controls fail
- Create simple runbooks for common security issues
- Maintain offline backups of critical data

Example: A small e-commerce startup implements password authentication but also creates a simple account recovery process for when users forget passwords or accounts get compromised. They test this recovery process monthly to ensure it works when needed.

Cross-Functional Considerations:

At the startup level, cross-functional coordination happens organically through direct communication:

Shared Visibility: Use simple, visible tools (like shared dashboards) that allow all team members to see security status (e.g. system availability, Dependabot issues) regardless of role
Unified Response: Develop simple incident response checklists that include steps for different functions (engineering fix, customer communication, legal notification)
Collective Ownership: Foster a culture where security is everyone’s responsibility, not siloed to technical team members

Example Boundary Artefact: A one-page “Security Incident Checklist” that defines roles for everyone during a security incident, regardless of their primary function.

Level 2: Scale-up Enhancement

For growing organizations (50-500 employees): Office

Develop systematic resilience capabilities
- Create formal incident response processes
- Implement security monitoring and alerting
- Establish security testing and validation practices
- Develop business continuity procedures
Practical application:
- Document expected failure modes for key systems
- Implement defense-in-depth for critical assets
- Create security dashboards to visualize control effectiveness
- Conduct regular tabletop exercises for security scenarios

Example: A growing FinTech company implements a dual-layer authentication system, with the explicit understanding that the primary method may fail. They create dashboards to monitor authentication success rates, establish alerts for unusual patterns, and document procedures for rapidly switching to backup authentication methods when needed.

Cross-Functional Considerations:

As the organization grows, more structured cross-functional coordination becomes necessary:

Security Suport Network: Designate and train security “champions” or “advocates” in key departments (engineering, product, operations)
Functional Security Guides: Create role-specific security guidance for different functions (developer security practices, product manager security considerations)
Collaborative Resilience Planning: Involve representatives from multiple functions in resilience planning sessions

Example Boundary Artefact:

Function-specific security checklists that translate security principles to specific roles
Simplified threat models that non-security specialists can understand and contribute to

Level 3: Enterprise Optimization

For large organizations (500+ employees): Buildings

Architect comprehensive resilience
- Implement formal resilience engineering practices
- Create advanced detection and response capabilities
- Develop adaptive security control frameworks
- Establish continuous learning from security events
Practical application:
- Conduct formal failure mode and effects analysis
- Create resilience architecture as part of security strategy
- Implement automated response to common security events
- Develop metrics for security control effectiveness and adaptation

Example: A large healthcare enterprise implements a zero trust architecture with the explicit understanding that some controls will fail. They create layered detection capabilities, develop response procedures for different compromise scenarios, establish formal learning processes after security events, and maintain a security control effectiveness dashboard with real-time adaptation metrics.

Cross-Functional Considerations:

Enterprise organizations require systematic approaches to cross-functional security coordination:

Security Governance Framework: Establish formal governance mechanisms that include representation from all key functions
Capability-based Security Model: Define security capabilities that span functional boundaries with clear responsibilities
Cross-functional Security Metrics: Implement shared security metrics that demonstrate how different functions contribute to overall resilience

Example Boundary Artefacts:

Enterprise resilience architecture documents with function-specific views
RACI matrices for security capabilities that span multiple functions
Security decision frameworks that different functions can use consistently

Common Implementation Challenges

Challenge	Level 1 Solution	Level 2 Solution	Level 3 Solution
Balancing prevention and resilience	Focus resources on recovery for critical systems	Develop tiered approach based on asset value	Implement formal resilience architecture framework
Convincing stakeholders	Use concrete examples of past security failures	Present cost-benefit analysis of resilience vs. prevention	Develop comprehensive risk management framework
Limited resources	Prioritize controls that provide both prevention and detection	Implement phased approach to building resilience	Develop risk-based resource allocation model
Complex technology landscape	Focus on critical system resilience first	Develop resilience patterns for common technologies	Create technology-specific resilience architectures
Functional silos	Regular all-hands security updates	Security champions in each function	Enterprise security operating model with clear interfaces

The People-Process-Technology Triangle

Security effectiveness requires balance across these three dimensions. This balance looks different at each organizational maturity level but remains a critical framework for security decisions.