We Accept Purchase orders from Government, Defence, Military, Universities, Schools and Colleges




Free UK delivery available
International shipping
Minimum 2 year warranty on all items
Government and Education orders accepted
Previous slide
Next slide

 Information Security Policy

PCI DSS Compliant

Website Certified by TrustedSite


APRIL 6TH 2020


  1. Introduction. 2
  2. Information Security Policy. 2
  3. Acceptable Use Policy. 4
  4. Disciplinary Action. 4
  5. Protect Stored Data. 4
  6. Information Classification. 5
  7. Access to the sensitive cardholder data. 5
  8. Physical Security. 5
  9. Protect Data in Transit 6
  10. Disposal of Stored Data. 7
  11. Security Awareness and Procedures. 7
  12. Network security. 8
  13. System and Password Policy. 8
  14. Anti-virus policy. 10
  15. Patch Management Policy. 10
  16. Remote Access policy. 11
  17. Vulnerability Management Policy. 11
  18. Configuration standards: 11
  19. Change control Process. 12
  20. Audit and Log review.. 13
  21. Secure Application development 15
  22. Penetration testing methodology. 16
  23. Incident Response Plan. 18
  24. Roles and Responsibilities. 22
  25. Third party access to card holder data. 22
  26. User Access Management 23
  27. Access Control Policy. 23
  28. Wireless Policy. 24

Appendix A.. 26

Appendix B.. 26

1.    Introduction

This Policy Document encompasses all aspects of security surrounding confidential company information and must be distributed to all company employees. All company employees must read this document in its entirety and sign the form confirming they have read and understand this policy fully. This document will be reviewed and updated by Management on an annual basis or when relevant to include newly developed security standards into the policy and distribute it all employees and contracts as applicable.

2.    Information Security Policy

 The SCSISHOP handles sensitive cardholder information daily.  Sensitive Information must have adequate safeguards in place to protect them, to protect cardholder privacy, to ensure compliance with various regulations and to guard the future of the organization.

The SCSISHOP commits to respecting the privacy of all its customers and to protecting any data about customers from outside parties.  To this end management are committed to maintaining a secure environment in which to process cardholder information so that we can meet these promises.

Employees handling Sensitive cardholder data should ensure:

We each have a responsibility for ensuring our company’s systems and data are protected from unauthorized access and improper use.  If you are unclear about any of the policies detailed herein you should seek advice and guidance from your line manager.

3.    Acceptable Use Policy

 The Management’s intentions for publishing an Acceptable Use Policy are not to impose restrictions that are contrary to The SCSISHOP’s established culture of openness, trust and integrity. Management is committed to protecting the employees, partners and The SCSISHOP from illegal or damaging actions by individuals, either knowingly or unknowingly. The SCSISHOP will maintain an approved list of technologies and devices and personnel with access to such devices as detailed in Appendix B.

4.    Disciplinary Action 

Violation of the standards, policies and procedures presented in this document by an employee will result in disciplinary action, from warnings or reprimands up to and including termination of employment. Claims of ignorance, good intentions or using poor judgment will not be used as excuses for non-compliance.

5.    Protect Stored Data 

It is strictly prohibited to store:

  1. The contents of the payment card magnetic stripe (track data) on any media whatsoever.
  2. The CVV/CVC (the 3 or 4 digit number on the signature panel on the reverse of the payment card) on any media whatsoever.
  3. The PIN or the encrypted PIN Block under any circumstance.

6.    Information Classification

Data and media containing data must always be labelled to indicate sensitivity level

7.    Access to the sensitive cardholder data

All Access to sensitive cardholder should be controlled and authorized. Any Job functions that require access to cardholder data should be clearly defined.

8.    Physical Security 

Access to sensitive information in both hard and soft media format must be physically restricted to prevent unauthorized individuals from obtaining sensitive data.

9.    Protect Data in Transit 

All sensitive cardholder data must be protected securely if it is to be transported physically or electronically.

 Card holder data (PAN, track data etc.) must never be sent over the internet via email, instant chat or any other end user technologies.

10.                       Disposal of Stored Data

 All data must be securely disposed of when no longer required by The SCSISHOP, regardless of the media or application type on which it is stored.


11.                       Security Awareness and Procedures 

The policies and procedures outlined below must be incorporated into company practice to maintain a high level of security awareness. The protection of sensitive data demands regular training of all employees and contractors.

12.                         Network security

13.                        System and Password Policy

All users, including contractors and vendors with access to The SCSISHOP systems, are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

Standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively.

  1. Be as long as possible (never shorter than 6 characters).
  2. Include mixed-case letters, if possible.
  3. Include digits and punctuation marks, if possible.
  4. Not be based on any personal information.
  5. Not be based on any dictionary word, in any language.


14.                       Anti-virus policy

15.                       Patch Management Policy

16.                       Remote Access policy



17.                       Vulnerability Management Policy


18. Configuration standards:


19.  Change control Process


20.  Audit and Log review


  1. Any additions, modifications or deletions of user accounts.
  2. Any failed or unauthorized attempt at user logon.
  3. Any modification to system files.
  4. Any access to the server, or application running on the server, including files that hold cardholder data.
  5. Actions taken by any individual with root or administrative privileges.
  6. Any user access to audit trails.
  7. Any creation / deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)


  1. Any failed user access attempts to log in to the Oracle database.
  2. Any login that has been added or removed as a database user to a database.
  3. Any login that has been added or removed from a role.
  4. Any database role that has been added or removed from a database.
  5. Any password that has been changed for an application role.
  6. Any database that has been created, altered, or dropped.
  7. Any database object, such as a schema, that has been connected to.
  8. Actions taken by any individual with DBA privileges.


  1. ACL violations.
  2. Invalid user authentication attempts.
  3. Logon and actions taken by any individual using privileged accounts.
  4. Configuration changes made to the firewall (e.g. policies disabled, added, deleted, or modified).


  1. Invalid user authentication attempts.
  2. Logon and actions taken by any individual using privileged accounts.
  3. Configuration changes made to the switch (e.g. configuration disabled, added, deleted, or modified).


  1. Any vulnerability listed in the Common Vulnerability Entry (CVE) database.
  2. Any generic attack(s) not listed in CVE.
  3. Any known denial of service attack(s).
  4. Any traffic patterns that indicated pre-attack reconnaissance occurred.
  5. Any attempts to exploit security-related configuration errors.
  6. Any authentication failure(s) that might indicate an attack.
  7. Any traffic to or from a back-door program.
  8. Any traffic typical of known stealth attacks.


  1. Any modification to system files.
  2. Actions taken by any individual with Administrative privileges.
  3. Any user access to audit trails.
  4. Any Creation / Deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)


  1. User Identification.
  2. Event Type.
  3. Date & Time.
  4. Success or Failure indication.
  5. Event Origination (e.g. IP address).
  6. Reference to the data, system component or resource affected.


21.  Secure Application development



  1. Design


  1. Coding


  1. Testing


  1. Deployment




Application Code Developers shall:




22.  Penetration testing methodology



Example 1#

    Risk: Denial of Service in systems or network devices because of the network scans.

    Mitigation measure 1: network scans must be performed in a controlled manner. The start and end of the scan must be notified to responsible personnel to allow monitoring during testing. For any sign of trouble will abort the scan in progress.

    Mitigation measure 2: scanning tools must be configured to guarantee that the volume of sent packets or sessions established per minute does not cause a problem for network elements. In this sense, we must perform the first scans in a very controlled way and a use minimum configuration that may be expanded when is evident that the configuration is not dangerous for network devices or servers in the organization.







    Technical Project Manager: M Gale

    Chief Information Security Officer: M Gale

    Chief Information Officer: M Gale

    Head of Communications: M Gale

    Responsible for web site www.scsishop.co.uk :





  1. Systems included in the scope

    System 1: IP: System: System Description

    System 2: IP: System: System Description

    Wi-Fi network The SCSISHOP


  1. Applications included in the scope

    Application 1: URL: Description of the application


  1. Systems excluded from the scope

    System 5: IP: System: System Description

    System 6: IP: System: System Description


  1. Applications excluded from the scope

    Application 3: URL: Description of the application




  1. Injections: Code, SQL, OS commands, LDAP , XPath , etc.
  2. Buffer overflows.
  3. Insecure storage of cryptographic keys
  4. Insecure Communications
  5. Improper error handling
  6. Cross -site scripting (XSS)
  7. Control of inappropriate access.
  8. Cross – site request forgery (CSRF).
  9. Broken authentication and incorrectly session management.
  10. Any other vulnerability considered High Risk by the organization.




    Executive Summary


    Identified vulnerabilities

    Recommendations for correcting vulnerabilities



23. Incident Response Plan

‘Security incident’ means any incident (accidental, intentional or deliberate) relating to your communications or information processing systems. The attacker could be a malicious stranger, a competitor, or a disgruntled employee, and their intention might be to steal information or money, or just to damage your company.

The Incident response plan has to be tested once annually. Copies of this incident response plan is to be made available to all relevant staff members, and take steps to ensure that they understand it and what is expected of them.

