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

---

Aritel Limited T/A We Voice (We Voice) 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.

We Voice 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:

• Handle Company and account data including cardholder information in a manner that fits with their sensitivity;
• Limit personal use of We Voice information and telecommunication systems and ensure it doesn’t interfere with your job performance;
• We Voice reserves the right to monitor, access, review, audit, copy, store, or delete any electronic communications, equipment, systems and network traffic for any purpose;
• Do not use e-mail, internet and other Company resources to engage in any action that is offensive, threatening, discriminatory, defamatory, slanderous, pornographic, obscene, harassing or illegal;
• Do not disclose personnel information unless authorised;
• Protect sensitive cardholder information;
• Do not use e-mail or other end messaging technologies such as messenger WhatsApp, Signal to share sensitive data including account data in the form of cardholder information.
• Keep passwords and accounts secure;
• Request approval from management prior to establishing any new software or hardware, third party connections, etc.;
• Always leave desks clear of sensitive cardholder data and lock computer screens when unattended;
• Information security incidents must be reported, without delay, to the individual responsible for incident response locally – Please find out who this is.

We each have a responsibility for ensuring our company’s systems and data are protected from unauthorised access and improper use.

---

The Management’s intentions for publishing an Acceptable Use Policy are not to impose restrictions that are contrary to We Voice’s 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. We Voice will maintain an approved list of technologies and devices and personnel with access to such devices as detailed in Appendix B.

• Employees are responsible for exercising good judgment regarding the reasonableness of personal use.
• Employees should ensure that they have appropriate credentials and are authenticated for the use of technologies
• Employees should take all necessary steps to prevent unauthorized access to confidential data which includes card holder data.
• Employees should ensure that technologies should be used and setup in acceptable network locations
• Keep passwords secure and do not share accounts.
• Authorized users are responsible for the security of their passwords and accounts.
• All PCs, laptops and workstations should be secured with a password-protected screensaver with the automatic activation feature.
• All POS and PIN entry devices should be appropriately protected and secured so they cannot be tampered or altered.
• Postings by employees from a Company email address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of We Voice , unless posting is in the course of business duties.
• Employees must use extreme caution when opening e-mail attachments received from unknown senders, which may contain viruses, e-mail bombs, or Trojan horse code.

---

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.

---

This policy aims to ensure that We Voice conducts its business in full compliance with all national and international laws and regulations that pertain to its industry, as well as professional standards, accepted business practices, and internal standards.

• The data processed by We Voice need to be identified along with the relevant laws, regulations and industry standards.
• The scope including assets, network diagrams, dataflow diagrams and data storage repositories need to be documented in accordance with identified laws and regulations.

---

In relation to this Information security policy and relevant laws regulation and industry standards We Voice need to maintain up to date documentation and ensure they are relevant and updated when changes are made as well as reviewed for accuracy on an annual basis.

The documents include procedures, standards, asset lists, network diagrams, cardholder flow diagrams.

---

All sensitive cardholder data stored and handled by We Voice and its employees must be securely protected against unauthorised use at all times. Any sensitive card data that is no longer required by We Voice for business reasons must be discarded in a secure and irrecoverable manner.

It is strictly prohibited to store:

1. The sensitive authentication data in the form of CVV2/CVC2/CAV2/CID (the 3 or 4 digit number on the signature panel on the reverse of the payment card) on any media whatsoever.

---

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

• Confidential data might include information assets for which there are legal requirements for preventing disclosure or financial penalties for disclosure, or data that would cause severe damage to We Voice if disclosed or modified. Confidential data includes account data and cardholder data.
• Internal Use datamight include information that the data owner feels should be protected to prevent unauthorized disclosure;
• Internal Use datamight include information that the data owner feels should be protected to prevent unauthorized disclosure;
• Public datais information that may be freely disseminated.

---

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

• Any display of the card holder should be restricted at a minimum of the first 6 and the last 4 digits of the cardholder data.
• Access rights to privileged user ID’s should be restricted to least privileges necessary to perform job responsibilities.
• Privileges should be assigned to individuals based on job classification and function (Role based access control).
• No other employees should have access to this confidential data unless they have a genuine business need.
• We Voice will have a process in place to monitor the PCI DSS compliance status of the TPSP.

---

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

