A defence-in-depth posture is a set of independent, overlapping controls, each of which can fail in a way the next one catches. A list of products that all rely on the same assumption is one control, not many.
Cybersecurity
Security that is useful because it is designed in — not bolted on, not the last forum before launch, and never the function nobody calls.
On this page
§ 01 ·
The common approach treats security as a control function that says yes or no. The control is technically in place; the business routes around it.
The work is to design security into the architecture and the operating model, not to apply it after the fact. The four phases the firm uses to do this work are on the How we work page.
§ 02 ·
Patterns we design our practice to avoid
Six failure modes we have seen repeatedly, across security engagements of every size. Each one motivates a specific choice in how we work. The page opens with the failure modes because that is where most security work quietly fails.
When security is the function that says no, the rest of the business learns to ask forgiveness, not permission. The control is technically in place and operationally irrelevant.
A threat model that does not change as the system changes is documentation, not architecture. The threat model is most useful as a living artefact the security practice uses to drive prioritisation.
Most security work in the enterprise is the evaluation of controls already chosen. Useful security work is the design of the controls in the first place, so the evaluation has something to evaluate.
An alert nobody reads is a missed detection. An alert everybody reads is a missed opportunity to engineer the alert volume down. The most useful operations work is the work that reduces the signal-to-noise ratio to a level the team can actually handle.
A response plan that has not been rehearsed is a plan that will be discovered to be wrong at the worst possible time. Rehearsal is the only way to know which of the plan's assumptions are still true.
§ 03 ·
How we approach security work
The common approach treats security as a control function that operates separately from the business it protects. Our approach treats it as an architectural and operating concern that has to be designed in, not bolted on, and that has to share a model of value with the business it protects.
The common approach
Security is organised as a control function. The team evaluates controls, runs the audit, and writes the policies. The business makes its own decisions about risk, speed, and convenience, and security is the function that says yes or no. The architecture implications tend to be left implicit.
- Security is a function that says yes or no.
- Controls are evaluated, not designed.
- Threat models are written, not maintained.
- Security is the gate; the business is the customer.
What we do
Security is an architectural and operating concern. The practice designs the controls in the first place, builds the operating model that keeps them honest, and aligns the security posture with the value the business is trying to protect. The architecture is explicit; the threat model is a living artefact; the controls are designed to fail independently.
- Security is a partner in the decision, not a gate after it.
- Controls are designed in, not bolted on.
- Threat models are living artefacts that drive prioritisation.
- The business and security share a model of value.
What you walk away with
A flat list of the artefacts a security engagement produces. The full shape of the engagement is on the [How we work](/services/methodology/) page.
A threat model organised by business outcome
A prioritised list of risks ranked by how much they block the rest of the work, not by system component. The threat model is the artefact against which the rest of the security work is evaluated.
A security architecture as a reference model
Names the trust boundaries, the controls at each boundary, the depth of the defence, the monitoring and detection model, and the incident-response story. Deliberately does not specify every component. That work belongs in service-level design reviews.
A detection and response model
Signal sources, alerting tiers, the on-call rotation, the runbooks for the incidents the practice has rehearsed, and the escalation paths for the ones it has not. The measurement is time-to-detect and time-to-recover, both tracked over time.
Operating-model documents
Who owns which decision, what the review cadence is, how exceptions are escalated, how the threat model is maintained, how the controls are tested, and how the architecture is revised when the evidence changes. Names what the operating model explicitly does not do.
A post-incident learning artefact (when an incident has occurred)
A short document recording what happened, what was assumed that turned out to be wrong, and the architecture change made so the same failure mode cannot happen the same way again.
§ 05 ·
What each phase produces in a security context is on the How we work page.
§ 06 ·
Common questions from clients
The questions we hear most often, in the order they tend to come up.
A security review asks: is this system safe? It looks at controls, threats, and gaps. It produces a finding list.
A security architecture asks: is the system built in a way that makes safety possible? It looks at the control design, the trust boundaries, the depth of the defence, the detection model, and the recovery story. It produces a reference model.
The two are complementary. The review tells you whether the controls in place are sufficient. The architecture tells you whether the system is built in a way that makes controls possible in the first place.
Most security engagements run between three and nine months. The framing phase (alignment on what the organisation is trying to protect) is six to twelve weeks; the security architecture work is the bulk of the early engagement; the detection and response work is sized to the operating model the client team can carry; the operation phase is ongoing.
Engagements are priced against the threat model produced in the framing phase. The cost depends on the depth of the threat model, the breadth of the architecture, the operating model the work needs, and whether the engagement includes an incident-response component. A typical range for a multi-phase engagement sits in the low-to-mid six figures; the final figure is set in the scoping call after the framing phase.
The first 30 days are the framing phase: a working session with the leadership to identify what the organisation is actually trying to protect, structured conversations with the practitioners who do the work, and the production of the threat model organised by business outcome. By the end of the first 30 days, the client has a prioritised list of risks it can act on.
The first job is to stop the damage from getting worse. The second job is to understand what happened. The third job is to recover. The fourth job is to revise the architecture so the same failure mode cannot happen the same way again.
The fourth job is the one most incident responses skip. Skipping it is how the same incident happens twice.
§ 07 ·
Evidence & references
Public frameworks and writing that inform the firm's practice.
NIST, 2014 (with revisions through 2024)
The Identify-Protect-Detect-Respond-Recover structure is the vocabulary for the security operating model. We use it as a checklist against specific risks, not as a process.
Threat Modeling: Designing for Security
Adam Shostack, Wiley, 2014
The pattern language for threat modelling (what to model, how to model it, when the model is good enough) — is the operational reference we lean on most often.
The Practice of Network Security Monitoring
Richard Bejtlich, No Starch Press, 2013
The strongest case for treating detection as a discipline, not a side effect of the controls. The measurement model (time-to-detect, time-to-recover) is the same one we use.
Security Engineering
Ross Anderson, Wiley, 2008 (3rd edition 2020)
The canonical reference. The pattern language for security protocols, access control, cryptography, and the economics of security is more durable than any single framework document.
The Fifth Domain
Richard Clarke & Robert Knake, Penguin, 2019
The strategic framing of cybersecurity as a question of organisational capability and policy, not a question of products. Consistent with the firm's own view that security is an architectural and operating concern.
Want to talk security?
If you are evaluating a security programme, responding to an incident, or strengthening the security architecture of an existing system, the firm is useful at that boundary. A short conversation is the right next step.
Start a conversation