Legistify Services Private Limited
PATCH MANAGEMENT POLICY
Document Name: | PATCH MANAGEMENT POLICY |
|
|
Classification: | Internal |
|
|
Document Owner: | CISO/MR- |
|
|
Document Approver: | Top Management |
|
|
Original Document Issue Date: | 10/09/2023 |
|
|
Current Edition: | Version 4.0 |
|
|
Revision History: |
|
|
|
S. No. | Description of Change | Date of Change | Version No. |
1 | Initial Release | 10/09/2023 | 1.0 |
2 | Second Release | 10/09/2024 | 2.0 |
3 | Third Release | 10/09/2025 | 3.0 |
4 | Fourth Release | 10/09/2026 | 4.0 |
Purpose of the Policy
This Policy defines how Legistify identifies, assesses, tests, approves, deploys, and verifies security patches across the assets supporting the Legistify SaaS platform.
In scope: operating systems and compute instances; container images and runtimes; databases and data stores; third-party application dependencies; the Legistify mobile application; CI/CD and source control tooling; cloud platform configuration and managed service versions; network and perimeter controls; employee endpoints with access to production or source code.
Out of scope: customer-managed systems, and third-party SaaS applications where patching is the vendor's responsibility.
Procedures
Roles and Responsibilities
Role | Responsibility |
Security Lead | Owns this Policy. Assigns severity, approves exceptions, reports patch compliance. |
Engineering Lead | Owns remediation delivery for application and dependency patches; assigns ticket owners. |
DevOps Owner | Executes OS, container, cloud and network patching; maintains scanning coverage. |
Change Approver | Authorises production deployment. |
IT Admin | Manages endpoint patching and compliance reporting. |
Vulnerability Identification
Vulnerabilities are identified through the following sources. All confirmed findings are raised as tickets in Zoho in the Patch Management project, irrespective of source.
Source | Coverage | Frequency |
SonarQube | Application source code, per repository | Every pull request / merge |
Trivy | Container base images, application images and bundled application dependencies | Every image build in CI |
Cloud provider advisories and maintenance notices | Managed services and platform | Continuous |
VAPT / penetration testing | Full platform | Annually |
Severity Classification and Remediation SLAs
Severity is taken from the rating reported by the detecting tool — SonarQube, Trivy, or the VAPT provider — and adjusted where warranted for exposure of the affected asset, presence of customer personal data, and availability of a public exploit. Any adjustment is justified in the ticket.
Severity | Remediation SLA |
Emergency — confirmed active exploitation | 24–48 hours |
Critical | 7 calendar days |
High | 30 calendar days |
Medium | 90 calendar days |
Low | 180 calendar days |
The SLA clock starts when the vulnerability is identified by Legistify, and is met only when remediation is verified in production per the Verification and Closure section. Employee endpoints are patched on a monthly cycle, with critical OS and browser updates applied within 7 days of vendor release.
Patch Management Process
Stage | Action | Timeline |
1. Identify | Ticket raised in Zoho recording the detection source, affected asset and environment, current and target version, CVE reference where applicable, and assigned owner. | 1 business day of detection |
2. Assess | The Security Lead confirms applicability, assigns severity and SLA due date, and identifies affected assets. False positives are closed with justification. | 2 business days; 4 hours for suspected Critical |
3. Plan | Owner determines remediation approach and documents a rollback plan, or a verified restore point where rollback is not feasible. | Within SLA |
4. Test | Patch tested in staging per the Security Testing section. Evidence attached to ticket. | Within SLA |
5. Approve | The Change Approver records approval in the ticket with name and timestamp. Approval must post-date test evidence. | Within SLA |
6. Deploy | Deployed via the standard CI/CD pipeline in the approved window. Date, time and executor recorded. Manual deployment recorded with justification. | Within SLA |
7. Verify | Remediation confirmed per the Verification and Closure section and evidence attached. | Within SLA |
8. Close | Closed by the Security Lead only where verification evidence is present. SLA compliance recorded. | — |
Emergency patches. Where active exploitation is confirmed, the Security Lead declares an emergency. Compensating controls — WAF rule, feature disablement, network restriction — are applied where they reduce immediate exposure. Testing is abbreviated to smoke and targeted regression. Approval may be given verbally by Top Management and must be recorded in the ticket within 24 hours. Full verification and retrospective review are completed within 5 business days.
Customer notification. Where a patch requires downtime or service degradation, customers are notified at least 48 hours in advance by email and WhatsApp. For emergency patches, notification is issued as early as practicable.
Verification and Closure
A ticket may not be closed on the basis of a deployment record alone. Closure requires at least one of:
Rescan by the detecting tool showing the finding resolved
Version confirmation on the affected asset
Targeted retest confirming the vulnerability is no longer exploitable
For VAPT findings, retest confirmation or closure certificate from the testing provider
Security Testing Before Deployment
No patch or change reaches production without the following:
Test | Applies To | Evidence |
Static analysis — SonarQube | All code changes | Analysis result with quality gate status |
Container image scan — Trivy | All container image builds | Trivy report showing no unresolved Critical / High |
Functional and regression testing | All behavioural changes | Test execution record |
Smoke test in staging | All patches | Confirmation in ticket |
The CI/CD pipeline enforces a security quality gate that blocks the build where SonarQube reports Critical or High code findings, or where Trivy reports an unresolved Critical or High vulnerability in a container image or its bundled dependencies. Overrides require approval from the Security Lead and the justification is recorded in the ticket.
Where a patch cannot be tested in staging — for example a provider-applied managed service upgrade — the rationale and the confirmed rollback or restore path are recorded in the ticket.
Exceptions
Where a patch cannot be deployed within SLA, an exception is raised in the ticket recording: the reason; compensating controls applied; residual risk; approver name, role and date; and an expiry date not exceeding 90 days. Critical and High exceptions require approval at Head of Engineering level. Open exceptions are reviewed monthly. An exception is not a permanent waiver.
Policy Revision History
Date | Version | Author | Reviewer | Approver | Comments |
10/09/2023 | 1.0 | ISMS Manager | CIO | Legistify Services Pvt. Ltd. Management | Initial release of the Patch Management Policy |
10/09/2024 | 2.0 | ISMS Manager | CIO | Legistify Services Pvt. Ltd. Management | Annual review completed; minor updates incorporated to reflect current patch management practices |
10/09/2025 | 3.0 | ISMS Manager | CIO | Legistify Services Pvt. Ltd. Management | Annual review completed; policy revised to align with updated organisational and security requirements |
10/09/2026 | 4.0 | ISMS Manager | CIO | Legistify Services Pvt. Ltd. Management | Annual review completed; policy updated to reflect changes in tooling and remediation standards |