Air-gapped & DPDP-first: sovereign SOC architecture for Indian enterprises

Abstract. Sovereignty in the Indian context is not a marketing position; it is a stack of overlapping legal and operational requirements that an enterprise must satisfy concurrently. DPDP Act 2023 governs personal-data handling and cross-border movement; CERT-In's directive imposes a six-hour incident-reporting clock; RBI, SEBI, IRDAI, and MeitY each layer sector-specific cyber-resilience obligations; and a meaningful fraction of defence, PSU, and BFSI workloads must operate inside an air-gapped network with no outbound connectivity at all. A platform that satisfies one of these constraints by accident usually breaks one of the others on purpose. This paper specifies the architectural primitives required to satisfy all of them simultaneously, and the deployment shapes that flow from those primitives.

1. The regulatory landscape, and what "data sovereignty" actually requires

The Indian regulatory perimeter is denser than is commonly understood outside the country, and it has tightened materially over the last twenty-four months. Five obligations dominate operational design.

1.1 DPDP Act 2023

The Digital Personal Data Protection Act establishes consent, purpose limitation, storage limitation, and breach notification as enforceable obligations. For the SOC, three consequences matter: personal data must be inventoried at field level, processing must be tied to a declared purpose, and a personal-data breach triggers a 72-hour notification to the Data Protection Board. The platform must therefore know, per event, whether the event touches personal data — which means the projector must classify at ingest, not at query time.

1.2 CERT-In's six-hour directive

The 2022 directive (and its subsequent clarifications) requires that a defined set of cyber incidents be reported to CERT-In within six hours of being noticed. The clock is short by global standards; it does not pause for triage and it does not wait for a confirmed root cause. The platform must therefore be able to assemble, on demand, a regulator-grade incident packet — entity inventory, timeline, indicators, scope — within the first hour, so that the remaining five hours can be spent on validation and submission rather than on data gathering.

1.3 RBI cyber-resilience framework

Reserve Bank guidance for regulated entities (and the cyber-resilience framework for market infrastructure) imposes obligations around continuous monitoring, root-cause analysis, board-level reporting, and supply-chain risk. The SOC must produce evidence at three cadences — real-time (active incidents), monthly (board pack), and annual (independent assurance) — and the evidence must be derived, not curated by hand.

1.4 SEBI CSCRF, IRDAI, MeitY

The SEBI Cybersecurity and Cyber Resilience Framework imposes graduated obligations on market participants by category, with mandatory ISO and SOC-2 alignment. IRDAI's information-and-cybersecurity guidelines extend equivalent obligations to insurance entities. MeitY's empanelment criteria and the broader IT Rules layer further requirements on platform providers themselves. The cumulative effect is that a single deployment must, in practice, generate evidence aligned to four to six concurrent frameworks.

1.5 What sovereignty therefore requires

Putting the five together yields five non-negotiable architectural properties. First, all personal data must remain within Indian jurisdiction by default, with cross-border movement disabled unless explicitly authorised. Second, the platform must be operable without any outbound connection — no phone-home, no licence check, no model call. Third, every piece of evidence the regulator may demand must be derivable from the graph, not assembled by hand. Fourth, key material must be tenant-owned and tenant-revocable, so that data destruction is a cryptographic operation rather than a deletion request. Fifth, the same codebase must run in commercial, on-prem, and air-gapped modes, because customers move between modes over time and the platform cannot fork.

2. Architectural primitives for air-gap

An air-gapped deployment is, in operational terms, a network with no outbound connectivity and tightly controlled inbound. The conventional consequence is that any platform component that assumes outbound network access — for licence validation, for telemetry, for model inference, for threat-feed updates, for software updates, for anything — becomes unrunnable. The architectural answer is to make every such dependency optional and locally satisfiable.

2.1 Internal mirror service

The platform ships with an internal mirror service whose job is to hold, locally, every artefact the platform would otherwise pull from the public internet. The mirror has three populations: container images and binaries; threat-feed and detection-content updates; and reference corpora for the embedded models. Each population has a defined update protocol — typically a signed bundle delivered on a removable medium, validated against an air-gap-friendly trust root, and applied with a documented rollback. The mirror is the single inbound channel, and it is auditable down to the bundle.

2.2 No phone-home, by construction

The platform's outbound surface is empty by default. Telemetry is disabled, licence validation is local, and there is no call-home for diagnostics. Where outbound is required — almost never, in our experience — it is explicit, named, and gated by configuration that the tenant administrator must set. A platform that ships with outbound enabled and asks the customer to disable it is the wrong shape for sovereign deployment; we ship with it disabled and ask the customer to enable it if they need it.

2.3 Offline corpus

