Penetration Testing Services in India

What Is a Penetration Test, and How Is It Different From a Vulnerability Scan?

A vulnerability scan compares what it can observe against a database of things known to be broken, and prints a list. It is fast, cheap, repeatable and worth running constantly. A penetration test is a person, given a window of time and a defined boundary, trying to achieve a specific outcome inside your system. Read a different customer's records. Get from a low privilege account to an administrator. Get from your public web application to something on the internal network that was never meant to be reachable from it.

The difference shows up in the shape of the output. A scan says your library version has a published advisory. A test says that library is only reachable through an endpoint that already requires authentication, so it is not your problem this quarter, but the avatar upload feature next to it will fetch any URL you give it, and that is how somebody reads your cloud instance metadata. One of those two statements changes what your team does on Monday.

Buyers get sold the two interchangeably, which is why so many reports labelled penetration test are a scanner export with a cover page. You can spot the substitution quickly. If the findings have no reproduction steps, if every risk rating is exactly the tool's default severity, if nothing in the report required knowing what your application does for a living, you bought a scan. A real test contains findings the tool could not have produced, because they depend on understanding that invoice 4471 belongs to a different company.

There is a third term in the mix that muddies things further. A vulnerability assessment sits between the two: it is human-reviewed, it uses tooling heavily, and it tells you what is wrong without proving exploitability. That is often the right purchase for a large estate where the goal is coverage. A penetration test goes narrower and deeper and ends with proof. Knowing which of the three you actually want is most of the value of the scoping call, and we will happily tell you that a test is the wrong purchase this quarter.

This page is about the human-led engagement. The continuous, automated half of the problem, meaning static analysis on pull requests, dependency and secrets scanning, authenticated dynamic scans on a schedule, lives on our security testing services in India page. The two are complements, not alternatives. Tooling stops the same class of bug reappearing every Tuesday. A test finds the classes your tooling cannot imagine.

Rules of Engagement and the Authorisation Letter

We do not start without written permission. Not because it is a formality we have to satisfy, but because the exact activity we are being paid for is, without that permission, a criminal offence in most of the jurisdictions our clients sit in. The UK has the Computer Misuse Act. The United States has the Computer Fraud and Abuse Act and a patchwork of state statutes. India has the Information Technology Act. Australia, Canada and New Zealand each have their own equivalents. The specifics are your counsel's territory rather than ours, and we will tell you that rather than pretending otherwise, but the operating rule is simple and absolute.

Who has to sign

Somebody with actual authority over the systems in scope. Not the engineer who invited us, unless that engineer also owns the systems. On a larger organisation this usually means a named executive or the person accountable for the platform, and it frequently takes longer to obtain than the client expects, which is why we raise it in the first conversation rather than the week before testing.

Where the target is hosted or operated by somebody else, that party signs too, separately. Where the data in the environment belongs to your customers, you confirm in writing that exposing it to a tester is something you are entitled to do. This is a question we ask rather than assume, and occasionally the answer sends us to a sanitised environment instead.

What the rules of engagement document actually contains

A short document, agreed by both sides, that answers the questions people otherwise argue about at two in the morning. Precisely which assets are in scope and which are explicitly excluded. The testing window, including whether weekend or overnight testing is permitted. The source addresses our traffic will come from, shared in advance so your monitoring team can distinguish us from a genuine intrusion. Named emergency contacts on both sides with out of band details, because if we take something down the escalation path cannot depend on the thing we took down.

Then the technique boundaries. Denial of service testing in or out. Automated fuzzing at what rate. Whether we may attempt password guessing against live accounts and what lockout policy exists, because an unthinking credential attack that locks out three hundred real users on a Tuesday morning is an incident we caused. Whether we may pivot into internal networks on success, and how far. Whether social engineering against your staff is permitted, which is a different conversation involving your HR position and local employment law.

Finally, the data rules. What we may extract as proof and what we must not, how evidence is stored and encrypted while the engagement runs, who on our side has access, and what happens to it afterwards. Retention and destruction terms are agreed in writing before testing starts rather than assumed.

Announced or unannounced

A decision worth making deliberately. If your security operations team knows the test is happening, you get maximum testing efficiency because nothing gets blocked mid-engagement and no incident bridge gets opened over our traffic. If they do not know, you also get a free measurement of whether they notice, which is genuinely valuable information, at the cost of some wasted effort and a real risk of somebody's weekend being ruined.

The middle path most teams settle on is that one or two people know, they hold the authorisation letter and our source addresses, and the wider team does not. If detection is what you actually want to measure, though, you want a red team exercise rather than a penetration test, and that distinction is covered further down this page.

