Vulnerability Management & Penetration Testing Policy

Reviewed: 29 January 2026

At a glance

• We operate a continuous vulnerability management programme with clear SLAs for remediation and documented exceptions.
• We perform independent penetration tests at least annually and after significant changes; high‑risk findings are tracked to closure.
• Zero‑day and actively exploited vulnerabilities trigger expedited patching and/or compensating controls with 24/7 monitoring.

Purpose

To define how UK Postbox identifies, triages, remediates and validates security vulnerabilities in a timely manner, and how we test defences through penetration testing, in line with UK GDPR Article 32 (security of processing) and good practice (NCSC/OWASP).

Scope

• Assets: web apps/portals, APIs, mobile apps (if applicable), backend services, infrastructure (cloud and on‑prem), endpoints, networks, CI/CD, mailroom systems that interface with digital services, and third‑party/SaaS services in our data flows.
• Data: any environment handling customer or operational data (controller or processor role).
• Exclusions: purely informational marketing microsites hosted by third parties may be scanned less frequently, but remain in inventory.

Roles & responsibilities

• Security Lead (owner): overall programme, tooling, risk acceptance, reporting, and approvals for exceptions.
• Engineering Leads: remediate findings within SLA; ensure secure coding and dependency management.
• IT/Ops: patch operating systems, containers, images and endpoints; maintain hardened baselines.
• Product Owners: plan remediation in backlogs; sign off risk where applicable with Security and DPO where personal data risk exists.
• Vendors/Sub‑processors: must notify relevant vulnerabilities/incidents without undue delay and cooperate on remediation.

Asset inventory & scope control

• Maintain a current asset inventory (systems, apps, services, cloud resources, data stores, endpoints) with owners, environment (prod/non‑prod), data classification and internet exposure.
• New assets must not go live without being added to inventory and onboarding to scanning/patch cycles. We perform periodic discovery scans to identify unauthorised or unknown assets (shadow IT) and bring them into inventory or decommission them.

Discovery & scanning

• Automated scans:
  • External perimeter: weekly scans of internet‑facing assets including both unauthenticated discovery and authenticated vulnerability assessment where applicable.
  • Internal/authenticated scans: at least monthly for servers/containers and weekly for critical systems; authenticated where feasible.
  • Cloud configuration (CSPM): continuous checks for misconfiguration and CIS/NCSC alignment.
  • Dependency/SCA: continuous software composition analysis on builds; block release on critical library issues unless exception approved.
  • Container images: scan pre‑deployment and on base‑image updates. Base images are rebuilt at least monthly or within 7 days of a critical vulnerability being published in a base component.
  • Endpoint/MDM: continuous policy compliance and vuln telemetry.
• Manual reviews: secure code review, threat modelling for significant changes.

Triage, severity & SLAs

We use CVSS v3.1 as baseline, adjusted for exploitability, exposure, data sensitivity and compensating controls. We supplement CVSS with Exploit Prediction Scoring System (EPSS) data to prioritise vulnerabilities with higher likelihood of exploitation. Severity levels and target SLAs:

• Actively exploited (KEV/known exploited) issues trigger expedited timelines regardless of base score.
• If remediation cannot meet SLA, implement temporary compensating controls (e.g., WAF rules, feature flags, config changes) and document an exception.

Exceptions & risk acceptance

• Exceptions require a documented risk assessment, proposed compensating controls, expiry date, and approvals from Security Lead (and DPO where personal data risk may remain).
• Exceptions are reviewed at least monthly until closed; no exception may persist beyond 90 days without senior approval (sign-off from the Security Lead and a member of the executive team).

Patch & change management

• Security patches follow change control with risk ratings and back‑out plans. Security patches are tested in a non-production environment before production deployment where time permits; emergency patches may proceed with post-deployment validation.
• Emergency patching may bypass standard change windows with retrospective approval.
• Base images and AMIs are rebuilt regularly; immutable infrastructure patterns preferred over in‑place patching.
• Secrets/keys rotated when patching auth components or upon compromise.

Penetration testing

• Cadence: at least annually, and after major changes (e.g., new application module, significant architecture change, new internet‑facing service).
• Scope: internet‑facing apps/APIs, auth flows (MFA, SSO), role‑based access, file upload/processing, mail‑image handling pipelines, admin tooling, and representative internal services. Social engineering and physical tests are out of scope unless expressly contracted.
• Providers: independent testers with CREST or CHECK accreditation (or equivalent recognised certification); conflict‑of‑interest avoided; signed NDA and rules of engagement.
• Methodology: OWASP ASVS/MSTG where relevant; test for OWASP Top 10/Top 10 API, authz/IDOR, SSRF, RCE, injection, access control, crypto, business logic abuse, rate limits, and cloud/IaC misconfig. API penetration testing covers authentication, authorisation, rate limiting, input validation, and business logic vulnerabilities per OWASP API Security Top 10.
• Retest: critical/high findings must be retested after fixes.

Findings management

• Findings are logged in a central tracker with severity, owner, due date, environment and evidence.
• Product/Engineering teams prioritise remediation per SLA; Security monitors progress and escalates overdue items. Findings approaching SLA breach (within 7 days) trigger automatic escalation to the Security Lead and relevant Engineering Lead.
• Validation: Security verifies fixes (scan/retest) before closure.
• Communication: Customer‑impacting vulnerabilities are assessed for disclosure; if a personal data breach occurs, follow the Incident Response & Breach Notification Policy and the DPA.

Third‑party & supplier vulnerabilities

• Monitor vendor advisories and threat intel (e.g., zero‑days in widely used libraries or platforms).
• Sub‑processors must notify without undue delay and share impact and remediation plans.
• Where a vendor cannot meet SLA, assess alternate controls or temporary suspension/failover.

Public/Coordinated Vulnerability Disclosure (CVD)

• Researchers may report suspected vulnerabilities to security@ukpostbox.com with enough detail to reproduce.
• We request a good‑faith testing approach: no data exfiltration, service disruption or privacy violations. UK Postbox provides safe harbour to security researchers acting in good faith; we will not pursue legal action for activities that comply with this policy. In-scope for vulnerability disclosure: *.ukpostbox.com, mobile applications, and APIs. Out of scope: third-party services, physical security, social engineering against staff.
• We will acknowledge within 5 business days, keep you updated, and credit contributors if desired. No bug bounty is currently offered.
• Do not publicly disclose issues until we confirm a fix or 90 days have elapsed, unless otherwise agreed.

Metrics & reporting

We track: total/open findings by severity, mean time to remediate (MTTR), SLA adherence, exception count/age, retest pass rate, and coverage (assets scanned, pen‑test scope). Metrics are trended over time to identify patterns and inform process improvements. Quarterly reports go to the Security Committee and DPO. We may commission periodic red team exercises to test detection and response capabilities; these are conducted under strict rules of engagement.

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