Security Incident Response Procedure (SIRP)¶

Owner	Classification	Review Date	Status
CDO Office	Internal	April 2027	Active

Document Type: Procedure | Owner: CISO | Classification: Confidential | Review Cycle: Annual

Field	Detail
Document #	SP-SIR-015
Version	V1.4
Issue Date	08/09/2025
Confidentiality Level	Class 2 (Private Data / Confidential)
Document Owner	Chief Technical Officer, Chief Network Officer, Chief Operating Officer
Authorised By	Yassir Pasha

Document Creation¶

Field	Detail
Document #	SP-SIR-015
Document Title	Security Incident Response Procedure
Version	V1.4
Confidentiality Level	Class 2 (Private Data / Confidential)
Date Created	26/03/2021
Issue Date	08/09/2025
Document Owner	Chief Technical Officer, Chief Network Officer, Chief Operating Officer
Author(s)	Simpaisa
Purpose	To ensure incidents are promptly identified, managed, and resolved in a consistent manner to minimise business, operational, and security impact.
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.3	10/10/2024	Syed Zubair Ahmed	Updated Section 5.1, 5.3, 5.4, Added section 7 and 9, Appendix A & B updated	Yassir Pasha
V1.4	08/09/2025	Simpaisa	Impact (high, medium, low) definition added	Yassir Pasha

1 Introduction¶

This document is intended to be used when an incident of some kind has occurred that affects the security of Simpaisa. It is intended to ensure a quick, effective and orderly response to security incidents.

The procedures set out in this document should be used only as guidance when responding to an incident. The exact nature of an incident and its impact cannot be predicted with any degree of certainty and so it is important that a good degree of common sense is used when deciding the actions to take.

However, it is intended that the structures set out here will prove useful in allowing the correct actions to be taken more quickly and based on more accurate information.

The objectives of this incident response procedure are to:

Provide a concise overview of how Simpaisa will respond to an incident affecting its information security
Set out who will respond to an incident and their roles and responsibilities
Describe the facilities that are in place to help with the management of the incident
Define how decisions will be taken with regard to our response to an incident
Explain how communication within the organisation and with external parties will be handled
Provide contact details for key people and external agencies
Define what will happen once the incident is resolved and the responders are stood down

All members of staff named in this document will be given a copy which they must have available when required.

A process is developed to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

This document is subject to annual reviews and at least an annual test of the incident procedure. Training and awareness will be provided to responsible members of the incident procedure.

Contact details will be checked and updated at least two times a year. Changes to contact or other relevant details that occur outside of these scheduled checks should be sent to [email protected] as soon as possible after the change has occurred.

All personal information collected as part of the incident response procedure and contained in this document will be used purely for the purposes of information security incident management and is subject to relevant data protection legislation.

2 Incident Response Flowchart¶

The flow of the incident response procedure follows these steps:

Incident Detection and Analysis
Activate Incident Response Procedure? (Yes → proceed; No → end)
Assemble Incident Response Team
Containment, Eradication, Recovery and Notification
Cease Response Activities? (Yes → proceed; No → return to step 4)
Post-Incident Activities
End of Procedure

These steps are explained in more detail in the rest of this procedure.

3 Incident Detection and Analysis¶

The incident may be initially detected in a wide variety of ways and through several different sources, depending on the nature and location of the incident. Some incidents may be self-detected via software/web application/network tools used within Simpaisa or by employees noticing unusual activity. Others may be notified by a third party such as a customer, supplier or law enforcement agency who has become aware of a breach perhaps because the stolen information has been used in some way for malicious purposes.

It is not unusual for there to be a delay between the origin of the incident and its actual detection; one of the objectives of prevention and detection systems is to reduce this time period. The most important factor is that the incident response procedure must be started as quickly as possible after detection so that an effective response can be given.

Once the incident has been detected, an initial impact assessment must be carried out in order to decide the appropriate response.

Incident response and monitoring coverage should be available 24/7 in case of:

Any evidence of unauthorised activity.
Detection of unauthorised wireless access points.
Critical IDS alerts.

This impact assessment should estimate:

The extent of the impact on IT infrastructure including computers, networks, equipment and accommodation
The information assets that may be at risk or have been compromised
The likely duration of the incident i.e. when it may have begun
The business units affected and the extent of the impact to them
Initial indication of the likely cause of the incident
Reports of unauthorised critical system or content file changes.

This information should be documented so that a clear time-based understanding of the situation as it emerges is available for current use and later review.

