Data Security & Encryption Practices

Reviewed: 29 January 2026

At a glance

  • We protect personal data with layered security and strong encryption in transit and at rest, in line with UK GDPR Article 32.
  • Access is controlled via least privilege, role‑based access control (RBAC) and multi‑factor authentication (MFA).
  • Keys and secrets are managed centrally with strict separation of duties, rotation, and audit.
  • We monitor and test continuously (logging/SIEM, vulnerability management, penetration tests) and hold Cyber Essentials Plus.

Purpose

This document explains the technical and organisational measures UK Postbox uses to secure systems and data, with emphasis on encryption, key management, access controls, monitoring, and secure handling of mail content.

Scope

  • Applies to production infrastructure, networks, applications, endpoints, mail‑room operations and third‑party processors used to deliver our services.
  • Covers personal data we process as controller (account, billing, support, analytics, marketing, CCTV, call recordings) and as processor (digital mail scans/metadata on customer instruction).
  • Complements our Data Protection Policy, DPA, Incident Response, and Retention & Deletion policies.

Data classification & handling

  • Data is classified as: Public (information intended for external publication); Internal (business information not intended for external sharing); Confidential (information requiring protection, including customer data and business-sensitive material); Restricted (highest sensitivity, including KYC artefacts, credentials, cryptographic keys, and mail content).
  • Handling rules (storage, transmission, access approval, and disposal) are defined per class.
  • Restricted (e.g., KYC, mail scans, credentials, keys) requires encryption at rest and in transit, limited access, and enhanced logging.

Encryption standards

In transit

  • Transport security uses TLS 1.2+ (TLS 1.3 preferred) with modern ciphers; deprecated protocols/ciphers are disabled. TLS certificates are managed via automated certificate lifecycle management; certificates are renewed at least 30 days before expiry.
  • HSTS, secure cookies, and security headers (e.g., Content‑Security‑Policy, X‑Content‑Type‑Options, Referrer‑Policy) are enforced on web apps.
  • Email security: SPF, DKIM, and DMARC (p=reject for primary domains; p=quarantine as minimum for all sending domains); opportunistic TLS for SMTP; sensitive payloads may be additionally encrypted.

At rest

  • Data stores holding personal data (relational/NoSQL databases, file/object storage, search indexes) are encrypted at rest using AES‑256 or provider‑equivalent. Data is encrypted using a key hierarchy: data encryption keys (DEKs) are encrypted by key encryption keys (KEKs), which are protected by the KMS root key.
  • File/object storage of digital mail images and KYC artefacts is encrypted at rest; access is mediated via app services using short‑lived credentials.
  • Endpoint storage (laptops/portable media) uses full‑disk encryption.

Backups & archives

  • Backups of production data are encrypted and stored separately from primaries; access is restricted and audited.
  • Backups follow retention windows and are purged via rotation (see Retention Policy).
  • Restore tests are performed periodically to validate integrity and recovery.

Key & secret management

  • Keys are managed via a central KMS/HSM‑backed service; customer data keys are envelope‑encrypted by master keys.
  • Separation of duties: key administrators cannot read data; application owners cannot manage key policies. No single individual has the ability to reconstruct or access root cryptographic keys; split knowledge and dual control are used for key ceremonies.
  • Rotation: master/root keys rotated at least annually; data encryption keys rotated annually or on material change; API keys and tokens rotated at least annually and immediately on personnel departure or suspected compromise.
  • Storage: secrets are stored in a dedicated secrets manager, never in source code or plaintext config.
  • Audit: key usage is logged and monitored for anomalies.

Identity & access management

  • RBAC with least privilege; access granted per role and time‑bound where possible.
  • MFA is enforced for privileged accounts and strongly recommended for all users.
  • SSO used where supported; password policy aligns to NCSC guidance: minimum 12 characters for staff, minimum 10 characters for customers; complexity not enforced but length prioritised; throttled attempts.
  • Joiner‑Mover‑Leaver process: prompt provisioning, change, and revocation; quarterly access reviews; break‑glass access controlled and logged.
  • Administrative actions are audit‑logged; logs are tamper‑resistant.

