“Compliance should be the natural result of a strong program, not the program itself.”
An audit tells you a control existed on the day someone looked. It doesn't tell you whether that control is working on a random Tuesday six months later. For Sean Bruton, that gap is where organizations get into trouble: they treat the assessment as the finish line, and they pour energy into what is being assessed while underinvesting in the systems around it, which is often exactly where an attacker gets in.
Bruton is Chief Information Security Officer at Illumia, which serves healthcare, higher education and senior living institutions, and he joined after more than 25 years in cybersecurity and compliance leadership, including as CTO of Zyston and co-founder of the compliance automation platform Complyify. In this conversation, he explains why having security capabilities is not the same as having a security program, how Illumia runs one program built to meet the most demanding client's expectations, and why a polished demo tells him little. He also describes what he wants from a proof of concept, why stability is part of security, how he builds a business case that earns backing beyond the security team, and what he wishes vendors understood about earning a CISO's confidence.
You’ve worked across security operations, compliance, product building, and technology leadership. What has that breadth taught you about the difference between having security capabilities and actually having a security program that works?
Early in my career, I assumed that if we had the right tools and processes in place, we were in good shape. Those capabilities are valuable, and you can’t defend against or respond to a threat without them. But I learned pretty quickly that having them isn’t the same as having them work together. A security program is designed around the outcomes we need to deliver for the business and for the clients who depend on us. It sets shared priorities, assigns clear ownership, and builds in the measures that let us manage security quantitatively. That way, we’re not just hoping our capabilities are working. We can see whether they are and adjust when they’re not.
You’re only a few months into the CISO role at Illumia. What are you trying to understand first about the existing security posture before deciding what needs to change?
I’ve been sitting down with leaders across product, engineering, operations, and the teams who work with our clients every day, and mostly I’m just asking questions. How do decisions really get made? What does a hard week look like for them? Where does security already show up in their work, and where does it feel like friction? You can get a handle on an environment’s technology fairly quickly. Learning the rhythm of the business takes longer, and it matters more. When security sits off to the side, people tend to navigate around it. When it’s part of how teams plan and work, managing risk just becomes how we operate. I’m lucky on that front. The people here have spent decades serving healthcare, higher education, and senior living, where protecting people’s information comes with the territory, so the instinct to prioritize security and privacy is already here.
Illumia’s customers span healthcare, higher education, and senior living, each with different regulatory and operational realities. Where do those differences make it hardest to build a consistent security posture?
We don’t run a different security program for each market. We run one, and it’s built to meet or exceed what the most demanding client in any of those industries would expect. Where the differences really show up is in how we work with clients on security. A hospital system is going to ask about HIPAA and want a business associate agreement. A university may be focused on FERPA and student data. A senior living community might care most about protecting residents and keeping services running without much IT support of its own. Each one has its own frameworks, its own questions, and its own way of engaging with us. Our job is to meet them on their terms and show how our program maps to what matters to them. The conversation changes from client to client; our operating program doesn’t.
You’ve worked deeply with PCI, NIST, HIPAA, HITRUST, and SOC 2. Where do organizations still confuse being compliant with actually reducing security risk?
Our clients are a pretty sophisticated group. Hospitals, universities, and senior living operators have lived with regulation for a long time, and they know a certificate on the wall isn’t the same thing as being secure. That’s why their questions go well beyond “are you compliant?” Frameworks like PCI, HIPAA, HITRUST, and SOC 2 are genuinely valuable. They give everyone structure and a common language. Where organizations get into trouble is treating the assessment as the finish line. An audit tells you a control existed when someone looked. It doesn’t tell you whether it’s working on a random Tuesday six months later. Scope is the other trap. Teams pour energy into what’s being assessed and underinvest in the systems around it, which is often exactly where an attacker gets in. Compliance should be the natural result of a strong program, not the program itself. If we’re managing real risk and measuring whether our controls hold up, the audits tend to take care of themselves.
Coming from the provider side, you know how different a polished demo can be from real deployment. What do you need to see from a vendor before believing its technology will work in your environment?
Having been on the other side of the table, I know how much work goes into a great demo, and I respect it. But a demo is built to show a product at its best, and our environment isn’t a demo environment. Like most organizations, we have legacy systems, integrations that grew over time, and data that never looks as clean as it does in a sales presentation. So I want to see the technology running against something real, even in a limited scope, with my own team at the controls rather than a sales engineer. I also want to talk to clients who look like us, ideally ones who’ve lived with the product for a few years and can tell me what happened after go-live. And I pay close attention to how candid a partner is about limitations. When someone tells me where their product struggles, I’m far more likely to believe them about where it shines.
Suppose two vendors address the same security gap, but one integrates better while the other offers stronger detection or automation. How would you weigh that trade-off given Illumia’s operational sensitivity?
It’s rarely as simple as picking the better feature set. Our clients rely on us for things that have to work every day, whether that’s a student getting into a residence hall, a patient getting the right meal, or a resident paying for services. In that kind of environment, stability is part of security. So I start with a practical question: what risk are we actually reducing, and what will it take to run this well over time? The strongest detection in the world doesn’t help much if it floods my team with alerts they can’t act on or adds fragility to systems our clients depend on. That doesn’t mean integration always wins. If the more capable tool closes a gap that really matters and the integration work is manageable, it can absolutely be worth it. But more often than not, I’d rather have a tool my team can run confidently than a more powerful one that struggles to fit.
If a security capability is important enough to protect Illumia’s critical workflows, what would you want to see during a proof of concept that a standard feature checklist or scripted demo would never reveal?
A checklist tells me what a product can do. A proof of concept should tell me how it behaves when things don’t go to plan. I want to see what happens when it runs into unexpected data, a network hiccup, or an integration it wasn’t designed around. Does it fail safely, or does it take something important down with it? I also want an honest read on the day-to-day effort: how many alerts it generates, how many are actually useful, and how long it takes my team to tune it. Updates matter too, because a tool that works on day one but disrupts operations every time it patches isn’t one we can rely on. And I watch closely how the partner’s team shows up when we hit a snag during the trial. That’s usually the best preview I’ll get of what the relationship will look like a year from now.
You’ve worked with organizations that need to justify security investments beyond the security team. What turns “we need this for security” into a business case that earns wider organizational backing?
“We need this for security” asks people to take our word for it. A real business case shows them what’s at stake in terms they already care about. For us, that means client trust, the commitments we make in our contracts, the reliability of services people use every day, and the cost of an incident weighed against the cost of preventing one. Being able to put numbers behind those things changes the conversation. I also try to show what an investment makes possible, not just what it prevents. Strong security helps our teams move through client reviews faster and gives clients the confidence to grow with us. The other piece is bringing business leaders in early, so the case reflects their priorities, too. And I’m candid about trade-offs. Leaders back security teams that are willing to say “This matters more than that,” because it shows we’re making the same kinds of choices they are.
After working on both sides of the security equation, your perspective on vendors is unusually informed. How has your approach to evaluating vendors changed, and what do you wish vendors understood about earning a CISO’s confidence?
Being on the provider side made me more empathetic and more demanding at the same time. I know how hard it is to build a product that works across hundreds of different environments, and I know the pressure sales teams are under. That also means I can usually tell when an answer is polished rather than true. Over time, I’ve put less weight on the pitch and more on what the relationship looks like after the contract is signed. How does a partner handle it when a vulnerability turns up in their own product? Does their roadmap reflect what clients are asking for? What I wish more providers understood is that confidence is built through consistency, not a single great meeting. Take the time to understand our business before you walk in. And if something breaks, I want to hear it from you first. That’s the moment trust is either earned or lost.
