Three Weeks to Launch, No Pen Test Booked

A Hong Kong startup set its launch date before it set its security budget. Three weeks out, someone finally asked "has this been pen-tested?" — late enough that the question itself decided what kind of test was still possible. This is a composite scenario, not a named client, built around a pattern Brocent sees often: security testing scoped against whatever time is left, rather than against the launch date from the start.

The industry: shipping first, testing second

Hong Kong's technology and SaaS scene moves on a compressed clock. A seed or Series A round comes with a runway measured in months, not years. A public launch date gets set early — sometimes announced to press, investors, or a beta waitlist before a single line of the production build exists — because a date is what makes a roadmap feel real to a board. Engineering then works backward from that date, and every week of slack that exists at the start of a build gets absorbed somewhere before the end of it: a delayed integration, a redesigned onboarding flow, a payment processor's own review queue.

Security testing is rarely the item that gets protected time on the calendar. It is not because founders think security doesn't matter — most will say the opposite when asked directly — it's that a launch date is a marketing and investor commitment, while "when do we test this" is an internal engineering decision with no external deadline attached to it, right up until someone in the room asks the question out loud. For a first or major customer-facing release — the app that will actually hold customer accounts, payment details, or business data for the first time — that question tends to arrive later than anyone intended, and later than the answer is comfortable.

This is not unique to any one company. It shows up across Hong Kong's tech and SaaS companies at a specific, recognisable moment: the product is functionally complete, the launch date is fixed and communicated, and someone — a technical co-founder, a new security-minded hire, an investor's diligence question, or an enterprise prospect's procurement checklist — asks whether the application has actually been tested by someone trying to break it, as opposed to scanned by a tool checking for known signatures.

The scenario: a launch date that was set by marketing, not by readiness

Picture a Hong Kong tech company — a dozen or so engineers, a product that has been in active development for the better part of a year, and a launch date that was set roughly two months earlier and has since made its way into a press release, a partner announcement, and a countdown on the company's own landing page. The build itself has moved fast, the way most pre-launch products do: features shipped in whatever order unblocked the next demo, a payment integration bolted on in the final sprint, and a handful of admin and internal tooling routes that exist because someone needed them for testing and never got removed.

Three weeks before go-live, in a routine engineering standup, someone — often the most security-literate person in the room, who may not be a dedicated security hire at all — asks the question that had been quietly assumed answered: "has this actually been pen-tested?" The honest answer, more often than not, is that the team ran an automated vulnerability scan at some point during development, treated a clean-ish scan report as reassurance, and never booked anything beyond that. Nobody had scoped a manual test. Nobody had put it on the calendar. It simply hadn't come up as a decision that needed making, until it did.

What happens next determines a lot about what the remaining three weeks are actually worth. A team that books a test immediately still has time to scope something meaningful — external network testing, the customer-facing web application, and the authentication and payment flows that matter most — and, critically, time to fix and retest what's found before the public launch. A team that spends a week deciding whether testing is even necessary, or shopping quotes, or debating whether the existing vulnerability scan is "close enough," burns the very runway that made a real test possible in the first place. The clock that matters here isn't the three weeks before launch; it's the days remaining once the decision to test is actually made.

The real problems this produces

A pen test request that arrives late in a fixed launch timeline creates a specific, repeatable set of problems — not because the underlying testing methodology changes, but because the constraints around it do.