• Employees are responsible for exercising good judgment regarding the reasonableness of personal use.
• Employees should ensure that they have appropriate credentials and are authenticated for the use of technologies.
• Employees should take all necessary steps to prevent unauthorized access to confidential data which includes card holder data.
• Employees should ensure that technologies should be used and setup in acceptable network locations.
• Personnel using the devices should be trained to report suspicious behaviour and indications of tampering of the devices to the appropriate personnel.
• Keep passwords secure and do not share accounts. Authorized users are responsible for the security of their passwords and accounts.
• Media is defined as any printed or handwritten paper, received faxes, floppy disks, back-up tapes, computer hard drive, etc.
• Media containing sensitive cardholder information must be handled and distributed in a secure manner by trusted individuals.
• Strict control is maintained over the external or internal distribution of any media containing card holder data and has to be approved by management.
• Strict control is maintained over the storage and accessibility of media.
• All computer that store sensitive cardholder data must have a password protected screensaver enabled to prevent unauthorised use.

---

• All data must be securely disposed of when no longer required by We Voice regardless of the media or application type on which it is stored.
• An automatic process must exist to permanently delete on-line data, when no longer required.
• All hard copies of cardholder data must be manually destroyed as when no longer required for valid and justified business reasons. A quarterly process must be in place to confirm that all non-electronic cardholder data has been appropriately disposed of in a timely manner.

---

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.

• Review handling procedures for sensitive information and hold periodic security awareness meetings to incorporate these procedures into day to day company practice.
• Distribute this security policy document to all company employees to read. It is required that all employees confirm that they understand the content of this security policy document by signing an acknowledgement form (see Appendix A)
• All third parties with access to credit card account numbers are contractually obligated to comply with card association security standards (PCI/DSS).
• Company security policies must be reviewed annually and updated as needed.
• Security awareness training need to include awareness on phishing.
• The security awareness training need to be updated at least annually.

---

• Firewalls must be implemented at each internet connection and any demilitarized zone and the internal company network.
• A firewall and router configuration document must be maintained which includes a documented list of services, protocols and ports including a business justification.
• Firewall and router configurations must restrict connections between untrusted networks and any systems in the card holder data environment.
• All inbound and outbound traffic must be restricted to that which is required for the card holder data environment.
• All inbound network traffic is blocked by default, unless explicitly allowed and the restrictions have to be documented.
• All outbound traffic has to be authorized by management (i.e. what are the whitelisted category of sites that can be visited by the employees) and the restrictions have to be documented.
• We Voice will have firewalls between any wireless networks and the cardholder data environment.
• We Voice will quarantine wireless users into a DMZ, where they will be authenticated and firewalled as if they were coming in from the Internet.
• A topology of the firewall environment has to be documented and has to be updated in accordance to the changes in the network.

---

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

• A system configuration standard must be developed along industry acceptable hardening standards (SANS, NIST, ISO)
• System configurations should be updated as new issues are identified (as defined in PCI DSS requirement 6.3)
• The systems configuration standard should be applied to any news systems configured.
• All vendor default accounts and passwords for the systems have to be changed at the time of provisioning the system/device into We Voice network and all unnecessary services and user/system accounts have to be disabled.
• All unnecessary services, protocols, daemons etc., should be disabled if not in use by the system.
• Any insecure protocols, daemons, services in use must be documented and justified.
• All users with access to card holder data must have a unique ID.
• All user must use a password to access the company network or any other electronic resources
• All user ID’s for terminated users must be deactivated or removed immediately.
• A unique password must be setup for new users and the users prompted to change the password on first login.
• Where SNMP is used, the community strings must be defined as something other than the Standard defaults of "public," "private" and "system" and must be different from the passwords used to log in interactively.
• All non-console administrative access will use appropriate technologies like ssh,vpn etc or strong encryption is invoked before the administrator password is requested.
• System services and parameters will be configured to prevent the use of insecure technologies like telnet and other insecure remote login commands.
• Administrator access to web based management interfaces is encrypted using strong cryptography.
• To protect against network analysis attacks, both the workstation and server should be cryptographically secured. Examples of strong protocols are the encrypted Netware login and Kerberos.

---

