Information Security Policy  PF -ISP-280819

Document control
Prepared by Tom Lindsey PhotoFit owner
Authorised by Tom Lindsey PhotoFit owner
Physical Copy Location Operations Folder white
Distribution owner
Published Copy Location www.photo-fit.com\GDPR
Other Referenced Documents Data Protection Policy
Related Material to Photo-Fit Generic events
Version Control
Title Information Security Policy & Reporting Weakness & events process
Description To ensure that all actual or potential information security incidents are reported efficiently enabling the company to react quickly and effectively to minimise the impact.
Created by Tom Lindsey
Date created 28-08-19
Maintained by Tom Lindsey – PhotoFit
Version ID PF – Modified by: Modifications: Date Modified Status
ISP 280819 TL First creation 28-08-19 Published
         
         

 

 

Contents

Purpose
Prerequisites
Conditions
Outcomes
Processes
Identifying a weakness or event sub-process
Classifying a weakness or event sub-process
Reporting a weakness or event sub-process
Management and Review

 

Purpose

PhotoFit (referred to as the company here after) uses many methods to detect possible security incidents. The purpose of this procedure is to ensure that all actual or potential information security incidents are reported efficiently enabling the company to react quickly and effectively to minimise the impact. The aims of the procedure are as follows:

  • To quickly enact procedures and plans & determine whether further controls or actions are required.
  • To Evaluate the information security management system and make necessary improvements.

All information security incidents will be dealt with by the owner who will review and advise on incidents and make recommendations on appropriate follow up and corrective action.  Specialist input will be sought where necessary using authorised contracted third parties.

Prerequisites

For this procedure to be followed the following conditions need to be met:

  • All parties need to be aware of their roles and responsibilities.
  • All parties have had the relevant training and the training is current and up to date.
  • Monitoring and measurement systems are in place to detect and notify of suspected incidents as defined in the Monitoring Policy.

 

Conditions

This procedure should be followed if there are signs of a breach or incident. Examples include but are not limited to:

  • A malware or suspected malware infection on any devices.
  • If a supplier suffers a breach.
  • If any of the monitoring systems detect unauthorized access.
  • If any parties have knowledge of undisclosed information.
  • If there is a physical or suspected physical break into the premises.
  • If equipment is lost or stolen.
  • If policies and procedures aren’t complied with.

 

Outcomes

  • Suspected incidents are identified
  • Incidents reported in an effective and efficient manner to the correct teams.
  • Records of the reports are documented
  • Further actions are determined where necessary

 

Processes

  1. Identifying a weakness or event sub-process

 

  1. New information has become available to a party within the company from a source; examples of sources include but are not limited to:
  2. Information submitted by contracted third parties
  3. Information submitted from a complaint
  4. Information from one of the monitoring systems defined in the Monitoring Policy.
  5. Information published by the press
  6. Information from tests or scans
  7. Information from reviews

 

  1. This information must concern information security or data protection; examples of such information include but are not limited to:
  2. Information processed or controlled by the company that is incorrect, inaccurate or incomplete.
  3. One or more of the company’s systems for interacting with controlled or processed data was unavailable.
  4. Information relating to a suspected breach.
  5. Information that the rights of a data subject are not being protected
  6. Information that information required to be provided to data subjects under Regulation (EU) 2016/679 (GDPR) is not being supplied in full.
  7. Objections to lawfulness or fairness of processing.
  8. Objections to consent gathering procedures.
  9. Concerns about the obligation to protect children.
  10. Concerns about the measures to protect data
  11. Concerns about the physical security of the company premises
  12. Stolen or missing equipment
  13. Non-compliance with company policies and procedures

 

  1. This information should classified with the classifying a weakness or event subprocess and reported using the reporting a weakness or event sub-process.

 

Processes

  1. Classifying a weakness or event sub-process
  2. The information that identifies an information Security weakness or event should be classified according to the table 1.1 below:
Level 0 1 2 3 4 5
  Low Medium Medium High High High
  No significant damage to reputation, organisation or data.

 

External interest unlikely.

 

Not a data breach.

 

Effects a non-production system.

 Damage to employee supplier reputation.

 

Possible external interest.

 

Potential breach of data.

 

Less than 5 records potentially affected and low risk due to security measures.

 Damage to departmental reputation.

 

Definite external interest.

 

Risk assessed as high.

 

Up to 50 records potentially affected and high risk due to inadequate security measures on data records.

 Damage to service availability or service reputation.

 

Low key local public interest.

 

Serious breach of data.

 

Up to 100 records potentially affected.

 Damage to product reputation.

 

National or local interest.

 

Serious breach of data including personal information.

 

Up to 1000 records potentially affected.

 Damage to organisation reputation.

 

National interest.

 

Serious breach of sensitive personal information.

 

 

Over 1000 records potentially affected.

 

  1. Reporting a weakness or event sub-process
  2. Open a copy of the Security Weakness and Events Template form (table 2.1) found in the location:

 

Date: The date the event occurred/weakness was discovered.
Time: The time the event occurred/weakness was discovered.
Affected Places: The physical locations of equipment that were affected by the event/weakness.
Name of responder: The designated Party for responding to the report.
Position:  
Classification: A value from 1 to 5 indicating the impact of the event/weakness.
Contact details: A contact email/number/other contact details of the person reporting the weakness/event.
Source of information: Where the information about the event/weakness came from.
Description: Details about the event/weakness.
Common Vulnerabilities & Exposure ID (s): Known CVE IDs connected to the weakness/event.
Verification status: Whether the information in this report has been verified.
Corrective actions: Actions that will need to be taken to respond to the reported weakness/event.
Date reviewed: Date to review this report and the corrective actions.
Date completed: The date that the corrective actions have been verified as complete

 

Table 2.1: Incident Report Template

  1. Save this report with the file name {date}-{classification level}-{weakness or event}-{initials}-{number of reports for that day}. For example, if John Smith wishes to submit a report for a level 3 weakness on November 15th and has made no other reports that day then the file name will be: 15NOV17-3-Weaknesses-JS-0001.
  2. A copy of this report should be sent via email to the owner Tom Lindsey.

 

Management and Review

This policy should be reviewed as scheduled once annually unless performance indicators, changes to legislation or the organisation necessitate it. Last Review Date: 28-08-2019 Next Review Date: 28-08-2020