Chapter 15 — Cybersecurity, Digital Public Infrastructure & Citizen Tech

The principles and institutions of digital rights — Citizen Data Trust, AI-Use Register, Grievance Justice Authority, the four binding tests — live in Vol…

Read this chapter in the interactive reader, or download the full 601-page manifesto (PDF).

---

The People’s Model

Manifesto v2026

Volume II — Sector Blueprints

Chapter 15

Cybersecurity, Digital Public Infrastructure & Citizen Tech

Digital government must be secure, private, inclusive — and operational every hour.

Where this chapter sits

The principles and institutions of digital rights — Citizen Data Trust, AI-Use Register, Grievance Justice Authority, the four binding tests — live in Vol I Chapter 6. This chapter owns the DELIVERY: defensive cybersecurity, the Digital Public Infrastructure stack, the open public datasets, and the citizen technology layer that runs on top of the spine. A reader who wants to know what rights they have should land in Vol I Ch 6. A reader who wants to know how those rights are operationally protected should land here. The 18 program design sheets live in Vol III Appendix H, sheets H.145–H.162.

15.1 Problem Snapshot

Digital governance expands the attack surface. Without serious cybersecurity, the operating spine becomes a single point of failure for fraud, identity theft, ransomware, and politically motivated leaks. Without operational digital public infrastructure, every department reinvents identity, payments, signing, and storage in incompatible silos — and the resident gets stuck navigating the seams.

• Karnataka’s departments today vary widely in security posture. Many run on outdated stacks, with inconsistent patching and incident response.
• Vendor and contractor systems are a particular weak link — outsourcing the system does not outsource the accountability for the breach.
• Resident-side awareness is uneven; digital exclusion compounds the security gap (a resident assisted by a kiosk operator they do not know presents a different attack surface than a literate user with a phone).
• Digital public infrastructure exists nationally (India Stack — Aadhaar, UPI, DigiLocker, Account Aggregator) but Karnataka has not built the operational layer that uses it consistently across departments.

Karnataka has hosted a meaningful share of India’s recent state-system breach incidents — vendor-managed identity systems, payments-adjacent state portals, and outsourced data-entry pipelines have each generated incident reports that informed national CERT-In advisories. The pattern is consistent across incidents: the underlying vulnerability is rarely sophisticated, the gap is in the operational layer — unpatched components past their EOL window, vendor-side credentials left in repositories, monitoring that detects but does not escalate, and incident-response procedures that exist on paper but not in muscle memory. The chapter’s commitment is to convert procedural promises into operational discipline with named owners, published timings, and binding audit.

The Digital Public Infrastructure side of the chapter starts from a different position. India Stack components — Aadhaar, UPI, DigiLocker, Account Aggregator — are operationally mature and broadly adopted. Karnataka’s gap is not in adopting them but in adopting them consistently: today, different departments integrate Aadhaar differently, payment flows are routed differently, and the citizen experiences seams where the state’s integrations meet. The chapter’s commitment is that DPI integrates once at the spine and is available to every department uniformly, with KSSL as the single anchoring layer.

Security is not an IT add-on. It is a governance guarantee.

15.2 People’s Model Blueprint

Karnataka builds the delivery layer of digital rights under five operating institutions.

• State Security Operations Centre (SOC) — 24/7, with MTTD (mean time to detect) and MTTC (mean time to contain) as published KPIs on Mission Control (Vol I Sec. 3.5).
• Secure-by-design standards for state systems and vendor procurement — published, binding, and audited.
• Consent-based data-access vault — the operating expression of the Citizen Data Trust’s consent framework (Vol I Ch 6).
• Incident transparency and independent audits — every breach notified to the Data Protection Board within 72 hours of becoming aware, affected residents informed without delay, and a public summary issued once containment is confirmed; post-incident reports published within 30 days.
• Cybercrime response capacity and digital-literacy programmes — for residents, kiosk operators, and small businesses.

Architecture integration — Karnataka State Service Log, CSOC, and the cryptographic floor

The architecture defined in Vol I Ch 2 sets a new bar for this chapter. Three structural shifts: a single mediation and logging layer — the Karnataka State Service Log (KSSL) — runs underneath every state digital service and anchors every inter-system interaction into a publicly verifiable structure. A statutory Karnataka Cyber Security Operations Centre (CSOC) holds compel-patching authority across every state system, with audit access independent of the executive. Post-quantum cryptography by default — hybrid from inception on everything new, legacy retired within a fifteen-year outer bound — carries the cryptographic floor through the next two decades.

KSSL — the cryptographic floor