• All Workstations, servers, software, system components etc. owned by We Voice must have up-to-date system security patches installed to protect the asset from known vulnerabilities.
• Where ever possible all systems, software must have automatic updates enabled for system patches released from their respective vendors. Security patches have to be installed within one month of release from the respective vendor and have to follow the process in accordance with change control process.
• Any exceptions to this process have to be documented.

---

• It is the responsibility of We Voice employees, contractors, vendors and agents with Remote access privileges to We Voice s corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to We Voice.
• Secure remote access must be strictly controlled. Control will be enforced by multi-factor authentication via one-time password authentication or public/private keys with strong pass-phrases.
• All hosts that are connected to We Voice internal networks via remote access technologies will be monitored on a regular basis.
• Vendor accounts with access to We Voice network will only be enabled during the time period the access is required and will be disabled or removed once access is no longer required.

---

---

• All the vulnerabilities would be assigned a risk ranking such as High, Medium and Low based on industry best practices such as CVSS base score.
• As part of the PCI-DSS Compliance requirements, We Voice will run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
• Quarterly internal vulnerability scans must be performed by We Voice by internal staff or a 3rd party vendor and the scan process has to include that rescans will be done until passing results are obtained, or all High vulnerabilities as defined in PCI DSS Requirement 6.3.3 are resolved.
• Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by PCI SSC. Scans conducted after network changes may be performed by the Company’s internal staff. The scan process should include re-scans until passing results are obtained.

---

• Information systems that process transmit, or store card holder data must be configured in accordance with the applicable standard for that class of device or system.  Standards must be written and maintained by the team responsible for the management of the system in conjunction with the Information Security Office. 
• Before being deployed into production, a system must be certified to meet the applicable configuration standard
• Administrators of network devices that do not adhere to tWe Voice standards (as identified via a previous exception) must document and follow a review process of announced vendor updates to operating system and/or configuration settings. This process must include a review schedule, risk analysis method and update method.
• All network device configurations must be checked annually against the configuration boilerplate to ensure the configuration continues to meet required standards.
• Where possible, network configuration management software will be used to automate the process of confirming adherence to the boilerplate configuration.
• For other devices an audit will be performed quarterly to compare the boilerplate configuration to the configuration currently in place.
• All discrepancies will be evaluated and remediated by Network Administration.

---

• Changes to information resources shall be managed and executed according to a formal change control process. The control process will ensure that changes proposed are reviewed, authorised, tested, implemented, and released in a controlled manner; and that the status of each proposed change is monitored.
• The change control process shall be formally defined and documented. A change control process shall be in place to control changes to all critical company information resources (such as hardware, software, system documentation and operating procedures). This documented process shall include management responsibilities and procedures. Wherever practicable, operational and application change control procedures should be integrated.
• All change requests shall be logged whether approved or rejected on a standardised and central system. The approval of all change requests and the results thereof shall be documented. A documented audit trail, maintained at a Business Unit Level, containing relevant information shall be maintained at all times. This should include change request documentation, change authorisation and the outcome of the change. No single person should be able to effect changes to production information systems without the approval of other authorised personnel.
• A risk assessment shall be performed for all changes and dependant on the outcome, an impact assessment should be performed.
• The impact assessment shall include the potential effect on other information resources and potential cost implications. The impact assessment should, where applicable consider compliance with legislative requirements and standards.
• All change requests shall be prioritised in terms of benefits, urgency, effort required and potential impact on operations.
• All changes shall be approved prior to implementation. Approval of changes shall be based on formal acceptance criteria i.e. the change request was done by an authorised user, the impact assessment was performed and proposed changes were tested.
• All users, significantly affected by a change, shall be notified of the change. The user representative shall sign-off on the change. Users shall be required to make submissions and comment prior to the acceptance of the change.
• Procedures for aborting and recovering from unsuccessful changes shall be documented. Should the outcome of a change be different to the expected result (as identified in the testing of the change), procedures and responsibilities shall be noted for the recovery and continuity of the affected areas. Fall back procedures will be in place to ensure systems can revert back to what they were prior to implementation of changes.
• Information resources documentation shall be updated on the completion of each change and old documentation shall be archived or disposed of as per the documentation and data retention policies.
• Specific procedures to ensure the proper control, authorisation, and documentation of emergency changes shall be in place. Specific parameters will be defined as a standard for classifying changes as Emergency changes.
• All changes will be monitored once they have been rolled-out to the production environment. Deviations from design specifications and test results will be documented and escalated to the solution owner for ratification.