• Scoping a test that fits the remaining time without becoming theatre. A full external-plus-internal-plus-web-application engagement is typically a two-to-three-week exercise on its own. Compressed into the days left before a fixed launch, a team either has to narrow scope honestly — focus the test on what's actually customer-facing and internet-exposed, the pieces an attacker on day one would actually reach — or risk commissioning something that looks thorough on paper but doesn't leave time to act on what it finds. A test that produces a report nobody has time to read before go-live is a compliance artefact, not a security control.
• Confusing a vulnerability scan for a penetration test. These are genuinely different exercises, and the confusion is common precisely because both produce a "clean" or "not clean" signal that non-specialists read the same way. A vulnerability scan is automated, broad, and repeatable — it checks a wide surface for known weaknesses using signature-based tools, and it's excellent at catching the obvious, unpatched, or misconfigured issue at scale. It does not attempt to exploit anything, chain findings together, or demonstrate what an attacker could actually reach once inside. A penetration test adds a human — a certified tester actively trying to break in, escalate access, and prove real-world impact, the way an actual attacker would. A team that ran a scan months earlier and treats that as "we've been tested" is answering a different question than the one a pre-launch security review is actually asking.
• Findings surfacing after launch instead of before it. This is the scenario every rushed pre-launch test is trying to avoid, and the one that a too-late request makes more likely. A critical finding discovered the week after go-live — once real customers hold accounts, once payment data is flowing — is a materially worse problem than the same finding discovered the week before, not because the vulnerability itself changed, but because the blast radius did.
• No established remediation window before customers are using the product. Finding an issue is only half the exercise; fixing it, and confirming the fix actually closed the gap, is the other half. A test booked with zero slack before launch leaves no time for either — the findings report becomes something the team reads for the first time after the product is already live, which defeats a large part of the reason to test before launch in the first place.

None of this reflects poorly on the team involved — it's a predictable outcome of treating security testing as a task to schedule "sometime before launch" rather than a fixed input to the launch date itself, in the same way that a payment integration or an app-store review queue is treated as a fixed input.

Brocent's perspective: plan the test against the launch date, not around it

The operating principle Brocent applies here is simple to state and easy to miss under deadline pressure: a penetration test needs to be planned against the launch date, not squeezed into whatever gap is left once every other launch task has claimed its slice of the calendar. That means treating "when do we test" as a decision made at the same time the launch date itself is set — not three weeks out, and ideally not three weeks after the product is functionally complete, but early enough that the test, the findings, and a real remediation window all fit comfortably before go-live.

That said, "we're already three weeks out" is not a reason to skip testing — it's a scoping constraint, and a legitimate one. Even a scoped, time-boxed test run the week before launch is worth meaningfully more than no test at all, provided the scope is chosen honestly around what's achievable rather than stretched to cover everything on paper. A tightly scoped external and web-application test that fits in the time available, with even a short, prioritised remediation window before go-live, catches the highest-severity, most exploitable issues that matter most in the first days a product is live to real customers. It is not the same depth of assurance as a full engagement booked with proper lead time — Brocent doesn't present it as equivalent — but it is a materially better position than launching on the strength of an old vulnerability scan alone.

The broader point, and the one Brocent makes to every team in this position: the earlier a test is booked relative to the launch date, the more it can actually change. Testing booked with six weeks of runway can cover external, internal, and web-application scope in full, leave real time for remediation, and support a re-test before go-live confirming the fixes actually closed the gaps. Testing booked with six days of runway can still find the issues that matter most before customers do — but the choices available shrink fast as the calendar does. Neither extreme is a reason for panic or for skipping the exercise; both are reasons to treat the decision to test as something made early, deliberately, and against the real date on the calendar rather than in reaction to a question raised in a standup three weeks out.

What this looks like in practice

For a Hong Kong tech or SaaS company approaching a first or major customer-facing launch, a pen test that's actually useful — whether booked with six weeks or six days of runway — tends to share the same shape.

Application-layer and infrastructure testing scoped to what's actually shipping. For most pre-launch products, this means the customer-facing web application tested against the OWASP Top 10 class of issues — injection flaws, broken authentication, insecure direct object references, access-control weaknesses, and security misconfigurations — alongside the external network perimeter the application sits behind: the firewalls, remote access points, and internet-facing infrastructure any outside attacker would reach first. Where the calendar allows it, internal network testing is added to check how far an attacker could move laterally after an initial foothold, and social engineering or phishing-simulation testing evaluates the human layer separately. Brocent's penetration testing service runs all four scopes — external, internal, web application, and social engineering — as closed-box (no prior knowledge, simulating a genuine outside attacker) or open-box (testers given architecture detail to maximise depth in a fixed window) engagements, so the scope can be matched honestly to what the calendar actually supports.

