Information Security Policy

Version 1.0 • Effective 3 September 2026 • Next review 3 September 2027

Approved by David Zeitoune, Information Security Officer

Introduction

This policy defines the information-security controls used by David Zeitoune trading as St Mary’s Pharmacy for GetMyMeds, its e-commerce website, payment administration, and supporting cloud and administrative systems. It applies to the policy owner, pharmacy personnel, contractors, and service providers who administer or support those systems.

David Zeitoune owns this policy and is responsible for distributing it to relevant personnel, recording acknowledgement, and reviewing it at least annually. Material changes to the payment flow, service providers, systems, regulatory requirements, or security risks trigger an earlier review.

Information Security Policy and Scope

GetMyMeds accepts e-commerce card payments through the Elavon Opayo Hosted Payment Page. The GetMyMeds website creates a payment registration and redirects the customer’s browser to an Opayo-hosted page. The customer enters the card number, expiry date, and security code directly into Opayo. GetMyMeds does not receive, process, transmit, or store full card numbers, security codes, PINs, or magnetic-stripe data.

Opayo performs payment authorisation and AVS/CV2 checks and handles any 3-D Secure authentication required for the transaction. Opayo returns a digitally signed result, which the GetMyMeds backend validates and confirms through a server-to-server transaction lookup before an order is treated as paid. GetMyMeds stores only operational payment metadata: the Opayo transaction identifier, status, amount, currency, card brand, last four digits, and authorisation or retrieval references. Refunds are instructed server-to-server using the transaction identifier.

The PCI DSS scope for this policy includes the merchant website, cloud services, administrative accounts, source code, payment configuration, and credentials that could affect the redirect to Opayo or the integrity of the payment outcome. GetMyMeds does not use merchant-controlled card-entry fields, embedded payment frames, telephone orders, mail orders, or card-present terminals for this e-commerce payment flow.

All personnel must:

• Handle company, patient, and payment-related information according to its classification.
• Use unique accounts, strong authentication, and approved systems only.
• Never ask a customer to send card details by email, message, consultation form, photograph, or telephone.
• Lock screens when unattended and keep desks clear of confidential information.
• Obtain management approval before introducing software, devices, integrations, or third-party access.
• Report suspected security incidents immediately to David Zeitoune at order@stmarys-pharmacy.co.uk or 01675 442696.

1. Network Security

The maintained payment data flow is: customer browser → GetMyMeds website → server-side payment registration → Opayo Hosted Payment Page → card issuer and 3-D Secure service → signed Opayo return → server-side transaction verification → order record. Card data is entered only after the customer reaches the Opayo-hosted domain.

• The public website uses HTTPS. Insecure HTTP requests are redirected to HTTPS, and security headers are maintained for the public site.
• Firebase Hosting serves the frontend. Google Cloud Functions, Firestore, Storage, and Authentication support the backend and administration in the getmymeds-pharmacy project.
• Opayo integration credentials are encrypted at rest, restricted to authorised server-side functions, and never exposed to the browser, source repository, analytics, or customer communications.
• Source changes are reviewed, built, tested, and deployed through authorised administration. Payment-flow changes receive an end-to-end sandbox test before live release.
• Operating runtimes, libraries, and administrative devices receive security updates promptly. Critical security patches are applied within one month of release or sooner when active exploitation or provider guidance requires it.
• External vulnerability scanning by a PCI SSC Approved Scanning Vendor is completed at least quarterly when required by the applicable PCI validation route or merchant acquirer, and after significant external-facing changes.
• The data-flow and system inventory are checked during the annual policy review and after any material change to hosting, checkout, authentication, or payment providers.

2. Acceptable Use Policy

Company systems and accounts are provided for authorised business use. Personnel must:

• Use only approved, supported, and securely configured computers and mobile devices for administration.
• Use a unique account for each person, protect passwords in an approved password manager, and never share credentials or authentication codes.
• Enable automatic screen locking and full-device encryption on devices used to administer GetMyMeds, Opayo, email, cloud hosting, or source code.
• Install software, browser extensions, remote-access tools, and integrations only with management approval.
• Exercise caution with links, attachments, login prompts, payment notifications, and requests to disclose credentials or change bank details.
• Keep patient, identity, order, and payment metadata out of personal email, personal cloud storage, consumer messaging applications, and unapproved removable media.
• Do not enter customer card data into GetMyMeds, MyOpayo notes, support tickets, emails, consultation forms, or administrative records.
• Report lost devices, suspicious prompts, phishing, malware, unauthorised access, or unexpected payment-flow changes immediately.

3. Protect Stored Data

GetMyMeds is designed not to store account data or sensitive authentication data. The following are prohibited on company systems, paper, email, logs, screenshots, support records, backups, or removable media:

• Full primary account numbers (PANs).
• Card verification or security codes (CVV, CVC, or CID).
• Full magnetic-stripe or equivalent track data.
• PINs or encrypted PIN blocks.
• Photographs, scans, recordings, or copies of payment cards.

Permitted payment records are limited to the Opayo transaction identifier, amount, currency, transaction status, card brand, last four digits, authorisation or retrieval references, refund references, and audit timestamps. Access is restricted to personnel who need these records to reconcile, support, or refund an order.

Encryption keys, API credentials, and webhook or signing secrets are Restricted information. They are kept in encrypted configuration or managed secret storage, separated from application source code, and rotated after suspected exposure or when access responsibilities change.

4. Information Classification

• Restricted: Payment credentials and secrets; any accidentally received card data; patient health data; identity documents and verification data; authentication recovery data. Access is strictly need-to-know.
• Confidential: Customer contact and delivery information, consultations, order records, payment transaction metadata, staff records, audit logs, contracts, and non-public business information.
• Internal: Procedures, technical documentation, supplier records, and operational information that is not approved for public release.
• Public: Approved website content, published policies, product information, and public regulatory or contact information.

Information must be stored, shared, retained, and disposed of according to the highest classification present. Restricted and Confidential information is not copied to unapproved systems or disclosed without an authorised business, clinical, legal, or regulatory purpose.

5. Access to Cardholder Data

No GetMyMeds role requires access to full cardholder data. Opayo alone receives card details on its Hosted Payment Page. Authorised GetMyMeds administrators may view only the limited transaction metadata described in section 3 and information made available through the secured MyOpayo account.

• David Zeitoune authorises administrative access and records the business purpose and assigned role.
• Access follows least privilege and is removed immediately when a person leaves, changes role, or no longer requires it.
• MyOpayo, cloud, email, and code-administration access must use unique accounts and multi-factor authentication whenever the service supports it.
• Administrative and payment activity is reviewed when reconciling transactions, investigating exceptions, and conducting access reviews.
• The service-provider register is maintained, and PCI or security assurance for relevant providers is checked annually.

6. Physical Security

GetMyMeds does not own or operate a device that captures payment card data for this e-commerce flow. Customers use their own devices and enter card details directly on Opayo’s hosted page.

• Personnel must not write down, print, photograph, scan, or otherwise physically record card details.
• Devices used for administration must be kept under the authorised user’s control, protected by automatic locking and device encryption, and stored securely when unattended.
• Visitors are not permitted unsupervised access to administrative devices or areas containing Restricted or Confidential information.
• Paper containing Restricted or Confidential information is kept in locked storage and cross-cut shredded when authorised retention ends.
• Loss, theft, tampering, or unauthorised use of an administrative device is reported immediately and handled under the incident-response plan.

7. Protect Data in Transit

• Full card details and security codes must never be transmitted by GetMyMeds personnel through email, messaging, telephone recordings, forms, support tickets, photographs, file transfer, or physical media.
• The website and server-to-server payment requests use encrypted HTTPS connections. Customers enter card data only on the authenticated Opayo-hosted page.
• The GetMyMeds backend validates the signed Opayo return and retrieves the transaction from Opayo before accepting a payment result.
• Payment credentials, session tokens, personal data, and card data are excluded from analytics payloads and must not be placed in URLs or application logs.
• Restricted or Confidential non-card information is shared only through approved encrypted services with an identified recipient and a documented business, clinical, legal, or regulatory purpose.

