CISO Diaries: Andy Curtis on Building Resilient, Executable Security Programs

Security leadership isn’t just about policies, dashboards, or threat alerts; it’s about creating systems and cultures that enable organizations to keep their promises. CISO Diaries highlights the people behind the decisions, offering a window into the daily routines, priorities, and philosophies of the world’s leading CISOs. From managing high-stakes risk to embedding security seamlessly into operations, these conversations reveal how top practitioners balance protection, progress, and resilience in real-world settings.

About the Interviewee: Andy Curtis

Andy Curtis is a seasoned cybersecurity leader and consultant with extensive experience piloting security and infrastructure programs for both government and enterprise clients. As a virtual and contract CISO, he has led ISO27001 compliance, Essential 8, NIST, and other control frameworks, transforming legacy systems into sustainable, risk-aligned security programs. Andy combines hands-on technical expertise with business acumen, focusing on executable strategies, measurable risk reduction, and practical solutions that keep organizations secure while enabling them to operate efficiently. His approach emphasizes clarity, operational resilience, and embedding security into culture and day-to-day decision-making.

How do you usually explain what you do to someone outside of cybersecurity?

I usually say: I help organisations keep their promises.

If you’re a bank, your promise is “your money is safe.” If you’re government, it’s “your services work, and your data is protected.” If you’re a retailer, it’s “you can trust us with your information, and we’ll still be open tomorrow.”

Then I translate it into something non-technical:

• Part city planner: ensuring roads, rules, and lighting so people can move safely.
• Part firefighter: planning so we don’t burn down, and practising so if we do, we recover fast.
• Part seatbelt engineer: security should be built-in and mostly invisible—until the day it saves you.

If I’m being cheeky: I’m paid to be professionally paranoid… but only in ways that are useful. The goal isn’t to be scared of everything; it’s to know what matters, protect it well, and keep the business moving.

What does a “routine” workday look like for you, if such a thing exists?

If there’s a routine, it’s a rhythm rather than a schedule:

1. Triage and signal check (early): What changed overnight? Any incidents, urgent risks, operational failures, or emerging issues that are actually real versus just loud?
2. Decision-making and alignment (mid-morning): Security is rarely blocked by “not knowing.” It’s blocked by competing priorities. A big part of my day is aligning leaders on what we’ll do now versus what we’ll consciously defer.
3. Uplift delivery and friction removal (middle of day): Making programs executable: clarifying ownership, simplifying requirements, unblocking teams, and turning security controls into something operations can sustain. In my world, “strategy” isn’t a slide—it’s what survives contact with reality.
4. Stakeholder conversations (throughout): Translating risk into business language without losing the technical truth. This ranges from frontline engineering conversations to executive risk calls.
5. End-of-day sanity check: What did we actually move forward today? What risks did we meaningfully reduce? What did we learn?

Some days are calm. Some days are an incident. The trick is building a program that keeps improving even when the day gets hijacked.

What part of your role takes the most mental energy right now?

Maintaining clarity in a world that rewards noise.

Security has never had more data, dashboards, alerts, vendors, and “urgent” things. The mental load is separating:

• True risk vs. hypothetical risk
• Control theatre vs. control effectiveness
• Important work vs. visible work
• One-off heroics vs. sustainable capability

And then there’s the hard part: changing systems run by humans.

Technology is often the easy half. Culture, incentives, ownership, and consistency are the energy sink. The work isn’t just building controls; it’s making sure they stick.

What’s one security habit or routine you personally never skip? (Work or personal.)

My non-negotiable habit is: “pause and validate.”

Before I approve, click, send, grant access, or escalate—there’s a short mental checklist:

• Do I understand what I’m authorising?
• Is this request consistent with normal behaviour?
• What’s the simplest way this could be wrong?
• If I’m wrong, what’s the blast radius?

It sounds basic, but it scales. Most security failures aren’t exotic; they’re unexamined assumptions at speed.

What does your own personal security setup look like? (Password manager, MFA, backups, devices, at a high level.)

At a high level, I keep it practical and boring—because boring is resilient:

• Password manager: unique, long passwords everywhere; no re-use. We use a Privileged Access Management platform (Secret Server).
• MFA everywhere: preferably app-based or hardware-backed where possible; SMS only when there’s no alternative.
• Device hygiene: automatic updates, full disk encryption, screen lock, and minimal “admin by default.”
• Backups: a 3-2-1 mindset (multiple copies, different media, one offline/immutable where possible), plus the important bit: I test restores. Backups you can’t restore are just comforting fiction.
• Separation of concerns: I try not to do everything on one device/account. Convenience is the enemy of containment.
• Phishing resistance: I assume every unexpected message is lying until proven otherwise—especially anything pushing urgency or secrecy. And yes, we use physical tokens for phishing resistance.

In short, I design my personal setup like a small enterprise—lightweight controls that reduce blast radius and make recovery predictable.

What book, podcast, or resource has influenced how you think about leadership or security? (Doesn’t have to be technical.)

A few have shaped how I operate:

• “The Checklist Manifesto” (Atul Gawande): It’s a reminder that in complex systems, expertise isn’t enough—repeatable discipline wins. This heavily influences how I think about executable security programs.
• “Turn the Ship Around!” (David Marquet): Leadership as empowerment and intent, not bottlenecking decisions. Security fails when the CISO becomes the “Department of No” traffic controller.
• ACSC Essential Eight (as a practice, not a poster): I like it because it pushes you toward controls that matter in the real world—patching, application control, MFA, backups—things that survive hype cycles.

The theme across all of these: reduce reliance on heroics, increase reliability of outcomes.

What’s a lesson you learned the hard way in your career?

One of the hardest lessons: a control that no one owns is a control that doesn’t exist.

Early in my career, I saw organisations “implement” security in ways that looked great on paper—policies, tools, dashboards—yet fell apart under pressure because:

• ownership was unclear,
• operations couldn’t sustain it,
• exceptions were unmanaged,
• and the real environment drifted away from the intended design.

Now I’m almost stubborn about three things:

1. Who owns it?
2. How is it operated day-to-day?
3. How do we prove it works when it matters?

Security isn’t what you intend. It’s what you can repeatedly execute.

What keeps you up at night right now, from a security perspective?

I worry less about the headline threats and more about the quiet failures that stack up:

• Identity sprawl: too many privileges, too many paths, too little certainty about who (or what) can do what.
• Recovery confidence: “We have backups” is not the same as “We can restore fast, cleanly, and under pressure.”
• Third-party and supply chain exposure: organisations increasingly run on other people’s software and services—often without a clear view of inherited risk.
• Speed-induced fragility: cloud and automation are incredible, but if governance and engineering discipline lag behind, you get failures at scale.

The real concern is compounding risk—small unmanaged gaps that align into a bad day.

How do you measure whether your security program is actually working?

I try to measure security the way you measure fitness: not by owning gym equipment, but by what you can actually do when it counts.

I look for a mix of:

Operational effectiveness (can we execute?)

• Patch and vulnerability remediation performance (especially for known exploited pathways)
• MFA coverage and enforcement quality
• Backup restore testing outcomes and recovery time confidence
• Privileged access controls and reduction of standing privilege

Detection and response capability (can we find and contain?)

• Mean time to detect and mean time to respond
• Incident learning loops: did we reduce recurrence, or just write a post-incident document?

Risk reduction (did the attack paths shrink?)

• Reduced “blast radius” for critical systems
• Fewer high-impact single points of failure
• Stronger segmentation and containment

Program health (is this sustainable?)

• Clear control ownership
• Exception management that’s explicit, time-bound, and reviewed
• Evidence that controls are operating—not just configured

If all we have is activity metrics (tickets closed, training completed), we’re measuring motion, not outcomes.

What advice would you give to someone stepping into their first CISO role today?

I’d give five pieces of advice—practical, not romantic:

1. Get the mandate in writing (or at least agreed): What are you accountable for, and what authority do you have? A CISO without authority is a scapegoat in slow motion.
2. Start with the basics and make them real: Before chasing shiny capabilities, make sure patching, identity, backups, and access control are executable and measurable.
3. Build alliances, not empires: Security succeeds through engineering, operations, risk, and business leaders. You’re not building a castle—you’re strengthening a city.
4. Translate risk into decisions, not fear: Leaders don’t need more scary stories. They need clear options, costs, and trade-offs.
5. Design for sustainability: If your program requires exceptional people performing exceptional effort every day, it will fail. Build systems that average humans can run on a bad week.

And personally, protect your credibility. Spend it on what matters.

What do you think will matter less in security five to ten years from now?

A few things I expect to matter less—or at least matter differently:

• Perimeter thinking as the default model. Not because networks disappear, but because identity, device posture, and service-to-service trust become the real control plane.
• Security theatre dashboards. More charts won’t fix weak execution. Outcome-driven measurement will replace vanity metrics.
• “Tool-first” security programs. Buying another platform won’t save you if your patching discipline, access model, and operational ownership are broken. Tools will commoditise; execution will differentiate.
• One-time compliance as the finish line. My “Continuous Compliance” Framework sets up foundations – Continuous assurance and continuous control operation will win over annual “big-bang” audit energy.

(And I hope we finally stop treating security awareness as a yearly ritual and start treating secure behaviour as a product of system design.)

Looking ahead 10 years, what do you believe security teams will spend most of their time on that they don’t today?

I think security teams will spend much more time on governing autonomy and complexity—especially machine-driven activity:

• Identity for non-humans: Managing and securing service identities, workloads, APIs, bots, and AI agents will be “the new perimeter.”
• Continuous control enforcement (“policy as code” at scale): Controls won’t be documents; they’ll be guardrails embedded into build pipelines and platforms.
• Assurance of data and provenance: Knowing where data came from, how it moved, and what touched it will become central—especially with AI, automation, and regulatory pressure.
• Resilience engineering as a first-class discipline: Not just “prevent incidents,” but “assume compromise and recover fast,” with practiced, testable restoration and containment.
• Supply chain verification: Software and infrastructure will be increasingly assembled, not built. Security will focus on integrity, attestation, and trust frameworks.

In short: less time chasing alerts, more time building systems where compromise is contained and recovery is reliable.