How long a penetration test takes and whether it disrupts your operations

Two questions come up before almost every penetration test: how long will it take, and will it knock something over? Both answers come down to the same thing, scope and planning, rather than luck. The short version for planning purposes: a focused test is measured in days, a broad one in weeks, and the full cycle from scoping to final report in one to two months. The rest of this page puts numbers against each scope and shows where those numbers stretch.

Typical timelines by scope

Scope is the biggest lever: how many targets, how deep the testing goes, and what kind of test it is. The test style matters too. A black-box test, where the tester starts with no inside knowledge, takes longer to find a foothold than a grey-box or white-box test where you share some access up front. These are the planning ranges we scope against.

These are planning guides from engagements we scope, not quotes. The real number falls out of a scoping call where you agree the targets, the depth, and the rules. OT environments sit at the long end for a reason: testing live industrial systems safely requires a different method entirely, which is covered in OT VAPT vs IT VAPT.

How long a vulnerability scan takes

A vulnerability scan and a penetration test answer different questions and run on different clocks. A scan is mostly machine time: a tool checks your hosts against a database of known weaknesses and reports what matches. A test is mostly human time, spent proving which of those weaknesses can be chained into real access. That is why a scan of an estate finishes in hours while a test of the same estate takes days or weeks. SEOJK 29/2022 point VII.2 describes them in exactly that order, with vulnerability identification carried out first and the penetration test following it.

As with the testing table above, these are planning guides from engagements we scope, not quotes. They are also scanner run times rather than project times, and the gap between the two is where schedules slip. An unfiltered scanner report on a mid-sized network runs to thousands of lines, most of them informational or duplicated across hosts, and turning that into a ranked list someone can act on usually takes longer than the scan did. We budget one to three days of analysis against a first full scan, less once the environment is tuned.

What Indonesian regulators ask for

Frequency has a different answer depending on who supervises you, and two of these rules are regularly misquoted.

For parties Bank Indonesia regulates, PBI 2/2024 Pasal 30 huruf c requires monitoring that includes "pemindaian Kerentanan Siber, secara konsisten dan berkelanjutan". Scanning there is not a scheduled event with a duration, it is a standing process, and the explanatory note to that article treats penetration testing as part of the same vulnerability-scanning activity.

For commercial banks, POJK 11/2022 splits testing into two streams and they carry different obligations. Pasal 24 ayat (1) requires vulnerability-analysis testing "secara berkala" without naming an interval, and Pasal 24 ayat (2) sends the results to OJK as part of the report on the current condition of the bank's IT. The once-a-year minimum that gets quoted so often is in Pasal 25 ayat (1), and it applies to scenario-based testing rather than to vulnerability analysis. SEOJK 29/2022 point VII.2 leaves the vulnerability-analysis interval to the bank's own evaluation, naming system criticality and architecture changes that increase risk exposure as the factors to weigh.

Every electronic system operator, public or private, also carries a separate duty under PP 71/2019 Pasal 34 ayat (1) to conduct an Uji Kelaikan Sistem Elektronik, which Pasal 1 angka 14 defines as an objective assessment of each component of the system, carried out independently or by an authorised and competent institution.

The phases, start to finish

A penetration test is more than the hands-on week, and planning the timeline around only that part is where schedules slip.

Scoping sets the targets and the rules of engagement. Testing is the hands-on part. The report turns raw findings into something your team can act on, and typically lands about a week after testing ends. You remediate, and a retest confirms the fixes actually held. Budget time for the bookends, not just the testing.

What stretches a timeline

In practice, four things stretch pentest schedules far more often than the testing itself does.

Scoping drag comes first. An incomplete asset list, an approval that needs a signature from someone on leave, or an undecided question about whether the mobile app is in scope can add weeks before a tester touches anything. Environment access is the second: test accounts not created, VPN access not granted, source IPs not whitelisted, or a staging copy that is still being built. Every day a tester waits for access is a day on the schedule.

The business calendar is the third. Change freezes around month-end closing, year-end, and the Lebaran period are common across Indonesian companies, and a test that cannot run during a freeze has to be booked around it. The fourth is the retest cycle: the gap between receiving the report and completing remediation is entirely in your hands, and it is the phase teams underestimate most. If the goal is a clean report for an auditor, remediation time belongs in the plan from day one.

Will it disrupt our systems

This is the fear that holds many teams back, and for a well-run test it is largely unfounded. A reputable tester plans around your operations: destructive or load-heavy checks are flagged in advance, run in a maintenance window, or pointed at a staging copy rather than production. The tester keeps a live contact open during the engagement and stops if something looks fragile. The aim is to find weaknesses the way an attacker would, without behaving like one who wants to cause damage.

Most of that protection is built in the scoping call, not during the testing. Agree the targets and the rules of engagement, set the timing windows, flag any fragile systems, decide what runs against production versus staging, and name an emergency contact on both sides.

Planning around a compliance or certification deadline

Most penetration tests in Indonesia are anchored to a date. For commercial banks, POJK 11/2022 Pasal 25 ayat (1) requires scenario-based cyber security testing at least once a year, with the results reported to OJK within ten working days of completion under Pasal 25 ayat (3). Operators of vital information infrastructure carry their own assessment expectations under Perpres 82/2022, and ISO 27001 certification audits routinely ask for a recent test report plus evidence that the findings were fixed.

Working backwards from a fixed date, a safe plan looks like this: one to two weeks for scoping and contracting, one to two weeks of provider lead time before testing starts, the testing window itself, a week for the report, two to four weeks for your team to remediate, and a short retest so the auditor sees closed findings. That is roughly ten to twelve weeks end to end. Teams that book a test one month before an audit usually end up presenting a report full of open findings. Teams that book a quarter ahead present a closed one, and the difference is visible to a regulator.

If the annual test is part of a wider program, it pairs with a recurring scan cadence; the split between the two is covered in vulnerability assessment vs penetration testing.

If you tell us what you want tested, what you are worried about breaking, and the date the result has to land on, we can scope an engagement around all three. See the full scope of our penetration testing services in Indonesia for methodology, targets, and reporting.