8. Disposal of Stored Data

GetMyMeds has no business need or permitted retention period for full card numbers, security codes, track data, PINs, or card images. Any such information received accidentally is secured, reported immediately, removed from normal processing, and irreversibly destroyed after evidence needed for incident handling is preserved.

• Paper containing card data is cross-cut shredded or destroyed by a contracted confidential-waste service.
• Electronic copies are securely deleted from active systems, synchronised folders, messages, logs, backups where technically feasible, and endpoint recycle or recovery locations.
• Credentials exposed with an incident are revoked and rotated; active sessions and access tokens are invalidated.
• Authorised transaction metadata and order records follow the pharmacy’s documented legal, clinical, tax, fraud-prevention, and operational retention schedule.
• Storage locations and retention controls are checked during the annual policy review and following material system changes.

9. Security Awareness and Procedures

Relevant personnel must receive security instruction before access is granted and at least annually thereafter. Completion and acknowledgement are recorded. Training covers:

• The redirect-only Opayo payment flow and the prohibition on collecting or recording card details.
• Phishing, social engineering, fraudulent payment or refund requests, credential theft, and safe verification of support contacts.
• Password-manager use, multi-factor authentication, secure device operation, software updates, and protection of Restricted and Confidential information.
• Recognition and immediate reporting of website tampering, unexpected redirects, lost devices, malware, unauthorised access, or accidental receipt of card information.
• The incident-response process, including preservation of evidence and the requirement not to investigate or communicate externally without coordination from the response lead.

David Zeitoune communicates material policy changes promptly and records acknowledgement using a controlled training record.

10. Payment Card Security Incident Response Plan

This plan applies to suspected or confirmed loss of payment credentials, phishing, malware, website or redirect tampering, unauthorised access to MyOpayo or merchant systems, accidental receipt of card data, payment fraud affecting system integrity, and compromise of a service provider used in the payment flow.

The incident response lead is David Zeitoune. Report an incident immediately to order@stmarys-pharmacy.co.uk or 01675 442696.

Response procedure

1. Report. Record the reporter, time, affected system, observed facts, and actions already taken. Do not include full card details in the incident record.
2. Contain. Remove affected devices or services from access where safe, disable compromised accounts, revoke sessions, preserve the legitimate payment route, and prevent further exposure without destroying evidence.
3. Preserve evidence. Retain relevant logs, timestamps, transaction identifiers, screenshots that contain no prohibited card data, email headers, configuration history, and provider communications. Restrict evidence access.
4. Assess. Identify affected systems, data, accounts, transactions, customers, time period, service providers, and the likelihood of continued compromise. Engage qualified technical, forensic, legal, or regulatory support when the incident requires it.
5. Notify. Contact Elavon/Opayo and the acquirer promptly for any suspected card-data or payment-system compromise. Notify affected individuals, the Information Commissioner’s Office, law enforcement, professional regulators, insurers, or other parties when the applicable legal, contractual, or regulatory threshold is met.
6. Recover. Remove malicious changes, patch the cause, rotate credentials, validate the intended Opayo redirect and signed return, test payment and refund paths, monitor for recurrence, and obtain the incident commander’s approval before normal operation resumes.
7. Close and improve. Document the cause, impact, notifications, recovery evidence, and corrective actions. Update controls, training, supplier oversight, and this policy to prevent recurrence.

Elavon UK compromise contact

Email: #ADCqueries-GB@elavon.com • Telephone: 01923 651 622. The initial notification identifies the merchant, contact details, affected service, incident time, and known impact without including full card numbers or security codes. The incident lead also uses the secured MyOpayo or Elavon support channel to confirm the case and any required next steps.

