India Cybersecurity and Technology

What we do to keep systems secure in India, and the statutory clocks we run against — including the six-hour one.

1. The framework

• Information Technology Act, 2000 — section 43A (compensation for negligent handling of sensitive personal data), section 66 (computer-related offences), section 70B (CERT-In's statutory mandate), section 72A (disclosure in breach of lawful contract).
• CERT-In Directions under section 70B(6), dated 28 April 2022 — the operative source of our reporting, logging and clock obligations.
• IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 — rule 8 recognises ISO/IEC 27001 as a reasonable security practice.
• Digital Personal Data Protection Act, 2023, section 8(5) — the duty to take reasonable security safeguards, and section 8(6) — breach notification.
• National Critical Information Infrastructure Protection Centre (NCIIPC) guidance, where a deployment supports a protected system under section 70 of the IT Act.

2. The six-hour clock

2.1 Reportable incidents. The Annexure to the Directions lists the incident types that must be reported, including targeted scanning of critical systems, compromise of critical systems, unauthorised access to data, website defacement, malicious code attacks, identity theft, denial of service, data breach and data leak, and attacks on IoT devices, servers and cloud infrastructure.

2.2 Our process. Detection routes to a duty responder at any hour. Triage classifies against the Annexure within thirty (30) minutes. A reportable classification triggers the CERT-In filing, with an incident commander appointed and the legal team engaged in parallel. Customer notification runs concurrently rather than afterwards.

2.3 Customer notification. Where an incident affects Customer Data we notify the affected customer without undue delay and in any event within seventy-two (72) hours, with what we know, what we do not yet know, and what they need in order to meet their own obligations to Data Principals and to the Data Protection Board.

2.4 Cooperation. We provide CERT-In with the information, assistance and access the Directions require, and we retain incident records for the mandated period.

3. Logs, clocks and jurisdiction

4. Security controls

4.1 Identity and access

• Mandatory multi-factor authentication on every administrative, search-privileged and engineering account. It cannot be disabled by a customer or by us.
• Role-based access control on least privilege; enrolment, search and export are separately grantable rights.
• Just-in-time, time-bounded, approved elevation for production access, written to the customer's own audit log.
• Quarterly access recertification; automatic revocation on separation.

4.2 Data protection

• TLS 1.2 or higher in transit, from camera to edge to cloud. AES-256 at rest.
• Biometric templates in a separately encrypted store with an independent key and independent access control.
• Key management with rotation, split custody and hardware-backed storage.
• No bulk export interface for biometric templates, in the UI or the API.

4.3 Infrastructure and monitoring

• Network segregation between tenants, and between the control plane and the data plane.
• Continuous vulnerability scanning of internet-facing infrastructure; remediation targets at Vulnerability Disclosure Policy.
• Centralised logging with anomaly detection on out-of-hours access, high query volume per user, and repeat queries against the same subject.
• Annual third-party penetration testing, and a test after any material architectural change.
• Secure development lifecycle: peer review, dependency scanning, secret scanning, and static analysis gating every merge.

4.4 Edge and hardware

• Signed firmware, verified boot, and authenticated over-the-air update with rollback protection.
• Per-device credentials; no shared or default passwords shipped, and first-boot credential rotation enforced.
• Tamper detection reported to the HUB as a security event.
• Edge buffers encrypted and bounded, so a stolen device does not yield a usable archive.

4.5 People

• Background verification proportionate to role, before production access.
• Security and privacy training on joining and annually, with role-specific training for engineers and support staff.
• Confidentiality obligations that survive employment.

5. Business continuity

We maintain documented business continuity and disaster recovery plans, with recovery objectives recorded on the Order Form for each service tier. Backups are encrypted, access-controlled, and restore-tested at least annually. Continuity plans are exercised at least annually and after any material incident, and the exercise report is available to customers under NDA.

6. Certification and assurance

Current certification and audit status — including ISO/IEC 27001 (recognised as a reasonable security practice under rule 8 of the SPDI Rules), SOC 2, and independent assessment reports — is published and dated at Compliance and Security Updates. We publish status rather than aspiration: a certification that is in progress is described as in progress.

7. Supply chain

Sub-processors are listed at Sub-processors and bound by the obligations at Vendor Terms, including flow-down of the CERT-In six-hour reporting requirement to any vendor whose systems could produce a reportable incident affecting us. Open source and third-party components, and how we monitor them for vulnerabilities, are at Third-Party Terms.

8. Reporting something to us

Security issues: security@dectify.in. Researchers should read Vulnerability Disclosure Policy first — it sets out the safe harbour we offer and the scope it covers.