Last updated: 8 July 2026

Security Policy

How we protect your data - our security programme, controls, and incident response.

1. Our Security Commitment

We build compliance software. If we can't secure our own platform, we have no business telling others how to secure theirs. Security isn't an afterthought here - it's a product requirement.

We implement technical and organisational measures per DPDPA S.8(5) and Rule 6. Every component is designed assuming customer data is sensitive and that breaches must be detected, contained, and reported.

2. Infrastructure Security

Everything runs in AWS ap-south-1 (Mumbai, India) inside a private VPC with no direct internet egress from application services.

  • Frontend (AWS Amplify): Automatic HTTPS, DDoS protection, environment variable isolation, deployed in Mumbai.
  • API (AWS App Runner): VPC-connected isolated compute (1 vCPU / 2 GB), automatic TLS, rolling zero-downtime deployments.
  • Database (AWS RDS PostgreSQL 16): KMS-encrypted at rest, accessed only through RDS Proxy with IAM token auth (no static passwords), TLS required on all connections, automated backups.
  • File storage (AWS S3): KMS-encrypted, Object Lock with 7-year governance retention for the consent proof vault (write-once, can't be deleted), no public access, presigned URL access only.
  • Cache (AWS ElastiCache Redis 7.1): TLS-encrypted, AUTH token required, KMS encryption at rest, accessible only within the VPC.
  • Secrets: All credentials live in AWS Secrets Manager with KMS encryption. Nothing sensitive in environment variables or source code.
  • Network: Private subnets, NAT Gateway, VPC endpoints for all AWS service calls (S3, Secrets Manager, KMS, ECR, Bedrock, STS). App Runner has zero internet egress.
  • Monitoring: AWS GuardDuty, Security Hub, CloudTrail (with 7-year Object Lock retention), AWS Config, and VPC Flow Logs running continuously.
  • Infrastructure access: SSM Session Manager only - no SSH keys, no public IPs. CI/CD uses OIDC (GitHub Actions to AWS via AssumeRole) - no static IAM keys in CI.
  • All data in transit: TLS 1.2 or higher. No exceptions.

3. Application Security

  • Authentication: JWT-based with 15-minute access tokens and 7-day refresh tokens. Account lockout after 5 failed attempts (15-minute cooldown). Timing-attack-resistant login flow.
  • Authorisation: Role-based access control (DPO, Analyst, Viewer, Super Admin) enforced at every API endpoint. Tenant isolation is architectural - every query is scoped to the authenticated tenant.
  • API hardening: Per-endpoint rate limiting, CORS restricted to registered origins, Zod schema validation on all inputs, HMAC-SHA256 webhook signatures, security response headers on every request.
  • Passwords: Bcrypt with 12 rounds. Never stored in plaintext or reversibly encrypted.
  • OTP security: 6-digit codes, 10-minute expiry, 3 attempts max, bcrypt-hashed before storage.
  • SDK security: Origin allowlist per API key, per-key rate limiting (600 req/min per IP, 5000 req/min global), SSRF prevention on all URL inputs.
  • Proof integrity: Consent receipts and closure PDFs stored with SHA-256 hashes in a write-once vault. No deletion API exists.

4. Access Controls

  • Principle of least privilege - team members see only data scoped to their tenant and role
  • Cross-tenant data access is architecturally impossible, not just policy-blocked
  • Super-admin access restricted to authorised DPDPA Shield personnel only
  • All privileged operations logged in immutable audit trails (database triggers block UPDATE and DELETE on audit tables)
  • Quarterly access reviews enforced with compliance tasks

5. Incident Response

If something goes wrong, here's the playbook:

  1. Detect: GuardDuty, CloudTrail, and application-level monitoring trigger alerts on anomalous access, error rate spikes, or security events
  2. Contain: Within 2 hours - isolate affected systems, revoke compromised credentials, preserve evidence
  3. Notify the Data Protection Board: Within 72 hours per DPDPA S.8(6) and Rule 7
  4. Notify affected Customers: Within 24 hours per our DPA
  5. Notify affected Data Principals: Without undue delay, per DPDPA S.8(6)
  6. Post-incident review: Root cause analysis, remediation, process improvements - all documented

6. Vulnerability Management

  • Automated dependency monitoring with vulnerability alerts
  • Critical CVEs patched within 7 days of public disclosure
  • Security review on major architectural changes before they ship
  • Comprehensive input validation audit completed (Zod schemas on all API surfaces)
  • Annual full-platform security review

7. Responsible Disclosure

Found a vulnerability? We want to hear about it. See our Responsible Disclosure Policy for how to report safely.

8. Contact

Security concern? Email hello@dpdpashield.in with subject “Security”. We acknowledge security reports within 2 business days.