How we approach security architecture
Three principles that shape how we work, whether we’re advising on a large program or reviewing the Microsoft 365 tenant of a 30-person firm.
Start with a framework, finish with evidence
Every organisation we work with already has obligations, whether that is ISO/IEC 27001, the NIST Cybersecurity Framework, the ACSC Information Security Manual or APRA CPS 234. We use these frameworks as the backbone of the work, not as a checklist bolted on at the end. They give everyone a shared language, and they make it clear why a control exists and which risk it is there to manage.
A framework on its own proves nothing, though. What matters is whether a control is actually designed, built and operating. So we trace requirements through to design artefacts, and from there to the evidence an auditor, a risk committee or a regulator will ask for. If a requirement can’t be traced to something real, it is a gap, and gaps are far cheaper to find in design than in an audit.
We use AI-assisted tooling in assessments to read faster and cover more ground, but the judgement stays human. Every finding, risk rating and recommendation is reviewed and owned by Jack Reason, our principal security architect, who leads every engagement.
We keep the paperwork proportionate. A good security artefact is one an engineer can build from and an executive can make a decision on. If neither of them will read it, it hasn’t done its job.
Identity is the control plane
Networks still matter, but most of the decisions that protect an organisation today are identity decisions: who is signing in, from which device, to what, and with how much privilege. That is why we treat identity as the control plane, and why Zero Trust is a practical design principle for us rather than a product category.
In practice, that means a few things. We start with a single, well-governed identity platform such as Microsoft Entra ID, with SSO and federation so that access is granted in one place and can be taken away in one place. We put conditional access in front of everything, and aim for strong authentication as the default rather than the exception. We keep standing privilege to a minimum, with privileged access that is time-bound, approved and logged. And we make sure separation of duties and regular access reviews are designed in, not added after an audit finding.
None of this needs to be exotic. A smaller organisation that gets MFA, admin separation and conditional access right in Microsoft 365 has already dealt with many of the most common ways accounts are compromised.
Proportionate, secure-by-design controls
Security that ignores the business tends to be bypassed, and security that arrives late tends to be waived. We avoid both by getting involved early, from ideation where possible, and by designing controls that fit the organisation’s risk appetite rather than an abstract ideal.
That starts with threat modelling: understanding what the system does, what it holds, who might want to misuse it and how. From there we design layered controls across identity, network, data, secrets and monitoring, sized to the actual risk. A low-risk internal tool and a payments platform should not carry the same control burden, and treating them the same wastes money and goodwill.
Where a risk can’t be fully mitigated, we would rather say so plainly, document it and help the right owner make an informed decision than hide it inside a design document. Clear risk decisions, made by the people accountable for them, are a sign of a healthy security function, not a failure of one.