Questions, answered plainly.

Ask four questions and insist on evidence for each. Who performs the test. Named, certified testers you are told about before you sign, not an anonymous pool. What they have found before. A public research record, Hall of Fame acknowledgements or disclosed advisories. What you receive. Ask for a redacted sample report before signing; it tells you more than any sales call. Whether retesting is included. If fixes are not re-verified, the engagement is incomplete by design.

Then check one more thing: whether the firm holds a security certification of its own. You are about to hand someone a list of live vulnerabilities in your platform.

A vulnerability assessment enumerates known weaknesses, usually with automated tooling, and reports them as a list. A penetration test attempts to exploit them, chains them together, and demonstrates real impact. The first tells you what might be wrong; the second tells you what an attacker can actually do. Most products sold as penetration tests in this market are vulnerability assessments with a different cover page. The tell is a report with hundreds of findings and no working proof of concept.

Because they are run as scans. An automated tool sends known payloads at known patterns; it cannot log in as two different users and compare what each can reach, and it has no model of what your application is for. Broken access control, business logic flaws, privilege escalation and chained exploits are the classes that cause breaches, and each one needs a human operator who understands what the system is for. A test that returns only informational findings usually means the surface was never authenticated against.

Any firm that answers that question with its own name, including this one, should be treated sceptically. Three things can be checked. The individual tester’s public record: Daniyal Nasir reached the Top 100 on HackerOne’s all-time leaderboard, with 100+ vendor Hall of Fame acknowledgements including Microsoft, GitHub, Intel and the U.S. Department of Defense. The firm’s own certification: Dunicot Private Limited operates a certified ISO/IEC 27001 ISMS. And the delivery record: 200+ delivered projects for 80+ organisations. Ask every shortlisted firm for the equivalent evidence and compare like for like.

Large firms offer breadth, brand recognition on an audit cover page and continuity if someone leaves. Specialists put the people who found those things on your engagement rather than supervising it from a distance. The practical question is who will be at the keyboard on your engagement: in a large firm that is frequently junior testers following a checklist, with a senior name on the report. Ask for the CVs and certifications of the people who will perform your test, and ask whether that is contractually guaranteed.

Penetration testing is an authorised simulated attack on your systems, carried out to find and prove the weaknesses a real attacker would use. It differs from a scan in that a human operator chains findings together and demonstrates actual impact: data read, an account taken over, money moved. The output is a report of what was proven, not a list of what might be wrong.

A penetration test asks how many weaknesses exist in a defined scope. A red team engagement asks whether a specific objective can be reached, such as moving money between accounts or obtaining customer records, and tests your detection and response along the way. Penetration testing gives you more findings; red teaming gives you fewer findings and a better picture of whether anyone would notice.

Read the findings, not the count. A real test produces findings a scanner cannot reach: broken access control between two accounts, business logic that can be raced, chained issues that compose into account takeover. Every finding should carry the full request and response, reproduction steps and a working proof of concept. A report with hundreds of findings and no proof of concept is a scan with a cover page.

Five to fifteen working days for a typical web application and API engagement, plus two to three days for reporting. Network engagements scale with host count; mobile adds roughly five days per platform. Add one to two weeks of lead time from signed scope to start, and allow for a retest two to four weeks after delivery once fixes are in.

A defined scope and written authorisation, test accounts (at least two per role, and two tenants if the product is multi-tenant), a staging environment where possible, and a technical contact for questions. API documentation, architecture notes and source access all help but are not required.

Denial-of-service and resource-exhaustion techniques are excluded by default. Exploits with known stability risk are flagged during scoping and run only with approval at an agreed time. Every request sent is logged, so any anomaly can be traced to the exact payload that caused it. Destructive actions against existing data are never performed without written approval.

You are told the same day, by the escalation contact agreed at scoping, with enough detail to act rather than waiting for the report. Critical findings that expose customer data or allow account takeover are not held back for a scheduled delivery date.

Yes. Every finding is retested in a clean session after remediation and closes only when re-exploitation fails. A signed attestation follows, recording what was raised, what was fixed and what was verified. Retesting is part of the engagement, not a separate line item.