KSSL is the single logging and anchoring layer. Every read, write, payment instruction, AI decision, and service hand-off across the state’s digital systems passes through KSSL, generating a log entry that is hashed, batched, and anchored into a publicly verifiable append-only structure. The integrity of the log is no longer trust-in-the-administrator — it is mathematically detectable if any entry is altered after the fact. Built on open standards used across software-supply-chain transparency tooling; published under open licence; reproducible by any party. Funded across the Cybersecurity + DPI line (App J — bumped to ~₹9.5k crore over 5 years to cover KSSL build-out, the Hardware Security Module fleet, threshold-cryptography signing, and the cryptography-engineering capacity that keeps every new system quantum-safe from inception).

Citizen receipts close the loop. Every transaction through any front door returns a signed receipt carrying an inclusion proof against the published KSSL anchor — the citizen can verify, on their own device or through any independent verifier, that their transaction is in the record and untampered. Transparency stops being something the state publishes and becomes something every citizen can check.

Anchors are witnessed. Each periodic KSSL anchor is co-signed by independent witnesses — the State Audit Office, the Civil-society Independent Audit Board, accredited universities and civil-society verifier nodes — and the anchor hash is published in the Karnataka Gazette and the press. No operator can show different versions of the log to different audiences, and the log is verifiable without internet access.

The spine fails safe. If KSSL mediation is down, citizen services continue against locally signed queues that anchor on recovery; bulk exports and threshold-quorum operations pause. A citizen is never denied service because the logging layer is unavailable, and every such window is logged and published.

Keys rotate; compromise is survivable. Anchoring and signing keys rotate on a published schedule, and a pre-published compromise-recovery protocol — revocation, witnessed re-anchoring, citizen notification, independent incident report within the statutory timeline — means even a worst-case key compromise has a known, public recovery path.

CSOC — the operating authority

CSOC is established as a statutory body (App I — Karnataka Cyber Security and Citizen Consent Act). It has audit access to every state digital system, the authority to compel patching, the authority to mandate a vendor change, the authority to isolate a non-compliant system pending remediation. CSOC reports to the Civil-society Independent Audit Board (Vol I Ch 6), not to the department it is auditing. Funding ring-fenced from departmental control.

Post-quantum cryptography — built in, not a programme

Two sentences cover the state’s PQC posture. (1) Everything the state builds or procures from Day 1 is quantum-safe (hybrid) by default — chosen at design time, at negligible marginal cost. PQC algorithms are open-source and free; compute overhead is negligible on servers and manageable on citizen-end devices with hybrid schemes; the only real money sits in two places — the Hardware Security Module fleet that supports the new primitives, and the engineer-training pipeline that builds and operates with PQC-aware cryptography — both already inside the Cybersecurity + DPI line (App J) and the State Project Delivery Cadre (Vol I Ch 5); post-quantum signatures are larger than classical ones (kilobytes instead of bytes) which matters slightly for receipts at scale but is a bandwidth cost, not a crore cost. (2) Everything inherited migrates as it is digitalised onto the spine anyway — Karnataka’s pre-TPM systems pick up PQC as they are rebuilt; central interfaces (Aadhaar, UPI, central schemes) track national migration; the citizen-device ecosystem catches up on its own refresh clock; archives re-encrypt gradually. The fifteen-year horizon is the honest outer bound for these four tracks taken together — not a fifteen-year cryptography project for the state to fund. Within the Day-1 commitment, long-secret data — citizen identity, health records, consent keys, KSSL signing keys — receives hybrid protection earliest (target: Year 4), closing the harvest-now-decrypt-later window. Migration progress on each track is published annually on the Karnataka Open Data Portal.

Threshold cryptography for high-impact operations

Any operation that touches more than 1 lakh personal records at once requires a threshold-cryptography quorum to execute — no single system administrator’s keys are sufficient. This applies to schema-wide queries, bulk exports, mass updates, and bulk consent overrides. The quorum is encoded in hardware (HSM fleet) and the policy is statutory (App I). The effect is that the architecture stays safe even if a single administrator account is compromised.

Software Bill of Materials and vendor diversity

Every commissioned system ships with a Software Bill of Materials documenting every dependency by version, source, and known vulnerability status, updated continuously. Vendor diversity is mandatory for critical service layers — no single vendor controls more than a defined share of any critical layer, ensuring that a vulnerability or vendor failure does not become a state-wide outage. Both requirements are statutory (App I — Karnataka State Digital Infrastructure Act).

Open-source mandate and reproducibility

