Technical Vulnerability Management Policy¶
| Owner | Classification | Review Date | Status |
|---|---|---|---|
| CDO Office | Internal | April 2027 | Active |
Document Type: Policy | Owner: CISO | Classification: Confidential | Review Cycle: Annual
| Field | Detail |
|---|---|
| Document # | SP-TVMP-035 |
| Version | V1.2 |
| Issue Date | 08/09/2025 |
| Confidentiality Level | Class 2 (Private Data / Confidential) |
| Document Owner | Chief Network Officer |
| Authorised By | Yassir Pasha |
Document Creation¶
| Field | Detail |
|---|---|
| Document # | SP-TVMP-035 |
| Document Title | Technical Vulnerability Management Policy |
| Version | V1.2 |
| Confidentiality Level | Class 2 (Private Data / Confidential) |
| Date Created | 06/03/2021 |
| Issue Date | 08/09/2025 |
| Document Owner | Chief Network Officer |
| Author(s) | Simpaisa |
| Purpose | To check technical vulnerability management policy is implemented |
| Authorised By | Yassir Pasha |
Reviewed By Steering Committee¶
| Name | Role |
|---|---|
| Yassir Pasha | Chief Executive Officer |
| Kamil Shaikh | Chief Operating Officer |
| Osama Hashmi | Chief Financial Officer |
| Bachir Njeim | Chief Strategy and Operations Officer |
| Saqlain Raza | Acting Chief Technology Officer |
| Rizwan Zafar | Chief Product Officer |
| Ahsan Hussain | Payment Channel Partnerships |
| Danish Abdul Hameed | Chief Information Security Officer |
| Shahroze Khan | Head of International Merchant Sales and Strategic Alliances |
| Noor Ali | Country Head Pakistan |
| Shoukat Bizinjo | Global Head of Regulatory Affairs & Regulatory |
Change Control¶
| Version | Date of Issue | Author(s) | Brief Description of Changes | Approved By |
|---|---|---|---|---|
| V1.0 | 28/04/2021 | Rizwan Zafar | Initial release | Salim Karim |
| V1.1 | 07/02/2022 | Rizwan Zafar | Annual review | Salim Karim |
| V1.2 | 02/02/2023 | Rizwan Zafar | Annual review | Salim Karim |
| V1.2 | 27/09/2024 | Syed Zubair Ahmed | Annual review | Yassir Pasha |
| V1.2 | 08/09/2025 | Simpaisa | Annual review | Yassir Pasha |
1 Introduction¶
Malware is any code or software that may be harmful or destructive to the information processing capabilities of the organisation and is one of the primary tools used by attackers to circumvent security in order to gather information, make money or just disrupt the normal operation of the business.
It is essential that effective precautions are taken by Simpaisa to protect itself against this threat which can come from a number of sources including organised gangs, competitor organisations, politically motivated groups, rogue employees, nation state sponsored "cyberwarfare" units or simply individuals exercising curiosity or testing their skills.
Whatever the source, the result of a successful security breach is that the organisation and its stakeholders are affected, sometimes seriously, and harm is caused.
Malware comes in many forms and is constantly changing as previous attack routes are closed and new ones are found.
For malicious software to carry out its intended purpose it needs to be installed on the target device or computer. There are a number of key ways in which malware infects computers and networks, although new ways are being created all the time.
The most common infection routes are as follows:
-
Phishing
-
Websites and Mobile Code
-
Removable Media
-
Hacking
But for these techniques to be used by an attacker, they must take advantage of a vulnerability in our defences (see section 2.1 for a definition).
This document sets out the organisation's policy on how it will assess and manage technical vulnerabilities within the IT environment, which includes the cloud services it uses. Its intended audience is IT and information security management and support staff who will implement and maintain the organisation's defences.
This control applies to all systems, people and processes that constitute the organisation's information systems, including board members, directors, employees, suppliers and other third parties who have access to Simpaisa systems.
The following policies and procedures are relevant to this document:
-
Mobile Device Policy
-
Remote Working Policy
-
Acceptable Use Policy
-
Electronic Messaging Policy
-
Internet Acceptable Use Policy
-
Change Management Process
-
Software Policy
-
Anti-Malware Policy
-
Network Security Policy
-
Information Security Policy
2 Technical Vulnerability Management Policy¶
2.1 What is a Technical Vulnerability?¶
A vulnerability is commonly defined as "an inherent weakness in an information system, security procedures, internal controls, or implementation that could be exploited by a threat source."
The software development process is complicated and its output in the form of software programs is rarely bug free. Most of these bugs simply affect the functionality of the software so that it doesn't work as intended. However, if manipulated in the correct way, some can allow an attacker to gain some form of advantage or access which was not intended by the developer. This type of bug is considered to be a software vulnerability.
These vulnerabilities are constantly being found and corrected via software updates or patches. Unfortunately, it is not always the developer or user who discovers these vulnerabilities. When discovered by a potential attacker the vulnerability becomes something to be exploited for gain and kept secret for as long as possible. A newly discovered vulnerability is often referred to as a "zero-day exploit" and is difficult to defend against.
Simpaisa's policy with respect to technical vulnerabilities is to be aware of them and to close them where possible, either directly or via other means.
2.2 Sources of Information¶
The first step in managing technical vulnerabilities is to become aware of them. Since we are talking about technical vulnerabilities these will of course depend upon the technology employed within the organisation. It is necessary then to gain a full appreciation of the technology components that make up the organisation's infrastructure and their versions (since most technical vulnerabilities are very version-specific).
This should include:
-
Operating systems e.g. Windows, UNIX, Cisco
-
Databases e.g. SQL Server, MySQL
-
Web servers e.g. IIS, Apache
-
Desktop software e.g. Office, Acrobat
-
Web technologies e.g. Flash, Java
-
Application software e.g. SAP, Agresso
-
Hardware e.g. servers, routers
Information about vulnerabilities with any of the above components is generally available from the vendor who will issue updates and patches to fix those that it becomes aware of.
A process must therefore be put in place to ensure that all relevant information about updates is being received and reviewed by competent staff members. This will usually give guidance about the level of urgency associated with each update.
Where configuration changes are recommended to close off vulnerabilities, these must be actioned through the organisation change management process so that appropriate controls are in place for testing, risk assessment and back-out.
For cloud services, the responsibilities of the cloud service provider (CSP) and Simpaisa as the cloud service customer, must be defined and agreed. This may involve the CSP being responsible for vulnerability assessment and patching for some or all aspects of the service, depending on the cloud service model adopted (e.g. IaaS, PaaS or SaaS or similar service definitions).
2.3 Assigning Risk Rankings¶
A process will be established to review new security vulnerabilities and assign a risk ranking. A simple scoring mechanism will be implemented to place the vulnerabilities into three categories of "High," "Medium," or "Low". The risk score will depend on the following factors:
-
Based on industry best practices on classifying vulnerability risk scores
-
Potential impact on the organisation
-
Classification by the vendor
-
System affected and the data it may hold
A security vulnerability can also be identified as "critical" if one or more of the following criteria are met:
-
Poses an imminent threat to the organisation
-
Impacts critical systems (e.g. public-facing devices or systems)
-
Will result in potential compromise to systems
2.4 Patches and Updates¶
Patches and updates will typically be issued by software vendors on a regular schedule as cumulative packages. These will be linked to the specific version of software that they relate to and may have dependencies stipulated with other software modules, products or operating systems.
Procedures must be put in place to obtain copies of the software updates electronically when they are issued by the vendor. If an update is identified as "critical," the update will be installed within one month of release. All other updates will be installed within three months of release. However, the scheduling of the installation of updates will depend upon several factors including:
-
The criticality of the systems being updated
-
The expected time taken to install the updates (and requirements for service outages to users)
-
The degree of risk associated with any vulnerabilities that are closed by the updates
-
Co-ordination of the updating of related components of the infrastructure
-
Dependencies between updates
An update release plan will be created and maintained to keep track of when various systems will be updated, considering the factors listed above. The plan must be managed through the change management process. For updates that are low risk and regular, a standard change may be defined within the change management process to allow this to happen without excess administrative overhead.
Patch management system NinjaRMM will be used to list patch management, alerts, security and support.
2.5 Hardening¶
A further action that must be taken to reduce the number and extent of vulnerabilities within Simpaisa systems is the hardening of server and other device configurations. This involves the shutting down of services and protocols that are not needed so that the attack surface is reduced.
These hardening activities must be carried out according to vendors' guidelines and under the control of the change management process.
2.6 Awareness Training¶
As a result of vulnerability assessment, it may be necessary to increase efforts in security awareness training for employees and contract staff. This training should explain the nature of vulnerabilities and what can be done to reduce them.
3 Network Security and Vulnerability Testing¶
A fundamental part of network security and vulnerability management is the ability to test and verify the 'strength' of the organisation's security controls against ever-changing cyber threats. To achieve this a variety of tests will be performed as described below.
Test results will be recorded, risk assessed, ranked (usually as high, medium and low) and applied to the treatment process to remediate any vulnerabilities found. Refer to the Risk Assessment and Treatment Process for more information.
Internal and external targets for testing include but are not limited to:
-
Perimeter network to the internet or public networks
-
DMZ
-
Internal network segmentation perimeters
-
Cardholder Data Environment (CDE) perimeter
-
Cloud providers
-
Wireless Network
3.1 Penetration Testing¶
A penetration test (also known as a pen test), is an authorised simulated attack on a computer or network that looks for security weaknesses, potentially gaining access to the system's features and data.
Internal and external penetration testing will be performed by a qualified internal resource or a qualified external third party at least annually (or every six months if the organisation is a service provider of card payment services) and after any significant infrastructure or application change. Tests will be based on industry-accepted penetration testing approaches (for example, NIST SP800115).
3.2 Vulnerability Scans¶
A vulnerability scanner is a computer program designed to assess computers, computer systems, networks, or applications for weaknesses.
Internal and external vulnerability scans will be performed at least quarterly and after any significant change to the network. To fulfil the organisation's PCI DSS compliance requirements, external scans will be performed via an Approved Scanning Vendor (ASV) designated by the PCI DSS Council.
3.3 Wireless¶
A process must be put in place to test for the presence of rogue unauthorised wireless access points on a quarterly basis. IDS/IPS (Intrusion Detection System/Intrusion Prevention System) technologies may be used to perform this test if available. Any potential threats found must be risk assessed and the treatment process applied to address any vulnerabilities found. Refer to the Risk Assessment and Treatment Process for more information.