Sovereign Cloud
Everything Bit2Bit runs for an institution sits on one platform: a separate tenant or private network for each institution, hosted in India, with logging, backup and exit designed in from the first day rather than bolted on before an inspection.
01 · Architecture
We keep the platform deliberately simple. Each layer can be inspected on its own, and each has a named owner on our side. An architecture diagram is not published on this page.
Compute, storage and networking in Indian data centres. Production, backup and archive copies are kept in separate locations.
Each institution gets its own tenant or virtual private cloud. Networks, databases and encryption keys are not shared between institutions.
Identity and single sign-on, logging, monitoring, backup, consent records and audit trails. These are common services, configured separately for each tenant.
Admissions, learning, examinations, results, credentials and records. Your existing systems, such as Samarth or Moodle, connect through documented integrations rather than being replaced by default.
02 · Isolation and residency
Shared multi-tenant databases are cheap to run and hard to explain to an auditor. We give each institution its own boundary, so the answer to "who else can see our data?" is short.
Your institution runs in its own tenant or virtual private cloud, with its own network rules, database instances and access policies. Larger institutions and state bodies can have dedicated infrastructure.
Student, staff and examination data is stored and processed in India. Where Indian law requires data to stay in India, it does not leave. You receive the data-residency statement in writing as part of the contract.
Data is encrypted at rest and in transit. Encryption keys are held per tenant, and access to them is logged. Whether an institution can hold its own keys is not stated on this page.
03 · Security controls
Role-based access, multi-factor authentication for all staff and administrators, and least-privilege defaults. Our own engineers reach production only through logged, time-bound access.
Private networking between services, firewalls at the tenant edge, and no administrative interfaces exposed to the public internet.
Regular patching, dependency scanning and periodic third-party testing. Findings and fixes are shared with the institution’s IT head on request.
We will list formal certifications here only once they are held and can be verified. None are listed on this page.
04 · Logging and incidents
The CERT-In Directions of April 2022 require ICT system logs to be kept securely for a rolling 180 days within Indian jurisdiction, and cyber incidents to be reported within six hours of being noticed. The platform is built around both.
Application, access, network and administrative logs are retained for at least 180 days on storage in India, protected from alteration, and available to you and to CERT-In when required.
Systems synchronise time to the sources CERT-In specifies, so log timestamps line up when an incident has to be reconstructed.
A written runbook names who decides that an incident is reportable, who files the report, and what goes in it. We rehearse it with your team. See the CERT-In guide.
05 · Backup, archive and exit
Immutable (WORM) backups on the 3-2-1 rule, a permanent archive for degrees and transcripts, and recovery drills that prove restores work. Details on the backup and archival page.
You can export your data at any time in documented, open formats such as CSV, JSON and PDF, with a data dictionary that explains every field.
Every contract includes an exit plan: a full export, a handover period, and certified deletion from our systems once you confirm the export is complete, except where the law requires us to keep records.
06 · What we do not do
Student data, answer scripts and proctoring recordings are not sent to third-party AI services. Where we use AI, such as exam proctoring, it runs on in-house models.
We do not move regulated data outside India, and we do not use overseas sub-processors for it.
We do not sell institutional or student data, use it for advertising, or combine it across institutions.
We do not publish uptime figures until they are measured and contracted. Support service levels are set in the contract, not on this page.
It runs in Indian data centres on infrastructure we operate or contract. Each institution gets its own tenant or private network, and data stays in India. Facility names and the hosting model are not published on this page.
Usually, yes. We integrate with systems such as Samarth and Moodle and replace them only when there is a clear reason to.
You receive a full export in open formats with a data dictionary, a handover period, and certified deletion once you confirm the export. This is written into the contract from the start.