Employees of The SCSISHOP will be expected to report to the security officer for any security related issues.

The SCSISHOP PCI security incident response plan is as follows:

  1. Each department must report an incident to the Information Security Officer (preferably) or to another member of the PCI Response Team.
  2. That member of the team receiving the report will advise the PCI Response Team of the incident.
  3. The PCI Response Team will investigate the incident and assist the potentially compromised department in limiting the exposure of cardholder data and in mitigating the risks associated with the incident.
  4. The PCI Response Team will resolve the problem to the satisfaction of all parties involved, including reporting the incident and findings to the appropriate parties (credit card associations, credit card processors, etc.) as necessary.
  5. The PCI Response Team will determine if policies and processes need to be updated to avoid a similar incident in the future, and whether additional safeguards are required in the environment where the incident occurred, or for the institution.
  6. If an unauthorized wireless access point or devices is identified or detected as part of the quarterly test this is should be immediately escalated to the Security officer or someone with similar privileges who has the authority to stop, cease, shut down, and remove the offending device immediately.
  7. A department that reasonably believes it may have an account breach, or a breach of cardholder information or of systems related to the PCI environment in general, must inform The SCSISHOP PCI Incident Response Team. After being notified of a compromise, the PCI Response Team, along with other designated staff, will implement the PCI Incident Response Plan to assist and augment departments’ response plans.

The SCSISHOP PCI Security Incident Response Team:

Incident Response Notification

Escalation Members

Escalation – First Level

Information Security Officer Controller

Director of The SCSISHOP Communications


Escalation – Second Level


Internal Audit

Auxiliary members as needed

      External Contacts (as needed)

Merchant Provider Card Brands

Internet Service Provider (if applicable)

Internet Service Provider of Intruder (if applicable) Communication Carriers (local and long distance) Business Partners

Insurance Carrier

External Response Team as applicable (CERT Coordination Center 1, etc.) Law Enforcement Agencies as applicable inn local jurisdiction

In response to a systems compromise, the PCI Response Team and designee s will:

  1. Ensure compromised system/s is isolated on/from the network.
  2. Gather, review and analyze the logs and related information from various central and local safeguards and security controls
  3. Conduct appropriate forensic analysis of compromised system.
  4. Contact internal and external departments and entities as appropriate.
  5. Make forensic and log analysis available to appropriate law enforcement or card industry security personnel, as required.
  6. Assist law enforcement and card industry security personnel in investigative processes, including in prosecutions.

The card companies have individually specific requirements the Response Team must address in reporting suspected or confirmed breaches of cardholder data.

Incident Response notifications to various card schemes 

  1. In the event of a suspected security breach, alert the information security officer or your line manager immediately.
  2. The security officer will carry out an initial investigation of the suspected security breach.
  3. Upon confirmation that a security breach has occurred, the security officer will alert management and begin informing all relevant parties that may be affected by the compromise.

 VISA Steps

If the data security compromise involves credit card account numbers, implement the following procedure:

Visa Incident Report Template

This report must be provided to VISA within 14 days after initial report of incident to VISA. The following report content and standards must be followed when completing the incident report. Incident report must be securely distributed to VISA and Merchant Bank. Visa will classify the report as “VISA Secret”*.

I.Executive Summary

a.Include overview of the incident

b.Include RISK Level(High, Medium, Low) 

c. Determine if compromise has been contained II. Background

III. Initial Analysis

IV.Investigative Procedures

a.Include forensic tools used during investigation V. Findings 

b.Number of accounts at risk, identify those stores and compromised

c.Type of account information at risk

d.Identify ALL systems analyzed. Include the following:

e.Identify ALL compromised systems. Include the following:

  1. Timeframe of compromise
  2. Any data exported by intruder
  3. Establish how and source of compromise
  4. Check all potential database locations to ensure that no CVV2, Track 1 or Track 2 data is stored anywhere, whether encrypted or unencrypted (e.g., duplicate or backup tables or databases, databases used in development, stage or testing environments, data on software engineers’ machines, etc.)
  5. If applicable, review VisaNet endpoint security and determine risk
  6. Compromised Entity Action

VII. Recommendations

VIII. Contact(s) at entity and security assessor performing investigation

*This classification applies to the most sensitive business information, which is intended for use within VISA. Its unauthorized disclosure could seriously and adversely impact VISA, its employees, member banks, business partners, and/or the Brand