A report prioritised by exploitability, not just severity in the abstract. A findings report that lists every technical issue in equal weight is not useful to a team with days, not weeks, before launch. What matters is a report that tells the team, in plain terms, which findings are actually exploitable, which represent real business impact if reached, and which can reasonably wait for a post-launch patch cycle. Brocent's reports are CVSS-scored with proof-of-concept evidence and business-impact context specifically so a small team can triage in an afternoon rather than a week — read the executive summary, understand what's genuinely urgent, and start fixing the right things first.

A fix-then-retest loop that fits before go-live. Finding an issue three days before launch is only useful if there's a mechanism to confirm the fix actually worked before customers touch the product. This is why Brocent structures its penetration testing packages around re-testing — a confirmation pass, after remediation, on exactly the findings that were flagged, rather than a second full engagement. For a compressed pre-launch timeline, this re-test is often the single most valuable few hours in the whole process: the difference between "we think we fixed it" and "we confirmed we fixed it," a distinction that matters a great deal once real customer data is at stake.

None of this requires a team to have started early to get real value — it requires the test to be scoped honestly against whatever time genuinely remains, rather than either skipped entirely or run as a box-ticking exercise nobody has time to act on.

Where this fits: testing as part of an ongoing security posture, not a one-off panic

A single penetration test — even a well-scoped one, run with proper lead time and a clean remediation window — answers one question: is this application, tested on this date, exploitable in the ways that matter? It does not answer the question a growing company actually needs answered on an ongoing basis: who owns security testing as a recurring practice, who tracks that the last test's findings actually got fixed, and who makes sure the next test happens before the codebase has drifted far enough that the last one's coverage is stale? A one-off engagement, however good, doesn't answer that on its own — and a team that only tests when a launch date forces the question tends to find itself back in exactly this scenario at the next major release, the next enterprise customer's security questionnaire, or the next funding round's diligence request.

This is the gap Brocent's managed IT plan is built to close. Rather than security testing being a fire drill that gets rediscovered under deadline pressure every time it matters, it becomes part of the ongoing coverage a growing team already has in place — scoped, scheduled, and tracked alongside the rest of the plan's managed security services, instead of re-negotiated from scratch under a launch-week deadline every time. A team on the plan isn't asking "who do we call for a pen test" three weeks before a launch date; the relationship, the scoping conversation, and the retesting cadence already exist, which is exactly what turns "we need this tested by a fixed date" from a scramble into a scheduling conversation.

Penetration testing itself — the engagement described above — remains available as its own scoped service, and for teams that have already built solid testing hygiene and want to measure whether their defenders would actually detect and stop a real intrusion in progress, Red Team Engagement is the next step up: an undisclosed, objective-based adversary simulation rather than a defined-scope vulnerability hunt. Both are real, standalone services with their own scope and cost. But for a growing Hong Kong tech company that wants to stop treating every launch date as a fresh security scramble, the more useful question isn't "which one-off test do we book this time" — it's whether security testing, remediation tracking, and the relationship that makes the next engagement fast to scope should simply live inside the managed IT plan already covering the rest of the stack. See the plan's tiers on the pricing page, or talk to Brocent about where a pre-launch test — booked this week or six weeks from now — actually fits.

FAQ

How far before launch should a pen test be booked?

As early as the launch date itself is set, ideally. A full external, internal, and web-application engagement typically runs two to three weeks, and that's before accounting for remediation time and a re-test. Booking with four to six weeks of runway before launch leaves room for the full scope, a real fix window, and confirmation that the fixes worked — which is the difference between a test that changes what ships and one that simply documents what already shipped.

What's the difference between a pen test and a vulnerability scan?

A vulnerability scan is automated and broad — it checks a wide surface of assets for known, signature-based weaknesses, quickly and repeatably, and is well suited to running on a regular cadence. A penetration test adds a certified human tester who actively attempts to exploit what a scan can only flag, chains multiple findings together the way a real attacker would, and demonstrates actual business impact rather than a list of potential issues. Many organisations use both: scanning on a recurring basis, and a manual penetration test for a launch, an annual check, or a specific compliance or customer requirement. A clean scan is not evidence that a manual test would also come back clean.

