As healthcare rapidly embraces AI, cloud platforms, connected medical devices, and digital patient services, cybersecurity has become inseparable from patient safety. Protecting sensitive health data today requires more than compliance—it demands security that is architected into every layer of the technology stack from the very beginning. In this conversation, Ayush Jain, CEO and Co-founder of Mindbowser, shares how the company has embedded security-by-design across more than 250 healthcare technology deployments. He discusses the realities of building zero-trust architectures, securing complex healthcare ecosystems, ensuring audit-ready data lineage, and preparing organisations for India’s evolving Digital Personal Data Protection (DPDP) regime. Ayush also explains why resilience, governance, and proactive engineering will define the future of secure digital healthcare.
CEO and Co-founder
Mindbowser
CISO Forum: Mindbowser has executed over 250 healthcare builds with a team trained in HIPAA and FHIR. From an engineering standpoint, what does ‘security-by-design’ actually mean at the architecture stage? What specific decisions get made before a single line of code is written?
Ayush Jain: “Security by design” means security decisions are made before product decisions, not alongside them. On every build, before a line of code is written, we’re deciding three things: where PHI physically lives and whether it ever needs to leave that boundary; what the blast radius looks like if a single service is compromised; and which person or service actually needs to see identifiable data versus a token. This is why zero trust isn’t a bolt-on for us — it’s written into our delivery process. Nothing is trusted by default, not even traffic inside our own network, until it’s verified. If a team is debating encryption strategy after the data model is finalised, the architecture stage has already passed them by.
CISO Forum: You’ve said bolt-on security fails specifically in healthcare. Can you walk through a concrete example of how retrofitted controls can create blind spots when EHRs, wearables, and IoT devices all feed data into the same platform?
Ayush Jain: We recently led a cloud migration for a healthcare platform running EHR, telemedicine, and billing on legacy infrastructure — roughly 180 databases and 30 terabytes of sensitive data that had to be migrated without a single record slipping through the cracks. What made that migration secure wasn’t a control we added afterwards. It was that every database went to Amazon RDS with encryption and Multi-AZ built in from the first design decision, and every third-party authentication path — the client’s existing Azure AD, other systems that needed VPN tunnelling — was mapped and secured as part of the architecture, not patched in once something broke. If you build the pipeline first and think about security later, the “boring” data is exactly what slips through: the feed from a device, the legacy auth system nobody flagged as sensitive. Nobody asked the question early enough.
CISO Forum: Threat modelling at the architecture stage sounds straightforward in theory but is hard in practice for complex, interoperable health systems. How do you actually scope a threat model when the attack surface includes third-party devices and external EHR integrations you don’t fully control?
Ayush Jain: Where most teams go wrong is trying to threat-model every system at the same depth; the result is a document no one actually reads. We instead draw the trust boundary explicitly. Anything we don’t operate ourselves — a third-party EHR, a legacy authentication provider, a device SDK — is treated as adversarial input by default, not as a trusted partner. That’s the underlying premise of zero-trust architecture. On that same migration, it meant securing every connection point explicitly — Site-to-Site VPN, Route 53, load balancers — rather than assuming a system was safe simply because it was already integrated. We model the interface, not the internals of a system we don’t own: what it can send us, what happens when the payload is malformed, and what happens if it goes silent. Across 250+ builds, this is the only version of threat modelling that has actually scaled.
CISO Forum: Encryption and least-privilege access “as defaults” is the principle — but what does enforcing that look like operationally across 200+ engineers working on different builds? How do you prevent default standards from quietly eroding as projects scale or deadlines tighten?
Ayush Jain: Saying “secure by default” is easy. Holding that standard across 200+ engineers working on different builds under different deadlines is the hard part — and it doesn’t survive on documentation alone. What actually works is removing the choice altogether. On our AWS builds, encryption at rest through AWS KMS and access scoping through IAM aren’t decisions left to an individual engineer’s judgment on a given project; they’re built into how we provision infrastructure from the outset. Paired with a continuous, audited compliance posture rather than an annual checkbox exercise, the standard no longer depends on any one engineer remembering to do the right thing on a Friday before a release.
CISO Forum: You mention audit-ready data lineage as a core design requirement. Technically, what does it take to build a system where every data flow can be traced and explained after the fact, without that traceability becoming a performance or latency burden?
Ayush Jain: Audit-readiness is not the same as logging everything — that’s the assumption that quietly kills performance. Capturing every transaction only adds overhead. The better approach is to design traceability into the architecture itself, so every piece of sensitive data carries a record of where it originated, which service processed it, who accessed it, and where it went next. Modern monitoring and observability tools make this possible without slowing the application down, because the tracking runs alongside the workload rather than sitting in the critical path. When lineage is designed in rather than reconstructed later, it earns its keep well beyond an audit: it helps engineering teams troubleshoot and respond to incidents far faster.
CISO Forum: DPDP’s breach-notification and significant-data-fiduciary obligations are pushing security into board-level conversations. From an engineering team’s perspective, how do these regulatory requirements actually change what gets built differently compared to, say, HIPAA-only compliance?
Ayush Jain: HIPAA governs data protection primarily through access control — who is permitted to view or handle data, and whether that access can be justified after the fact. India’s DPDP Act, under the Rules notified in November 2025, adds a sharper, more time-bound obligation on top of that. The breach-notification clock starts the moment an organisation “becomes aware” of a breach, not when it finishes its investigation — and it’s a two-stage duty: a detailed report to the Data Protection Board within 72 hours, plus notification to every affected individual. Unlike GDPR, there’s no materiality threshold to hide behind; if individuals are affected, they have to be told. For entities classified as Significant Data Fiduciaries, the Rules also establish a concrete expectation of annual independent audits and demonstrable governance — evidence of active compliance, not policy documentation that exists only on paper.
This turns detection and monitoring from a compliance afterthought into a first-class engineering requirement. It’s the same principle we apply across our builds: real-time monitoring designed into the system, not added after the fact. A system that can’t quickly and precisely identify what data was accessed or altered cannot realistically meet a 72-hour clock. That’s a materially higher bar than HIPAA on its own.
CISO Forum: Healthcare breaches carry a patient-safety dimension that most other sectors don’t — a compromised system can disrupt actual care delivery, not just expose data. How does that risk change your engineering priorities around redundancy, failover, and system availability compared to a standard data-security build?
Ayush Jain: The question we ask isn’t “Can we prevent every attack?” It’s “Can care continue if something goes wrong?” — a very different engineering mindset. In healthcare, systems have to absorb failures without interrupting clinical workflows, which means redundancy, automated failover, and recovery procedures built in from day one rather than assumed. Concretely, that’s patterns like Multi-AZ deployment so a single-zone failure doesn’t take the platform down, health-checked failover that reroutes automatically rather than waiting for a human, and recovery procedures we’ve actually rehearsed rather than only documented. Security protects patient data; resilience protects patient care. In healthcare, you need both.
CISO Forum: With healthcare accounting for roughly a fifth of all cyberattacks in India last year, which attack vectors are you seeing most frequently in the field right now, and have they shifted the kind of security work Mindbowser is being asked to do?
Ayush Jain: Healthcare draws such a large share of attacks because it pairs high-value patient data with unusually complex digital ecosystems — legacy systems, cloud platforms, connected devices, and third-party apps, all at once. Phishing and credential theft remain the most common entry points. Still, we’re seeing a clear rise in attacks targeting APIs, integrations, and connected medical devices, where controls are often the least mature. That’s changed the conversations we have. Where clients once asked us to secure a specific application, they now want the whole ecosystem assessed — integration layers, vendor connections, device communications — end-to-end, not system-by-system.
CISO Forum: 2026 is shaping up as the build-and-test year before DPDP enforcement begins in earnest. What’s the biggest technical gap you’re seeing in Indian healthcare platforms today that organisations need to close before enforcement starts?
Ayush Jain: If I had to pick one priority, it’s understanding your own data — you can’t protect what you can’t see. Plenty of healthcare organisations have invested in digital transformation, but far fewer have mapped where sensitive patient data resides, how it moves between systems, and who can access it. That map is the foundation for everything else: breach response, consent management, audit readiness. And the clock is real. The substantive DPDP obligations — breach notification, security safeguards, and Significant Data Fiduciary duties — commence in May 2027, making 2026 the year to build and test, not to wait. For hospitals, the pressure is sharper still: where CERT-In directions apply, the first reporting clock can start at six hours, not seventy-two. The organisations that map their data now will meet that deadline as a formality. The ones that start in 2027 will meet it as a crisis.
