Information Security Policy  


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

Appendix A.. 29

Appendix B. 30


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


Utechservs Local SEO & Web Services 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 organisation.

Utechservs Local SEO & Web Services 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 unauthorised 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 Utechservs Local SEO & Web Services’ established culture of openness, trust and integrity. Management is committed to protecting the employees, partners and the Company from illegal or damaging actions by individuals, either knowingly or unknowingly. Utechservs Local SEO & Web Services 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 authorised. 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 unauthorised 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.




10.Disposal of Stored Data



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 Utechservs Local SEO & Web Services 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


remote access privileges to Utechservs Local SEO & Web Services’ corporate network to ensure that their remote

access connection is given the same consideration as the user’s on-site connection to Utechservs Local SEO & Web Services.



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 unauthorised 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:

    Chief Information Security Officer:

    Chief Information Officer:

    Head of Communications:

    Responsible for web site





  1. Systems included in the scope

    System 1: IP: System: System Description

    System 2: IP: System: System Description

    Wifi network Utechservs Local SEO & Web Services


  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 company will be expected to report to the security officer for any security related issues.


Utechservs Local SEO & Web Services 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.
  1. 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.
  2. 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.
  3. If an unauthorised 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.
  4. 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 Utechservs Local SEO & Web Services 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.


Utechservs Local SEO & Web Services PCI Security Incident Response Team: (Update as applicable)


Communications Director    
Compliance Officer      
Information Security Officer      
Collections & Merchant Services      
Risk Manager      


Incident Response Notification


Escalation Members


Escalation – First Level

Information Security Officer Controller

Executive Project Director for Credit Collections and Merchant Services Legal Counsel

Risk Manager


Director of Utechservs Local SEO & Web Services Communications


Escalation – Second Level

Utechservs Local SEO & Web Services President

Executive Cabinet


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 designees 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.
  1. Contact internal and external departments and entities as appropriate.
  2. Make forensic and log analysis available to appropriate law enforcement or card industry security personnel, as required.
  3. 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”*.

  1. Executive Summary


  1. Include overview of the incident
  2. Include RISK Level(High, Medium, Low)
  3. Determine if compromise has been contained II. Background

III. Initial Analysis

  1. Investigative Procedures


  1. Include forensic tools used during investigation V. Findings
  2. Number of accounts at risk, identify those stores and compromised


  1. Type of account information at risk
  2. Identify ALL systems analyzed. Include the following:






  1. Identify ALL compromised systems. Include the following:





  1. Timeframe of compromise


  1. Any data exported by intruder
  2. Establish how and source of compromise
  3. 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.)
  4. If applicable, review VisaNet endpoint security and determine risk
  5. 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


  1. Provide the MasterCard Merchant Fraud Control Department with a complete list of all known compromised account numbers.
  2. 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).


  1. Provide weekly written status reports to MasterCard, addressing open questions and issues until the audit is complete to the satisfaction of MasterCard.
  2. Promptly furnish updated lists of potential or known compromised account numbers, additional documentation, and other information that MasterCard may request.


  1. 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.


  1. Distribute the account number data to its respective issuers.


Employees of the company 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 company 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


  1. 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 Utechservs Local SEO & Web Services 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 company.
  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)