Three questions a hospital CISO should ask a healthcare fintech vendor

Three questions a hospital CISO should ask a healthcare fintech vendor In this Help Net Security video, Drew McCombs, CTO and CISO at Cylerity, explains how he balances both roles. Security work is scheduled into every sprint, and issues touching patient data or funds disbursement come first. He covers how Cylerity keeps PHI away from its bank partner, why AI models recommend but never act, and why turning on MFA for email is the cheapest fix for small practices. He also lists three questions a hospital CISO should ask a fintech vendor, and the answer that should end the talk. You hold both the CTO and CISO titles. When the roadmaps compete, who wins? How do you keep yourself honest? I often find that these two roadmaps align well, and I don’t treat them as independent backlogs. Security is a core feature that is never complete, and it’s scheduled into every sprint so we keep making progress on key projects. It’s also discussed across the entire engineering team, which keeps it front of mind through all development instead of being something that comes after. Additionally, our SDLC requires a full security scan of all development, and we keep investing in our foundation so we can deliver quickly without taking on new risk. This approach means most conflicts are handled before planning, and we have full visibility into our plan each sprint. But when we have to choose, it’s clear: if an issue affects patient data or funds disbursement, it wins. Period. Beyond that, we balance feature delivery against steady progress on our core security initiatives. Holding both titles does require visibility and accountability for progress on core security projects. That’s why they’re tracked and reviewed with leadership on a regular basis, so it’s clear what’s happening and when. That way, I’m not the only one making the call, and security is treated with the appropriate urgency. Where do HIPAA and banking expectations contradict, and how do you resolve it? It’s important to start with what Cylerity is and isn’t. Cylerity isn’t a bank and it does not factor receivables. We fund healthcare organizations using a bank credit facility, and we serve only businesses, not consumers. This means many of the core banking regulations don’t apply to us directly. Instead, the bank’s expectations reach us through our credit agreements and our partner bank’s diligence, which includes reviewing who our customers are, how funds are moved, what we report, and what they can audit. That sits well with HIPAA, but the area that gets complicated is collateral. We lend against healthcare claims, and claims contain patient information (PHI). When the bank wants to discuss a customer’s borrowing base, it’s often helpful to get down to the line level, and that’s where we take a specific plan to make sure we’re not exposing PHI to the bank. Here’s our approach. First, we always work with the minimum data required to support our customers. That usually means providing summarized information at the payer or customer level, with claim-level details removed. Second, if we need to get down to the line level, we don’t expose claim identifiers. We build our own unique identifiers for when we need that level of detail, so PHI stays protected. Finally, across the platform we keep PHI separate from the data needed for financing. That’s how we answer every data request, including our lending partners. What’s the one control you’d insist on before a model touches money or patient data? For me, it’s simple: the model doesn’t act. AI can recommend, summarize, or flag, but a person is always in the loop between its output and anything that releases funds or exposes patient data. We bring these insights into our underwriting and monitoring so our team has more information to make informed decisions, but the decision stays with our team. Explainability is what makes that control work, but it isn’t the control itself. A reviewer can’t meaningfully approve something they don’t understand. So when a model surfaces a recommendation, it shows the source data it relied on, and our team checks against that source, not against the model’s own explanation. A model describing its own reasoning isn’t evidence. The risk I watch most closely isn’t a dramatic attack. It’s gradual drift, where a reviewer approves the first hundred recommendations carefully and then starts rubber-stamping. We address that by involving multiple people in decisions and regularly reviewing decisions after they’re made. What’s the most common weakness when onboarding a small practice, and the cheapest fix? The most common weakness isn’t unique to small practices. It’s not unique to any business at all. MFA continues to be one of the most important controls, and it’s still underused. It’s especially important for the organizations we work with. They were built to deliver care and services, not to run IT, and many are handling patient data and healthcare payments for the first time. That’s why the cheapest fix is also the most impactful: turn on MFA, starting with email. It’s usually already included in the email service they’re paying for. It’s table stakes, and closing that one gap shuts down the most common path to account takeover and payment fraud. Our role goes beyond recommending it. Because we support our customers’ day-to-day revenue cycle, we see their claims and funding activity as it happens. That gives us the opportunity to spot activity that doesn’t fit their normal pattern faster than a small team could on its own. Additionally, when a deposit account change comes in, we confirm it by phone using a number already on file, never one provided in the request. What three questions should a hospital CISO ask a fintech vendor, and which answer should make them walk away? First, “Can you list every party that touches our data, including subprocessors, AI services, and any financing partners or their auditors?” If a vendor can’t produce that list quickly, they don’t know where your data goes. It’s important to remember that a fintech’s lenders may have audit rights over records that contain your patients’ information, and you should know that before you sign. Second, “How do you verify a change to where funds are sent?” For a fintech vendor, payment redirection is the attack that costs real money. You want to hear about an out-of-band confirmation step that no one can skip, not “we review requests carefully.” Finally, “Walk me through the first 24 hours after you discover a breach involving our data. Who calls whom?” You’re looking for names, roles, and timing, not a policy document. The answer that should end the conversation is “We’re HIPAA certified.” There’s no official HIPAA certification, so that answer tells you the vendor either misunderstands the rule or is counting on you not to know. Webinar: Closing the accountability gap in AI-assisted delivery