A security auditor sits at a laptop in a workspace in Jakarta. In front of him is an e-commerce application that has been running for two years, handling thousands of transactions every month. His task today is not to review documents or interview staff. He is trying to break in. For three weeks, he probes every gap: login forms, APIs, the admin panel, server configuration, even keys left in code repositories. Two weeks after testing ends, his report comes out. At the top of the list: one critical finding — a flaw allowing anyone to access full customer data without logging in. That flaw had existed since launch, and no functional test had ever found it.
That is the job of penetration testing: finding the gaps before criminals do.
Many business owners in Indonesia only encounter this term after their application has already been breached. Yet penetration testing is one of the most sensible security investments for a business that depends on digital systems: relatively affordable compared to the cost of a single incident, and its output is concrete — a list of found vulnerabilities and how to fix them.
This article covers what penetration testing is, how it differs from a security audit (and other security checks that are often confused with it), the types, the methodology professionals use, what it costs in the Indonesian market, and how to choose the right vendor.
What Penetration Testing Is
Penetration testing, or pentest, is a security exercise in which security experts attack your systems in a controlled manner using the same techniques as real attackers: scanning for weaknesses, attempting exploitation, and searching for a way into your data or systems. The difference: this attack is carried out with your permission, within an agreed scope, and the results are reported to you, not sold on the dark web.
The goal is not merely to prove the system can be breached. The goal is to find and understand vulnerabilities before attackers exploit them, so you can close them first.
The closest analogy: crash testing for cars. You do not wait for a real accident to learn whether a car design is safe. You deliberately crash it in a laboratory, measure the damage, then improve the design. A pentest is a crash test for your digital systems, complete with a damage report and repair recommendations.
Pentest vs. Security Audit vs. Vulnerability Scan
The most common confusion among business owners is telling apart three terms often used interchangeably. They actually answer different questions.
| Type | Question it answers | How it works | Output |
|---|---|---|---|
| Vulnerability scan | "What known weaknesses exist?" | Automated scanning with tools, matching signatures of known vulnerabilities | A list of vulnerabilities with severity ratings |
| Penetration testing | "How deep can an attacker get in?" | A combination of scanning and manual exploitation by experts, mimicking real attacks | Exploitation evidence, impact analysis, remediation recommendations |
| Security audit | "Do security policies and controls meet the standard?" | Review of configuration, processes, documents, and compliance against standards | A gap report and compliance recommendations |
A vulnerability scan is cheap and can be automated monthly, but it only sees the surface: it knows the list of known vulnerabilities, but not whether a flaw can actually be exploited to reach important data. A pentest goes deeper: it actually attempts to pass through defenses, so the results show real risk rather than a theoretical list. A security audit looks at a different dimension: not "can it be breached or not," but "are the processes, configuration, and controls correct against the standard."
All three complement each other. A healthy business runs vulnerability scans regularly, pentests periodically (usually annually or after major changes), and a security audit when compliance needs or significant changes arise. Our article on security audits covers the audit side in more depth.
Types of Penetration Testing
Pentests come in several variants, each with its own depth and character.
Black Box
The tester is given no information about the system: no documents, no access, no source code. They start like an outside attacker who only knows your website address or IP. The results are the most realistic for the "attacked from outside" scenario and closest to how real attackers work. The downside: it takes longer and costs more, because the tester must map the system from scratch.
White Box
The tester is given full access: source code, documentation, credentials, system architecture. This enables the most thorough testing, because logic flaws that are hard to spot from the outside become clearly visible from the inside. The result is more findings, and the cost per finding is more efficient, because time is not wasted mapping basics.
Grey Box
A combination of the two: the tester is given some information, such as a regular user's credentials or brief documentation, but not full access. This is the most common choice in the industry because it balances attack realism with depth of findings.
Variations by Target
Beyond these three, pentests also differ by what is tested: web applications, mobile applications, APIs, network infrastructure, and even physical testing (attempting to enter the server room) and social engineering (attempting to deceive employees). For digital businesses, the most commonly needed combination is web applications, APIs, and infrastructure.
Methodology: How Testers Work
A professional pentest follows a structured methodology, not random trial and error. The best-known frameworks are the OWASP Testing Guide for web applications and PTES (Penetration Testing Execution Standard) for general testing. The flow looks roughly like this:
1. Agreement and Scope
Before anything begins, there is a crucial contract: the rules of engagement. This document defines what may be tested, testing hours (so operations are not disrupted), emergency contacts, and limits that must not be crossed. A clear scope protects both parties: testers know their boundaries, and you know what will be tested.
2. Reconnaissance
Testers gather as much information as possible about the target: subdomains, technologies in use, employees exposed on social media (for social engineering), and other digital footprints. The more information, the greater the chance of finding a flaw.
3. Vulnerability Mapping
With information in hand, testers map the attack surface: endpoints, forms, APIs, server configuration. They look for known vulnerabilities (via automated and manual scanning) as well as logic weaknesses only visible to human eyes, such as an authorization flow that can be bypassed by changing a single parameter.
4. Exploitation
Discovered flaws are exploited: injecting SQL, attempting privilege escalation, stealing sessions, or taking over an admin account. The goal is to prove real impact: how deep an attacker could get and what data could be reached. Exploitation is carried out carefully in the agreed environment so production data is not damaged.
5. Reporting
The results are compiled into a report that is the main product of the pentest: a list of findings, severity ratings (critical, high, medium, low), technical evidence (reproduction steps, screenshots), business impact, and remediation recommendations. A good report is understandable to management, not just programmers.
6. Verification of Fixes (Optional)
After fixes are made, testers verify that the flaws are truly closed. This verification session is usually shorter and cheaper than the initial test, but very important: flaws that were "believed fixed" but are still open are a common occurrence.
The Most Common Findings in Indonesia
Based on industry experience in the Indonesian market, several types of findings appear repeatedly in business applications:
- Loose authorization. Regular users can access admin data or functions just by changing a number in the URL or a parameter. This is the most common and most dangerous finding, because the impact is immediate and often invisible to ordinary functional testing.
- Weak or leaked credentials. Default passwords never changed, or access keys left in public code repositories.
- Accidental data exposure. API endpoints returning excessive data, publicly downloadable backups, or debug mode still active in production.
- Weak session management. Session tokens that never expire, can be guessed, or are not invalidated on logout.
- Loose server configuration. Missing security headers, admin panels exposed to the internet, or inconsistent data encryption.
An interesting pattern: most critical findings do not come from sophisticated attacks, but from configuration mistakes that could have been prevented from the start. This is why application security should be a consideration from the development process, not an addition at the end.
When Your Business Needs a Pentest
Not every business needs a pentest tomorrow morning. But there are conditions where a pentest is no longer a choice; it is a requirement:
- Applications handling financial transactions or personal data. The more sensitive the data, the higher the stakes. Payment applications, e-commerce, and systems storing customer data fall into this category.
- Before launching a major system. Launching an application without a pentest is like opening a store without locking the warehouse. It is far cheaper to find flaws before the public accesses them.
- After major changes. New architecture, new integrations, or other major overhauls change the attack surface. A previous pentest may no longer be relevant.
- Partner or regulator requirements. Many banks, payment gateways, and government institutions require pentest results as part of collaboration or compliance processes.
- As part of a regular cycle. Mature businesses run pentests periodically, usually annually, as a comprehensive health check.
If this is your first pentest, start with the systems most important to operations. Prioritize by impact: which system, if breached, would hurt your business the most?
How Much Does Penetration Testing Cost in Indonesia
The most frequently asked question, and the answer often surprises because it is more affordable than expected. Prices in the Indonesian market vary widely depending on complexity, scope, and vendor reputation. Here are realistic ranges:
- Simple web application (company profile, landing page): Rp 5-15 million per test. Usually completed within 1-2 weeks.
- Web application with transactions and user accounts: Rp 15-40 million per test. Takes 2-4 weeks depending on depth.
- Complex systems (multiple applications, APIs, infrastructure, mobile): Rp 40-150 million per test, more for enterprise.
- Retesting after fixes: usually 20-30 percent of the initial test cost.
What makes prices differ? The number of pages and features, the number of user roles, API complexity, the need for mobile testing, and vendor reputation. Cheap is not necessarily bad, but beware offers that are too cheap for a complex system: it may just be a vulnerability scan packaged under the pentest name.
A fair comparison: one exploited critical flaw can cost tens to hundreds of millions of rupiah once you count data leaks, recovery, and reputation. An annual pentest for a transactional application, say Rp 20-30 million, is a clearly sensible financial decision.
How to Choose a Pentest Vendor
Pentest quality depends on the tester, not the tools. Two vendors can use identical equipment, yet produce very different results. Watch for these points when choosing:
- Team qualifications. Certifications such as OSCP, OSWE, or CEH indicate a certain competency standard, though not an absolute guarantee. Ask about the experience of the tester who will handle your project, not just the company name.
- A clear methodology. A good vendor can explain its methodology: the frameworks used, testing stages, and how it handles findings that risk damaging systems.
- A written, agreed scope. Beware vendors who are too casual about scope. Firm rules of engagement protect your operations.
- Report quality. Ask for a sample report (redacted). A good report has clear severity ratings, reproducible steps, and realistic recommendations, not jargon.
- Experience in your industry. Vendors who have tested similar systems understand where flaws usually hide.
- Testing data security. Make sure there is a non-disclosure agreement and that findings are stored securely. Pentest findings are a treasure map for attackers if they leak.
Preparing for a Pentest at Your Company
When you decide to run a pentest, good preparation makes the process smooth and the results maximal.
- Define the goal. What do you want to learn? Only the web application, or also APIs and infrastructure? Are there compliance deadlines to meet?
- Prepare the scope. Gather the list of URLs, applications, and systems to be tested. Explicitly decide what is NOT to be tested.
- Inform internal teams. Technical staff need to know testing will take place, so suspicious-looking activity is not mistaken for a real attack.
- Prepare emergency contacts. Decide who testers contact if they find something extremely critical mid-test.
- Schedule outside peak hours. High-risk exploitation (such as testing that could disrupt service) should happen outside operating hours.
- Prepare the remediation process. Before the report arrives, decide who is responsible for fixing findings and how long it takes. A pentest without follow-up is just an expensive document.
After the Report Arrives: What to Do
The pentest report is the beginning, not the end. A disciplined remediation process determines whether the money you spent pays off.
- Sort by severity. Close critical and high findings first, ideally within weeks. Medium and low findings are scheduled according to resources.
- Fix root causes, not symptoms. If loose authorization is found in five places, do not patch them one by one; fix the authorization design.
- Involve the development team from the start. Give them access to the report and allocate dedicated fix time. Piled-up fixes always lose to new feature work.
- Schedule retesting. After fixes, have the vendor verify. This closes the loop with evidence, not assumptions.
- Store the report securely. A pentest report maps your system's weaknesses. Keep it like the most valuable secret document in your company.
Pentest and Application Development: Change the Mindset
The most expensive mistake businesses make is treating the pentest as a "final check." When security is only considered after the application is finished, fixes are expensive and often postponed because "features matter more."
The healthy mindset: security is built from the start. The principles tested in a pentest — correct authorization, input validation, session management — are design decisions to be made on day one of development. This is why choosing a development partner that understands security matters as much as choosing the features to build. An application built on a sound security foundation will sail through a pentest with few findings and low fix costs.
A Pentest Is an Investment, Not an Expense
Back to the auditor from the opening story. After his report came out, the client needed a month to close all critical findings. No data leaked, no customers were harmed. What that tens of millions of rupiah bought was just a set of reports and a few weeks of repair work. Compare that with the scenario where an attacker found the flaw first: a customer data breach, reporting obligations, and a reputation that takes years to rebuild.
A pentest does not make your system invulnerable. Nothing does. What it does is move the moment of surprise: would you rather a flaw be found by a tester you pay, or by an attacker you do not know?
If your business depends on an application or website processing important data, schedule a pentest before an attacker schedules one for you. The Kartech team in Bandar Lampung can help prepare your systems for testing: straightening out the security foundation, closing common gaps, and guiding the remediation process after the pentest is complete. Reach us through our contact page or explore our services.
The biggest gap in security is not in your code; it is in the decision not to look.
