Penetration Testing and Security Audits for Business Applications: When You Need Them, What Gets Tested, and How to Act on Findings

Many business owners only think about application security after an incident: customer data leaks, an admin account is taken over, or a payment page is tampered with. Yet most of the weaknesses attackers exploit have been there since launch; nobody had simply looked for them on purpose. A penetration test (often shortened to pentest) is the way to look for those weaknesses first, using methods that imitate an attacker but carried out officially and under control.

This article explains penetration testing and security audits in language owners and managers can use: how they differ from automated scanning, when to run one, what gets tested, how to read the report, and how to make sure findings actually get fixed. The goal is to make sure your security budget goes to what matters most, rather than to a certificate or a report that ends up in a drawer.

Summary

• A penetration test is an authorized, controlled search for security weaknesses by testers who think like attackers, unlike automated scanning, which only matches known patterns
• The best times to test are before a major launch, after architecture changes or sensitive features such as payments, and periodically at least once a year
• A clear scope, written rules of engagement, and a safe test environment matter as much as the tester's skill
• A good report contains risk-rated findings, reproducible evidence, and concrete remediation advice, not just a list of technical jargon
• The value of a pentest lies in the fixes and the retest, not in the report itself

What a penetration test is and how it differs from scanning

Three activities are often mixed up, although their purposes differ.

• Vulnerability scanning: automated tools check systems against a list of known weaknesses, such as outdated software versions or weak configurations. It is cheap, fast, and suited to running regularly, but it does not understand your business logic
• Penetration testing: human testers, helped by tools, try to actually break in by chaining several small weaknesses into an attack path. It answers the question "what can a determined attacker achieve?"
• Security audit or code review: a systematic examination of code, configuration, policies, and processes against a given standard. It answers the question "are we following the right practices?"

The three complement one another. Scanning catches the easy things every week, an audit confirms the foundations are right, and a pentest checks whether all of that holds against a creative opponent. An example a scanner will never find: customer A can see customer B's invoice simply by changing a number in the page address. The scanner sees a page that works normally, while a human tester immediately tries changing that number.

When to run a penetration test

Not every application needs testing every month, but some moments make it close to mandatory.

• Before launching a new application that stores customer data, employee data, or financial transactions
• After a major change: a cloud migration, a new login system, a new payment integration, or opening an API to partners
• Before a peak season or big campaign, when attacks and fraud tend to rise
• When corporate customers or regulators ask for evidence of security testing as a condition of working together
• Periodically, at least once a year, because code, libraries, and attack techniques keep changing

If the budget is tight, prioritize the components that face the internet and hold the most sensitive data: login pages, customer portals, APIs, and payment flows. Internal panels reachable only from the office network can usually follow. Keep in mind, though, that attackers often enter through leaked employee accounts, so internal panels deserve testing in a later round.

What is usually tested

The usual scope for web and mobile applications follows commonly recognized risk categories, including the top web application risk lists published by open security communities.

Authentication and session management

Testers check whether weak passwords are accepted, whether login attempts are limited, whether account recovery can be abused, and whether sessions end properly on logout. If you use two-step verification or passwordless login, the fallback flows are tested too, because they often become the back door.

Access control

This category most often produces serious findings in business applications. The question: can an ordinary user reach data or functions meant only for admins or other users? In multi-branch or multi-customer systems, this test confirms that one party's data does not leak to another.

Input validation and injection

Testers feed unexpected data into forms, address parameters, and file uploads to see whether the application can be forced to run database commands, run malicious scripts, or store files it should not.

Business logic

This is where humans beat tools. Examples: can a coupon be used many times, can the price in the cart be changed before paying, can an order be cancelled after shipment while the refund still goes through, or can multi-level approval be bypassed through a particular sequence of steps.

Configuration and infrastructure

Unnecessarily open ports, admin panels reachable by the public, error messages that reveal system structure, publicly open file storage, and secret keys left in code are routine finds. Key handling is covered further in the article on managing secrets and API keys.

Mobile apps and APIs

For mobile apps, testers check data storage on the device, communication with the server, and whether the app can be taken apart to extract keys or sensitive logic. For APIs, the focus is authorization on every request, rate limiting, and excess data in responses. The design principles match those of a well designed business API.

Testing models: black box, grey box, and white box

Testers can be given information at three levels, and the choice affects cost and depth of results.

• Black box: the tester gets nothing but the target address, resembling an outside attacker. Realistic, but much of the time goes to reconnaissance, which limits depth
• Grey box: the tester gets an ordinary user account, basic documentation, and perhaps a test admin account. This is the most common and most efficient choice for business applications because the focus goes straight to logic and access control
• White box: the tester has access to source code and architecture. The deepest, suited to critical components such as payment modules

For most mid-sized businesses, grey box testing on customer-facing applications gives the best value per rupiah.

Preparing the test properly

The quality of results depends heavily on your preparation.

• Set a written scope: addresses, applications, and APIs that may be tested, and what is off limits, such as attacks that take the service down or social engineering of employees
• Prepare a test environment that resembles production with fictional data. Testing directly in production may be needed in some cases, but hours, emergency contacts, and a recovery plan must be agreed
• Notify those who need to know: the hosting provider, the support team, and the security service provider, so test traffic spikes are not mistaken for real incidents
• Provide accounts with different roles so access control between roles can be tested
• Name one person on your side who can answer the tester's questions within hours, not days
• Back up data before the test, following your [business data backup strategy](/blog/strategi-backup-data-bisnis)