The WAF question

Almost nobody decides this in advance and it changes results substantially. If we test through your web application firewall, we are testing the combination of the firewall and the application, and a finding that gets blocked at the edge may be reported as low risk while the underlying flaw is untouched. If we test with our source addresses allowlisted past it, we are testing the application on its own merits and finding what is actually in the code.

Our preference on most engagements is to do both, sequentially, and report separately. First unfiltered, to learn what the application does when nothing protects it. Then filtered, to see what the edge genuinely stops. The gap between those two lists is the honest measure of how much of your security posture is a rented product rather than your code.

Methodology: OWASP WSTG, PTES and the Standards That Actually Get Used

Methodology is what stops a penetration test being one person's habits. Two testers of similar ability will find different things; a documented methodology narrows that gap and makes the report auditable. When your customer's security team asks how the test was conducted, the answer needs to be a named standard and a checklist rather than a description of somebody's instincts.

OWASP Web Security Testing Guide

The WSTG is the working checklist for web application testing, and it is the one we run against by default for anything browser-facing. It is organised into categories that map onto how applications actually fail: information gathering, configuration and deployment management, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic and client-side testing.

Its value is coverage rather than insight. Working through it stops the ordinary embarrassments, meaning the session token that never expires, the password reset link that stays valid after use, the CORS policy that reflects any origin with credentials enabled. It will not find the clever chain on its own. It is the floor, not the ceiling, and a tester who only produces WSTG checklist items has not really tested anything.

PTES, for the shape of the engagement

The Penetration Testing Execution Standard describes the engagement rather than the checks: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. Seven phases, and the two most commonly skipped are the first and the third.

Threat modelling before exploitation is the phase that separates a productive test from a scattershot one. Half a day spent working out what an attacker would actually want from this system, which assets are worth money, which roles are worth becoming, tells you where to spend the remaining four days. Testing every endpoint equally is how you run out of time before reaching the payment flow.

OWASP ASVS, when you want a level rather than a list

The Application Security Verification Standard turns security into graded requirements across three levels, from a baseline appropriate to most applications up to a level intended for systems handling the highest value transactions. It is a verification standard rather than a testing methodology, which makes it useful in a different way: it gives you and your customer a shared vocabulary for how much assurance was actually obtained.

We use it where the driver is a contractual or procurement requirement, because a statement that an application was verified against a named ASVS level communicates far more than a count of findings. It also gives your engineering team a target to build against between tests rather than a backlog to react to.

The others, and when each is right

The OWASP API Security Top 10 is the reference for anything where the client is not a browser, and its top entries are dominated by authorisation failures rather than injection, which tells you where to look. The OWASP Mobile Application Security Testing Guide and its verification standard cover mobile builds properly, including the parts people forget such as local data storage, certificate pinning and what happens to the application when the device is rooted. NIST Special Publication 800-115 is a technical guide to information security testing that procurement teams in regulated sectors often reference by name. OSSTMM offers a more measurement-focused approach for infrastructure and physical testing.

Threat behaviour gets described with MITRE ATT&CK, which is more useful in post-exploitation reporting than in web application findings, because it lets your defensive team map what we did onto techniques their tooling claims to detect. Findings get classified with CWE identifiers, which matters more than it sounds: CWE-639 tells your developer this is an authorisation failure through a user-controlled key, whereas the phrase insecure direct object reference has been used to mean four different things over the years.

None of these standards replace judgement. They stop you missing the obvious and they make the engagement defensible. The findings that actually change your risk position come from a person who understood your business well enough to know what a bad day looks like for you.

Exploitation, and the Lines We Do Not Cross

Exploitation is where a suspected weakness becomes a proven one. Until something is exploited it is a theory, and theories get argued about in remediation meetings until somebody decides the risk is acceptable. Proof ends that argument in ten seconds.

The working toolkit, and where the judgement sits

Burp Suite Professional carries most web application work, and the parts that matter are the unglamorous ones. Repeater for hand-crafting a request forty times in a row. Intruder and Turbo Intruder for controlled parallelism when testing race conditions. The Autorize extension for replaying every request as a second, lower privileged user and flagging the ones that still succeed, which finds authorisation gaps faster than any other single technique we use. OWASP ZAP covers similar ground and is what we reach for when a client needs the tooling reproducible without a commercial licence.

Beyond that, nuclei for templated checks against known issues at scale, sqlmap once injection is confirmed by hand rather than as a discovery tool, jwt_tool for token manipulation, and Metasploit for a subset of infrastructure work where a reliable public module exists. Naming the tools is the easy part. The judgement is in knowing that sqlmap fired blindly at an application produces noise and occasionally damage, while sqlmap pointed at a parameter a human already confirmed is quiet and precise.