David Zeitoune exercises this plan at least annually and after material changes to the payment flow. Test records include the scenario, participants, decisions, gaps, and completed corrective actions.

11. Transfer of Sensitive Information Policy

GetMyMeds does not transfer cardholder data because it does not receive it. Customers transmit card details directly to Opayo. Personnel must refuse requests to forward card data and must use the incident-response process if card data is received accidentally.

• Service providers are assessed before use for security capability, contractual responsibility, access scope, incident support, data location, continuity, and termination arrangements.
• Contracts require providers to protect information they process, restrict use to the contracted purpose, notify relevant incidents, and return or delete data at termination in accordance with legal obligations.
• PCI DSS compliance evidence or merchant/acquirer assurance is checked annually for service providers that store, process, transmit, or can affect the security of cardholder data.
• Provider access is limited to the service delivered, recorded, protected by strong authentication, and removed promptly when no longer required.

12. User Access Management

• David Zeitoune approves all access to GetMyMeds administration, MyOpayo, Firebase/Google Cloud, Stripe Identity, email, source code, and deployment systems.
• Each person receives a unique identity. Shared or generic interactive accounts are prohibited.
• Access requests record the user, role, business purpose, systems, privileges, start date, approving person, and review or removal condition.
• Least privilege is applied. Administrative, clinical, catalogue, order, payment, and support permissions are separated when the system permits.
• Access is changed promptly when duties change and revoked immediately when employment, engagement, or business need ends. Active sessions, recovery methods, API credentials, and shared secrets affected by the departure are also revoked or rotated.
• Inactive accounts are disabled within 90 days. Privileged and service accounts are inventoried and checked during each access review.
• User and privileged access must be reviewed at least every six months and after material role, supplier, or system changes. David Zeitoune records the outcome and corrective action.

13. Access Control Policy

• Access follows need-to-know and least-privilege principles, with explicit approval for administrative or security-sensitive privileges.
• Multi-factor authentication must be enabled for MyOpayo, cloud administration, email, source control, and other administrative services that support it.
• Passwords are unique, resistant to guessing, never reused across services, stored only in an approved password manager, and changed immediately after suspected exposure.
• Production integration keys, passwords, signing secrets, encryption keys, and recovery codes are never committed to source control, placed in frontend code, or sent through ordinary email or messaging.
• Administrative access uses supported, encrypted, patched devices. Remote access is allowed only through approved encrypted connections and must not be performed from untrusted shared devices.
• Authentication, configuration, payment, refund, and administrative audit information is retained and reviewed for security events and operational reconciliation without recording prohibited card data.
• Failed login activity, unexpected redirects, configuration changes, new administrative users, payment anomalies, and provider alerts must be investigated promptly.
• Access-control exceptions require written approval from David Zeitoune, a documented reason, compensating safeguards, an expiry date, and removal when the reason ends.

Payment Card Capture Devices

No merchant-controlled payment-card capture device or card-entry application is used for the GetMyMeds e-commerce flow. Customers use their own device and enter card details directly on the Opayo Hosted Payment Page.

Service Providers

• Elavon / Opayo: Hosted Payment Page, card processing, AVS/CV2, 3-D Secure, transaction administration, and refunds. Opayo receives card data directly and is the in-scope payment service provider.
• Google Cloud / Firebase: Website hosting, serverless API, database, storage, and authentication. GetMyMeds does not store or transmit PAN/CVV in Google Cloud.
• Stripe: Identity-document verification for eligible consultations. Stripe Identity is separate from the Opayo payment flow and does not process GetMyMeds card payments.
• Resend: Transactional order and consultation email delivery. Emails contain no PAN, CVV, PIN, track data, or payment credentials.

Policy contact

GetMyMeds is operated by David Zeitoune trading as St Mary’s Pharmacy, 48 Fentham Road, Hampton-in-Arden, Solihull B92 0AY. Registered pharmacy premises: GPhC 1038376. For questions about this policy, email contact@stmarys-pharmacy.co.uk or call 01675 442696.