Penetration Testing in Delhi · Gov + PSU

Delhi penetration testing is dominated by central-government, ministry, PSU and regulator buyers, with a long tail of public-sector banks, central PSEs and statutory bodies headquartered in Shastri Bhawan, Nirman Bhawan, Rail Bhawan, Krishi Bhawan, Sanchar Bhawan and the CGO Complex. Scopes typically cover citizen-facing portals built on the National Informatics Centre (NIC) stack, internal MPLS networks running on NICNET, regulator data-exchange APIs, the Aadhaar AUA / KUA integration where the ministry consumes UIDAI services, and the long tail of legacy on-prem applications that ministries still run on RHEL / WebLogic / Oracle. Procurement, contracting and reporting expectations are very different from a private-sector VAPT — and a vendor who has never read a GeM contract does not survive the first review.

We deliver penetration testing on Delhi government and PSU estates in CERT-In empanelled format with STQC and NIC-friendly reporting structure — the explicit observation / risk / recommendation table format, traceable evidence per finding (with the screenshot, request / response and exploit witness numbered to the finding ID), and the empanelled-auditor letter required for the next regulator inspection or audit closure with the Comptroller and Auditor General (CAG). The report goes into the ministry's file-noting system, gets file-numbered, moves through the additional secretary's office and lands on the secretary's desk — and at every step a vendor-format Burp HTML export gets returned with objections. We ship in the format the ministry expects.

Common scopes for ministries and central PSEs we have delivered against: citizen-services portal — e-Office (NIC), parivahan-style transport portals, e-Hospital, the long list of state-deployed Mission-mode-project (MMP) portals; internal MPLS / NICNET / SD-WAN segmentation review including the dial-back from NIC datacentre to ministry LAN; data-exchange API between the ministry and state implementations where the centre publishes a master record and states consume / write back; Active Directory and RBAC review on the central IT estate; Aadhaar AUA / KUA integration audit against UIDAI's published compliance checklist and the data-vault tokenisation expectation; and the dependency on shared NIC infrastructure (NIC-hosted virtual machines, NIC-managed firewalls, NIC SOC feeds) where the boundary between in-scope and out-of-scope blurs daily.

Onsite kickoff in Delhi is next-day from Mumbai BKC — flights land at IGI Terminal 3 and consultants are at Shastri Bhawan, Rail Bhawan, Nirman Bhawan or the CGO Complex inside the morning, with badges arranged the previous evening through the ministry's security cell. For multi-week engagements we keep a Delhi-resident lead consultant onsite throughout the testing window — same person on the first kickoff and the final sign-off, no bait-and-switch staffing. The testing window itself routinely runs across weekends and government holidays because that is when the application owner can take portal downtime.

Government engagement plans always assume the ministry's own IT cell, the NIC team supporting the deployment, and (where the system holds Aadhaar data) the UIDAI compliance representative will need to sit through portions of the test live. We schedule those joint-test sessions in advance, share a daily testing-log e-mail with the additional secretary's office, and provide read-out memos after each major milestone so file-noting and approvals do not stall while waiting for the final report. The CERT-In incident-reporting clock — six hours under the 28 April 2022 directive — is treated as a hard SLA inside the engagement, with a pre-defined escalation path to the CERT-In handle.

Where the scope crosses state implementations of a centrally-sponsored scheme (CSS) — Ayushman Bharat, PMAY, e-Hospital state instances, agriculture extension portals — we coordinate with the state IT secretariat to evidence the boundary contract: what the centre owes (master record integrity, API contract enforcement, data-fiduciary obligations under the DPDP Act), what the state owes (instance hardening, regional language UI, state DPDP overlay), and where joint controls apply (Aadhaar masking, SDC hosting, BCP region). That avoids the most common audit gap on centre-state platforms and is the single most-asked-about clarification we have seen from CAG audit teams.

Adversary modelling for ministry estates is not theoretical. We test against the actual TTPs that have hit Indian government systems in the last 24 months — credential-stuffing waves against e-Office and parivahan-style portals, SQL-injection chains in regional MMP deployments, JWT misuse and IDOR variants on Aadhaar-AUA wrappers, ransomware-affiliate footholds (LockBit, ALPHV, RansomHub) on PSU IT estates, and the supply-chain compromise pattern where a third-party application-vendor's CI/CD pipeline became the foothold (a recurring 2024-25 pattern). The report explicitly maps each finding to the TTP and the threat actor most likely to weaponise it.

Procurement and commercial nuance is part of the engagement. Macksofy is GeM-listed (category 99 / cybersecurity audit services) and accepts direct purchase orders from central and state government buyers through the GeM portal; we also participate in CPPP and ministry-specific tenders. Our PAN, GST, MSME registration, CERT-In empanelment number and ISO 27001 / 9001 certification are kept current on the GeM dashboard so the procurement-cell verification on the bidder side completes in hours, not days. For ministries that procure through the National Informatics Centre Services Inc (NICSI) rate contract route, we deliver via NICSI's empanelment too.