Security & Privacy
Security as Operating Posture, Privacy as Obligation
The threat environment Fluxion operates in
Port infrastructure is critical national infrastructure in any country that depends on seaborne trade, and India’s major ports handle cargo volumes that make them targets for state-level and criminal threat actors. The convergence of operational technology (OT) systems — the programmable logic controllers, SCADA systems, and industrial control systems that operate cranes, gates, and cargo tracking infrastructure — with the IT systems that manage logistics data creates an attack surface that did not exist in previous-generation port operations.
Clinical data is among the most sensitive personal data that exists. ETOH’s hospital operating system will handle patient records, diagnostic data, clinical notes, and treatment histories at scale across multiple hospital facilities. The regulatory environment governing this data is evolving — India’s Digital Personal Data Protection Act 2023 establishes a framework for data fiduciaries that imposes specific obligations on entities like Fluxion — and the ethical obligations exceed the legal requirements in ways that matter for how Fluxion designs its systems.
OT and industrial systems security
The security architecture for Fluxion-operated port and industrial systems must treat OT and IT as fundamentally different threat surfaces requiring different controls, and must resist the pressure — common in industrial modernization projects — to converge them prematurely in pursuit of data integration benefits.
Fluxion’s core OT security principles are: network segmentation between OT and IT environments as a hard requirement, not a soft recommendation; zero-trust access models for any connection between OT systems and external networks; supply chain verification for automation components, with documented provenance for any hardware or software component that has control over physical systems; and anomaly detection that can identify deviations from baseline operational patterns that may indicate compromise, including subtle deviations that would not trigger conventional intrusion detection.
OT security incidents at industrial facilities have historically caused physical damage, environmental harm, and in some cases casualties. Fluxion will treat a cybersecurity failure in an OT environment as a safety incident, not merely a data incident, and will apply the same hierarchy of controls — eliminate, engineer, override, protect — that governs physical safety.
Patient data and the ETOH privacy framework
ETOH’s privacy framework begins with a principle of data minimization: the system should collect and retain only the patient data that is necessary for the clinical and operational functions it performs. This is more restrictive than collecting everything that might be useful and deciding later what to do with it — an approach that is common in health IT and that consistently produces privacy problems downstream.
Purpose limitation.
Patient data collected for clinical care must not be used for purposes the patient was not informed of at the time of collection. This includes using clinical data for commercial analytics, product development, or any use beyond the direct care relationship and the operational functions necessary to support it. The boundary between legitimate operational use and commercial use of patient data is one Fluxion will draw conservatively.
Data sovereignty in the Indian healthcare context.
Patient data generated in Indian healthcare facilities is subject to Indian regulatory jurisdiction and must be stored, processed, and governed accordingly. Fluxion will not architect ETOH in ways that route Indian patient data through jurisdictions that would subject it to foreign regulatory or legal access without patient notice and consent. This is not merely a compliance requirement — it reflects a substantive position that patients’ health data should be governed under the legal framework of the country where their care is delivered.
Breach transparency.
In the event of a breach or unauthorized access to patient data, Fluxion’s default is disclosure to affected patients and to relevant regulatory authorities on the timeline required by law and, where law is silent, promptly. We will not allow legal uncertainty about disclosure obligations to delay notification where we have reasonable confidence that patient data has been compromised. Patients whose data has been exposed have a right to know, and timely disclosure is necessary for them to take protective action.
Clinical AI model governance.\
Models trained on patient data carry privacy obligations that persist after training. Fluxion will maintain documentation of what patient data was used to train ETOH’s clinical models, under what consent framework, and will have a defined process for responding to requests by patients or institutions to remove their data from training pipelines. The right of data principals under India’s DPDP Act to withdraw consent and to have their data erased is a real operational requirement, not a theoretical one.
Security as a design property, not a feature layer
The most expensive and least effective approach to security is to build systems first and add security controls afterward. Fluxion’s position is that security requirements must be specified as design inputs, not implementation afterthoughts, for both its industrial automation and clinical technology platforms. This means security review at the architecture stage, threat modeling before development, and penetration testing before deployment — not after.
The same principle applies to the vendors and technology partners Fluxion works with. Third-party components — automation hardware, cloud infrastructure, clinical data integrations — carry their own security postures that become part of Fluxion’s attack surface. Fluxion will apply security diligence to its supply chain commensurate with the access that supply chain participants have to Fluxion’s systems and the data those systems hold.