A list of the information assets, business activities, products, services, teams and supporting processes that may have been affected by the incident should be created together with an assessment of the extent of the impact.

As a result of this initial analysis, any member of the management team has the authority to contact the Incident Response Team Leader at any time to ask him/her to assess whether the Incident Response Procedure should be activated.

4 Activating the Incident Response Procedure¶

Once notified of an incident the Team Leader must decide whether the scale and actual or potential impact of the incident justifies the activation of the Incident Response Procedure and the convening of the Incident Response Team (IRT).

Guidelines for whether a formal incident response should be initiated for any incident of which the Team Leader has been notified are if any of the following apply:

There is significant actual or potential loss of classified information
There is significant actual or potential disruption to business operations
There is significant risk to business reputation
Any other situation which may cause significant impact to the organisation

In the event of disagreement or uncertainty about whether to activate an incident response the decision of the Team Leader will be final.

If it is decided not to activate the procedure, then a plan should be created to allow for a lower-level response to the incident within normal management channels. This may involve the invocation of relevant procedures at a local level.

If the incident warrants the activation of the IR procedure the Team Leader will start to assemble the IRT.

5 Assemble Incident Response Team¶

Once the decision has been made to activate the incident response procedure, the Team Leader (or deputy) will ensure that all role holders (or their deputies if main role holders are uncontactable) are contacted, made aware of the nature of the incident and asked to assemble at an appropriate location. The exception is the Incident Liaison, who will be asked to attend the location of the incident (if different) to start to gather details for the incident assessment that the IRT will conduct so that an appropriate response can be determined.

5.1 Incident Response Team Members¶

The Incident Response Team will generally consist of the following people in the roles specified and with the stated deputies, although the exact make-up of the team will vary according to the nature of the incident. Following members of Simpaisa are designated to be available on a 24/7 basis to monitor and respond to alerts and incidents.

Role/Business Area	Main Role Holder	Deputy
Team Leader	Saqlain Raza	Technology Head
Team Facilitator	Muhammad Taimoor Bhatti	Product Manager
Information Technology	Muhammad Mohsin	Head of DevOps
Business Operations	Ahsan Hussain	Business Operation
Health and Safety	Atiya Abdul	Human Resource
Human Resources	Atiya Abdul	Human Resource
Business Continuity Planning	Ahsan Hussain, Muhammad Mohsin, Saqlain Raza, Muhammad Taimoor Bhatti, Atiya Abdul, Yassir Pasha, Danish Hamid, Rizwan Zafar
Communications (PR and Media Relations)	Khushnood Shoukat Andani, Zara Haleem	Media Team
Legal and Regulatory	Moiz Bhirya	Accounts & Finance

Contact details for the above are listed at Appendix A of this document.

5.2 Roles and Responsibilities¶

The responsibilities of the roles within the incident response team are as follows:

5.2.1 Team Leader¶

Decides whether or not to initiate a response
Assembles the incident response team
Overall management of the incident response team
Acts as interface with the board and other high-level stakeholders
Final decision maker in cases of disagreement

5.2.2 Team Facilitator¶

Supports the incident response team
Co-ordinates resources within the command centre
Prepares for meetings and takes record of actions and decisions
Briefs team members on latest status on their return to the command centre
Facilitates communication via email, fax, telephone or other methods
Monitors external information feeds such as news

5.2.3 Incident Liaison¶

Attends the site of the incident as quickly as possible
Assesses the extent and impact of the incident
Provides first-person account of the situation to the IRT
Liaises with the IRT on an on-going basis to provide updates and answer any questions required for decision-making by the IRT

5.2.4 Information Technology¶

Provides input on technology-related issues
Assists with impact assessment
Business Operations
Contributes to decision-making based on knowledge of business operations, products and services
Briefs other members of the team on operational issues
Helps to assess likely impact on customers of the organisation

5.2.6 Facilities Management¶

Deals with aspects of physical security and access
Provides security presence if required

5.2.7 Health and Safety¶

Assesses the risk to life and limb of the incident
Ensures that legal responsibilities for health and safety are met at all times
Liaises with emergency services such as police, fire and medical
Considers environmental issues with respect to the incident

5.2.8 Human Resources¶

Assesses and advises on HR policy and employment contract matters
Represents the interests of organisation employees
Advises on capability and disciplinary issues

5.2.9 Business Continuity Planning¶

Provide advice on business continuity options
Invoke business continuity plans if required

5.2.10 Communications (PR and Media Relations)¶