---

• This procedure covers all logs generated for systems within the cardholder data environment, based on the flow of cardholder data over We Voice network, including the following components:
  • Operating System Logs (Event Logs and su logs).
  • Database Audit Logs.
  • Firewalls & Network Switch Logs.
  • IDS Logs.
  • Antivirus Logs.
  • Cctv Video recordings.
  • File integrity monitoring system logs.
• Audit Logs must be maintained for a minimum of 3 months online (available for immediate analysis) and 12 months offline.
• Review of logs is to be carried out by means of We Voice’s network monitoring system (the Company to define hostname), which is controlled from We Voice console (the Company to define hostname). The console is installed on the server (the Company to define hostname / IP address), located within We Voice data centre environment.
• The following personnel are the only people permitted to access log files (the Company to define which individuals have a job-related need to view audit trails and access log files).
• The network monitoring system software (the Company to define) is configured to alert We Voice [RESPONSIBLE TEAM] to any conditions deemed to be potentially suspicious, for further investigation. Alerts are configured to:
• A dashboard browser-based interface, monitored by the Company [RESPONSIBLE TEAM].
• Email / SMS alerts to We Voice [RESPONSIBLE TEAM] mailbox with a summary of the incident. The Company [ROLE NAME] also receives details of email alerts for informational purposes.
• The following Operating System Events are configured for logging, and are monitored by the console (We Voice to define hostname): a) Any additions, modifications or deletions of user accounts. b) Any failed or unauthorised attempt at user logon. c) Any modification to system files. d) Any access to the server, or application running on the server, including files that hold cardholder data. e) Actions taken by any individual with root or administrative privileges. f) Any user access to audit trails. g) 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.)
• The following Database System Events are configured for logging, and are monitored by the network monitoring system (We Voice to define software and hostname): a) Any failed user access attempts to log in to the Oracle database. b) Any login that has been added or removed as a database user to a database. c) Any login that has been added or removed from a role. d) Any database role that has been added or removed from a database. e) Any password that has been changed for an application role. f) Any database that has been created, altered, or dropped. g) Any database object, such as a schema, that has been connected to. h) Actions taken by any individual with DBA privileges.
• The following Firewall Events are configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname): a) ACL violations. b) Invalid user authentication attempts. c) Logon and actions taken by any individual using privileged accounts. d) Configuration changes made to the firewall (e.g. policies disabled, added, deleted, or modified).
• The following Switch Events are to be configured for logging and monitored by the network monitoring system (the Company to define software and hostname): a) Invalid user authentication attempts. b) Logon and actions taken by any individual using privileged accounts.  c) Configuration changes made to the switch (e.g. configuration disabled, added, deleted, or modified).
• The following Intrusion Detection Events are to be configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname): a) Any vulnerability listed in the Common Vulnerability Entry (CVE) database.  b) Any generic attack(s) not listed in CVE. c) Any known denial of service attack(s). d) Any traffic patterns that indicated pre-attack reconnaissance occurred. e) Any attempts to exploit security-related configuration errors. f) Any authentication failure(s) that might indicate an attack. g) Any traffic to or from a back-door program. h) Any traffic typical of known stealth attacks.
• The following File Integrity Events are to be configured for logging and monitored by (the Company to define software and hostname): a) Any modification to system files. b) Actions taken by any individual with Administrative privileges. c) Any user access to audit trails. d) 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.)
• For any suspicious event confirmed, the following must be recorded on F17 - Log Review Form, and We Voice [ROLE NAME] informed: a) User Identification. b) Event Type. c) Date & Time. d) Success or Failure indication. e) Event Origination (e.g. IP address). f) Reference to the data, system component or resource affected.

---

• The Secure Application development policy is a plan of action to guide developers’ decisions and actions during the software development lifecycle (SDLC) to ensure software security. This policy aims to be language and platform independent so that it is applicable across all software development projects. 
• The adherence to and use of Secure Application Development Coding Policy is a requirement for all software development on We Voice information technology systems and trusted contractor sites processing the Company data.
• Each phase of the SDLC is mapped with security activities, as explained below: a) Design
  • Identify Design Requirements from security perspective
  • Architecture & Design Reviews
  • Threat Modelling
  b) Coding
  • Coding Best Practices
  • Perform Static Analysis
  c) Testing
  • Vulnerability Assessment
  • Fuzzing
  d) Deployment
  • Server Configuration Review
  • Network Configuration Review
