Incident Management Policy
1. Purpose
The purpose of this Incident Management Policy is to outline the procedures and responsibilities for effectively managing and resolving incidents within MedWorks, a Canadian software company. This policy aims to minimize the impact of incidents on business operations, maintain the integrity and security of company systems and data, and ensure timely communication and resolution to stakeholders.
2. Scope
This policy applies to all employees, contractors, and third-party vendors who have access to MedWork's systems, networks, and data.
3. Incident Classification
Security Events should be reported through appropriate management channels as quickly as possible. Personnel and contractors using the organization’s information systems and services are required to note and report any observed or suspected Security Weakness in systems or services.
Incidents will be classified based on their severity and impact on business operations, following the guidelines outlined below:
Critical: Incidents that severely impact business operations, compromise system integrity, or pose significant security risks.
Major: Incidents that disrupt business operations but can be contained with immediate action.
Minor: Incidents that have minimal impact on business operations but require attention to prevent escalation.
4. Incident Reporting
All employees, contractors, and third-party vendors are responsible for promptly reporting incidents to the designated Incident Response Team. Incidents can be reported via Security Incident Response Team (SIRT), Senior Management:
Security Incident Response Team (SIRT)
Senior Management
MedWorks Staff
5. Incident Response Team
The Incident Response Team comprises designated individuals from relevant departments, including IT, Security, Legal, and Communications. Their responsibilities include:
Assessing the severity and impact of reported incidents.
Initiating immediate response actions to contain and mitigate incidents.
Communicating updates and progress to stakeholders.
Documenting incident details, response actions, and resolutions.
6. Incident Response Procedures
Upon receiving a report of an incident, the Incident Response Team will follow these procedures:
Assessment: Evaluate the severity and impact of the incident to determine the appropriate response level.
Containment: Take immediate actions to contain the incident and prevent further damage or escalation.
Investigation: Conduct a thorough investigation to identify the root cause, affected systems, and potential vulnerabilities.
Resolution: Implement corrective measures to resolve the incident and restore affected systems to normal operations.
Documentation: Document all incident details, response actions, and resolutions for post-incident analysis and reporting.
Communication: Provide timely updates and notifications to stakeholders, including employees, customers, and regulatory authorities, as required.
7. Incident Communication
Communication regarding incidents will be managed transparently and responsibly, following these guidelines:
Internal communication: Provide regular updates and instructions to employees regarding the incident and its impact on business operations.
External communication: Coordinate with the Communications team to draft and disseminate external communications to customers, partners, and regulatory authorities, ensuring accuracy and consistency in messaging.
Media relations: Designate a spokesperson to handle media inquiries and provide official statements regarding the incident, in accordance with company policies and legal obligations.
8. Incident Review and Improvement
After resolving an incident, the Incident Response Team will conduct a post-incident review to assess the effectiveness of response procedures and identify areas for improvement. Recommendations for enhancing incident management processes will be documented and implemented to strengthen the company's incident response capabilities.
9. Policy Compliance
All employees, contractors, and third-party vendors are required to comply with this Incident Management Policy. Non-compliance may result in disciplinary action, up to and including termination of employment or contract.
10. Policy Review
This Incident Management Policy will be reviewed and updated annually to ensure its effectiveness and alignment with evolving business needs and regulatory requirements. Any proposed changes to the policy will undergo review and approval by the designated stakeholders.
11. Policy Acknowledgement
By accessing MedWorks's systems, networks, and data, all employees, contractors, and third-party vendors acknowledge their understanding of and compliance with this Incident Management Policy.
Approved By:
[Name], [Position] [Date]
Revision History:
Version 1.0 - [Date]: Initial Release
Incident Management Response, Policies and Procedures
1. DOCUMENT PURPOSE
1.1. The purpose of this Incident Management Response Policy is to outline the procedures and responsibilities for effectively managing and resolving incidents within MedWorks. This document defines the policy for addressing Security Incidents through appropriate Incident Response.
1.2. This document applies to all Personnel and supersedes all other policies relating to the matters set forth herein.
2. TERMS & DEFINITIONS
Term/Acronym | Definition |
Data Breach | A Security Incident that directly impacts Personal Data, Sensitive Personal Information or Personally Identifiable Information. |
Data Controller | Means the person or organization that determines the purpose and means of the Processing of Personal Data. |
Escalation | The engagement of additional resources to resolve a Security Incident. |
Incident Response / Incident Management | Process for detecting, reporting, assessing, responding to, dealing with, and learning from Security Incidents. |
Information Security | Preservation of confidentiality, integrity, and availability of Information and the equipment, devices or services containing or providing such Information. |
Personal Data | Means any information relating to an identified or identifiable Data Subject, where such information is protected under applicable law. For clarity, Personal Data includes any SPD, SPI, and/or Tracking Data that directly or indirectly identifies a Data Subject. |
Personnel | MedWorks Inc., employees (part and full time), subcontractors, contractors and interns. |
Security Event | An identified occurrence of a system, service or network state indicating a possible breach of information security policy, a possible exploitation of a Security Vulnerability or Security Weakness or a previously unknown situation that can be security relevant. |
Security Incident | A single or series of unwanted or unexpected Security Events that compromise business operations with an impact on Information Security. |
Security Incident Response Team (SIRT) | A predefined group of individuals needed and responsible for responding to a Security Incident, managed by the Information Security Department. During a Security Incident, the SIRT is responsible for communication with and coordination of other internal groups. |
Security Vulnerability | A weakness of an existing asset or control that can be exploited by one or more threats. |
Security Weakness | A weakness that results from the lack of an existing, necessary control. |
3. SCOPE
The objective of this policy is to ensure a consistent and effective approach to the management of Security Incidents, including the identification and communication of Security Events and Security Weaknesses.
4. INCIDENT RESPONSE POLICY
The Incident Response policy is as follows:
Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to Security Incidents.
The objectives for Security Incident management should be agreed upon with management, and it should be ensured that those responsible for Security Incident management understand the organization’s priorities for handling Security Incidents.
Security Events should be reported through appropriate management channels as quickly as possible.
Personnel and contractors using the organization’s information systems and services are required to note and report any observed or suspected Security Weakness in systems or services.
Security Events should be assessed, and it should be decided if they are to be classified as Security Incidents.
Security Incidents should be responded to in accordance with documented Incident Response procedures.
Knowledge gained from analyzing and resolving Security Incidents should be used to reduce the likelihood or impact of future incidents.
Procedures should be defined and applied for the identification, collection, acquisition, and preservation of information, which can serve as evidence.
Awareness should be provided on topics such as:
The benefits of a formal, consistent approach to Incident Management (personal and organizational).
How the program works, expectations.
How to report Security Incidents, who to contact.
Constraints imposed by non-disclosure agreements.
Communication channels should be established well in advance of a Security Incident. Include all necessary parties in relevant communication:
SIRT members
Senior Management
MedWorks Inc., Personnel
In the event a Security Incident, Data Controllers, government bodies and other necessary parties should be notified in a reasonable timeframe, and in compliance with regulatory and other applicable requirements and guidance.
5. DOCUMENT PURPOSE
5.1. The purpose of this document is to define the Incident Response procedures followed by MedWorks Inc., in the event of a Security Incident. This policy aims to minimize the impact of incidents on business operations, maintain the integrity and security of company systems and data, and ensure timely communication and resolution to stakeholders.
5.2. This document is a step-by-step guide of the measures Personnel are required to take to manage the lifecycle of Security Incidents within MedWorks Inc., from initial Security Incident recognition to restoring normal operations. This process will ensure that all such Security Incidents are detected, analyzed, contained and eradicated, that measures are taken to prevent any further Security Incidents, and, where necessary or appropriate, that notice is provided to law enforcement authorities, Personnel, and/or affected parties.
5.3. This document applies to all Personnel and supersedes all other procedures, practices, and guidelines relating to the matters set forth herein.
6. TERMS & DEFINITIONS
Term/Acronym | Definition |
Abnormal Activities | Unsuccessful attacks that appear particularly significant based on MedWorks Inc., understanding of the risks it faces. |
Data Breach | A security that directly impacts Personal Data, Sensitive Personal Information or Personally Identifiable Information. |
Data Controller | Means the person or organization that determines the purpose and means of the Processing of Personal Data. |
Escalation | The engagement of additional resources to resolve or provide the status regarding a Security Incident. |
Incident Record | Created at the time a Security Incident is initially recognized. Contains all relevant information pertaining to the Security Incident. |
Incident Response/Incident Management | Process for detecting, reporting, assessing, responding to, dealing with, and learning from Security Incidents. |
Information Security | Preservation of confidentiality, integrity, and availability of Information and the equipment, devices or services containing or providing such Information. |
Personal Data | Means any information relating to an identified or identifiable Data Subject, where such information is protected under applicable law. For clarity, Personal Data includes any SPD, SPI, and/or Tracking Data that directly or indirectly identifies a Data Subject. |
Personally Identifiable Information (PII) | Means any information about a Data Subject, whether in paper, electronic, or other form, which can be used to distinguish or trace an individual’s identity, such as name, email address, or telephone number. |
Personnel | MedWorks Inc., employees, (part and full time) Contractors, Sub-contractors and interns. |
Security Event | An identified occurrence of a system, service or network state indicating a possible breach of information security policy, a possible exploitation of a Security Vulnerability or Security Weakness or a previously unknown situation that can be security relevant. |
Security Incident | A single or series of unwanted or unexpected Security Events that compromise business operations with an impact on Information Security. |
Security Incident Response Team (SIRT) | A predefined group of individuals needed and responsible for responding to a Security Incident, managed by the Information Security Department. During a Security Incident, the SIRT is responsible for communication with and coordination of other internal groups. |
Sensitive Personal Information (SPI) | Means specific standalone PII or a combination of information that could identify, trace, or locate a Data subject, which if lost, compromised, or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. |
Security Vulnerability | A weakness of an existing asset or control that can be exploited by one or more threats. |
Security Weakness | A weakness that results from the lack of an existing, necessary control. |
7. SCOPE
This document covers the Incident Response process for all identified Security Incidents.
The following activities will be covered:
Detection
Analysis
Containment
Eradication
Recovery
Post-Incident Activities
The Incident Response process is considered complete once Information confidentiality, integrity, and/or availability are restored to normal, and verification has occurred.
8. OVERVIEW
8.1. Roles and Responsibilities
Individuals needed and responsible for responding to a Security Incident make up the SIRT. Core members will include the following:
Director, Information Security (SIRT Primary Lead)
Director/Legal & Compliance (SIRT Secondary Lead)
Security team staff
Information owner
Other groups and/or individuals that may be needed include:
Senior management
Legal Department representative
Human Resources/ Chief of Staff (CoS)
End User Support
ISS or Dev Ops Staff
Building and/or facilities management staff
Other Personnel involved in the Security Incident or needed resolution.
Contractors (as necessary)
Communications Resources
9. PROCESS
9.1. Detection Phase
In the detection phase the SIRT, or an internal or external entity, identifies a Security Event that may be the result of a potential exploitation of a Security Vulnerability or a Security Weakness, or that may be the result of an innocent error.
Immediately upon observation or notice of any suspected Security Event, Personnel shall use reasonable efforts to promptly report such knowledge and/or suspicion to the Information Security Department at the following address:
Email: [email protected]
A Security Event may be discovered in many ways, including the following:
Observation of suspicious behavior or unusual occurrences.
Lapses in physical or procedural security.
Information coming into the possession of unauthorized Personnel or Third Parties.
Information inappropriately exposed on a publicly facing website.
To assess whether a Security Event must be reported, Personnel should consider whether there are indications that:
Information was used by unauthorized Personnel or Third Parties.
Information has been downloaded or copied inappropriately from MedWorks Inc.’s computer systems or equipment.
Equipment or devices containing Information have been lost or stolen.
Equipment or devices containing Information have been subject to unauthorized activity (e.g., hacking, malware).
Personal Data has been publicly exposed.
In addition, the following situations should be considered for Security Event reporting:
Ineffective security controls.
Breach of integrity, confidentiality, or availability expectations.
Human errors (innocent or otherwise).
Non–compliance with policies or standards.
Breaches of physical security arrangements.
Uncontrolled systems changes.
Malfunctions of software or hardware.
Access violations.
Even if Personnel are not sure whether a Security Event is an actual Security Incident, they are still required to report it as provided herein, as it is better to be cautious than to be compromised.
The SIRT will usually require the reporter to supply further information, which will depend upon the nature of the Security Event. However, the following information normally shall be supplied:
Contact name and information of person reporting the Security Event.
Date and time the Security Event occurred or was noticed.
Type and circumstances of the Security Event.
The type of data, information, or equipment involved.
Location of the Security Event, data or equipment affected.
Whether the Security Event puts any person or other data at risk; and
Any associated ticket numbers, emails or log entries associated with the Security Event.
SIRT Primary Lead will ensure that the SIRT is promptly engaged once such notice is received. The following actions will also be taken:
The SIRT, under the leadership of the SIRT Primary Lead, shall use reasonable efforts to analyze the matter within four (4) hours of notice and decide whether to proceed with the Analysis Phase of the Incident Response Procedures.
Determination to initiate the Analysis Phase must be made quickly so that Personnel can make an initial determination as to the urgency and seriousness of the situation.
Upon making the decision to begin the Analysis Phase, if the SIRT suspects that the Security Event may result in damage to the reputation of MedWorks Inc., or legal liability, the Legal Department shall initiate a legal assessment of actual or potential legal issues.
9.2. Analysis Phase
The initial response to detection of a Security Event is typically the Analysis Phase. In this phase the SIRT determines whether or not a Security Event is an actual Security Incident. To determine if a Security Event is a Security Incident the following considerations apply:
Leverage diagnostic data to analyze the Security Event using tools directly on the operating system or application. This may include, but not be limited to:
Taking screenshots, memory dumps, consulting logs and network traces.
Performing analysis on the information being collected.
Analyzing the precursors and indications.
Looking for correlating information; and
Performing research (e.g., search engines, knowledgebase).
Identify whether the Security Event was the result of an innocent error, or the actions of a potential attacker. If the latter, effort shall be made to identify who the potential attacker may be, by:
Validating the attacker's IP address.
Researching the attacker through search engines.
Using incident databases.
Monitoring attacker communication channels, if possible; and
In unique cases, and with the approval of legal counsel, potentially scanning the attacker's system.
If the SIRT has determined that a Security Event has triggered a Security Incident, the appropriate SIRT team members will be engaged accordingly and the SIRT will begin documenting the investigation and gathering evidence. The type of Security Incident is based on the nature of the event. Example types are listed as follows:
Data exposure.
Unauthorized access.
Distributed Denial of Service/ Denial of Service (DDoS/DoS).
Malicious code.
Improper usage.
Scans/Probes/Attempted access.
If it is determined that a Security Incident has not been triggered, additional activities noted under ‘5.6. Post-Incident Activities’ may be initiated under the direction of the SIRT.
The Security Incident’s potential impact on MedWorks Inc., and/or its subscribers shall be evaluated and the SIRT shall assign an initial severity classification of low, medium, high or critical to the Security Incident. To analyze the situation, scope, and impact, the SIRT shall:
Define and confirm the severity level and potential impact of the Security Incident.
Identify which resources have been affected and forecast which resources will be affected.
Estimate the current and potential effect of the Security Incident.
The SIRT shall attempt to determine the scope of the Security Incident and verify if the Security Incident is still ongoing. Scoping the Security Incident may include collecting forensic data from suspect systems or gathering evidence that will support the investigation. It may also include identifying any potential data theft or destruction. New investigative leads may be generated as the collected data is analyzed. If the Security Incident involves malware, the SIRT shall analyze the malware to determine its capabilities and potential impact to the environment. Based on the evidence reviewed, the SIRT will determine if the Security Incident requires reclassification as to its severity or cause (e.g., whether it was originally thought to be the action of a malicious actor but turned out to be an innocent error, or vice versa).
As indicated above, a Security Incident may require evidence to be collected. The collection of such evidence shall be done with due diligence and the following procedures shall apply:
Gathering and handling of evidence (forensics) shall include:
Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) address, and IP address of a computer);
Name, title, and phone number of everyone who collected or handled the evidence during the investigation.
Time and date (including time zone) of each occurrence of evidence handling.
Locations where the evidence was stored, and conditions of storage (e.g., locked spaces, surveilled spaces); and
Reasonable efforts to create two backups of the affected system(s) using new, unused media — one is to be sealed as evidence and one is to be used as a source of additional backups
To ensure that evidence is not destroyed or removed, where any Personnel are suspected of being responsible for a Security Incident, MedWorks Inc., shall, consistent with its procedures, use reasonable efforts to place monitoring and forensics agents and/or confiscate all computer/electronic assets that have been assigned to him or her.
This task may be done surreptitiously and should be completed as quickly and in as non-intrusive a manner as possible.
The SIRT should consider restricting access to the computers and attached peripherals (including remote access via modem, secure remote system access, etc.) pending the outcome of its examination.
Where applicable, and depending upon the seriousness of the Security Incident, items and areas that should be secured and preserved in an “as was” condition include:
Work areas (including recycling bins and wastebaskets).
Computer hardware (keyboard, mouse, monitor, CPU, etc.).
Software.
Storage media (removable drives, USBs, etc.).
Documentation (manuals, printouts, notebooks, notepads).
Additional components as deemed relevant (printer, cables, etc.).
In cases of damage, the computer system and its surrounding area, as well as other data storage devices, should be preserved for the potential collection of evidence (e.g., fingerprinting).
If the computer is “Off”, it should not be turned “On”. For a stand-alone computer system, if the computer is “On”, the Information Security and IT Departments are to be contacted.
It is important to establish who was using the computer system at the time of the Security Incident and/or who was in the immediate area. The SIRT should obtain copies of applicable records (e.g., access logs, swipe card logs, closed circuit television (“CCTV”) recordings) as part of the investigation.
Based on the severity level and the categorization of the Security Incident, the proper team or Personnel shall be notified and contacted by the SIRT.
Until the SIRT, with the approval of MedWorks Inc., management, makes the Security Incident known to other Personnel, the foregoing activities shall be kept confidential to the extent possible.
If it is determined that a Security Incident has occurred and may have a significant impact on MedWorks Inc., or its subscribers, the SIRT shall determine whether additional resources are required to investigate and respond to the Security Incident. The extent of the additional resources will vary depending on the nature and significance of the Security Incident.
Abnormal Activities Notification:
The SIRT recognizes that there may be many attempts to gain unauthorized access to, disrupt or misuse information systems and the information stored on them, and that many of these attempts will be thwarted by MedWorks Inc.,’ information security program. In general, the SIRT will not report unsuccessful attacks to customers. For example, the SIRT would generally not be required to report to a Data Controller or customer if it makes a good faith judgment that the unsuccessful attack was of a routine nature.
However, the SIRT will take reasonable steps to notify customers or Data Controllers of any identified Abnormal Activities. For example, in making a judgment as to whether a particular unsuccessful attack should be reported, MedWorks Inc., might consider whether handling the attack required measures or resources well beyond those ordinarily used, like exceptional attention by senior personnel or the adoption of extraordinary non-routine precautionary steps. In cases of identified Abnormal Activities, the Data Controller or customer would be notified by means agreed upon by MedWorks Inc., and the Data Controller or customer within twenty-four (24) hours upon MedWorks Inc., becoming aware of the Abnormal Activity.
Data Breach Notification:
If it is determined during the analysis phase that a Security Incident has occurred that constitutes a Data Breach, with notification obligations based on regulatory, legal, or similar requirements, notification of such Data Breach shall be provided to the impacted Data Controller by email, telephone, or other means agreed upon by MedWorks Inc., and the Data Controller, within twenty-four (24) hours upon MedWorks Inc., becoming aware of the Data Breach. Additional activities noted under ‘5.6. Post-Incident Activities’ may also be initiated under the direction of the SIRT.
9.3. Containment Phase
The Containment Phase mitigates the root cause of the Security Incident to prevent further damage or exposure. This phase attempts to limit the impact of a Security Incident prior to an eradication and recovery event. During this phase, the SIRT may implement controls, as necessary, to limit the damage from a Security Incident. If a Security Incident is determined to be caused by innocent error, the eradication phase may not be needed. For example, after reviewing any information that has been collected investigating the Security Incident the SIRT may:
Secure the physical and network perimeter.
For example, shutting down a system, disconnecting it from the network, and/or disabling certain functions or services.
Connect through a trusted connection and retrieve any volatile data from the affected system.
Determine the relative integrity and the appropriateness of backing the system up.
If appropriate, back up the impacted system.
Change the password(s) to the affected system(s). Personnel, as appropriate, shall be notified of the password change.
Determine whether it is safe to continue operations with the affected system(s).
If it is safe, allow the system to continue to function, in which case the SIRT will:
Update the Incident Record; accordingly, and
Move to the Recovery Phase.
If it is not safe to allow the system to continue operations, the SIRT will discontinue the system(s) operation and move to Eradication Phase.
The SIRT may permit continued operation of the system under close supervision and monitoring if:
Such activity will assist in identifying individuals responsible for the Security Incident;
The system can run normally without risk of disruption, compromise of data, or serious damage; and
Consensus has been reached within the SIRT before taking the supervision and monitoring approach.
The final status of this stage should be appropriately documented in the Incident Record.
Data Subject Access Request
Name |
|
Address |
|
City, Province |
|
Postal Code |
|
Email Address |
|
Phone Number |
|
Date |
|
Dear [Recipient's Name],
I am writing to submit a Data Subject Access Request (DSAR) under the General Data Protection Regulation (GDPR) and the Personal Information Protection and Electronic Documents Act (PIPEDA). As a Canadian citizen and user of your services, I am entitled to request access to my personal data that your company holds.
Please find below the details of my DSAR:
Identification Information:
Full Name Registered |
|
Date of Birth |
|
Address |
|
City, Province |
|
Postal Code |
|
Email Address |
|
Phone Number |
|
Date |
|
Any other Relevant information |
|
2. Details of Request:
Please specify the personal data you are requesting access to.
|
Provide any relevant context or timeframe for the data requested.
|
3. Preferred Method of Access:
Specify your preferred method for receiving the requested personal data (e.g., electronic copy, postal mail). _________________________________________________________
4. Verification of Identity:
Enclosed with this letter, please find a copy of my government-issued identification document (e.g., driver's license, passport) to verify my identity.
5. Contact Information:
Please use the contact information provided above to communicate any updates or responses regarding this DSAR.
I understand that, according to PIPEDA, your company is required to respond to this request within 30 days. Additionally, I am aware that you may request further information or clarification to process my request effectively.
I appreciate your prompt attention to this matter and look forward to receiving the requested information.
Sincerely,