The reasoning components that would otherwise depend on the public internet for context — threat intelligence, technique catalogues, regulator templates, software-bill-of-materials lookups — operate against an offline corpus that ships with the platform and is updated through the mirror. The corpus is versioned, signed, and queried locally; the air-gapped deployment knows exactly what it is reasoning against, and can produce a manifest on demand.

2.4 In-cluster language model

The agent layer's language model runs inside the cluster. No request leaves the perimeter. Model weights are part of the air-gap bundle; inference is performed on tenant-owned hardware; prompts and completions are logged into the same audit channel as every other agent call. This is the single largest architectural difference between a sovereign-capable platform and a commercial one, and it is not a bolt-on — the agent layer's retrieval boundary was designed to be model-agnostic for exactly this reason.

// Air-gap default configuration (conceptual)
outbound:
  default: deny
  named_exceptions: []
mirror:
  bundles: [images, content, corpora, model_weights]
  trust_root: tenant_owned_pki
  ingress: signed_removable_only
model:
  runtime: in_cluster
  weights: from_bundle
  external_calls: forbidden
telemetry:
  enabled: false
licence:
  validation: local_signed_token

3. Per-tenant key management and crypto-shredding

The DPDP Act treats data destruction as an enforceable obligation. In a platform that stores months of telemetry, destruction by deletion is operationally painful and forensically suspect — it is hard to prove that every replica, every backup, every index segment has been purged. The architectural answer is to make destruction a key operation rather than a data operation.

3.1 Tenant-owned root keys

Each tenant has a root key that is held in tenant-controlled key material — an on-premises hardware security module, or a software vault under the tenant's exclusive operational control. The platform never sees the root; it receives derived keys, rotated on a schedule the tenant sets. Loss of access to the root makes the tenant's data cryptographically unrecoverable; this is by design, and it is what makes the platform safe to host inside a regulated tenancy.

3.2 Per-domain derived keys

Below the root, derived keys are scoped to data domain — personal-data-bearing telemetry, code artefacts, secret-store contents, network metadata, and so on. The graph carries the domain classification on every edge, so the encryption boundary is enforced at write time rather than inferred at read time. Domain-level keys can be rotated or revoked independently; revocation of a domain key is, in effect, the destruction of that domain's data.

3.3 Crypto-shredding

The DPDP-mandated right to erasure, the CERT-In requirement to preserve evidence, and the operational need to age data out of expensive storage are reconciled through crypto-shredding. To destroy a class of data, the tenant revokes the corresponding derived key; the underlying ciphertext remains, becomes unreadable, and ages out of storage through the platform's normal retention policy. A signed shred certificate is produced, naming the domain, the key generation, the time of revocation, and the affected record counts. Regulators receive a cryptographic proof of destruction; auditors receive a derivation chain that is easier to verify than a deletion log.

Operation	Conventional approach	Crypto-shred approach
Right-to-erasure request (DPDP)	Locate and delete across all replicas; difficult to prove	Revoke domain key; signed shred certificate; ciphertext ages out
Tenant offboarding	Destroy storage volumes; multi-week process	Revoke tenant root; complete in minutes; verifiable
Regulatory hold conflict (preserve vs. erase)	Operational impasse	Hold ciphertext under regulator's seal; revoke key only after hold lifts
Forensic recovery after revocation	Possible if backups remain	Impossible without re-issuing key; matches DPDP intent

4. Regulator-ready evidence packs

The regulator does not want a database export; the regulator wants a packet — a specific set of facts, in a specific shape, in a specific format, on a specific clock. The platform's job is to produce that packet on demand, from the graph, without curation. The evidence pack is the deliverable; the graph is the substrate.

4.1 CERT-In templates

The CERT-In incident-reporting templates have a fixed structure: incident class, time of detection, time of occurrence, affected systems, indicators of compromise, containment actions, root-cause analysis (where available within six hours), and contact information. The platform binds each field to a graph query whose result is the field's value. When the analyst initiates a CERT-In submission, the packet is assembled, presented for review, and submitted with the analyst's signature. The graph queries are logged; the packet's pedigree is queryable later.

4.2 DPDP 72-hour notification

A personal-data breach triggers a 72-hour notification to the Data Protection Board and, where applicable, to affected principals. The platform's projector classifies events as personal-data-bearing at ingest, so the breach scope is a graph query — every personal-data edge touched by the incident sub-graph, deduplicated by data principal. The notification packet enumerates the principals, the data categories, the likely consequences, and the mitigation steps, and is timestamped against the discovery clock.

4.3 Cross-framework reuse

The same graph generates evidence for GDPR (where Indian entities serve EU principals), HIPAA-equivalent obligations (for healthcare workloads), ISO 27001 control families, SOC-2 trust criteria, and the sectoral frameworks named earlier. The economy comes from sharing the substrate: a single ingest, a single classification pass, and many derivative packets.

