Home Projects Career Skills Blog Resume Contact
← Back to All Projects
🛡️ 2955% projected ROI

Security Audit & DPDP Act Compliance

Security Analysis SQL Injection Remediation SSL/TLS DPDP Act 2025 Risk Modeling Compliance Engineering
2955% Projected ROI
4-Phase Remediation Strategy
100s SQL Injection Vectors Found
Full DPDP Compliance Roadmap

🔍 Context

A comprehensive security review uncovered critical vulnerabilities in a legacy operations platform: SQL injection exposure across hundreds of query patterns, SSL verification disabled in multiple locations, and no compliance framework for India's Digital Personal Data Protection Act 2025.

The legacy platform — a Laravel-based operations system — had been in production for years with minimal security oversight. It processed sensitive customer data, financial transactions, and employee information daily. The codebase had grown organically, with multiple developers contributing over the years, and no security review had ever been conducted.

India's DPDP Act 2025 introduced significant regulatory requirements for personal data handling, with penalties reaching up to ₹250 crore for non-compliance. The organization had no awareness of its obligations under the act, no data classification system, and no consent management framework — representing both a legal and financial risk.

⚙️ Approach

Conducted a systematic security audit covering code-level vulnerability analysis, infrastructure security assessment, and regulatory compliance gap analysis — treating it as three interconnected workstreams rather than isolated checks.

Code-Level Vulnerability Analysis: Performed manual code review of the entire legacy codebase, identifying every instance of raw SQL query construction, unsanitized user input, and parameter injection risk. Cataloged hundreds of SQL injection vectors organized by severity, exploitability, and business impact. Mapped data flow paths to understand which vulnerabilities could lead to data exfiltration versus service disruption.

Infrastructure Security Assessment: Audited SSL/TLS configuration across all endpoints, discovering disabled certificate verification in API integrations that exposed the system to man-in-the-middle attacks. Reviewed authentication mechanisms, session management, and access control patterns. Assessed server hardening, firewall rules, and network segmentation.

DPDP Act Compliance Gap Analysis: Mapped the organization's entire personal data processing landscape — what data is collected, where it's stored, how it flows between systems, who has access, and what retention policies exist (or don't). Compared current practices against every requirement in the DPDP Act: consent management, data minimization, purpose limitation, breach notification timelines, cross-border transfer controls, and Data Protection Officer requirements.

Remediation Strategy Design: Created a prioritized 4-phase remediation plan: Phase 1 (critical vulnerabilities — immediate), Phase 2 (high-risk items — 30 days), Phase 3 (medium-risk hardening — 90 days), Phase 4 (compliance framework — 6 months). Each phase included specific technical tasks, resource requirements, and success criteria.

🚀 Impact

  • Identified and cataloged critical security vulnerabilities across the entire platform — hundreds of SQL injection vectors, disabled SSL verification, weak authentication patterns
  • Designed 4-phase remediation strategy with prioritized execution plan, clear ownership, and measurable milestones
  • DPDP Act compliance roadmap with projected 2955% ROI through regulatory risk elimination — calculated against potential penalties and breach costs
  • Created reusable security assessment methodology — documented processes, checklists, and tooling that can be applied to future audits
  • Elevated security from reactive firefighting to proactive governance — established security review as a standard part of the development lifecycle
  • Board-level risk presentation delivered to executive leadership, translating technical vulnerabilities into business risk language with financial impact modeling

🏗️ Key Technical Decisions

Manual Code Review over Automated Scanning

Chose manual review over automated SAST tools for the initial assessment. The legacy codebase used non-standard patterns that automated scanners would miss — custom query builders, dynamic table names, and indirect parameter passing through configuration. Manual review caught vulnerability patterns that no scanner would have flagged.

Risk-Based Prioritization over Blanket Remediation

Rather than attempting to fix everything simultaneously, designed a risk-scored prioritization model. Each vulnerability was scored on exploitability (how easy to attack), impact (what data is exposed), and business criticality (which operations are affected). This ensured the most dangerous vulnerabilities were addressed first while maintaining operational continuity.

Compliance as Architecture, Not Checklist

Approached DPDP Act compliance as an architectural challenge rather than a paperwork exercise. Designed data classification, consent flows, and retention policies as system-level features — integrated into the data model and application architecture rather than bolted on as afterthought policies.

💡 Lessons Learned

01
Security debt compounds faster than technical debt. Every month a SQL injection vulnerability exists in production, it's a ticking time bomb. Unlike performance issues or UX problems, security vulnerabilities have catastrophic failure modes — one exploit can compromise everything. The ROI on proactive security isn't just about preventing breaches; it's about avoiding existential risk.
02
Executives respond to risk language, not technical language. Presenting "hundreds of SQL injection vectors" got blank stares. Presenting "₹250 crore regulatory exposure with current data handling practices" got immediate budget approval. Translate vulnerabilities into business risk — that's how security gets funded.
03
Compliance frameworks are actually useful architecture guides. The DPDP Act's requirements for data minimization, purpose limitation, and consent management aren't just legal obligations — they're good data architecture principles. Following them forced a cleaner data model than we would have designed otherwise.