Security and data governance
Trust is part of the architecture. A digital twin should only know what it needs to know, and a system should only reach what it is authorised to reach.
Responsible digital twins
Four rules that apply to every Helix, ViSE and MTRX design.
Only what it needs
A digital twin should only know what it needs to know. Data is minimised to the use case.
Only what is authorised
A system should only access what it is authorised to access, with roles and permissions.
For a defined purpose
Data is used for a stated purpose, and a new purpose needs a new decision.
Understood by people
People can see how their information is used, and institutions have clear governance boundaries.
Governance controls we design for
Each control is specified in the technical design of a deployment. Capabilities are described by what is actually implemented there.
| Control | What it means | How it is confirmed per deployment |
|---|---|---|
| Data ownership | The customer or institution owns its data; iViRTH processes it for the agreed purpose. | Stated in the project agreement; data-ownership map in the technical design. |
| Consent | Where personal data is used, consent or another lawful basis is recorded. | Consent route and records defined per use case. |
| Access control | Role-based, least-privilege access to data and administration. | Roles and permissions matrix; access reviews. |
| Encryption | Data is encrypted in transit and, where stored, at rest. | Stated for each data store and link in the design. |
| Identity separation | Identity data (Helix) is kept apart from measurement data (ViSE) and analytics outputs unless a use case needs them linked. | Data-flow diagram and linking rules. |
| Data minimisation | Collect the minimum; prefer aggregate and non-identifying measures. | Data inventory and privacy review before go-live. |
| Retention and deletion | Each data class has a retention period and a deletion route. | Retention schedule; deletion tested at close-out. |
| Auditability | Significant access and changes are logged where implemented. | Logging scope and retention stated. |
| Institutional controls | Institutions set policy for their users, and can restrict what is shared. | Admin and policy settings defined with the customer. |
| Child and minor safeguards | Extra protections where learners under 18 are involved. | See the children and minors policy. |
Helix owning the canonical twin model does not mean every sensor reading is stored in Helix. Each technical design defines data ownership, event transport, storage, APIs, permissions and retention explicitly.
How this website is protected
Plain facts about ivirth.in, not marketing.
- A static website: no visitor accounts, no database of visitor data and no payment processing.
- Delivered over HTTPS with a single canonical host (www redirects to ivirth.in).
- Security headers: X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, X-Frame-Options SAMEORIGIN and a Permissions-Policy that disables camera, microphone and geolocation.
- Fonts and videos are served from ivirth.in itself, with no third-party trackers or embeds.
- A published security.txt for reporting issues.
See the cookie notice for what the site does and does not store in your browser, and the privacy notice for how enquiry data is handled.
In pilots and deployments
Security and privacy are scoped at the site-assessment stage.
Assess
Data types, who is affected, lawful basis, connectivity and hosting location are identified during the site assessment.
Design
Roles, data flows, encryption, retention and audit logging are written into the technical design.
Pilot
The pilot runs with the agreed controls and a named contact for incidents.
Close-out
Data is retained, returned or deleted as agreed, and the close-out summary records what changed.
Data residency, private deployment and customer-controlled environments are options we scope per project. They are not blanket statements about every deployment.
Report a vulnerability or incident
Tell us first, and we will respond.
Email hello@ivirth.in (see security.txt). Include steps to reproduce and the affected URL. Good-faith research is welcome under the terms of our responsible disclosure policy.
If a personal-data breach occurs, we will assess it, contain it, notify affected people and the authorities as the law requires, and tell the customer involved in a deployment under the agreed timeline. Cyber-security incidents are reported to CERT-In as required.
What we do not claim
We do not claim any security certification, audit result or standard compliance on this website. If and when iViRTH holds one, we will name it with its scope and date. Absolute claims such as "fully secure" are not used.
Discuss data governance for your pilot
Tell us who and what will be connected. We map it to the right controls before anything is installed.