Responsible for ensuring internal communications are effective
Decides the level, frequency and content of communications with external parties such as the media
Defines approach to keeping affected parties informed e.g. customers, shareholders
Legal and Regulatory
Advises on what must be done to ensure compliance with relevant laws and regulatory frameworks
Assesses the actual and potential legal implications of the incident and subsequent actions

5.2.11 Responsible, Accountable, Consulted and Informed (RACI)¶

Task	TL	TF	IL	IT	BO	FM	HS	HR	CP	CO	LR	EM
Incident detection	A	R	R	I	C	R	R	I	I	I	I	R
Incident analysis	A	R	R	C	C	C	C	I	C	I	I	I
Assemble incident response team	A	R	C	C	C	C	C	C	C	C	C	I
Containment	A	R	R	C	R	R	R	I	I	I	I	I
Eradication	A	R	R	C	R	R	R	I	C	I	I
Recovery	R	C	C	C	A	R	R	C	C	I	C	I
Communication – internal	A	C	C	C	C	C	C	R	C	R	C	I
Communication – external	A	C	C	C	C	C	C	C	C	R	C	I
Notification, for example ICO	A	C	C	R	C	C	C	C	I	C	R	I
Incident report	A	R	C	C	C	C	C	C	C	I	C	C
Post-incident review	A	R	C	C	C	C	C	C	C	C	C	C

5.3 Incident Management, Monitoring and Communication¶

Once an appropriate response to the incident has been identified, the Incident Response Team (IRT) must manage the overall response, monitor the status of the incident, and ensure effective communication occurs at all levels. Regular IRT meetings must be held at an appropriate frequency (e.g., daily, every other day, or weekly) as decided by the Team Leader. A standard agenda for these meetings is included in Appendix C. The purpose of these meetings is to manage incident resources effectively and make key decisions promptly based on adequate information. Minutes will be documented for each meeting by the Team Facilitator.

The Incident Liaison will provide updates to the IRT at a frequency decided by the Team Leader, using methods such as email, phone, or secure messaging platforms. These updates should be coordinated with IRT meetings to ensure the latest information is available for discussion.

5.4 Communication Procedures¶

It is crucial to maintain effective communication among all parties involved in the incident response. The following outlines the internal and external communication methods, guidelines, and procedures.

5.4.1 Internal Communication¶

Primary Communication Methods:

Face-to-Face Meetings: Used for initial discussions and when detailed explanations are necessary.
Telephone Communication: Both landline and mobile for immediate updates.
Secure Messaging Apps: For quick, informal communication among the IRT members.

Guidelines for Internal Communication:

Stay Calm: Keep conversations focused and succinct.
Designate Spokespersons: Only authorised IRT members should communicate information about the incident to prevent misinformation.
Refer Requests: Advise internal team members to refer all information requests to the IRT.
Documentation: All communications must be clearly and accurately recorded, including call times, details, responses, and actions taken. This documentation may be required for legal action later.

Regular Updates:

The IRT should establish a schedule for regular updates to be shared with internal stakeholders, ensuring everyone is informed of the incident status and response actions.

5.4.2 External Communication¶

Primary Communication Methods:

Official Statements: Pre-written press releases for consistency and clarity.
Media Briefings: Scheduled press conferences when necessary.
Direct Communication: Telephone calls or emails to stakeholders as appropriate.

Guidelines for External Communication:

Timeliness and Accuracy: Ensure that information released to external parties is timely and accurate.
Crisis Management Team: Designate a member of the IRT responsible for external communications who will coordinate with relevant departments (e.g., Legal, Public Relations).
Interested Parties Notification: Create a prioritised list of external parties who need to be notified (customers, suppliers, shareholders, regulatory bodies). Define the messages to be communicated to each group.

External Party	Message to Communicate	Method
Customers	Status updates on service and potential impacts	Email, phone calls
Suppliers	Information on supply chain impacts	Direct calls, emails
Shareholders	Overview of the incident's impact on the business	Official statements, reports
Regulatory Bodies	Compliance updates and required notifications	Formal letters, emails

The Communications IRT member should make a list of such interested parties and define the message that is to be given to them. A list of some external agencies is given at Appendix B.

Interested parties who have not been alerted by the IRT may call to obtain information about the incident and its effects. These calls should be recorded in a message log and passed to the Communications member of IRT.

5.4.3 Communication with the Media¶

In general, the communication strategy regarding the media will be to issue updates via top management. No staff member should give interviews with the media unless pre-authorised by the IRT.

