(Security testing)

Security testing that tells you what an attacker could actually reach

Security testing is defensive work: with your written authorisation and an agreed scope, we look for the weaknesses in your own systems before somebody less friendly does, then help you close them.

Talk to an engineer What we deliver
Engineer writing code
Security testing

(What a test is and is not)

A penetration test is a time-boxed, authorised attempt to reach something you would rather nobody reached — an admin account, another tenant’s data, the payment flow. It is not a vulnerability scan with a logo on it, and it is not a certificate. What you get is a list of ways in, ranked by how much damage each one buys.

Everything happens under a signed scope and a rules-of-engagement document that names the targets, the window, the accounts and the person to ring if something goes wrong. Nothing outside that scope is touched.

(What we deliver)

Penetration testing services we run

Each test is scoped against a specific asset and a specific threat. Most clients start with the application their customers log into.

  1. Authenticated testing across roles, aimed at the flaws that matter in real applications: broken access control between accounts, injection, insecure deserialisation, session handling, file upload, and business logic that lets an order be priced at zero.

  2. iOS and Android builds tested against the OWASP MASVS: local storage of tokens and personal data, certificate pinning, root and jailbreak handling, deep links, and the back end the app talks to — which is where most mobile findings actually live.

  3. REST and GraphQL endpoints tested from the outside in, using your OpenAPI spec where one exists. Object-level authorisation, mass assignment, rate limiting, token scope and the internal services that quietly trust anything arriving from inside the network.

  4. A workshop before the code exists, or before a redesign: what the system holds, who would want it, and where the trust boundaries sit. Cheaper than finding the same answers in a report, and it shapes what the later test should concentrate on.

  5. Two documents — a summary a board can read, and a technical report with reproduction steps, evidence, CVSS scoring and a concrete fix per finding. Once your team has worked through them, a retest of everything raised is included.

  6. If a researcher emails you about a bug, someone has to judge whether it is real, how bad it is and what to say. We triage inbound reports, verify them, and help you publish a responsible-disclosure policy so the next one arrives somewhere sensible.

(What testing uses)

(How we work)

How a penetration test runs

Five stages over one to three weeks, depending on scope. Nothing starts until the authorisation document is signed by someone entitled to sign it.

  1. 01

    Scope and authorisation

    We agree the targets, the environment, the test window, the user roles we are given and the limits — no denial-of-service, no social engineering unless you ask for it. You sign the authorisation; if the system is hosted by a third party, they are told too.

  2. 02

    Reconnaissance

    Mapping what is actually exposed: hosts, endpoints, parameters, technologies, versions and forgotten subdomains. Most engagements turn up at least one thing the client did not know was reachable from the internet.

  3. 03

    Testing

    Manual testing against ASVS, supported by tooling rather than led by it. High-severity findings are reported to you the day they are found, not held back for the report, so you can start fixing before the test ends.

  4. 04

    Reporting

    A technical report with reproduction steps, evidence and a specific remediation per finding, plus a short summary for people who will not read it. A walkthrough call with your developers comes as part of the price.

  5. 05

    Retest

    When the fixes are in, every finding is retested and the report is reissued with the current status. That reissued document is the one you send to the customer or insurer who asked for the test.

(Why Team of Keys)

What makes a test report useful

Most of the value is in what happens after the testing stops. A report that a developer cannot act on has cost you money and changed nothing.

  1. 01

    Manual testing, tool-assisted

    Scanners find missing headers and old libraries. People find the endpoint that returns another customer’s invoice when you change one digit. The second kind is why you are paying for a test.

  2. 02

    Findings rated on your context

    Severity is judged against what the flaw reaches in your system, not against a generic score. An exposed staging database with real customer data outranks a theoretical issue in an internal tool.

  3. 03

    Fixes, not just names

    Each finding names the affected component and the change that closes it — the header, the check, the library version. Where you want it done rather than described, the same bench can implement and retest.

  4. 04

    Retest included, not upsold

    A test without a retest proves nothing was fixed. One retest of every raised finding is inside the agreed price, so the final report reflects the system as it now stands.

  5. 05

    Honest about accreditation

    We test to OWASP ASVS and report with CVSS, and we hold no CREST, OSCP or equivalent accreditation. If your insurer requires an accredited body, that is worth knowing before you buy, so we say it first.

(Related)

More in quality & security

All quality & security services

(FAQ)

Questions, answered

It is priced by scope and days, not by an hourly rate. A single web application with two or three user roles is typically five to eight testing days, plus reporting and a retest. Larger scopes — several applications, an API estate, a mobile app and its back end — are quoted per asset after a short scoping call.

One to three weeks end to end for most applications. Scoping and authorisation take a couple of days, active testing runs five to ten working days, the report follows within a week of testing finishing, and the retest happens whenever your fixes are ready — usually a few weeks later.

A staging environment that genuinely mirrors production is the safer choice, and we prefer it. Where staging differs materially, or does not exist, production testing is possible with a narrow window, agreed rate limits and a named contact on call. Either way the decision is yours and it is written into the scope.

Careful testing rarely does, but the honest answer is that any testing carries some risk. We avoid destructive techniques, exclude denial-of-service by default, and work in an agreed window with your team reachable. Take a backup before we start, and tell us about any fragile component so it can be handled gently or excluded.

A technical report with reproduction steps, evidence and remediation per finding; a short executive summary; a CVSS-scored finding list you can paste into your tracker; a walkthrough call with your developers; and a reissued report after the retest, which is the version to share with customers who asked for the test.

(Global presence)

Nine countries, one studio behind them.

Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.

NoidaDrag to turn

Studio · Noida, India · --:--

(Next step)

Get a scope for your first test

Tell us what the application does, who logs into it and what you would least like exposed. You get a scope, a day count and a fixed price.

START

Or write to info@teamofkeys.com · Noida, India