• Development of code shall be checked and validated with the most current versions of We Voice Coding Standards for Secure Application Development. All code developers shall verify that their code is in compliance with the most recent and approved coding standards and guidelines.
• Only validated code shall be implemented into We Voice production environment. A review and validation ensures that code exhibits fundamental security properties to include correctness, predictability, and attack tolerance.

Application Code Developers shall:

• Ensure code meets the level of confidence that software is free from exploitable code vulnerabilities, regardless of whether they are already designed into the software or inserted later in its life cycle.
• Ensure code provides predictable execution or justifiable confidence and that the software, when executed, will provide security functionality as intended.
• Coding techniques must address injection flaws particularly SQL injection,buffer overflow vulnerabilities, cross site scripting vulnerabilities, improper access control (insecure direct object reference, failure to restrict URL access, directory traversal etc.,), cross site request forgery (CSRF), broken authentication and session managment
• Never trust incoming data to the system, apply checks to this data.
• Never rely on the client to store sensitive data no matter how trivial.
• Disable Error messages that return any information to the user.
• Use object inheritance, encapsulation, and polymorphism wherever possible.
• Use environment variables prudently and always check boundaries and buffers.
• Applications must validate input to ensure it is well-formed and meaningful.

---

• In this section, should be listed the risks inherent in conducting penetration testing over the information systems of We Voice . Additionally, it should be noted for each mitigation measures that will be taken. Examples might be: 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.
• Key staff involved in the project by the organization will be listed:

  Technical Project Manager:

  Chief Information Security Officer:

  Chief Information Officer:

  Head of Communications:

  Responsible for web site YYYY.com:

• External intrusion tests will be performed remotely from the supplier's premises .Internal intrusion tests will be conducted in the office We Voice of the Organization. Audit team must to have access to the Organization's network. It must manage access permissions to the building early enough to ensure that the audit team can access without problems during planning period.
• If segmentation is used to limit the scope of PCI DSS the segmentation techniques need to be tested using a segmentation test.
• All the tests will be conducted from the equipment owned by the audit team so no equipment for the execution of the tests is required. The only requirement in this regard will be to have an active network connection for each member of the audit team. Those connections must provide access to the target network segment in every case.
• If an incident occurs during the execution of the tests that have an impact on the systems or services of the organization, the incident should be brought immediately to the attention of those responsible for incident management in the project
• It should be noted that in order to comply with PCI DSS the scope of the test should include, at least the following:
  • All systems and applications that are part of the perimeter of the cardholder data environment card (CDE).
  • Critical systems within the CDE.
• For all findings or vulnerabilities identified during the tests carried out will be generated and documented sufficient evidence to prove the existence of the same. The format of the evidence can be variable in each case, screen capture, raw output of security tools, photographs, paper documents, etc.

---

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

We Voice 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. 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.
3. 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.
4. 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.
5. 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.
6. 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 We Voice 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.

---

Roles and responsibilities need to be defined down to a requirement level.

Chief Security Officer (or equivalent) is responsible for overseeing all aspects of information security, including but not limited to:

• Creating and distributing security policies and procedures.
• Ensure that security controls are maintained
• Perform risk analysis
• Monitoring and analysing security alerts and distributing information to appropriate information security and business unit management personnel.
• creating and distributing security incident response and escalation procedures that
• Maintaining a formal security awareness program for all employees that provide multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings).
• Manage the vulnerability management and penetration testing program
• Maintain a list of service providers.
• Ensure there is a process for engaging service providers including proper due diligence prior to engagement.
• Maintain a program to verify service providers’ PCI-DSS compliant status, with supporting documentation.

The Information Technology Office (or equivalent) shall maintain daily administrative and technical operational security procedures that are consistent with the PCI-DSS (for example, user account maintenance procedures, and log review procedures).

Network Administrators shall:

• Maintain network devices including firewalls and routers.
• Perform firewall ruleset reviews every six months.
• Ensure that network devices are securely configured.

System and Application Administrators shall:

• monitor and analyse security alerts and information and distribute to appropriate personnel.
• administer user accounts and manage authentication.
• Monitor and control all access to data.
• Ensure that systems and devices are securely configured.