The preferred interface with the media will be to issue pre-written press releases. In exceptional circumstances a press conference will be held to answer questions about the incident and its effects. It is the responsibility of the Communications IRT member to arrange the venue for these and to liaise with press that may wish to attend.

Media Communication Guidelines: When drafting a statement for the media, the following guidelines should be observed:

Personal Information Protection: Ensure that all personal information is protected at all times.
Stick to the Facts: Do not speculate about the incident or its cause.
Legal Consultation: Obtain legal advice prior to issuing any statements.
Anticipate Questions: Prepare for reasonable questions that may be asked by the media.
Highlight Preparedness: Emphasise that a prepared response has been activated and that all efforts are being made to address the incident effectively.

The following members of staff will be appointed spokespeople for the organisation:

Name	Role	Incident Scale
Zara Haleem	IRT Communications	Low
Shahroze Ahmed Khan	Head of Corporate Communications	Medium
Yassir Pasha	Chief Executive Officer	High

6 Incident Containment, Eradication, Recovery and Notification¶

6.1 Containment¶

The first step will be to try to stop the incident getting any worse i.e. contain it. In the case of a virus outbreak this may entail disconnecting the affected parts of the network; for a hacking attack it may involve disabling certain profiles or ports on the firewall or perhaps even disconnecting the internal network from the Internet altogether. The specific actions to be performed will depend on the circumstances of the incident.

Note: if it is judged to be likely that digital evidence will need to be collected that will later be used in court, precautions must be taken to ensure that such evidence remains admissible. This means that relevant data must not be changed either deliberately or by accident e.g. by waking up a laptop. It is recommended that specialist advice should be obtained at this point – see contacts at Appendix B.

Particularly (but not exclusively) if foul play is suspected in the incident, accurate records must be kept of the actions taken and the evidence gathered in line with digital forensics guidelines. The main principles of these guidelines are as follows:

Principle 1: Don't change any data. If anything is done that results in the data on the relevant system being altered in any way, then this will affect any subsequent court case.

Principle 2: Only access the original data in exceptional circumstances. A trained specialist will use tools to take a bit copy of any data held in memory, whether it's on a hard disk, flash memory or a SIM card on a phone. All analysis will then take place on the copy and the original should never be touched unless in exceptional circumstances e.g. time is of the essence and gaining information to prevent a further crime is more important than keeping the evidence admissible.

Principle 3: Always keep an audit trail of what has been done. Forensic tools will do this automatically, but this also applies to the first people on the scene. Taking photographs and videos is encouraged as long as nothing is touched to do it.

Principle 4: The person in charge must ensure that the guidelines are followed. Prior to the arrival of a specialist, basic information should be collected. This may include:

Photographs or videos of relevant messages or information
Manual written records of the chronology of the incident
Original documents, including records of who found them, where and when
Details of any witnesses

Once collected, the evidence will be kept in a safe place where it cannot be tampered with and a formal chain of custody established.

The evidence may be required:

For later analysis as to the cause of the incident
As forensic evidence for criminal or civil court proceedings
In support of any compensation negotiations with software or service suppliers

Next, a clear picture of what has happened needs to be established. The extent of the incident and the knock-on implications should be ascertained before any kind of containment action can be taken.

Audit logs may be examined to piece together the sequence of events; care should be taken that only secure copies of logs that have not been tampered with are used.

6.2 Eradication¶

Actions to fix the damage caused by the incident, such as deleting malware, must be put through the change management process (as an emergency change if necessary). These actions should be aimed at fixing the current cause and preventing the incident from re-occurring. Any vulnerabilities that have been exploited as part of the incident should be identified.

Depending on the type of incident, eradication may sometimes be unnecessary.

6.3 Recovery¶

During the recovery stage, systems should be restored back to their pre-incident condition, although necessary actions should then be performed to address any vulnerabilities that were exploited as part of the incident. This may involve activities such as installing patches, changing passwords, hardening servers and amending procedures.

6.4 Notification¶

The notification of an information security incident and resulting loss of data is a sensitive issue that must be handled carefully and with full management approval. The IRT will decide, based on legal and other expert advice and as full an understanding of the impact of the incident as possible, what notification is required and the form that it will take.

Simpaisa will always comply in full with applicable legal and regulatory requirements regarding incident notification and will carefully assess any offerings to be made to parties that may be impacted by the incident, such as credit monitoring services.

