Penetration Testing for Regulated Firms in Gurugram: RBI, IRDAI, PCI DSS

• Scoping

  You hear back within one business day. A 30–45 minute call with the testers maps your critical and internet-facing systems against the clause that applies, and names what is out of scope.

• Written scope and fixed price

  Targets, test windows, rules of engagement, deliverables and price, in writing. Windows respect change freezes and settlement cycles. Not a day rate that quietly extends.

• Testing

  Manual and exploit-driven, backed by tooling rather than replaced by it. Anything critical reaches you within three hours of discovery, with proof, not at the end of the engagement.

• Remediation and retest

  The tester who found the flaw briefs your developer. Once fixes land we retest inside the same engagement and issue a verified retest report for your board pack and regulator file.

Durations: one to three weeks for most web or API scopes, plus the retest window. Internal networks, multi-entity estates, thick clients and IoT run longer.

• How can you serve a Gurugram bank or insurer from a Greater Noida West office?

  Most of the work never needs an address. Web applications, APIs, mobile apps and cloud accounts are reached over the internet, the way an attacker reaches them, so remote testing is the accurate version of the work rather than a cheaper substitute. What the branch at Golden-I, Greater Noida West gives a Gurugram client is the non-remote remainder: an internal network test run from inside your building, an architecture workshop with a whiteboard, a leadership readout in a room. We schedule those as on-site days in Gurugram, priced in the written scope, and we book whole days because tower access in Cyber City or Udyog Vihar needs a pre-approved pass and an escort. We hold two addresses, Greater Noida West and the registered office in Kanpur Nagar, and we will not invent a third. The practical benefit is time zone, not geography: a confirmed critical finding reaches you the same hour, not the next morning.

• Does the RBI require an annual penetration test, and does our last test still count?

  Under the RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, issued on 31 July 2026, critical information systems and customer-facing systems in the DMZ need a vulnerability assessment at least every six months and a penetration test at least every twelve months, with a risk-based cycle for non-critical systems and testing across the lifecycle, including production after implementation. The clauses sit at para 151 for commercial banks, para 150 for small finance banks and para 121 for NBFCs, where they apply to middle, upper and top layer entities. So confirm your layer first. The clock runs from your last test, not from your next audit date, which is the trap: booking a test for the month the auditor arrives leaves no remediation period. Testing must be done by independent information security experts or auditors. Our guide to the 2026 RBI Directions sets the chapters out entity by entity.

• We are an insurance company under the IRDAI guidelines. What cadence applies?

  We are not going to give you a number we cannot source. The IRDAI Information and Cyber Security Guidelines, 2026 require periodic vulnerability assessments, penetration testing and audits. The only source we have been able to retrieve is a secondary brief carrying that sentence and nothing further, and the IRDAI site did not serve the circular during our checks. So read the circular, or ask your compliance team for the copy they hold, and bring the clause to the scoping call. We will scope against your text rather than a vendor's summary of it. Where the circular requires an empanelled signature, be aware that SecureRoot is not CERT-In empanelled; we do the testing, remediation and retest beside the auditor who signs.

• Our parent company owns the application. Can you still test it?

  Yes, with written authorisation from whoever owns the asset, which on a captive or GCC scope usually means your global parent as well as your entity. That permission is the slowest part of nearly every engagement of this kind, so raise it on the first call rather than the week before the window opens. Three more things we will ask about: whether the group security policy specifies a tester qualification, accreditation or empanelment the supplier must hold, since that can rule us out and we would rather say so early; whether change freezes, release trains or settlement cycles close parts of the calendar; and who is accountable for a critical finding when the owning CISO is five or eight hours behind India. Where a finding is the parent's or a vendor's to fix, the report still comes to you, written so it survives being forwarded, and we retest on your instance to confirm the fix held.

• Do we need a CERT-In empanelled auditor for our Gurugram engagement?

  It depends on who is asking, and you should be wary of any firm that implies empanelment is always required or never matters. It genuinely matters in some regulated finance work: a SEBI CSCRF audit or VAPT requires a CERT-In empanelled auditing organisation, many government and public-sector tenders name the panel, and some insurance and banking requirements do too. For an enterprise customer's security questionnaire, a SOC 2 or ISO 27001 audit, a PCI DSS assessment or your own assurance, what is wanted is a manual test with proof for every finding and a retest to closure, and empanelment is not part of that. Our position, stated plainly: SecureRoot Risk Advisory LLP is not a CERT-In empanelled auditing organisation, and we will not blur the line. Where an empanelled signature is required, that auditor signs. We do the hands-on testing that decides how the audit goes, and we tell you which situation you are in on the call.

• Can one test produce evidence for PCI DSS, RBI and ISO 27001 at once?

  Usually, if it is scoped for all of them at the start. PCI DSS requirements 11.4.1 to 11.4.3 want a documented methodology based on industry-accepted approaches, external and internal testing on a defined cadence, and segmentation testing where you claim segmentation. The RBI Directions want independent testing of critical and customer-facing systems on their own cycle. ISO 27001 maps the same work to its technical-vulnerability and secure-development controls, and SOC 2 expects the systems in scope to be tested. Those overlap heavily but not completely, so the differences are decided in scoping: cardholder data environment boundaries, which internal segments are in, and whether your regulator's definition of critical matches your own asset register. The same team runs those compliance programmes, so the report is written to satisfy the control instead of being reinterpreted afterwards. Tell us every framework in play and we will scope one engagement rather than bill the same work twice.