What proof looks like, and what it does not

Proof is the minimum demonstration that establishes impact. For a SQL injection, that is the database version string and a count of rows in a sensitive table, not a dump of the table. For an authorisation flaw, that is a screenshot of one test account reading a second test account's record, with both account identifiers visible. For a server-side request forgery, that is a response from an internal address that should not be reachable.

What proof is not: exfiltrating real customer data to demonstrate that it is exfiltratable. Encrypting anything. Modifying production records. Leaving any artefact behind. If a finding genuinely cannot be proven without crossing one of those lines, it gets written up as unproven with the reasoning, and we ask you whether you want to authorise the step in a controlled way, usually against staging with a specific person watching.

Cleanup as part of the work

Every account created, file uploaded, webshell placed, configuration touched and payload stored is logged as it happens and removed at the end, with the removal confirmed in writing in the report appendix. Test artefacts that outlive the engagement are a genuine hazard: a proof of concept file left in an upload directory is an unauthenticated remote code execution that you now own and did not know about.

The same log serves your incident response team afterwards. When somebody finds an odd entry in an audit trail three weeks later, being able to match it against our timestamped activity record saves a day of panic. We provide that record whether or not anybody asks for it.

Business Logic Flaws That No Scanner Will Ever Find

This is the category that justifies paying for a person. A logic flaw has no signature. The request is well formed, the input validates, the authentication is correct, no library is out of date, and the outcome is still wrong because the application permitted a sequence of legitimate actions that combine into something it should have refused.

How we find them

By learning the business first. Before attacking, we map every workflow that moves money, grants access, changes an entitlement or transitions a record through states. For each step we write down the rule it is supposed to enforce and who is supposed to be able to trigger it. Then the attack is simply an attempt to reach the end state without satisfying the rules along the way.

The manipulations that work are consistent across industries. Skip a step by posting directly to a later endpoint. Repeat a step that was meant to happen once. Reverse a step and check whether its side effects reverse too. Run two requests in parallel to catch a check-then-act gap. Send a negative number, a very large number, a different currency, a value in a unit the developer did not consider. Replay a token issued before a permission was revoked. Change a value the client was never supposed to modify because the server assumed the interface would not let you.

Three shapes we look for on almost every engagement

The first is a discount or credit that can be applied more than once. Checkout flows validate a coupon at application time and then trust that validation at settlement. Fire twenty redemption requests within the same few milliseconds and a single-use code is frequently accepted several times, because the check and the write are not in one transaction. Turbo Intruder exists largely for this test. The fix is almost never more validation; it is a database constraint or an atomic operation, because validation at the application layer cannot win a race against itself.

The second is a workflow state machine that only validates locally. An approval process with four stages where each endpoint checks that its own inputs are valid but not that the previous stage completed. Post the final approval payload directly and the record transitions to approved without ever having been reviewed. This is common in lending, insurance, procurement and anything with an internal sign-off. The fix is to make the transition itself the guarded operation rather than guarding each form.

The third is entitlement drift in multi-tenant products. A user is removed from a workspace, but an existing session token still carries the old claim and remains valid for its full lifetime. Or an account downgrades from a paid tier and the feature flag is enforced in the interface while the underlying API still answers. Both are found the same way: perform the change of state, then replay every request captured before it and see what still works.

Why your test suite will not catch these

Functional tests verify that the application does what it is supposed to do. Logic testing asks whether the application refuses what it is supposed to refuse, and nobody writes that test because nobody thought of the sequence. The gap is structural rather than a sign of a careless team. It is also why these findings tend to be the ones that generate the longest remediation discussion, since the fix is frequently a design change rather than a patch.

The Report: Evidence, Reproducibility and Risk That Means Something

The test is the work. The report is the product. A finding your developer cannot reproduce is a finding that gets marked cannot reproduce and closed, and everybody has wasted their money.

What every finding contains

A plain description of what is wrong and why it matters to your business specifically, not a paragraph copied from a vulnerability database. The affected assets, listed precisely. The exact reproduction steps: the request in full, the account used, the timestamp, any prerequisite state, and what the response looked like. Evidence in the form of annotated screenshots or captured traffic, redacted where it contains real data. A risk rating with the reasoning shown rather than asserted. Remediation guidance specific enough to act on, including the pattern to fix rather than only the instance we found.