MasterCard Steps:

  1. Within 24 hours of an account compromise event, notify the MasterCard Compromised Account Team via phone at 1-636-722-4100.
  2. Provide a detailed written statement of fact about the account compromise (including the contributing circumstances) via secured e-mail to
  3.  compromised_account_team@mastercard.com.Provide the MasterCard Merchant Fraud Control Department with a complete list of all known compromised account numbers.
  4. Within 72 hours of knowledge of a suspected account compromise, engage the services of a data security firm acceptable to MasterCard to assess the vulnerability of the compromised data and related systems (such as a detailed forensics evaluation).
  5. Provide weekly written status reports to MasterCard, addressing open questions and issues until the audit is complete to the satisfaction of MasterCard.
  6. Promptly furnish updated lists of potential or known compromised account numbers, additional documentation, and other information that MasterCard may request.
  7. Provide finding of all audits and investigations to the MasterCard Merchant Fraud Control department within the required time frame and continue to address any outstanding exposure or recommendation until resolved to the satisfaction of MasterCard.

Once MasterCard obtains the details of the account data compromise and the list of compromised account numbers, MasterCard will:

  1. Identify the issuers of the accounts that were suspected to have been compromised and group all known accounts under the respective parent member IDs.
  2. Distribute the account number data to its respective issuers.

Employees of The SCSISHOP will be expected to report to the security officer for any security related issues. The role of the security officer is to effectively communicate all security policies and procedures to employees within The SCSISHOP and contractors. In addition to this, the security officer will oversee the scheduling of security training sessions, monitor and enforce the security policies outlined in both this document and at the training sessions and finally, oversee the implantation of the incident response plan in the event of a sensitive data compromise.

Discover Card Steps

  1. Within 24 hours of an account compromise event, notify Discover Fraud Prevention
  2. Prepare a detailed written statement of fact about the account compromise including the contributing circumstances
  3. Prepare a list of all known compromised account numbers
  4. Obtain additional specific requirements from Discover Card



American Express Steps


  1. Within 24 hours of an account compromise event, notify American Express Merchant Services
  2. Prepare a detailed written statement of fact about the account compromise including the contributing circumstances
  3. Prepare a list of all known compromised account numbers

Obtain additional specific requirements from American Express


24.                       Roles and Responsibilities




25.                       Third party access to card holder data



  1. Adhere to the PCI DSS security requirements.
  2. Acknowledge their responsibility for securing the Card Holder data.
  3. Acknowledge that the Card Holder data must only be used for assisting the completion of a transaction, supporting a loyalty program, providing a fraud control service or for uses specifically required by law.
  4. Have appropriate provisions for business continuity in the event of a major disruption, disaster or failure.
  5. Provide full cooperation and access to conduct a thorough security review after a security intrusion to a Payment Card industry representative, or a Payment Card industry approved third party.


26.                       User Access Management



Name of person making request:

Job title of the newcomers and workgroup:

Start date:

Services required (default services are: MS Outlook, MS Office and Internet access):



27.                       Access Control Policy




28.                       Wireless Policy


If the need arises to use wireless technology it should be approved by The SCSISHOP and the following wireless standards have to be adhered to:


  1. Default SNMP community strings and passwords, passphrases, Encryption keys/security related vendor defaults (if applicable) should be changed immediately after the installation of the device and if anyone with knowledge of these leaves The SCSISHOP.
  2. The firmware on the wireless devices has to be updated accordingly as per vendors release schedule
  3. The firmware on the wireless devices must support strong encryption for authentication and transmission over wireless networks.
  4. Any other security related wireless vendor defaults should be changed if applicable.
  5. Wireless networks must implement industry best practices (IEEE 802.11i) and strong encryption for authentication and transmission of cardholder data.
  6. An Inventory of authorized access points along with a business justification must be maintained. (Update Appendix B)


Appendix A – Agreement to Comply Form Agreement to Comply With Information Security Policies 





Employee Name (printed) 


Board of Directors



I agree to take all reasonable precautions to assure that company internal information, or information that has been entrusted to The SCSISHOP by third parties such as customers, will not be disclosed to unauthorized persons. At the end of my employment or contract with The SCSISHOP, I agree to return all information to which I have had access as a result of my position. I understand that I am not authorized to use sensitive information for my own purposes, nor am I at liberty to provide this information to third parties without the express written consent of the internal manager who is the designated information owner. 

I have access to a copy of the Information Security Policies, I have read and understand these policies, and I understand how it impacts my job. As a condition of continued employment, I agree to abide by the policies and other requirements found in The SCSISHOP security policy. I understand that non-compliance will be cause for disciplinary action up to and including dismissal, and perhaps criminal and/or civil penalties. 

I also agree to promptly report all violations or suspected violations of information security policies to the designated security officer. 



Employee Signature  

APRIL 6TH 2020