Most organisations in Bangladesh buy their first penetration test without a clear picture of what they are buying. They approve a quote, a team they have never met disappears for a fortnight, and a PDF lands in the CISO's inbox with a severity table and some screenshots. If the findings are serious, nobody is quite sure what to do first. If the findings are thin, nobody is sure whether that means the systems are sound or the test was shallow.
This is a walkthrough of what a vulnerability assessment and penetration test actually involves, stage by stage, and — more usefully — what your own team is doing at each point. A VAPT is not something done to your organisation. The engagements that produce real change are the ones where the client is active throughout.
Before anything starts: scoping
Scoping is where most engagements are won or lost, and it is the stage clients most often want to rush.
The scoping conversation should establish four things:
- What is in scope. Specific IP ranges, domains, applications, APIs and mobile apps. “Our website” is not a scope. “app.example.com.bd, its REST API, and the admin panel at admin.example.com.bd” is.
- What is explicitly out of scope. Third-party services you do not own, production payment processors, anything your hosting provider's terms forbid testing.
- What kind of test. Black box (no credentials, simulating an external attacker), grey box (limited credentials, simulating a compromised low-privilege user), or white box (full access and source code). Grey box gives the best coverage per taka for most organisations.
- Rules of engagement. Testing windows, escalation contacts, and what happens if the team finds something critical mid-test — that last one matters more than people expect.
What your team does: nominate a single technical point of contact with authority to answer questions quickly. Engagements stall when every clarification has to travel up and down an approval chain.
Week 1 — Reconnaissance and automated assessment
The first week is mapping. The testing team enumerates your external surface: subdomains, exposed services, technology versions, certificate details, DNS records, and anything your organisation has leaked into public view without noticing.
Automated vulnerability scanning happens here too. This is the “VA” half of VAPT, and it is genuinely useful for coverage — a scanner will check thousands of known issues faster than a human can. But a scanner-only report is not a penetration test, and any vendor selling you one at pentest prices is selling you a commodity at a premium.
What your team does: expect questions about assets you may have forgotten. A staging server someone spun up in 2023 and never decommissioned is one of the most common serious findings in Bangladeshi organisations, and it almost always surfaces in week 1.
Week 2 — Manual testing and exploitation
This is where a real engagement separates from a scan. Human testers work through the things automation cannot reliably find:
- Business logic flaws — can a user change a price, skip a payment step, or approve their own request? No scanner understands your workflow well enough to test this.
- Broken access control — can a low-privilege user reach data belonging to another tenant by changing an ID in a URL? This is consistently among the most common serious findings in web applications, and it is almost entirely a manual-testing discovery.
- Authentication and session handling — token expiry, password reset flows, multi-factor bypass paths.
- Chained vulnerabilities — two medium findings that combine into a critical one. A scanner reports them separately; a tester notices they connect.
Where the rules of engagement permit, findings are exploited rather than merely reported. There is a meaningful difference between “this parameter appears vulnerable to injection” and “here is the customer table we extracted through it.” The second one gets budget approved. The Shwapno breach is a reminder of what that data is worth once it leaves your control.
What your team does: stay reachable. If a tester finds something critical — active compromise, exposed customer data — you want that call answered within the hour, not at the end of the engagement.
Week 3 — Reporting
A useful report has two distinct audiences and should be written for both.
The executive summary is for people who will not read the technical detail. It should state, in plain language, what an attacker could do, what it would cost the organisation, and what the three most important fixes are. No CVSS vectors, no tool output.
The technical findings are for the people fixing things. Each finding needs: a clear description, evidence that it is real, the exact steps to reproduce it, a severity rating with the reasoning behind it, and a specific remediation — not “implement input validation” but “parameterise this query in this file.”
Findings should be ranked by real risk in your environment, not by raw CVSS score. A critical vulnerability in a system with no sensitive data and no network path to anything else may matter less than a medium in your payment flow. A report that does not make that judgement is offloading the hardest part of the work back onto you.
What your team does: read the executive summary before the debrief call, and come with questions. The debrief is the most valuable hour of the engagement and it is routinely wasted on a slide-by-slide walkthrough that everyone could have read themselves.
Week 4 onward — Remediation and retest
The engagement is not over when the report arrives. It is over when the findings are fixed and verified.
Good practice is a retest window included in the original scope — typically 30 to 90 days — in which the team re-tests remediated findings and confirms the fix actually worked. Fixes fail more often than people expect: a patch is applied to staging but not production, or a fix addresses the specific payload in the report rather than the underlying flaw.
What your team does: assign each finding an owner and a date. Findings without an owner do not get fixed; they get rediscovered in next year's test.
How long should it actually take?
The week-by-week structure above describes a typical mid-sized web application engagement. Real timelines vary considerably with scope — a single marketing site is days, a multi-tenant platform with mobile apps and a partner API is considerably more than four weeks.
Be sceptical of anyone quoting a fixed duration before scoping. It means either the scope is not understood or the test is a scan with a report template. Our wider services practice runs the same way: scope first, then commit.
Frequently asked questions
How often should we run a VAPT?
Annually as a baseline, and additionally after any significant architectural change — a new payment integration, a migration, a major release. Organisations under compliance obligations may have a defined cadence set by their regulator.
Will testing take our systems down?
It should not, and rules of engagement exist to prevent it. Denial-of-service testing is normally excluded by default unless specifically requested. Discuss any fragile legacy systems during scoping so they can be tested carefully or excluded.
Should we test production or staging?
Production, where it is safe to do so — staging environments routinely differ from production in exactly the configuration details that matter. Where production testing is too risky, test a staging environment that is a genuine mirror, and say so in the report.
What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment identifies and catalogues known weaknesses, largely through automation, and answers “what might be wrong?” A penetration test attempts to exploit them, including through manual testing, and answers “what can an attacker actually do?” VAPT combines both. Buying only the first while believing you bought the second is the most common and most expensive misunderstanding in this market.
Talk through what testing your environment would involve
We will tell you plainly whether a full VAPT is the right next step or whether something smaller would serve you better.
Book a 30-minute call