DPDPA.center — Incident Response Policy

Version: 1.0 | Effective date: 2026-06-12 Operated by: CynorSense Solutions Pvt. Ltd., India Incident contact: dpo@cynorsense.com

This policy governs how CynorSense detects, contains, and communicates security incidents and personal data breaches affecting the DPDPA.center service, consistent with the Digital Personal Data Protection Act, 2023 (“DPDP Act”) §8(5)–(6) and the Data Processing Addendum (dpa.md).

1. Definitions

• Security incident: any event that compromises, or credibly threatens, the confidentiality, integrity, or availability of the service or the data it processes.
• Personal data breach (DPDP Act §8(6)): unauthorized processing, disclosure, acquisition, alteration, or destruction of personal data, or loss of access to it.

2. Detection and monitoring

• Container logs across all services capture full error detail (user-facing errors are sanitized; complete diagnostics stay server-side).
• The append-only audit store (webhook envelopes, erasure trails, consent-push records) provides a tamper-evident record for reconstructing who/what/when during an investigation.
• Post-deploy health endpoints are checked after every release.
• Reports from site owners, Data Principals, or external researchers via dpo@cynorsense.com are triaged as potential incidents.
• [PLACEHOLDER: automated alerting — owner to document any uptime/log alerting in place beyond manual log review and health checks.]

3. Severity tiers

4. Response steps

1. Triage and classify — assign a severity tier and an incident lead; open an incident record with a timeline.
2. Contain — isolate affected containers/tenants; revoke and rotate affected credentials in the OpenBao vault; invalidate affected sessions (tenant-bound sessions limit blast radius to a single site); block exploited paths at the reverse proxy if needed.
3. Assess impact — use container logs and the append-only audit store to determine which tenants, Data Principals, and data categories are affected, and over what window.
4. Eradicate and recover — patch the root cause, redeploy, verify via health endpoints and the verification runbook.
5. Notify (see §5).
6. Document — preserve evidence, the timeline, and remediation actions in the incident record.

5. Notification

• To affected Data Fiduciaries: for any personal data breach affecting a tenant, CynorSense notifies the site owner’s DPO email on record without undue delay and in any event within 72 hours of becoming aware, including: nature and scope, affected data categories, approximate number of Data Principals, likely consequences, measures taken, and a contact point. Interim notification is sent if the investigation is incomplete at 72 hours, with updates as facts develop.
• Data Protection Board of India: the duty to notify the Board and affected Data Principals under DPDP Act §8(6) rests with the Data Fiduciary. CynorSense supports the Fiduciary’s notification with incident timelines, audit-log extracts for their tenant, affected-record counts, and remediation summaries, and will cooperate with any Board inquiry.
• Where CynorSense is itself the Fiduciary (e.g., a breach of site-owner account data), CynorSense notifies the Board and affected persons directly as the DPDP Act and its rules require.

6. Post-incident review

Within 10 business days of closure, the incident lead completes a post-incident review covering: root cause, detection gap, containment effectiveness, notification timeliness, and corrective actions with owners and due dates. Corrective actions are tracked to completion; recurring classes of incident trigger an update to this policy and the Security Statement.

7. Policy maintenance

This policy is reviewed at least annually, and after every SEV-1 or SEV-2 incident. Policy owner: [PLACEHOLDER: named role/person responsible, e.g., DPO / CTO of CynorSense Solutions Pvt. Ltd.]