Yes, with agreed rate limits, testing windows and a documented rollback path. A staging environment mirroring production is preferred, same authentication stack, comparable data volumes. Production testing is routine for read-heavy surfaces and handled more carefully where write operations are in scope.

Three documents. A technical report for your engineers with every finding, its severity, the full request and response, reproduction steps and a working proof of concept. An auditor-facing summary with scope, methodology, dates and outcomes. A redacted attestation letter with no exploitation detail, written to be shared with customers under NDA. Findings are mapped to whichever framework you agreed at scoping.

Provision the accounts first: at least two per role, and two tenants if your product is multi-tenant, because a single account cannot demonstrate a boundary between two. Then confirm the scope in writing, name an escalation contact, and tell us about anything fragile. Account provisioning is the most common reason an engagement starts late, so it is worth doing before the kickoff call.

Yes, when it is authorised in writing by a party entitled to grant that authorisation. Unauthorised access is a criminal matter in every market we work in, which is why every engagement runs under a signed letter naming the systems, the testing windows and the techniques excluded. Where you are not the asset owner, we require the owner's written authorisation before active testing begins.

You get the report and a readout session with the people who did the testing, then you remediate, then every finding is retested in a clean session and closed only when re-exploitation fails. A signed attestation follows, recording what was raised, what was fixed and what was verified. That attestation is usually the document your auditor or enterprise buyer actually wants.

Cost follows scope, not a price list: the number of applications, roles and endpoints, whether internal network testing is included, and whether source code is in scope. A fixed quote is issued after a short scoping call, with no hourly billing and no change orders mid-engagement unless you change the scope.

Yes. Scope is defined in writing and the price is fixed against it. If something in scope turns out to be materially larger than described, you are told before any additional work is done rather than after.

Yes, before scoping, not after. A mutual NDA is standard, and your own template is acceptable. Engagement data is handled under a certified ISO/IEC 27001 ISMS and destroyed on closure.

Typically one to two weeks from signed scope, depending on the current calendar. Engagements driven by an audit date or a customer deadline can often be brought forward. The constraint is usually your side’s account provisioning, not the calendar.

Yes. Dunicot Private Limited operates a certified ISO/IEC 27001 information security management system. The certificate and its scope statement are provided to clients and prospects on request under NDA, along with the current statement of applicability.

Three documents are produced: a technical report for your engineers, an auditor-facing summary with scope, methodology, dates and outcomes, and a redacted attestation letter for customers and prospects. Findings are mapped to whichever framework you agreed at scoping: SOC 2, ISO 27001 Annex A, PCI DSS, HIPAA safeguards or OWASP ASVS.

Annually as a baseline, which is what most frameworks expect, plus after significant change: new authentication, new roles, a new tenancy model, a payments integration or a major infrastructure migration. Teams deploying continuously typically run one full annual engagement and shorter delta tests after major releases.

Share the attestation letter, not the technical report. The technical report contains working exploitation detail and should stay internal. The attestation covers scope, dates, methodology, severity counts and remediation status, which is what a customer security review needs.

SOC 2 does not name penetration testing, but auditors ask for it and the monitoring criteria are hard to evidence without it. Testing supports CC4.1 on control monitoring, CC7.1 on vulnerability detection and CC7.2 on anomaly monitoring. For a Type II, run it before the observation window opens so findings are remediated and re-verified inside the period rather than sitting open in the auditor's sample.

Not by name. ISO 27001 requires that technical vulnerabilities be identified and managed (Annex A.8.8), that security testing happen during development and acceptance (A.8.29), and that control effectiveness be evaluated (Clause 9.1). Certification bodies consistently accept independent penetration testing as evidence for all three, and increasingly expect it for any organisation with a significant internet-facing estate.

Yes. PCI DSS requirement 11.4 mandates internal and external penetration testing at least annually and after any significant change, performed by a qualified tester who is organisationally independent of the system being tested. Where segmentation is used to reduce scope, that segmentation must also be tested, every six months for service providers and annually for merchants.

HIPAA does not name penetration testing. The Security Rule requires a risk analysis and periodic technical evaluation (45 CFR 164.308(a)(8)), and testing is how that evaluation is evidenced rather than asserted. OCR investigations have repeatedly found organisations with a completed risk analysis and controls that were never tested, which is the gap testing closes.