Records collected as part of the incident response may be required as part of any resulting investigations by relevant regulatory bodies and Simpaisa will cooperate in full with such proceedings.

7 Evidence Handling Procedures¶

7.1 Identification of Evidence¶

When addressing information security incidents, the identification of evidence is critical, requiring a thorough approach tailored to the specific incident type. For digital security incidents, relevant evidence may include system logs, network traffic logs, malware samples, email headers, and other digital communications. Tools like firewalls, intrusion detection and prevention systems (IDS/IPS), and security information and event management (SIEM) platforms assist in identifying this evidence. For compliance or legal violations, evidence may come from contracts, emails, compliance reports, audit logs, and policy violation logs, sourced from departments such as legal, human resources, and finance. In the case of physical and operational incidents, access control logs, camera footage, entry/exit records, physical device configurations, and maintenance logs serve as key evidence sources.

7.2 Collection and Acquisition of Evidence¶

During the collection and acquisition of evidence, it is paramount to gather all evidence in a forensically sound manner to preserve its integrity and ensure admissibility in investigations or legal proceedings. For digital evidence, this may involve creating forensically sound copies of system images or network packet captures, collecting logs from security systems (such as SIEM, firewalls, or IDS/IPS), and ensuring that sensitive evidence is encrypted during the collection process. Physical evidence collection includes photographing or documenting physical assets or environments and collecting access control logs and CCTV footage. Human-related evidence is gathered through formal interviews with involved personnel and obtaining personnel files, activity logs, or communications related to the incident.

7.3 Preservation of Evidence¶

The preservation of evidence is vital to maintaining its integrity and preventing tampering throughout the investigation. A strict chain of custody must be observed, documenting every stage of evidence handling, including collection, transfer, and storage, along with who had access to the evidence at each point. Digital evidence should be stored in secure, access-controlled environments, whether in isolated drives or secure cloud storage, with encryption applied. Physical evidence, such as hard drives, documents, or equipment, must be secured in tamper-evident containers or secure storage areas.

7.4 Analysis of Evidence¶

Evidence analysis varies depending on the type of incident. For digital evidence, forensic tools like EnCase, FTK, or Wireshark should be used to examine data, recover deleted files, and analyse system and network behaviour. System and network logs should be reviewed to reconstruct timelines, identify suspicious behaviour, or trace the source of an attack. For physical evidence, inspection of hardware components or damaged equipment for signs of tampering is necessary, while reviewing surveillance footage can help track unauthorised entries or suspicious activities. Legal or compliance teams should review contracts, audit logs, and communication records to identify policy or regulatory violations, and perform data integrity checks to ensure financial or operational data has not been falsified.

7.5 Documentation of Evidence¶

Throughout the investigation, documentation of evidence is essential to maintain transparency and ensure its admissibility in court or during internal reviews. Incident reports should detail the type of evidence collected, how it was handled, who managed it, and the analysis results. For digital evidence, hash values or checksums should be included to verify that files and logs remain unaltered. Audit trails must also be maintained, logging all actions taken on the evidence, including transfers or access by authorised personnel.

7.6 Disposal or Retention of Evidence¶

Finally, after the investigation, disposal or retention of evidence must be handled according to legal and organisational requirements. Digital evidence should be securely wiped using methods like degaussing or cryptographic erasure, while physical evidence (e.g., hardware or documents) should be destroyed in a way that makes recovery impossible. In cases where retention is legally required, evidence must be securely stored for the appropriate period, following all relevant legal frameworks and internal policies.

8 Post-Incident Activity¶

The Team Leader will decide, based on the latest information from the Incident Liaison and other members of the team, the point at which response activities should be ceased and the IRT stood down. Note that the recovery and execution of plans may continue beyond this point but under less formal management control.

This decision will be up to the Team Leader's judgement but should be based upon the following criteria:

The situation has been fully resolved or is reasonably stable
The pace of change of the situation has slowed to a point where few decisions are required
The appropriate response is well under way and recovery plans are progressing to schedule
The degree of risk to the business has lessened to an acceptable point
Immediate legal and regulatory responsibilities have been fulfilled

If recovery from the incident is on-going the Team Leader should define the next actions to be taken. These may include:

Less frequent meetings of the IRT e.g. weekly depending on the circumstances
Informing all involved parties that the IRT is standing down
Ensuring that all documentation of the incident is secured
Requesting that all staff not involved in further work return to normal duties

All actions taken as part of standing down should be recorded.

