| 1 | Receive reports via the /lapor form under the Kerentanan Keamanan (security vulnerability) category or by email to csirt@kutaitimurkab.go.id (with PGP encryption for sensitive information; the public key is on the Contact page). Reports received by email are recorded as tickets. | Secretary; Information Security Sub-Team | Vulnerability report ticket | When the report is received |
| 2 | Send an initial response to the reporter: acknowledgment of receipt, the ticket number, and a request for additional information if the report does not yet include a description, reproduction steps, impact, affected assets, or supporting evidence. | Information Security Sub-Team | Initial response sent | ≤ 3 working days after the report is recorded |
| 3 | Validation: checking the scope and the Out of Scope list, checking for duplicates of earlier reports, reproducing the finding non-destructively, assessing the impact, and setting the severity. The validation date is recorded on the ticket as the start of the remediation target period. | Information Security Sub-Team; Coordinator sets the severity | Validation result: valid, duplicate, out of scope, or not reproducible | Once the information is complete |
| 4 | If the report is a duplicate, out of scope, or cannot be reproduced, inform the reporter together with the reason, then resolve the ticket. If signs of active exploitation or a compromised system are found, open incident handling in accordance with SOP-KUTIMCSIRT-01. | Information Security Sub-Team | Notification to the reporter; incident ticket if needed | After validation |
| 5 | If the reporter has accidentally accessed personal data or confidential information, ask the reporter to stop accessing it, not to store or share the data, and to confirm its deletion. Assess together with the system owner whether a personal data protection failure has occurred. Suspected violations of the testing guidelines (for example DoS, altering or deleting data, or retrieving more data than a PoC requires) are reported to the Chair for a decision. | Information Security Sub-Team; Chair | Notes on the ticket | When this becomes known |
| 6 | Identify the system owner and send a TLP:AMBER vulnerability notification to the head of the regional government agency and the technical contact, describing the vulnerability, its severity, recommended fixes, temporary mitigations where available, and the remediation target. The reporter's identity is not included unless the reporter agrees. | Secretary; Information Security Sub-Team | TLP:AMBER vulnerability notification | After the report is found valid |
| 7 | Inform the reporter that the report is valid and has been forwarded to the system owner. | Information Security Sub-Team | Status update to the reporter | After step 6 |
| 8 | Monitor remediation together with the system owner and its third-party developers, provide technical support, and keep the reporter informed of progress. If the remediation target is at risk of being missed, escalate to the head of the regional government agency through the Chair and propose temporary mitigation. | Coordinator; relevant sub-team | Monitoring and escalation notes | Remediation targets from validation: Critical ≤ 30 days; High ≤ 60 days; Medium/Low ≤ 90 days |
| 9 | Fix verification: retesting non-destructively that the vulnerability can no longer be exploited. If it is not fully fixed, it is returned to the system owner with notes. | Information Security Sub-Team | Fix verification results | After the system owner declares the fix complete |
| 10 | Inform the reporter that the vulnerability has been fixed. Offer a listing in the Hall of Fame and ask for the reporter's consent to the name or alias and affiliation to be displayed. Hall of Fame entries contain only the name or alias, affiliation, a general summary of the finding without technical details, and the month of recognition. | Information Security Sub-Team; Chair approves the entry | Notification to the reporter; Hall of Fame entry (TLP:CLEAR) if approved | After successful verification |
| 11 | Disclosure: the reporter does not publish vulnerability details before they are fixed and without the approval of KUTIM-CSIRT. Requests for disclosure after the fix are reviewed first, including the reporter's draft write-up, to ensure it contains no personal data, credentials, or details of other assets that have not yet been fixed. If the vulnerability is in a third-party product also used by others, KUTIM-CSIRT coordinates with the product developer and may involve Gov-CSIRT Indonesia (BSSN). | Chair; Information Security Sub-Team | Written approval or rejection of disclosure | After the fix is verified |
| 12 | Close the ticket once all notes, notifications, and verification results have been archived. | Secretary | Ticket Closed | After steps 10 and 11 |