Penetration Testing Methodology

Last updated: 14 October 2026.

This page explains how we test the security of your systems, from the first agreement to the retest.

Before testing starts

  • A written scope. We agree which addresses, applications and servers may be tested, and which must not be touched at all.
  • Written permission from whoever is authorised for those systems. If they run on someone else's service (cloud, hosting or a SaaS application), we make sure the test follows that provider's rules.
  • Rules of engagement. The testing schedule, emergency contacts on both sides, the IP addresses we test from, and what is off limits.
  • A confidentiality agreement before we see anything of your systems.

Without all four, testing does not start.

The standards we use

  • Web applications and APIs: the OWASP Web Security Testing Guide and the OWASP Top 10. We test authentication, access control, business logic, input handling and configuration.
  • Infrastructure and networks: mapping the exposed services, checking configuration and security patching, then manual testing where the risk is highest.
  • Severity of each finding is rated with CVSS, and we explain its impact on your business in plain language.

Automated tools only help. Every finding is checked and proven by hand, so your report is not full of false alarms.

During testing

  • We test only what is in scope, from IP addresses we have told you about beforehand.
  • Testing is designed to keep your business running: no attacks meant to take a system down, and no deleting or changing real data. If a step carries risk, we ask you first.
  • If we find a critical hole, for example customer data anyone can open, we tell you straight away rather than waiting for the final report.
  • If there are signs that someone else has already broken into your systems, we stop testing that part and tell you immediately.

Your data

  • Data we see during testing is used only to prove a hole. We take only what is needed, for example one sample rather than a whole database, and that sample is masked in the report.
  • All test data and evidence (data samples, screenshots and tool output) are deleted no later than 30 days after the retest. The final report is kept encrypted for one year as a reference for the next test, unless you ask us to delete it sooner.
  • We never publish findings about your systems. The research we publish comes only from our own website and from vulnerabilities that have already been officially announced.

What the report contains

  • A summary for management: the main risks and what to fix first, without unnecessary jargon.
  • A list of findings, ordered from the highest risk. Each has its severity, its impact on the business, the steps to reproduce it and how to fix it.
  • What is already good, so you know which parts need no change.
  • The report is available in Indonesian or English.

Retest

Once you have fixed the holes, we retest the same findings once at no extra cost, within 60 days of handing over the report. The result is added to the report, so you have a record that the holes are closed.

What we do not do

  • Test without written permission, or outside the agreed scope.
  • Attacks meant to take a system down (DoS).
  • Social engineering against your staff, such as phishing emails or fake phone calls. This is not part of our service yet.
  • Keep, sell or share your data.

Questions

Want to know whether a test suits your systems? Reach us through the contact page. If you find a security hole on our own website, tell us at security@digimasi.com.