All state-developed software is open-source by mandate. Any party can read the code, audit it, fork it, and reproduce a deployment. Combined with the cryptographic anchoring of KSSL, this means a citizen, journalist, or oversight body can independently verify what the state is running and verify that the system is behaving as the code says it should. The mandate applies to commissioned work as well — Intellectual Property terms in state contracts default to open-source release. Statutory (App I).

Bug bounty and continuous red-team

CSOC runs a continuous bug-bounty programme open to all citizens, with defined disclosure terms, defined safe-harbour provisions, and defined reward structures. A separate continuous red-team programme operates against state systems on a rolling basis. Findings flow to CSOC and to the Civil-society Independent Audit Board. Incident disclosure timelines are statutory (App I).

Citizen Consent Ledger

Every state data flow that touches a resident’s personal data requires a consent token from that resident, recorded in the Citizen Consent Ledger (Vol I Ch 6). Consent is time-bound, revocable, and the revocation propagates across systems within a defined window. The Ledger is itself anchored to KSSL — there is no path by which a department can claim consent it does not have.

Published aggregates meet a privacy standard. Any figure published from citizen-level data passes a published statistical-disclosure test — minimum cell sizes plus formal noise addition — so no dashboard, KPI, or equity breakdown can be reversed to identify a person. Every data class carries a published retention schedule, and citizens hold a deletion right over records not under legal hold, with deletion events verifiable through the Consent Ledger. By Year 3, a zero-knowledge eligibility pilot lets a citizen prove entitlement to one scheme without revealing the underlying records at all.

Disaster recovery, BCP, and graceful degradation

Critical systems run with disaster-recovery copies in at least two independent data centres within Karnataka (App I mandate). Service continuity plans require defined recovery-time and recovery-point objectives by service tier. The architecture is designed for graceful degradation — when a non-critical surface (Open Data Portal, AI-Use Register) is unavailable, the citizen-facing service still works; the surface catches up when it comes back. Critical financial and identity surfaces have higher availability requirements, backed by HSM redundancy and active-active deployments.

Citation discipline

This chapter does not name external companies, products, or nation-state programmes. The architectural decisions are described by what they do, not by who else uses them, so that the model is portable and the language is durable.

15.3 How it Works (key workflows)

Incident-response loop

Detect → contain → eradicate → recover — each with a published timeline and a named owner. Tabletop exercises monthly; the largest exercise is annual and cross-departmental.

Vulnerability loop

Coordinated vulnerability disclosure programme → triage → patch → verification → public summary. Karnataka stands up a bug bounty for the operating-spine surfaces in Year 1.

Consent loop

Resident grants consent for a specific purpose and a specific period → access logged in the vault → revocation propagates downstream → audit visible to the resident and the Citizen Data Trust.

DPI integration

Aadhaar, UPI, DigiLocker, Account Aggregator are integrated through the Identity layer (Vol I Ch 2 — Identity & Consent subsystem) — never as a direct integration by a department system. The seams are owned, not improvised.

The Program Catalog enumerates every named programme this chapter funds. Detailed budgets, delivery agencies, evaluation criteria, and SLA tables live in Vol III Appendix H sheets H.145–H.162.

Karnataka State Service Log (KSSL)

A statutorily mandated single mediation and logging layer underneath every state digital service. Hashed, batched, anchored to a publicly verifiable append-only structure with witnessed periodic anchors co-signed by the State Audit Office, Civil-society Independent Audit Board, accredited universities, and verifier nodes. Citizen receipts return inclusion proofs against the published anchor for every transaction. Capital build-out across the Cybersecurity + DPI line (App J ~₹9.5k crore over 5 years).

Karnataka Cyber Security Operations Centre (CSOC)

A statutory body under the Karnataka Cyber Security and Citizen Consent Act with 24/7 operations, compel-patching authority across every state system, audit access independent of the executive, and authority to mandate vendor changes or isolate non-compliant systems pending remediation. Reports to the Civil-society Independent Audit Board (Vol I Ch 6), not to the department it audits. Funding ring-fenced from departmental control.

Hardware Security Module Fleet and Threshold-Cryptography Quorum

A state-operated Hardware Security Module fleet supporting KSSL signing, post-quantum primitives, and threshold-cryptography quorum operations on schema-wide queries, bulk exports, mass updates, and bulk consent overrides. Quorum is encoded in hardware; policy is statutory. The architecture stays safe even if a single administrator account is compromised.

Identity and DPI Integration Library (v1+)

A single state-maintained integration library for Aadhaar, UPI, DigiLocker, and Account Aggregator. Departments integrate against the library, not against the upstream DPI components directly. The library handles consent capture, KSSL anchoring, error-handling, and audit-log emission uniformly. Open-source, reproducible, and statutorily mandated for new state services.

