Cyber Incident Response and Breach Notification Plan — Veloxis

Effective date: [to be set on first publication] Last revised: 2026-05-24 Plan owner: CA Krishna Gujarathi (Managing Partner + Grievance Officer) Plan scope: All systems supporting the Veloxis Platform: production server (Linode VM at 103.13.113.43), PostgreSQL database, Cloudflare R2 object storage, Cloudflare DNS, Nginx + Let's Encrypt SSL, PM2 process supervisor, Tokenisation Sidecar, and all client / server code in the Veloxis Git repository.

This plan operationalises the Firm's obligations under:

• CERT-In Cyber Security Directions, 28 April 2022 issued under §70B(6) of the Information Technology Act, 2000 — requires reporting "cyber incidents" within six hours of noticing or being brought to notice.
• Digital Personal Data Protection Act, 2023, §8(6) — requires intimation of a personal-data breach to the Data Protection Board of India and to each affected data principal at the earliest and in any case within the period specified by the Board.
• IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 — applies in transition until the DPDP Rules subsume them.

The Firm has a single Indian-incorporated entity for legal purposes (VKG & Associates), one production environment, one Managing Partner. The plan is sized to that scale and is not designed for a 24×7 SOC.

1. What counts as an incident

A "cyber incident" for CERT-In reporting purposes includes:

• Unauthorised access to data, IT systems, or applications.
• Unauthorised modification of data or system configuration.
• Denial-of-service or distributed-DoS event that meaningfully degrades the Platform.
• Malicious code infection on Firm infrastructure.
• Unauthorised data exfiltration, even where data is encrypted in transit and at rest.
• Compromise of any cryptographic key used by Veloxis (the firm key, an engagement key, the JWT signing secret, the Anthropic / Google API keys, the database password).
• Attacks targeting the Tokenisation Sidecar or the AI provider integration that could degrade the privacy controls.

A "personal data breach" for DPDP purposes is a subset: any incident above that involves personal data of any data principal (Firm staff, client portal user, third-party PII held in client books).

The trigger is noticing or being brought to notice. A staff member who notices anomalous activity must escalate within fifteen minutes to the Plan owner via WhatsApp, e-mail, and phone — at least two channels.

2. Severity classification

SEV-1 and SEV-2 trigger CERT-In + DPDP reporting paths. SEV-3 triggers internal investigation only.

3. Incident response timeline

0 to 15 minutes — Detect + Escalate

• Anyone who notices the indicator (staff, client, automated alert) raises it to the Plan owner via WhatsApp + e-mail.
• The Plan owner acknowledges receipt within five minutes during business hours, fifteen minutes outside business hours.

15 minutes to 1 hour — Triage

• Plan owner establishes the first known time of the incident, the affected systems, and the indicator that surfaced the issue.
• A new Git branch incident/{YYYYMMDD-HHmm} is created and a timeline file is started under docs/incidents/{YYYYMMDD-HHmm}.md.
• The severity is provisionally classified.
• If SEV-1 or SEV-2, the Plan owner starts the CERT-In reporting clock.

1 hour to 4 hours — Contain

Containment runs in parallel to triage and uses the playbooks in §4.

• The affected system is isolated where possible.
• Active sessions of suspect users are terminated.
• Compromised credentials are rotated.
• The Platform is put into read-only mode if exfiltration is plausible (veloxis-prod is restarted with the READONLY=true env flag).

Pre-condition — NIC NTP synchronisation

CERT-In §III mandates that all ICT clocks be synchronised to NIC or NPL NTP. The incident timeline depends on accurate clocks; the Firm's chronyd configuration synchronises to samay1.nic.in and samay2.nic.in. If clock drift is detected during incident triage, the Plan owner records the drift and uses the NIC clock as authoritative.

4 hours to 6 hours — CERT-In report

For SEV-1 and SEV-2, the Plan owner submits the CERT-In incident report. Report channels in order of priority:

1. E-mail — incident@cert-in.org.in with subject Incident Report — Veloxis — {YYYYMMDD-HHmm}.
2. Phone — +91 1800 11 4949 (CERT-In Helpdesk).
3. Web — https://www.cert-in.org.in/ Incident Reporting form.

The report contains the fields in CERT-In Annexure I: organisation details, incident description, severity, time of detection, observed indicators, suspected root cause, immediate actions taken. CERT-In Directions, 2022 list a category-based set of mandatorily reportable incidents (Annexure I, twenty categories — including targeted scanning, unauthorised access, defacement, malware, identity theft, DoS, data breach, fake mobile apps, attacks on critical infrastructure, etc.). The 6-hour clock applies to any incident falling in the listed categories, irrespective of the Firm's internal SEV classification. The internal SEV classification helps decide internal response intensity; it does not narrow the CERT-In reporting obligation.

CERT-In Point of Contact

The Firm has designated CA Krishna Gujarathi (e-mail: krishna@vkg.co.in, phone: [PHONE — to insert]) as the CERT-In Point of Contact ("PoC") on behalf of VKG & Associates. The PoC details have been [registered with CERT-In / are pending registration — confirm status]. Updates to the PoC details shall be intimated to CERT-In within seven days.

The Firm shall respond to any CERT-In information request within six hours, in compliance with §V of the 2022 Directions.

6 hours to 72 hours — DPDP notification (only if personal data breach confirmed)

If, by the 6-hour mark, the Plan owner has reasonable grounds to believe personal data was accessed or exfiltrated, the Firm notifies under DPDP §8(6) read with the Digital Personal Data Protection Rules, 2025:

• Data Protection Board of India ("DPB") — established under §18 of the DPDP Act, 2023, and notified by the Central Government in 2025. The DPB has published an incident-intimation channel; the Plan owner shall use that channel as in force on the date of reporting. The Plan owner records the channel used and the acknowledgement reference in the incident file.
• Affected data principals — each data principal whose data was confirmed accessed or exfiltrated is notified by e-mail at the address held by the Firm. The notification describes the data classes affected, the time of the incident, the steps the Firm has taken, the steps the data principal should take, and the Grievance Officer contact.

Under the DPDP Rules, 2025, the Firm is required to provide an initial intimation without undue delay on becoming aware of the breach, followed by a detailed report within 72 hours (or such longer period as the Board may, on a written request, allow). The Firm shall not wait for the 72-hour mark to send the initial intimation; the intimation is sent as soon as the data scope is reasonably understood, typically before the CERT-In 6-hour mark when the personal-data aspect is clear at first triage.

The notification is repeated when materially new facts emerge (e.g., the scope is enlarged after forensics complete).

72 hours to 30 days — Forensics + Post-mortem

• Full timeline, indicators of compromise, root cause, contributing factors, scope, lessons learned.
• Public-facing post-mortem published on the Veloxis status page only if SEV-1 affecting multiple users.
• The post-mortem document lives at docs/incidents/{YYYYMMDD-HHmm}.md and is checked into the Veloxis Git repository.

30 days onward — Remediation tracking

• Each lesson-learned becomes a tracked task in the Veloxis backlog with an owner and a target close date.
• The Plan owner reviews open remediation tasks weekly until all are closed.

4. Playbooks

4.1 — Compromised firm key

The firm key derives every engagement key. Its compromise compromises every encrypted TokenMap row.

1. Rotate FIRM_KEY_BYTES in .env and .env.prod.
2. Re-encrypt every TokenMap.plaintextEncrypted row by running scripts/privacy/rotate-firm-key.cjs (TBD — to be authored as a remediation task).
3. Revoke all active sessions; force a password reset for every active user.
4. Treat every AI prompt in AICallSnapshot from before the rotation as potentially exposed.

4.2 — Compromised database password

1. Rotate DATABASE_URL password.
2. Restart veloxis-prod, veloxis-dev, veloxis-engine-worker.
3. Audit pg_stat_activity for unrecognised connections and pg_stat_statements for unexpected queries.
4. Search /var/log/postgresql/ for the suspect window.

4.3 — Compromised Anthropic / Google API key

1. Revoke the key via the provider console.
2. Mint a new key.
3. Rotate the env var and restart the application.
4. Review the provider's recent usage page for billed traffic the Firm did not initiate.
5. If billed traffic indicates the key was used at scale, escalate the incident to SEV-1.

4.4 — Ransomware on the production VM

1. Disconnect the VM from the public internet (Cloudflare DNS pointed to a holding page).
2. Snapshot the disk for forensics.
3. Restore from the latest clean DB backup.
4. Bring up a fresh VM, deploy from Git, restore DB, repoint DNS.
5. Report SEV-1.

4.5 — Unauthorised login

1. Check AuditLog for the suspect session and the IP.
2. Terminate the session via prisma.session.delete.
3. Force password reset for the affected user.
4. If the IP is foreign and the account is a partner, escalate to SEV-1.

4.6 — AI provider safety violation flagged by Anthropic / Google

If the provider notifies the Firm that a prompt or response violated their AUP:

1. Pause AI features for the affected engagement.
2. Review the prompt + response.
3. If the violation is genuine (e.g., the auditor asked the AI to do something prohibited), counsel the user; document.
4. If the violation is a false positive (provider misclassified an audit query), reply to the provider with evidence and resume.

5. Communications

• Internal — WhatsApp broadcast to the Firm partners + senior staff. Daily status update during an active SEV-1 / SEV-2.
• Affected users — e-mail in the format prescribed in §3 above. No public social media communication during an active incident without Plan owner sign-off.
• Clients of the Firm (entities whose books are in Veloxis) — written communication on Firm letterhead, signed by the Managing Partner, summarising the incident and the data classes potentially affected.
• CERT-In — only the Plan owner submits the report. No other staff member contacts CERT-In on behalf of the Firm during an active incident.
• Press / media — no contact with press during the first seventy-two hours. After that, only the Managing Partner speaks for the Firm.

6. Documentation and evidence preservation

From the moment an incident is suspected:

• Write to-day's incident file under docs/incidents/{YYYYMMDD-HHmm}.md. Every step taken, every command run, every observation, every decision goes in with a timestamp.
• Capture screenshots of the indicator (provider console pages, log lines, terminal output).
• Save logs from the affected window — Nginx access log, PostgreSQL log, PM2 logs for each process — into docs/incidents/{YYYYMMDD-HHmm}-evidence/.
• Hash each evidence file (sha256sum) and record the hash in the incident file.

This forms the audit trail relied upon for CERT-In and DPDP reporting and the basis of the post-mortem.

7. Annual drill

The Plan owner conducts a tabletop exercise of one playbook from §4 each year. The exercise is logged at docs/incidents/drill-{YYYY}.md. Findings feed remediation tasks.

The next scheduled drill: 2027-04-01.

8. Plan review

This plan is reviewed annually or whenever:

• CERT-In Directions are amended.
• DPDP Rules are notified.
• The Firm changes infrastructure (host, region, providers).
• A SEV-1 or SEV-2 incident closes, in which case the post-mortem may mandate a plan revision.