There is no formal expiry, but most auditors, enterprise buyers and cyber insurers treat a report as current for twelve months, and many ask for one dated within the last six. A report also stops being meaningful the moment the system changes materially, which is why significant releases usually trigger a delta test rather than waiting for the annual cycle.

Named, certified testers from our team, agreed with you during scoping and held to contractually. Not an anonymous pool, and not juniors working under a senior's byline. You can ask for the CVs and certifications of everyone assigned before you sign, and delivery is reviewed by our Principal Consultant. The certifications held across the team are listed on the credentials page.

HackerOne’s all-time leaderboard ranks researchers by reputation accumulated from valid, triaged vulnerability reports across public bug bounty programs. It is earned from findings that companies validated and paid for, which makes it one of the few security credentials that reflects demonstrated results rather than an examination.

Public Hall of Fame acknowledgements include Microsoft, the U.S. Department of Defense, GitHub, Intel, SAP, Booking.com, Starbucks, Docker Hub, DoorDash, Grab, ABN AMRO Bank, New Relic, ESET, Malwarebytes and more than eighty others, 100+ documented in total. These are public acknowledgements of responsible disclosure, not client engagements.

Yes. The best known is the 2018 disclosure that data belonging to 1.4 million Careem drivers was exposed, covered by Khaleej Times, Gulf News, Databreaches.net, MenaBytes and Zawya.

Yes. Endpoints are recovered from JavaScript bundles, mobile binaries, historical URL archives, GraphQL introspection and observed traffic. Undocumented endpoints are frequently the most productive part of an engagement, largely because nobody has reviewed them.

Yes: introspection exposure, alias batching against rate limits, field-level authorisation, query depth and cost limits, persisted-query CSRF and subscription authorisation over WebSocket. GraphQL moves authorisation to the field level, so every type and field is tested independently rather than per route.

Yes, where an application exposes them: prompt injection (direct, and indirect through retrieved content), tool and function-calling abuse, system prompt disclosure, retrieval poisoning, and authorisation boundaries on what the model can reach on a user’s behalf. The last is where the severe findings are: a model with more access than the user driving it.

Testing that starts from a standard user account rather than spending the engagement on initial access. Phishing eventually succeeds against every organisation; the useful question is what happens next. Assumed-breach testing answers how far one compromised workstation reaches, and it tells you more than proving that an email can be delivered.

For every medium-severity finding and above, yes: the full request and response, reproduction steps and a working proof of concept. A finding that cannot be reproduced in a clean session does not appear in the report.

By target: web application, API, mobile application, cloud, internal and external network, source code review, and IoT or embedded. By method: black box with no information, grey box with credentials and documentation, and white box with source access. Most commercial engagements are grey box, because starting an authenticated tester outside the login page spends your budget on reconnaissance rather than on findings.

Black box gives the tester nothing, which models an outside attacker but spends much of the engagement on discovery. White box gives source code and architecture, which finds the most per hour but is furthest from how an attack actually starts. Grey box gives credentials and documentation without source, and is what most engagements should be: it skips the reconnaissance an attacker would eventually complete anyway and spends the time on authorisation, logic and chaining.

External testing starts from the internet and asks what an attacker reaches without any access. Internal testing starts from inside the network, usually from a standard user account, and asks how far one compromised workstation reaches. Most organisations need both: the external test defines the perimeter, and the internal test answers what happens after a phishing email succeeds, which it eventually will.

OWASP Top 10 and OWASP ASVS for web and API coverage, OWASP MASVS for mobile, and PTES and NIST SP 800-115 for engagement structure. Those set the floor rather than the ceiling: the testing itself is driven by your application's own roles, tenancies and business logic, because a checklist finds what every checklist finds and the findings that matter are the ones specific to what you built.

Yes, including multi-cloud estates tested as one engagement. The escalation paths differ by provider but the pattern does not: identity is the perimeter, and the severe findings are usually two reasonable permissions that compose into access neither was meant to allow. Coverage includes identity and role escalation, exposed storage, metadata reachable from your own application, Kubernetes and CI/CD pipelines.