Citizen Consent Ledger Vault

A consent-capture and revocation-propagation system covering every state data flow that touches a resident’s personal data. Consent is purpose-bound, time-bound, revocable. The Ledger is anchored to KSSL so that no department can claim consent it does not have. Revocation propagates downstream within statutory window (target: ≤1 hour by Year 5).

Post-Quantum Cryptography Migration

Quantum-safe (hybrid) by default for everything the state builds or procures from Day 1. Existing systems migrate as they are digitalised onto the spine. Long-secret data (citizen identity, health records, consent keys, KSSL signing keys) receives hybrid protection earliest with Year 4 target. Migration progress on each track publishes annually on the Karnataka Open Data Portal. The fifteen-year horizon is the honest outer bound.

Bug Bounty and Continuous Red-team

A standing bug-bounty programme open to all citizens with defined disclosure terms, safe-harbour provisions, and reward structures. A separate continuous red-team programme operates against state systems on a rolling basis. Findings flow to CSOC and to the Civil-society Independent Audit Board. Incident disclosure timelines are statutory (App I — 72 hours public disclosure after containment; full post-incident report within 30 days).

Open-Source State Software Mandate

A statutory mandate that all state-developed software is open-source. State contracts default to open-source release in Intellectual Property terms. Any party can read, audit, fork, and reproduce a deployment. Combined with KSSL cryptographic anchoring, this means a citizen, journalist, or oversight body can independently verify what the state is running.

Software Bill of Materials Registry

A state-operated registry of Software Bill of Materials for every commissioned system, documenting every dependency by version, source, and known vulnerability status. Continuously updated. Vendor diversity is mandatory for critical service layers — no single vendor controls more than a defined share of any critical layer.

Karnataka Open Data Portal

A statewide open-data platform publishing non-personal state datasets with machine-readable APIs, identified-developer rate-limit tiers, and statistical-disclosure safeguards. Dataset coverage target: ≥2,000 datasets at monthly refresh by Year 3; ≥10,000 datasets by Year 5.

Cybercrime Response and Digital-Literacy Programmes

A statewide cybercrime response capacity supporting incident-response for residents (account compromise, financial fraud, online harassment), kiosk operators, and small businesses. Companion digital-literacy programmes delivered through schools, libraries, Panchayat Service Centres, and the Karnataka Public Broadcaster.

15.4 Program Catalog (what we will actually do)

15.5 Finance & Accountability

• Security spending prevents massive losses, fraud, and trust collapse. The avoided-cost calculation is published per programme.
• Use shared security services — the SOC, the consent vault, the identity-layer library — to reduce duplication across departments.
• Vendor procurement enforces secure-by-design requirements; breaches by contractors are themselves contractual events with consequences on the Open Ledger.
• Publish incident transparency reports and audit summaries on the Open Ledger; non-disclosure is itself an audit event.

Total annual outlay tied to this chapter is projected at ₹1,900 crore at Year 3 steady-state, scaling to ₹2,500 crore at Year 5, of which roughly 40 percent funds KSSL operations, CSOC standing capacity, and Hardware Security Module fleet; 20 percent funds the Identity and DPI Integration Library and Citizen Consent Ledger Vault; 15 percent funds Post-Quantum Cryptography migration and engineering capacity; 10 percent funds the Bug Bounty + Red-team programmes and incident-response infrastructure; 10 percent funds the Karnataka Open Data Portal operations; and the remaining 5 percent funds cybercrime response and digital-literacy outreach. The total Cybersecurity + DPI envelope across the 10-year horizon sits at approximately ₹9.5k crore over the first five years per App J, scaling thereafter on a published trajectory.

The avoided-cost case is direct. A single severe state-system breach typically costs more in remediation, contract renegotiation, audit overhead, and trust collapse than several years of structural cybersecurity capacity. The chapter’s outlay is structural prevention — operational maturity that converts ad-hoc reaction into predictable defence — not a series of one-off projects.

15.6 KPIs & Public Dashboards

Six headline KPIs for Cybersecurity, DPI & Citizen Tech, each measurable from the KSSL anchoring pipeline, CSOC dashboards, the Citizen Consent Ledger, and the Karnataka Open Data Portal. Each KPI’s definition, unit, source dataset, and audit frequency is published in Vol III Appendix A (Sector KPI Dictionary); per-sheet KPIs in Vol III App H sheets H.230 to H.233.