Application & platform security

  • Secure SDLC: code review, dependency scanning (SCA), SAST/DAST where applicable, and pre‑release security checks. Threat modelling is performed for new features handling sensitive data or significantly changing the attack surface.
  • Configuration as code for infrastructure; production changes via peer‑reviewed pull requests and CI/CD with approvals.
  • WAF/DDoS protection and rate limiting protect public endpoints; automated bot detection where appropriate.
  • Input validation, output encoding, prepared statements, and CSRF protections are standard.
  • Least‑privilege service accounts and short‑lived tokens for inter‑service auth.

Logging, monitoring & detection

  • Centralised logging for apps, infrastructure and security controls; time‑synchronised.
  • SIEM monitors events with alerts for anomalous access, privilege misuse and data exfiltration patterns.
  • Health and performance telemetry feed into availability monitoring; paging for critical incidents.
  • Logs are retained per the Retention Policy and protected from tampering.

Vulnerability & patch management

  • Automated scanning of infrastructure and applications; findings triaged by severity.
  • Target remediation SLAs: Critical ≤ 7 days, High ≤ 14 days, Medium ≤ 30 days, Low as scheduled. Actively exploited vulnerabilities (zero-days): mitigating controls within 48 hours.
  • Emergency patching procedures exist for actively exploited issues.
  • Penetration testing: at least annually and after major changes; key results tracked to closure.
  • Software composition: third‑party/library vulnerabilities monitored and updated.

Mailroom & physical security

  • Secure handling areas with access control, CCTV, and visitor management. Scanning workstations are hardened, do not have general internet access, and are subject to enhanced monitoring.
  • Chain‑of‑custody for physical items; segregation between customer items.
  • BS EN 15713 compliant destruction for paper.
  • Staff vetting and training for mail‑handling procedures.

Endpoint & device security

  • Corporate devices baseline‑hardened; full‑disk encryption, automatic lock, and remote wipe.
  • EDR/anti‑malware with central policy; removable media restricted.
  • Mobile device management (MDM) for supported devices.

Supplier & sub‑processor security

  • Due diligence prior to onboarding: security questionnaires, attestations/certifications (e.g., Cyber Essentials Plus), contractual DPA and transfer safeguards (IDTA/UK Addendum).
  • Change notifications for sub‑processors; right to audit/assess via reports.
  • Contractual obligations to notify incidents without undue delay.

Incident response & business continuity

  • Incident Response & Breach Notification Policy defines triage, containment, eradication and recovery, with ICO notification within 72h where required.
  • BC/DR plans cover loss of facilities, systems or suppliers; RPO/RTO objectives are reviewed and tested.

Data retention, deletion & disposal

  • Retention follows our Data Retention & Deletion Policy.
  • Digital deletions are executed via application workflows and secure wipe of storage blocks as supported by the platform; backups purge via rotation.
  • Physical mail is stored 1 month by default and then securely destroyed unless instructed otherwise (see Mail Inspection & Handling Policy for detailed retention options).
  • Certificates/logs of destruction retained for audit where appropriate.

Customer responsibilities (shared responsibility model)

  • Keep login credentials secure; enable MFA.
  • Configure retention for digital scans per your compliance needs.
  • Use strong, unique passwords and keep account contact details up to date.
  • Do not share or upload malicious content; follow our Acceptable Use Policy.
  • Notify security@ukpostbox.com immediately if you suspect compromise.

Governance, training & review

  • Security and privacy training provided annually with role‑specific refreshers.
  • Policy owner: Security Lead.
  • Review: at least annually and on significant changes to law, risk, or architecture. We are monitoring developments in post-quantum cryptography and will evaluate migration requirements as standards mature (NIST PQC).

UK Postbox Limited

13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, Dorset, BH16 6FH, United Kingdom


Support: support@ukpostbox.com

Security: security@ukpostbox.com

Legal notices: legal@ukpostbox.com

Data protection: dpo@ukpostbox.com

Complaints: complaints@ukpostbox.com

Accessibility: accessibility@ukpostbox.com

Website: www.ukpostbox.com


Registered in England and Wales Company Number: 06723381

MLR registration no: XLML00000192390

ICO registration no: ZA038907