The Human Resources Office (or equivalent) is responsible for tracking employee participation in the security awareness program, including:

• Facilitating participation upon hire and at least annually.
• Ensuring that employees acknowledge in writing at least annually that they have read and understand the Company’s information security policy.

General Counsel (or equivalent) will ensure that for service providers with whom cardholder information is shared:

• Written contracts require adherence to PCI-DSS by the service provider.
• Written contracts include acknowledgement or responsibility for the security of cardholder data by the service provider.

---

• All third-party companies providing critical services to We Voice must provide an agreed Service Level Agreement.
• All third-party companies providing hosting facilities must comply with the Company’s Physical Security and Access Control Policy.
• All third-party companies which can affect the security of Card Holder information must:
  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.
  6. Provide a responsibility matrix defining the requirements they are responsible for and which ones that are shared.

---

• Access Control systems are in place to protect the interests of all users of We Voice computer systems by providing a safe, secure and readily accessible environment in which to work.
• We Voice will provide all employees and other users with the information they need to carry out their responsibilities in as effective and efficient manner as possible.
• Generic or group IDs shall not normally be permitted, but may be granted under exceptional circumstances if sufficient other controls on access are in place.
• The allocation of privilege rights (e.g. local administrator, domain administrator, super-user, root access) shall be restricted and controlled, and authorization provided jointly by the system owner and IT Services. Technical teams shall guard against issuing privilege rights to entire teams to prevent loss of confidentiality.
• Access rights will be accorded following the principles of least privilege and need to know.
• Every user should attempt to maintain the security of data at its classified level even if technical security mechanisms fail or are absent.
• Users electing to place information on digital media or storage devices or maintaining a separate database must only do so where such an action is in accord with the data’s classification
• Access to The Company IT resources and services will be given through the provision of a unique Active Directory account and complex password.
• No access to any The Company IT resources and services will be provided without prior authentication and authorization of a user’s We Voice Windows Active Directory account.
• Password issuing, strength requirements, changing and control will be managed through formal processes. Password length, complexity and expiration times will be controlled through Windows Active Directory Group Policy Objects. 
• Access to Confidential, Restricted and Protected information will be limited to authorised persons whose job responsibilities require it, as determined by the data owner or their designated representative. Requests for access permission to be granted, changed or revoked must be made in writing.
• Users are expected to become familiar with and abide by We Voice policies, standards and guidelines for appropriate and acceptable usage of the networks and systems.
• Access for remote users shall be subject to authorization by IT Services and be provided in accordance with the Remote Access Policy and the Information Security Policy. No uncontrolled external access shall be permitted to any network device or networked system.
• Access to data is variously and appropriately controlled according to the data classification levels described in the Information Security Management Policy.
• Access control methods include logon access rights, Windows share and NTFS permissions, user account privileges, server and workstation access rights, firewall permissions, IIS intranet/extranet authentication rights, SQL database rights, isolated networks and other methods as necessary.
• A formal process shall be conducted at regular intervals by system owners and data owners in conjunction with IT Services to review users’ access rights. The review shall be logged and IT Services shall sign off the review to give authority for users’ continued access rights.

---

Where the Company are utilizing POI’s the following policies are applicable:

POI Device Inventory and Management:

• Maintain an up-to-date inventory of all POI devices, including make, model, location, and serial number.
• Establish procedures for securely adding, relocating, and decommissioning POI devices.

Physical Security Measures:

• Secure POI devices to prevent tampering or substitution. This includes using tamper-evident seals or enclosures.
• Regularly inspect devices for signs of tampering or substitution.
• Implement secure storage for devices not in use.

Device Inspection and Maintenance:

• Conduct regular inspections and maintenance of POI devices to ensure they are functioning correctly and haven't been compromised.
• Document and maintain a record of all inspections and maintenance activities.

Secure Configuration and Software Management:

• Ensure that POI devices are configured securely and in compliance with PCI DSS requirements.
• Implement measures to prevent unauthorized changes to software and configuration settings.
• Regularly update POI device software, including patches for known vulnerabilities.

Access Controls:

• Restrict access to POI devices to authorized personnel only.
• Use strong authentication methods for administrative access to POI devices.
• Implement role-based access controls and segregate duties to minimize the risk of unauthorized access or changes.