// Evidence pack generation (conceptual)
incident_id = "inc-2026-04-…"
scope = graph.query("""
  MATCH (i:Incident {id:$id})-[:TOUCHES]->(e)
  RETURN e
""", id=incident_id)

pack = EvidencePack(template="CERT_IN_v3")
pack.bind("incident_class",         classify(scope))
pack.bind("time_of_detection",      incident.detected_at)
pack.bind("affected_systems",       graph.distinct(scope, type="Workload"))
pack.bind("indicators",             graph.iocs(scope))
pack.bind("containment_actions",    response.actions_for(incident_id))
pack.bind("root_cause_summary",     incident.root_cause_or_unknown())
pack.sign(analyst, ts=now())
pack.submit_to("CERT-In")

5. Deployment shapes on the same codebase

A platform that ships three codebases — one for commercial cloud, one for on-prem, one for air-gap — ships none of them well. Drift sets in within a release cycle, parity claims become aspirational, and the air-gapped customer is, by month six, on a fork that the rest of engineering has forgotten about. The discipline that makes sovereign deployment sustainable is single-codebase by construction.

5.1 On-prem single-organisation

The simplest shape: the platform runs inside the customer's data centre, the customer holds the keys, and outbound is permitted for software updates and model corpora over a controlled egress proxy. This shape is appropriate for organisations that want sovereignty over data residency but accept managed updates over the network. Operational overhead is low; the customer's team operates the cluster but does not run the mirror.

5.2 Air-gapped

The strictest shape: no outbound at all, mirror operated by the customer, model weights and corpora delivered as signed bundles on a defined cadence. Appropriate for defence, classified PSU, and the most regulated BFSI workloads. Operational overhead is highest here — the customer's team takes on bundle management — but the platform's behaviour is identical to the on-prem shape minus the egress paths.

5.3 MSSP / multi-tenant sovereign

An MSSP operating from inside Indian jurisdiction, serving multiple customer tenants, each with their own key material and their own evidence-pack cadence. The platform supports this with tenant-level isolation at the graph layer (every node and edge carries a tenant identifier; queries are tenant-bound; cross-tenant queries require explicit MSSP-operator authority and are logged). The MSSP shape is operationally similar to commercial multi-tenancy, with the additional discipline that each tenant's key material lives in their own HSM domain.

Deployment shape	Outbound	Key material	Updates	Suitable for
On-prem single-org	Egress proxy, named destinations	Customer-held HSM	Pull over egress proxy	Regulated enterprise, sovereign cloud
Air-gapped	None	Customer-held HSM	Signed bundles, removable media	Defence, classified PSU, top-tier BFSI
MSSP / multi-tenant sovereign	Egress proxy per MSSP policy	Per-tenant HSM domain	Pull, propagated per tenant	India-resident MSSPs, sector-specific operators

6. What this means for procurement and audit

Two practical observations from deployments over the last eighteen months. First, audit cost falls sharply. A regulator-ready evidence pack derived from a graph is, in practice, easier to defend than a curated artefact assembled by hand — the auditor can re-run the query, follow the retrieval log, and verify the derivation. Second, procurement timelines compress when the platform answers sovereignty questions with documented architecture rather than commercial commitments. The DPO, the CISO, and the CIO are answering different questions; the architecture answers all three.

6.1 The CISO question

"Will the platform operate when the network is severed?" Answered by the in-cluster model, the offline corpus, and the mirror service. Demonstrable in a test cell with the cable physically removed.

6.2 The DPO question

"How do we satisfy DPDP erasure?" Answered by crypto-shredding plus the signed shred certificate. Demonstrable in a tenant-onboarded sandbox.

6.3 The CIO question

"How do we keep the platform updated without compromising the perimeter?" Answered by the mirror bundle cadence and the signed-bundle trust root. Demonstrable in the customer's own update workflow.

7. What we are not claiming

We are not claiming that sovereignty is free. Air-gapped operation has real overhead: the mirror has to be operated, the bundles have to be managed, the in-cluster model is more expensive to run than a hosted call. We are not claiming that every customer needs the strictest shape; many will find the on-prem single-organisation shape sufficient. And we are not claiming that a platform with these properties replaces a competent regulatory team — the platform produces evidence; the team interprets and submits it.

What we are claiming is that sovereignty in the Indian context is achievable on a single codebase, with documented architectural primitives, against the regulatory perimeter as it stands in mid-2026. Deployments under that perimeter should not require a bespoke fork, and they should not require the customer to choose between regulatory compliance and product capability.

About this paper

Authored by Autocops Desk — the Netgraph practitioner team. First published 30 April 2026. Confidential to recipient.