The reproducibility bar is the one worth being strict about. The test is whether a developer who has never spoken to us can follow the steps and see the same result on a Tuesday morning. If they cannot, the finding is not finished. That standard costs us time during write-up and saves your team considerably more during remediation.

Structure that survives contact with an organisation

An executive summary that a non-technical reader can act on, stating what was tested, what the overall position is and what the two or three things that matter most are. The scope and methodology section, including dates, standards used and what was not tested and why. That last part is the one auditors read first. The attack narrative walking the chains. The detailed findings. Then appendices with the activity log, the cleanup confirmation and any raw tool output worth keeping.

We deliver findings as they are confirmed rather than only at the end. If something critical is found on day one, you hear about it on day one through the agreed escalation contact, not eleven days later when the document is formatted. Anything that suggests an existing compromise rather than a theoretical one stops the test and goes to you immediately.

CVSS, and why it is not the same as your risk

Every finding gets a CVSS score because your customers, auditors and internal processes expect one, and a shared numeric scale is genuinely useful for comparison across tests. But the base score describes a vulnerability in the abstract, on a hypothetical system, with no knowledge of yours. Two findings with an identical 7.5 can differ by an order of magnitude in what they would actually cost you.

So we score twice. The CVSS vector, shown in full so your team can see the assumptions rather than just the number, including the temporal and environmental considerations where they apply. Then a separate business risk rating that accounts for what the affected asset holds, whether it is internet-facing, how many customers are affected, what regulatory exposure follows, and how hard the attack actually is to execute given your specific controls.

The gap between those two ratings is where the useful conversation happens. A 9.8 on an internal service reachable only from a network segment that six people can enter may deserve to sit behind a 6.5 on your public sign-up flow. Reporting only the first number tells your team to fix the wrong thing first, and doing that repeatedly is how security teams lose credibility with engineering.

Where a finding maps to something under active exploitation in the wild, we say so and cite the source rather than leaving you to work it out. A moderate score on something being exploited today outranks a critical that nobody has ever used.

Web, API, Network, Cloud and Mobile: What Changes Per Target

The methodology holds across targets. What changes is where the interesting failures live, and scoping a cloud review as though it were a web application test is a common way to buy the wrong thing.

Web applications

The bulk of most engagements. Authentication and session handling, authorisation across roles and tenants, input handling at every trust boundary, business logic, file handling, client-side issues including cross-site scripting that survives the actual template layer and content security policy that is present but permissive enough to be decorative. Single-page front ends move much of the interesting surface into the API behind them, so a modern web test is usually an API test with a browser attached.

APIs

Authorisation dominates. Object level checks on every endpoint that takes an identifier, function level checks on every administrative operation, and property level checks because an endpoint that returns the whole object including fields the interface never shows is a quiet data leak. Beyond that: mass assignment, rate limiting and resource consumption, deprecated versions still routed, inconsistent enforcement between the gateway and the service behind it. GraphQL brings its own set, including introspection left enabled, deeply nested queries as a denial of service vector, and batching used to bypass rate limits that count requests rather than operations.

Network and infrastructure

External infrastructure testing looks at what is exposed, what versions are running, what authenticates and what does not. Internal testing, which usually starts from an assumed foothold, looks at segmentation, service authentication, credential reuse across hosts, and in Windows estates the Active Directory relationship graph. The recurring finding is not a vulnerable service. It is that the network is flatter than the architecture diagram claims.

Cloud configuration

Identity is the perimeter here, so identity is where the review concentrates: over-permissive roles, wildcard policies, trust relationships that allow assumption from unexpected accounts, long-lived access keys that should have been federated credentials, and the absence of boundaries around what a compromised workload can request. Then storage exposure, network controls, key management, and whether audit logging is enabled everywhere and actually retained. Tooling such as ScoutSuite and Prowler gives the configuration baseline quickly; the human work is the exploitation path from a foothold to the data. Identity design across your estate is covered by our identity and access management work.

Mobile applications

Both halves matter and clients usually scope only one. On the device: what is stored in local databases, preferences and caches, whether certificate pinning is implemented and how easily it is bypassed with a hooking framework, what the application does when the device is rooted or jailbroken, what leaks into logs and screenshots. On the server: the API the application talks to, which is where the real risk lives and which is often less protected than the web equivalent because the team assumed the mobile client was the only consumer.

How Does a Penetration Testing Team in India Work Across Your Timezone?

This gets asked in the first call and it deserves an honest answer rather than a claim about follow-the-sun coverage.

The real overlap numbers

