Welcome to secure-working.com. This is a notebook of practical security architecture writing, focused on the patterns, decisions, and trade-offs I work through in my day job.
Who I am
I’m a security architect specialising in AWS, working at scale in regulated financial services. The day-to-day is multi-account AWS estates, infrastructure-as-code, threat modelling, and the slow grind of turning organisational risk appetite into controls that actually hold up under audit. Before that, a long stretch in infrastructure security, and before that, a different career entirely in the British Army — the discipline carries over more than you’d expect.
I’m based in Kent, work hybrid, and write here on weekends and evenings when something I’ve been wrestling with at work feels like it would be useful to someone else.
What this site is
A place to publish the technical writing I’d otherwise have only in private notes. The posts are grounded in real engagements but stripped of anything organisationally sensitive — the patterns and trade-offs are the point, not the specifics of any one employer’s environment.
Topics I keep coming back to:
- AWS security at multi-account scale — landing zones, delegated administration, organisation-wide tooling, the realities of operating security services across hundreds of accounts and multiple regions
- Infrastructure-as-code — Terraform module patterns, secure defaults, policy-as-code, the practical bits of making secure-by-default actually default
- PKI and cryptography in cloud environments — ACM and ACM Private CA, KMS, FIPS validation, IAM Roles Anywhere, the slow death of long-lived credentials
- Detection, response, and operational security — GuardDuty, Security Hub, sensible aggregation patterns, what good looks like for a security operations function attached to a cloud estate
- The boring but important stuff — third-party risk on cloud services, egress controls, backup and recovery as security concerns, things that don’t get conference talks but cause the breaches that do
What this site isn’t
Not a vendor blog. Not a marketing site. Not a place to pick up certifications or pass an exam. The earlier version of this site listed consultancy services; that’s no longer the focus. If you’re looking for hands-on consulting, there are better-suited firms.
I also try not to write about anything I haven’t done in practice. There’s enough armchair commentary on cloud security already, and I’d rather publish less and have it be grounded.
Where to start
If you’re new here, the four posts that frame everything else:
- Cloud Security Architecture in 2026: What Actually Matters — the umbrella post covering what a modern cloud security architecture looks like and where most organisations have gaps
- Multi-Region GuardDuty and Security Hub at Scale — the practical detection and response pattern for organisations running AWS across many accounts and regions
- AWS Certificate Manager Private CA: A 2026 Refresh — an updated take on private PKI in AWS, with current FIPS 140-3 references
- Terraform Patterns for Secure S3 and RDS — secure-by-default module patterns for the two services that most often turn up in cloud breaches
Get in touch
If something here is useful, wrong, or sparks a thought worth sharing, I’d genuinely like to hear it. The contact form on the homepage works, or you can find me through the usual professional channels.
A few things I won’t help with: free architecture reviews, exam answers, anything that looks like a vendor pitch, or commentary on a specific employer (current or past).
On the writing itself
I write in British English, prefer plain prose to jargon, and use first person where I’m drawing on direct experience and neutral language where I’m describing widely-known patterns. The opinions are mine, not those of any employer. Where I’m uncertain or where the landscape moves quickly — FIPS validations, AWS service updates, the like — I’ll say so and point at the authoritative source rather than asking you to take my word for it.
Thanks for reading.