Penetration test remediation: from findings to retest

Penetration test remediation is the work your team does after the report arrives: reading the findings, deciding what to fix first, making the fixes, documenting the evidence, and requesting retest. A report does not fix anything on its own, and the gap between a confirmed finding and a genuinely more secure system depends entirely on how systematically the remediation process is run.

Triaging findings before remediation begins

Not every finding needs to be handled in the same week. Triage is the first step: sort findings by severity, then assign deadlines by group. The most widely used severity framework is the Common Vulnerability Scoring System (CVSS) v3.1 from the Forum of Incident Response and Security Teams (FIRST), scored from 0 to 10.

The severity bands come from CVSS. The deadlines do not. FIRST's CVSS documents define the 0 to 10 scale and its bands but set no remediation deadlines, and no Indonesian regulation sets them either, so the targets in the right-hand column are the ones we suggest to clients, not a standard you can cite.

FIRST is also explicit that a CVSS score measures severity, not risk, and that it should be combined with your own environment and threat context. That is where the targets should move. Pull a finding forward when the system faces the internet, when the vulnerability is being exploited in the wild (CISA's Known Exploited Vulnerabilities catalogue is a quick check), when the asset holds customer or personal data, or when it supports a critical service. Push one back only when there is a real compensating control, such as the system being unreachable from untrusted networks, and write the reasoning down. A High finding on an internet-facing payment API that is already being exploited deserves Critical treatment; a Critical finding on an isolated test server with no data may not.

One thing worth noting: a Low finding in isolation carries low risk. But if several Low findings exist on the same system and can be chained together, their combined value rises significantly. A thorough report will call this out.

Who fixes what

A penetration test touches many system layers, and each layer is typically owned by a different team.

Application code vulnerabilities, such as SQL injection, broken access control, or flawed business logic, go to the development team responsible for that code. Infrastructure vulnerabilities in server configuration, firewalls, or network segmentation are handled by the infrastructure or operations team. Access policy issues, privilege management problems, or duty-separation failures often require IT governance or a division head, because policy changes go through a different approval path. Findings that require significant architectural change usually need a decision from management or the CTO, not just the technical team.

A well-structured report will suggest a recommended owner for each finding. If the report does not, the first step in the remediation discussion is mapping each finding to the right team before setting any deadline.

Practical timelines per severity level

Critical does not mean "fix within an hour." It means two separate deadlines. Containment comes first and should happen within 24 hours: isolate the affected system, revoke exploitable access, or disable the vulnerable feature. The root-cause fix follows, with a target of about a week. Containment buys time; it is not the fix. If the real fix genuinely needs longer, for example because it involves an architectural change, record that as a time-bound risk acceptance with the containment documented, rather than letting the deadline slide quietly.

High is more flexible: typically achievable within a two-week sprint without pushing schedules too hard. Medium fits into a normal sprint without acceleration. Low and Informational findings can be batched into scheduled maintenance cycles, because the effort required to fix all of them immediately is disproportionate to the risk they represent.

The remediation lifecycle from finding to closure

The diagram below shows the typical flow from report delivery to a finding being closed or formally risk-accepted. The return arrow from Retest to Fix represents the situation where evidence submitted is insufficient or the fix does not fully address the finding.

Evidence the retest team accepts

A retest cannot proceed without verifiable evidence. The testing team needs to see that the claimed change was actually applied and that it addresses the finding directly, not just masks the symptom.

A proof-of-concept that worked before and fails after the fix is useful evidence, but it is not enough on its own. The original exploit can fail for reasons that have nothing to do with the vulnerability: a filter that blocks that one payload, credentials that were rotated, or an endpoint that happened to be down during the retest. So the retest team looks for both: evidence that the underlying cause was fixed, such as the commit, configuration change or patch, and an exploitation path that stays closed when the attack is varied.

How a retest works

A retest is not a full repeat of the original engagement, but it is more than replaying one request. The testing team confirms the fix is in place at the root cause, runs the proof-of-concept from the original report against the fixed system, and then tries reasonable variations: a different encoding of the payload, a neighbouring parameter or endpoint, another user role. If any of them still works, the finding stays open. If the original exploit now fails only because a WAF rule or input filter blocks that payload, the finding is recorded as mitigated rather than closed, and the root-cause fix stays on the list. A finding is closed when the cause is fixed and the variants fail too, and the result is recorded.

Retest results are published as an addendum to the original report, not as a new document. This matters because management, auditors, and partners who hold the original report can see progress without requesting a separate document. The addendum shows which findings are closed, which remain open, and whether open findings are still being remediated or have been formally accepted as risk.

The time between submitting fix evidence and the scheduled retest slot is typically agreed at the start of the engagement. Contact us early if fixes complete ahead of schedule, since open retest slots are not always immediately available.

Findings that cannot be fixed right now

Some findings cannot be resolved within a normal timeframe: legacy systems no longer supported by vendors, architectures requiring significant redesign, or third-party dependencies awaiting an unavailable update. In these cases, the available path is formal risk acceptance with documented compensating controls.

Compensating controls are measures that reduce the likelihood or impact of exploitation without fixing the underlying vulnerability: restricting network access to a vulnerable system, tightening log monitoring, or isolating the system from more critical segments. These need to be documented in writing, covering who made the decision, why an immediate fix is not possible, what controls are in place, and when the situation will be reviewed.

Risk acceptance is not a decision that can be made informally. In regulated environments, this typically needs to enter the IT risk management documentation and be recorded by decision-makers at the appropriate level.

Remediation and reporting obligations in Indonesia

For commercial banks, the reporting rule depends on which kind of test it was. A penetration test belongs to the vulnerability-analysis stream, and its results go to OJK as a compilation inside the annual report on the bank's IT condition, no later than 15 working days after the end of the reporting year (SEOJK 29/2022 romawi VII.4.b.1). Scenario-based tests are reported within 10 working days, and the test counts as complete when its results report is finished, not when testing stops (romawi VII.4.b.2). The prescribed format for scenario reports in Lampiran VI has a column for corrections already made and another for the follow-up plan where a finding is still open, which is exactly what a retest addendum gives you.

ISO/IEC 27001:2022 covers this in Annex A control 8.8, management of technical vulnerabilities (A.12.6.1 in the 2013 edition), which expects vulnerabilities to be identified, assessed and addressed. Certification auditors commonly ask to see that findings were actually closed, and a retest addendum is the cleanest evidence of that.

UU PDP names no specific test. Pasal 35 requires controllers to protect and secure personal data through technical operational measures, at a security level set by the nature and risk of the data. A remediation record that runs from finding to verified fix is the kind of evidence that shows those measures work in practice.

For testing scope and duration planning, see web and application penetration testing and how long a penetration test takes.