The engagement agreement should also cover confidentiality, how findings are stored, and the tester's obligation to delete any data obtained during testing.

Choosing a penetration testing provider

Several considerations separate a good provider from one that merely sells reports.

• Experience with applications similar to yours, not only generic networks
• A clear methodology that references recognized standards, rather than running a single scanner and swapping the logo
• Tester qualifications and willingness to introduce who will actually do the work
• Sample reports showing evidence, reproduction steps, and remediation advice
• Willingness to retest after fixes, ideally included in the price
• A written disclosure and confidentiality policy

Beware very cheap offers and promises of "no findings". Real applications almost always have something to fix, and a report with no findings more often signals shallow testing than a perfect application.

Reading and prioritizing the report

A good pentest report usually has an executive summary, a list of findings, and technical appendices. The executive summary is for management; the detailed findings are for the technical team.

Each finding should state a title, risk level, location, evidence or reproduction steps, business impact, and remediation advice. Risk ratings are typically critical, high, medium, low, and informational. Prioritize by weighing two things together: how easy it is to exploit and how large the loss would be.

• Critical and high: fix within days, and apply interim mitigation such as disabling the feature if necessary
• Medium: schedule in the next development cycle with a clear deadline
• Low and informational: group them and handle alongside other fixes

A common mistake is treating the raw rating as absolute truth. A medium weakness in a system storing health data may be more urgent than a high one on a public information site. Involve someone who understands the business when deciding the order.

Closing the loop: fixes, retest, and learning

The greatest value of a pentest appears after the report arrives.

• Create a ticket for each finding with an owner and a deadline, and track it like any other work
• Fix the root cause, not just the symptom. If one page leaked because authorization was not checked, see whether other pages share the same code pattern
• Request a retest of important findings to confirm the fix is correct and has not opened new holes
• Add automated tests for weaknesses that were found so they do not return in the next release, as part of [automated testing and CI/CD](/blog/pengujian-otomatis-dan-ci-cd-untuk-aplikasi-bisnis)
• Record recurring patterns and use them for training or coding standards for the team
• Update the [incident response plan](/blog/rencana-respons-insiden-keamanan-siber-untuk-bisnis) if the test revealed attack paths it does not yet cover

With this cycle, every test makes the application more resilient instead of merely producing a document.

Maintaining security between two tests

A pentest is a snapshot in time. Applications change every week, so you need habits that maintain security between tests.

• Automated vulnerability scanning and checks of [third party dependencies](/blog/keamanan-dependensi-dan-rantai-pasok-perangkat-lunak) on every release
• Code review with a security checklist for changes touching login, payments, and permissions
• Monitoring and alerts on suspicious patterns, supported by [good observability and logging](/blog/observabilitas-log-dan-penanganan-error-aplikasi-bisnis)
• A simple vulnerability reporting channel: a dedicated email address for researchers or customers who find a problem
• Applying the basics described in [basic business application security](/blog/keamanan-dasar-aplikasi-bisnis)

Common mistakes

• Testing too late, right before launch, so serious findings force a delay or get ignored to meet the deadline
• A scope so narrow that the riskiest parts are never touched
• Treating a certificate or a clean report as a permanent guarantee
• Not following up on findings because the team ran out of capacity
• Testing only one user role so cross-role weaknesses stay hidden
• Storing the report where many people can open it, even though it is a map to your weaknesses

Frequently asked questions

How much does a penetration test cost?

The cost depends on scope, depth, and the tester's working days. A small web application takes a few days, while a large system with many roles, APIs, and mobile apps can take weeks. Ask for a quote based on a written scope and compare what is included, especially the retest and the results briefing.

Is automated scanning enough?

For a small business with a simple application, routine scanning plus good basic practices is a reasonable start. But once the application stores customer data, processes payments, or has many user roles, manual testing is needed because logic and access control flaws are almost invisible to tools.

Can a penetration test damage the system?

The risk is small when managed properly, which is why the rules, test hours, and data backups should be agreed beforehand. Potentially disruptive testing, such as heavy load, is usually excluded or run separately.

How often should it be repeated?

At least once a year and whenever there are major changes to architecture, login, or payments. For fast-changing applications, consider lighter, more frequent testing of newly released features.

Can the internal team do it themselves?

An internal team can run scans and code reviews. But an external tester brings a fresh perspective and is not influenced by the assumptions the developers worked with, so is more likely to find what was missed.

Conclusion

A penetration test is not a sign that your application is bad; it is a sign that you want to find problems before someone else does. The results are most valuable when the scope is clear, the tester is experienced, findings are prioritized with business judgment, and fixes are verified by a retest. Combined with routine scanning and secure development habits, periodic testing turns security into an ongoing process rather than a one-off project.

Agsora helps businesses build applications with security practices from the start, prepare applications for testing, and follow up on findings until they are resolved. If you want to assess the security readiness of your business application, we are ready to talk.