After the IRT has been stood down the Team Leader will hold a debrief of all members ideally within 24 hours. The relevant records of the incident will be examined by the IRT to ensure that they reflect actual events and represent a complete and accurate record of the incident.

Any immediate comments or feedback from the team will be recorded. A more formal post-incident review will be held at a time to be decided by top management according to the magnitude and nature of the incident.

9 Incident Reporting, Post-Incident Review Timelines (TAT)¶

This section defines the timelines for reporting incidents, conducting post-incident reviews, and implementing corrective actions. These timelines help ensure prompt incident handling, thorough analysis, and swift remediation to reduce the risk of recurrence.

Incident Reporting: Incident Reporting must be performed promptly, based on incident severity, to ensure timely mitigation and response.
Post-Incident Review (PIR): A Post-Incident Review (PIR) is mandatory after the closure of an incident. The review analyses the root cause and response effectiveness, identifying lessons learned to improve future response strategies.
Corrective Actions: Corrective Actions are essential to address identified weaknesses, prevent recurrence, and improve security measures. Corrective actions should be completed within a defined period after the post-incident review.

Incident Severity	TAT for Incident Reporting	TAT for Post-Incident Review (PIR)	TAT for Corrective Actions
High Severity	Must be reported within 3 hours of detection	PIR to be completed within 72 hours of incident closure	Corrective actions to be completed within 5 working days
Medium Severity	Must be reported within 10–15 hours of detection	PIR to be completed within 5 days of incident closure	Corrective actions to be completed within 25 working days
Low Severity	Must be reported within 24 hours of detection	PIR to be completed within 7 working days of incident closure	Corrective actions to be completed within 35–45 working days

This structure ensures that incidents are reported, analysed, and resolved efficiently, with corrective actions implemented to prevent future occurrences.

10 Impact¶

Impact is determined by how many personnel or functions are affected. There are three grades of impact:

1 – High: All users of a specific service. Personnel from multiple departments (organisation units) are affected. Public facing service is unavailable. The impact of an incident will be used in determining the priority for resolution.

2 – Medium: Multiple personnel are at one physical location. Service is degraded and still functional but not operating within specifications. It appears the cause of the incident falls across multiple service provider groups.

3 – Low: One or two personnel. Service is degraded but still operating within specifications of Simpaisa business need derived from IT department systems as service.

Appendix A – Initial Response Contact Sheet¶

Name	Role in Plan	Email	Mobile Tel
Saqlain Raza	Team Leader	[email protected]	03002431009
Muhammad Taimoor Bhatti	Team Facilitator	[email protected]	03367165534
Maqsood	Incident Liaison	[email protected]	03003087086
Muhammad Mohsin	Information Technology	[email protected]	03242717080
Ahsan Hussain	Business Operations	[email protected]	03332222528
Shahzad Iqbal	Facilities Management	[email protected]	03352228833
Atiya Abdul	Health and Safety	[email protected]	0333 1234360
Atiya Abdul	Human Resources	[email protected]	0333 1234360
Khushnood / Zara Haleem	Communications (PR and Media Relations)	[email protected] / [email protected]	03212369686 / 03172124057
Moiz Bhirya	Legal and Regulatory	[email protected]	03452181514

Appendix B: Useful External Contacts¶

Organisation	Contact	Telephone No	Email
Forensic Investigation Consultancy		021-99333950 / 021-99333951	[email protected]
Security Software Supplier	Mr. Ahmed Safdar	0213-5341369	[email protected]
Law Enforcement Agency	DSP Admn South	021-99205672	[email protected]
Regional Incident Response Group	Mr. Jahnzaib Sanjarani	021-99332003-5	[email protected]
Internet Service Provider	Transworld	111 837 837	[email protected]
Insurance Company	Salam Takaful	021-111-875-111	[email protected]
Media Relations Consultants	Monarch Seo Agency	0327 2328345	[email protected]
Customer Representative Group	Logicbot	92 307 0298206	[email protected]
Industry Association	All Pakistan Commercial Export	92-91-2213520	[email protected]
Industry Regulator	District Municipal Corporation South Karachi	+92 21 99218874-5	[email protected]

Appendix C: Standard Incident Response Team Meeting Agenda¶

13.1 Agenda¶

Attendees: All members of Incident Response Team
Location: Karachi Office
Frequency: 1 Week
Chair: Team Leader
Minutes: Team Facilitator

Items:

Actions from previous meeting
Incident status update
Decisions required
Task allocation
Internal communications
External communications
Standing down
Any other business