Vulnerability Remediation SLA

A commitment to fix an identified vulnerability within a stated period. Without a stated period, “we patch promptly” means whatever is convenient, and the only evidence of a lapse is the breach that follows it.

Severity follows the CVSS v3.1 base score, adjusted by whether the vulnerability is actually reachable in this application.

A vulnerability in a dependency that this application does not call may be downgraded, but the reasoning is recorded and the dependency is still upgraded at the next opportunity. Downgrading is a scheduling decision, not a dismissal.

These windows are chosen to be honest for a single-operator business rather than impressive. A seven-day critical window is achievable alone; a twenty-four-hour one is not, and committing to it would produce a policy breached on its first test.

• Automated dependency alerts on the source repository, with automated security patch pull requests. This is the primary channel.
• Platform advisories from the hosting and database providers, who patch the infrastructure layers they manage and notify of anything requiring action.
• Vendor notices from the payment processor, CRM and bank connectivity providers.
• Operating system updates on the administration workstation, installed automatically.
• Continuous web application vulnerability scanning of the company’s WordPress estate at pxlpod.co, using Patchstack via WP Umbrella. This monitors WordPress core, themes and plugins against a vulnerability database and reports newly disclosed issues affecting installed components.

The WordPress estate sits outside the scope declared in the Information Security Policy §1, which covers this application rather than the public website. It is named here because the commitment to scan is an organisational one, and describing only the half that falls inside one document’s boundary would understate what is actually done.

What is not scanned, stated so the scope of the commitment is unambiguous:

• Network and infrastructure. There are no servers to scan — the application runs on managed serverless infrastructure and the database is managed by its provider.
• Endpoints. There is one workstation rather than a fleet, protected by full-disk encryption and automatic operating system updates.
• Payment pages. The pages at billing.pxlpod.co and invoice.stripe.com are served and controlled by Stripe. They are not ours to scan, and scanning them would be neither meaningful nor permitted.

Every fix travels the same path as any other change: a branch, a production build and the projection fixtures run by a pre-push hook, then a push to the main branch. There is no expedited route that bypasses the build, because a patch that breaks the ledger is not an improvement on the vulnerability it fixed.

Where a fix cannot be applied within its window — no upstream patch exists, or the upgrade breaks compatibility — the mitigation, the reason, and the revised date are recorded in the repository.

The repository history is the log. Each security-relevant change records what was fixed, the severity, and when the alert arrived, so that compliance with §3 can be checked after the fact rather than asserted.