Vulnerability Management and Patching Policy
PART I - PURPOSE, SCOPE, AND LEGAL BASIS
Article 1. Purpose
1.1. This Policy establishes the process for identifying, assessing, classifying, remediating, and patching security vulnerabilities across HiTechCloud's entire system, in order to reduce the attack surface, prevent vulnerability exploitation, and uphold our information security commitment to Customers.
Article 2. Scope of application
2.1. Applies to: server and workstation operating systems; system software, middleware, and databases; web applications, APIs, and internal source code; container images and orchestration (Kubernetes); network devices and firmware; cloud infrastructure and integrated third-party services; and software libraries/dependencies.
Article 3. Legal basis and reference standards
- Law on Cybersecurity 2025 (Law No. 116/2025/QH15) and its implementing decrees; Decree 85/2016/ND-CP on securing information systems by classification level;
- Law on Personal Data Protection 2025 (Law No. 91/2025/QH15) and Decree 356/2025/ND-CP;
- Penal Code 2015 (amended and supplemented 2017);
- Reference standards: CVSS v3.1/v4.0 (vulnerability scoring); ISO/IEC 27001:2022 (A.8.8 – technical vulnerability management); NIST SP 800-40 (patch management); the OWASP Top 10; CIS Benchmarks; the MITRE ATT&CK framework; and the CVE/NVD databases.
This policy complements the Information Security Management System (ISMS) Policy and operates together with the Incident Response (IR) procedure.
PART II – VULNERABILITY IDENTIFICATION AND ASSESSMENT
Article 4. Vulnerability identification sources
4.1. HiTechCloud identifies vulnerabilities through: (a) scheduled automated vulnerability scanning; (b) third-party penetration testing; (c) monitoring of advisory sources including NVD/CVE, VNCERT/CC, software vendors and threat intelligence feeds; (d) a Responsible Disclosure / Bug Bounty program where applicable; and (e) source code security review (SAST/DAST/SCA) in the CI/CD pipeline.
Article 5. Scan frequency
5.1. Public-facing (internet-facing) systems: scanned weekly. Internal systems: scanned monthly. After every major infrastructure or application change: an additional scan is mandatory before going into production. Container images: scanned at build time and periodically in the registry.
Article 6. Severity classification (using CVSS)
| Level | CVSS score | Maximum patching deadline from confirmation |
|---|---|---|
| Critical | 9.0 – 10.0 | 7 days (urgent: applied immediately under emergency maintenance SLA) |
| High | 7.0 – 8.9 | 30 days |
| Medium | 4.0 – 6.9 | 90 days |
| Low | 0.1 – 3.9 | 180 days or per the scheduled maintenance cycle |
6.1. For vulnerabilities under active exploitation (actively exploited / zero-day) or with publicly available exploit code (PoC), the patching deadline is shortened as far as possible and the case is handled as an emergency regardless of CVSS score, in coordination with the Incident Response Procedure.
6.2. The base CVSS score is adjusted for context (environmental score): systems processing Level 4 data (under the ISMS classification) and high-criticality systems are prioritized for earlier patching.
PART III – PATCHING PROCESS
Article 7. Standard process
7.1. Handling sequence: (a) receive and verify the vulnerability (eliminating false positives); (b) assess severity and scope of impact; (c) plan the patch and test it in a staging environment; (d) obtain change approval under the Change Management process; (e) deploy the patch to production; (f) verify after patching and close the ticket; and (g) update the vulnerability record.
7.2. Every patch must be tested in a staging environment before going to production, except emergency patches for vulnerabilities under active exploitation — in that case the patch may be deployed rapidly with the approval of the Incident Commander and close monitoring afterwards.
Article 8. Temporary mitigation measures
8.1. When a vulnerability cannot be patched immediately (no patch is yet available, or the patch causes conflicts), HiTechCloud applies temporary mitigation measures: blocking at the WAF/firewall, disabling the affected feature, increasing monitoring, network segmentation, or a compensating control — until an official patch is applied.
Article 9. Change management and maintenance windows
9.1. Patching follows the Change Management process and is carried out within the maintenance window defined in the Service Level Agreement (SLA). Emergency patches are applied under the emergency maintenance mechanism (at least 30 minutes’ advance notice; not counted toward Downtime under the SLA if completed within 4 hours).
9.2. Every change must have a rollback plan in case the patch causes a fault.
PART IV - RESPONSIBILITIES, REPORTING, AND EFFECT
Article 10. Responsibilities and the shared responsibility model
10.1. HiTechCloud's responsibilities patching vulnerabilities at the infrastructure, platform and operating system layers managed by HiTechCloud (managed services).
10.2. Customer's responsibilities patching and updating applications, source code, CMS platforms (WordPress, plugins and so on), libraries and software that the Customer deploys on the service themselves (unmanaged/self-managed). HiTechCloud may provide alerts, or a chargeable patching service under a separate agreement.
10.3. The Information Security Officer (ISO) leads; the systems operations team carries out the work; vulnerability status is reported to the Information Security Committee (ISC).
Article 11. Reporting and measurement
11.1. HiTechCloud tracks the following metrics: the number of vulnerabilities by severity; the mean time to remediate (MTTR) at each severity level; the on-time patching rate (SLA compliance); and the number of outstanding vulnerabilities past their deadline.
11.2. Vulnerability management reports are submitted to the ISC quarterly; any overdue critical vulnerability must be reported to the Board of Directors.
Article 12. Responsible disclosure
12.1. HiTechCloud accepts vulnerability reports from security researchers via security@photuesoftware.com; we commit to taking no legal action against a good-faith reporter who stays within the permitted scope and does not exploit the vulnerability or disclose it publicly before HiTechCloud has remediated it. Testing must stay within the permitted scope and must not violate Clause 7 of the Terms of Service, the Abuse Reporting Policy, or the Cybersecurity Law 2025 (Luật An ninh mạng 2025).
Article 13. Effect
13.1. This policy takes effect from 01/07/2026 and is reviewed at least once every 12 months. The Vietnamese version prevails.