• KSSL anchor publication cadence — baseline: 0; Year 1 daily anchors; Year 3 hourly; Year 5 streaming anchors with defined publication window.
• CSOC mean-time-to-patch on compelled-patching orders — baseline: (new); Year 1 baseline; Year 3 ≤7 days; Year 5 ≤72 hours.
• Citizen Consent Ledger revocation propagation time — baseline: (new); Year 3 ≤24 hours; Year 5 ≤1 hour.
• Bug-bounty disclosure response time (median triage) — baseline: (new); Year 3 ≤72 hours; Year 5 ≤24 hours.
• Post-quantum adoption — % of new builds quantum-safe (hybrid) by default — baseline: 0%; Year 1 procurement standard published; Year 3 100% new builds; Year 4 long-secret data hybrid first.
• Karnataka Open Data Portal dataset coverage — baseline: 0; Year 3 ≥2,000 datasets with monthly refresh; Year 5 ≥10,000 datasets.

15.7 Implementation Roadmap

Foundations — 0 to 100 days

• Security audit of existing critical state systems; publish a remediation backlog.
• Interim secure-coding and vendor rules issued; mandatory in new procurements.
• Identity-layer integration library v1 published.

Foundations — Year 1

• SOC operational with published MTTD/MTTC; first bug bounty launched.
• Consent vault live; first quarterly incident transparency report published.
• DPI integration for the top 100 services on Identity and Payments.

Build-out — Years 2 to 5

• Mature cyber workforce and incident-handling capability; continuous security testing.
• Open APIs programme reaches statewide developer use under audited governance.

Consolidation — Years 5 to 10

• High-trust digital state — strong rights operationally protected, strong resilience, no second-class users.

Connection to The Learning State. Per Vol II Ch 7 Sec. 7.4, the Learning State generates significant new data flows — JANATA Learner role-card activity (Sec. 7.4.4), museum visit records (Sec. 7.4.6), DHEC and KAI research data (Sec. 7.4.7–8), KPB viewing patterns (Sec. 7.4.2). All of this is governed by the Citizen Data Trust (Vol I Ch 6) with the high-risk mitigations in Vol III App I Sec. I.4. The KAI cybersecurity research range (Sec. 7.4.8) and DHEC cybersecurity labs (Sec. 7.4.7) form the talent pipeline that staffs Karnataka’s State SOC and DPI security work described in this chapter.

Citizen surface — JANATA role view

Per Vol III Ch 22 Sec. 22.0a, the Cybersecurity + DPI chapter governs role-data access for every role-card in JANATA. Citizens see a Consent log role-view (audit log of every data access on their record — who, when, why) and a Cyber-incident reporter role-card (report account compromise, financial fraud, online harassment with case-tracking through to closure). The Citizen Data Trust (Vol I Ch 6) governs role-data sharing; Vol III App I Sec. I.4 mitigations apply.

15.8 Governance, Audit, and Cryptographic Floor

Every transaction this chapter authors — CSOC operating expense, KSSL anchoring infrastructure cost, Hardware Security Module fleet capital and maintenance, bug-bounty reward payout, vendor procurement payment, integration library development cost — is itself anchored on KSSL. The chapter’s architectural commitment is recursive: the system that anchors the rest of the state’s transactions has its own transactions anchored at the same standard.

The Civil-society Independent Audit Board runs annual audits on four programmes under this chapter: (1) KSSL anchor publication cadence and witnessed-anchor integrity, (2) CSOC compel-patching SLA compliance and incident disclosure timeline adherence, (3) Post-Quantum migration progress against published trajectory, and (4) Citizen Consent Ledger revocation propagation. CSOC itself reports to the Audit Board, not to the executive; the Audit Board’s funding is ring-fenced from departmental control via statutory appropriation.

The Karnataka Citizen Data Trust governs every flow that touches resident personal data and holds joint complaint jurisdiction with CSOC over Consent Ledger violations. Verifier-node operators (Vol I Ch 2) independently re-derive KSSL anchors, audit dataset publication cadence on the Karnataka Open Data Portal, and verify citizen receipts at scale, giving civil-society organisations, journalists, and academic researchers the structural ability to detect retroactive tampering, undisclosed access, or missing publication events.

15.9 Citations & Further Reading

• Full bibliography for this chapter and the wider manifesto is in Vol III Appendix G (Research References).
• Cross-references: Volume I Ch 2 (spine), Ch 3 (Mission Control), Ch 6 (digital rights — this chapter is the operational counterpart); Vol II Ch 16 (inclusive access); Vol III App H sheets H.145–H.162.

---

← Chapter 14 — Youth Power & Innovation · Chapter 16 — Inclusive Governance: Representation, Access, Accommodation →

This is a chapter of The People's Model manifesto for Karnataka — published in full for public review. Every claim may be challenged: write to [email protected].