How much does a pen test cost in Hong Kong?

It depends heavily on scope. Manual, consultant-delivered penetration testing in Hong Kong's market commonly runs from around US$5,000 into the tens of thousands of US dollars depending on how many scopes (external, internal, web application, social engineering) are included and how large the environment is. Brocent's own scoped engagements start from US$3,500, with the final quote set by the specific scope agreed during a proposal conversation — a focused external and web-application test for a single pre-launch product will price differently from a full four-scope engagement across a larger environment.

Can a pen test be done in two weeks?

Yes, with the right scope. A full external, internal, and web-application engagement is typically a two-to-three-week exercise on its own, which leaves little to no room for remediation inside a strict two-week pre-launch window. A tightly scoped test — focused on the external perimeter and the customer-facing web application, the pieces most exposed on day one — can fit inside two weeks and still leave a short remediation window before go-live. The honest trade-off is coverage: a two-week window supports a focused scope well; it does not support the same depth as a six-week engagement.

What happens if the test finds a critical issue right before launch?

The finding gets triaged immediately against exploitability and business impact, using the CVSS-scored, evidence-backed detail in the report rather than a raw severity label. For a genuinely critical, easily exploitable issue, the honest options are: fix and re-test before go-live if the remaining timeline allows it, or delay launch of the specific affected feature or flow while the rest ships on schedule. Neither is a comfortable conversation days before a public launch, but finding out before customers do is the entire point of testing pre-launch rather than after.

Do we need a pen test if we've already done a vulnerability scan?

Generally, yes, particularly for a first or major customer-facing release. A scan is a useful, repeatable baseline — it catches known, signature-based issues efficiently — but it doesn't attempt exploitation, chain findings together, or demonstrate real-world impact the way a manual test does. A clean scan result answers "did we find any known weaknesses with automated tools," not "could someone with real effort actually get in." For a launch that will hold customer accounts or payment data for the first time, that's a meaningfully different question worth answering before, not after, go-live.

Is a red team engagement the same as a pen test?

No — they answer different questions. A penetration test asks "what vulnerabilities exist in this defined set of systems," is usually disclosed and scheduled with the internal team in advance, and typically runs days to weeks. A red team engagement asks a different question entirely — "can an attacker reach a specific objective, and would we notice" — is undisclosed except to a small internal contact, tests detection and response rather than vulnerability existence, and typically runs weeks to months. Red teaming generally assumes a working penetration-testing programme already exists; it's the next step once foundational security hygiene is in place, not a substitute for the pre-launch test itself.

Skipping it vs. a rushed test vs. testing planned against the date

The gap between these three approaches isn't really about testing methodology — the same certified testers, the same techniques, and the same reporting standard apply in all three. It's about when the decision to test gets made, and how much of the calendar is left to act on what's found.

Skipping it ("we'll fix things after launch")

• No independent verification that the application resists a real attempt to break in — only whatever an automated scan, if run at all, happened to catch.
• Any critical issue is discovered by real users, or by an attacker, after customer accounts and data are already live — the worst possible timing for the worst possible finding.
• No fix window exists before exposure begins, because exposure has already begun by the time anything is found.

A rushed last-week test (some coverage, no time to remediate)

• A test does happen, and it can still catch genuinely serious, easily exploitable issues — this is meaningfully better than skipping testing entirely.
• Scope is usually narrowed under time pressure, often informally rather than deliberately, which can leave gaps in what actually gets tested.
• Findings typically surface with little or no time to fix and re-test before go-live, so the report becomes documentation of known risk at launch rather than a driver of pre-launch remediation.

Scoped testing booked against the launch date, with a remediation window (Brocent's model)

• Scope is chosen deliberately against the time available — honestly narrower for a compressed timeline, fuller where lead time allows — rather than either skipped or stretched thin.
• A findings report prioritised by real exploitability and business impact, so a small team can triage quickly and act on what actually matters first.
• A fix-then-retest cycle confirms remediation before go-live, turning "we think we fixed it" into "we confirmed we fixed it" while there's still time to act on the answer either way.