A standard working day here runs 09:30 to 18:30 IST. Against the UK that gives roughly four hours of live overlap in your morning. Against continental Europe, a little more. Against the Australian east coast, about four hours in your afternoon, and New Zealand is tighter still at the edges. Against US Eastern time it gives you almost nothing, perhaps the first half hour of your day. Against US Pacific, effectively zero.

Where the overlap is genuinely too small, the answer is a shifted rota rather than a promise. A team working 13:00 to 22:00 IST buys a US Eastern client about three and a half hours of proper overlap. That is a real option and it has a real cost, in coordination and in the fact that a shifted schedule is harder to staff consistently, so it is agreed with you before the engagement rather than assumed. We will not tell you that continuous coverage is free.

Why testing tolerates low overlap better than most work

The execution phase does not need you awake. Testing is solitary work against systems that are running whether or not anybody is at their desk, and there is a reasonable argument that a tester working while your traffic is at its lowest is safer for you. What does need synchronous time is a smaller and more predictable set: the scoping conversation, the kick-off confirming access works, any live escalation, and the findings walkthrough at the end. Four meetings, scheduled in advance, inside whatever window we agree.

Everything else runs written-first. A daily status note covering what was tested, what was found, what is planned next and anything blocking, delivered before your morning. Findings raised in a shared tracker as they are confirmed rather than held back. Critical findings escalated immediately through an agreed out of band contact, which is the one path that must not wait for a working day on either side.

The talent question, answered honestly

India has a deep offensive security community, visible in bug bounty leaderboards, CVE credits and the research presented at conferences here. It also has a large volume of people who have completed a course and never tested a live system, which is why the market is genuinely hard to buy from if you cannot assess capability yourself.

We are not going to make a claim about credentials on a marketing page. What we will do is let you assess the work directly before committing: ask to see a redacted report from a comparable engagement, ask who specifically will run your test and what they have worked on, and ask them to talk you through a chain they built. A tester who can explain how four low findings became a critical, in their own words, is demonstrating something no certificate demonstrates. That is the conversation we would want if we were buying this, so it is the one we offer.

Pen Test, Red Team, Purple Team or Bug Bounty: Which Do You Need?

These four get used interchangeably by people selling them, and buying the wrong one wastes both money and the appetite your organisation has for this kind of work.

Penetration test

A defined scope, a defined window, maximum coverage of that scope, findings documented for remediation. Your team usually knows it is happening. It answers the question of how much of this specific thing is breakable. This is the right purchase for the large majority of organisations, and it stays the right purchase until it stops producing meaningful findings.

Red team

Objective-based, stealth-oriented, broad scope, and aimed at your defenders rather than your code. The question is not what vulnerabilities exist; it is whether your monitoring, alerting and response actually work when somebody is deliberately trying to avoid them. It is more expensive, produces far fewer findings, and is close to worthless if a penetration test would still surface straightforward issues, because it will simply reach the objective through the front door and tell you nothing new.

The prerequisite is a defensive capability worth measuring. If you have no security monitoring, a red team exercise measures the absence of something you already know is absent.

Purple team

Attack and defence in the same room, working through techniques collaboratively and checking in real time whether each one is detected. Less a test than a training and tuning exercise. It is the highest-value option for a team that has detection tooling and wants to know how much of it actually fires, and it improves your defensive posture faster than an adversarial exercise because the feedback loop is minutes rather than weeks.

Bug bounty

Continuous, broad, driven by many people, paid per valid finding. Excellent for breadth and for the long tail nobody would have thought to look for. Poor for coverage assurance, because you cannot direct where the effort goes and you cannot prove anything was examined. It also carries an operational load people underestimate, since somebody has to triage a stream of submissions of wildly varying quality every week.

A bounty complements a penetration test rather than replacing it. If somebody asks whether your payment flow was tested, a bounty programme cannot answer, and no auditor will accept it as evidence that it was.

Where This Sits Alongside Our Other Work

A penetration test is one instrument. It works best when the things it finds have somewhere to go.

The continuous, automated half of application security, meaning static analysis on pull requests, dependency and secrets scanning, and authorisation tests that run on every merge, is covered by our security testing work. Broader programme-level questions, architecture review and defensive design sit with our cybersecurity services. Where the findings concentrate on identity, roles and token handling, our identity and access management work is where the redesign happens. Where they concentrate on the container platform, our Kubernetes engagement covers cluster hardening properly. And where remediation needs hands rather than advice, we can put engineers directly on the codebase.

The sequence we would suggest to most teams, if asked: fix the reproducibility and dependency basics first, get automated checks running so new bugs stop arriving, then buy a test to find what the automation structurally cannot see. Testing a codebase that has never had a static analyser pointed at it means paying a human to find things a machine would have found for nothing.