Information Security Incident Response Procedure
PART I – PURPOSE, DEFINITIONS AND LEGAL BASIS
Article 1. Purpose
1.1. This procedure establishes the standard framework by which HiTechCloud detects, analyzes, contains, remediates, recovers from and learns from a Security Incident, in order to: (a) limit damage; (b) maintain SLA commitments to Customers; (c) protect personal data in accordance with the PDPD; and (d) comply with the obligation to notify the competent authority and affected Customers.
Article 2. Definitions
2.1. “Security Event” (Security Event): an observation potentially related to security (failed login, port scan). “Security Incident” (Security Incident): a confirmed event that breaches, or threatens to breach, security policy. “Data Breach” (Data Breach): an incident that exposes, loses, alters or destroys data without authorization. “CSIRT”: HiTechCloud's internal information security incident response team.
Legal basis:
- The Law on Cybersecurity 2025 (Luật An ninh mạng 2025 — Law No. 116/2025/QH15, effective 1 July 2026; a consolidating law replacing the Law on Cybersecurity 2018 and the Law on Cyberinformation Security 2015), on protecting cybersecurity and on incident coordination and response;
- Decree 85/2016/ND-CP on securing information systems by classification level, and the decrees implementing the Cybersecurity Law 2025;
- The Personal Data Protection Law 2025 (Law No. 91/2025/QH15) and Decree 356/2025/ND-CP on personal data breach notification;
- Decision 05/2017/QĐ-TTg on the national emergency response plan for cyber information security and the incident response network (VNCERT/CC);
- GDPR (Articles 33 and 34) - applies to data subjects within scope.
PART II - INCIDENT RESPONSE TEAM (CSIRT) STRUCTURE
Article 3. CSIRT composition
3.1. The CSIRT comprises: (a) the Incident Commander — the security manager (CISO/ISO); (b) technical response staff (Tier 1/Tier 2 NOC plus SOC); (c) digital forensics specialists; (d) legal counsel and the DPO (for incidents affecting personal data); (e) a communications and customer relations representative; and (f) a Board observer (for P1 incidents).
3.2. CSIRT operates 24/7 on a rotating on-call basis. Email: csirt@photuesoftware.com.
Article 4. Incident severity levels
4.1. Incidents are classified into 4 levels: P1 – CRITICAL (system-wide loss of service, Level 4 data breach, widespread ransomware, key/secret disclosure — response ≤ 15 minutes); P2 – HIGH (loss of service for a significant customer group, unauthorized access to production systems, disclosure of Level 3 data — response ≤ 30 minutes); P3 – MEDIUM (malware on 1–2 servers, brute force from a single IP, an unexploited critical vulnerability — response ≤ 2 hours); P4 – LOW (port scans, unusual failed logins, minor anomalies — response ≤ 1 business day). The classification levels are aligned with the data classification in the Information Security System Policy and with the P1–P4 priority levels in the SLA.
PART III - THE SIX-STEP PROCESS (BASED ON NIST SP 800-61)
Article 5. Step 1 – Preparation
5.1. HiTechCloud maintains: (a) incident response runbooks by incident type (DDoS, ransomware, data leak, phishing, insider threat), reviewed every 12 months; (b) a standard forensic toolkit (FTK Imager, Volatility, Wireshark, GRR, Velociraptor, OSSEC, Wazuh); (c) incident exercises (tabletop plus live drill) at least every 6 months; and (d) an emergency contact list covering state authorities, infrastructure partners, legal counsel and insurers.
Article 6. Step 2 - detection and analysis
6.1. Detection sources: (a) SIEM – centralized log aggregation; (b) IDS/IPS and EDR/XDR real-time alerts; (c) Customer reports by ticket, hotline or email report@photuesoftware.com (under the Abuse Reporting Policy); (d) notification from a third party (VNCERT/CC, a CDN partner, a threat intel feed).
6.2. On receiving a signal, SOC Tier 1 performs an initial assessment within ≤ 15 minutes and classifies the event P1–P4. P1 and P2 incidents are escalated to Tier 2 and to the Incident Commander immediately.
Article 7. Step 3 – Containment
7.1. Short-term containment: isolate the compromised host, block malicious IPs/domains at the NGFW/DNS layer, temporarily lock suspicious accounts, and snapshot virtual machines before isolation.
7.2. Long-term containment: rebuild systems, rotate all secrets and keys, patch the root-cause vulnerability, and apply new hardening configurations.
7.3. Containment decisions are approved by the Incident Commander; for P1, the Board of Management is notified within 1 hour.
Article 8. Step 4 – Eradication
8.1. After containment, the technical team identifies the root cause, removes the malware, closes fraudulent accounts and deletes attacker artifacts.
8.2. Every eradication action must be fully logged (timestamp, person performing it, action, affected host).
Article 9. Step 5 – Recovery
9.1. Restore the service from a clean backup (confirmed uninfected) under the Backup & Recovery Policy.
9.2. Before a system is returned to production, the following must be completed: vulnerability scanning, integrity checks on critical files, and 7 days of enhanced monitoring after recovery.
Article 10. Step 6 - lessons learned
10.1. After each P1 or P2 incident, the CSIRT holds a review meeting within 5 business days and issues a root cause analysis (RCA) report within 10 business days.
10.2. The RCA covers: the incident timeline, technical and process root causes, estimated losses, remedial actions, and measures to prevent recurrence.
PART IV – NOTIFICATION OBLIGATIONS
Article 11. Customer notification
11.1. For incidents that affect Customer services, HiTechCloud sends notifications via the registered email address, the status board at status.hitechcloud.vn and a system ticket, and — for P1 incidents — by direct telephone call where possible.
11.2. Time to first notification: ≤ 30 minutes from confirmation of a P1; ≤ 2 hours for P2; ≤ 8 hours for P3/P4. Update notifications are issued at least every 2 hours for P1 until the issue is resolved.
Article 12. Notification to state authorities
12.1. For network information security incidents: coordinate with and notify the competent state authorities on network safety and security (the Ministry of Science and Technology; VNCERT/CC) and the Department of Cybersecurity and High-Tech Crime Prevention (A05, Ministry of Public Security), in accordance with the Cybersecurity Law 2025 (Luật An ninh mạng 2025) and Decision 05/2017/QĐ-TTg.
12.2. For a personal data breach incident: notify A05 (Ministry of Public Security) within the period prescribed by the Personal Data Protection Law 2025 (Luật Bảo vệ dữ liệu cá nhân 2025) and Decree 356/2025/NĐ-CP, and also notify the affected data subjects and Customers where the risk is high. HiTechCloud's operational target is to notify within 72 hours of confirming the breach, unless the law prescribes a different deadline.
Article 13. Notification in international jurisdictions
13.1. For data on subjects in the EU/EEA: notify the relevant supervisory authority within 72 hours under Article 33 GDPR, and notify the data subjects under Article 34 GDPR where the risk is high.
13.2. For data subjects in other jurisdictions that impose notification requirements (UK, California, Singapore…): the requirements of each jurisdiction are followed.
PART V - EVIDENCE PRESERVATION AND COOPERATION WITH INVESTIGATIONS
Article 14. Chain of custody
14.1. All digital evidence (disk images, memory dumps, logs, packet captures) is collected under chain-of-custody principles, recording who collected it, when, the SHA-256 hash, the method used and the purpose.
14.2. Evidence is held in a separate repository under strict access control for at least 24 months from the date the incident closes (or longer where required by a competent authority or by ongoing legal proceedings).
Article 15. Cooperation with investigating authorities
15.1. HiTechCloud cooperates with the police, the procuracy and the courts upon lawful written request.
15.2. Every request for the provision of data must be reviewed by the legal department for lawfulness and scope before the data is provided; the provision of personal data follows the minimum-necessary principle under the PDPD.
PART VI - EFFECT
Article 16. Effective date and review
16.1. This procedure takes effect on 01/07/2026 and is reviewed at least once every 12 months.
16.2. Every amendment must be approved by the Director and announced internally at least 5 business days before it takes effect.
