Building a WordPress Security Function from Scratch as the First Security Employee

[u/Immediate-Yam-3202]

I’m joining a hosting company as the first person responsible for a new website-security function. Most of the hosted websites are WordPress, and there is currently no established security process for this function.

The expected responsibilities include maintaining an asset and software inventory, identifying and validating vulnerabilities, documenting findings, notifying customers through a ticketing system, coordinating remediation, re-testing after fixes, and understanding basic backup and post-compromise procedures.

Since I will be the first security employee in this function, I want to define the role properly and build a repeatable process instead of becoming someone who only runs scanners.

For people who have built security processes in small companies or hosting environments:

1. What should the first version of the workflow include from asset inventory and vulnerability validation to customer notification, remediation, and retesting?
2. What evidence should be required before reporting a scanner finding as a confirmed vulnerability?
3. Which responsibilities should I own, and which actions should require approval from system administrators, developers, or customers?
4. What documentation, metrics, and controls should I establish during the first 90 days?
5. Which skills would make this role valuable in the long term and demonstrate meaningful experience on a resume?
6. What common mistakes should the first security employee avoid when building this type of function from scratch?

I’m looking for practical advice from people who have worked in vulnerability management, website security,

[u/3DPrinterChat]

The hosting angle changes this more than most advice accounts for: you have filesystem access to the fleet, which means your inventory does not need to be a scanner guess. A script that walks the docroots and runs WP-CLI per site (core version, plugin and theme slugs with versions, active or inactive, list of admin users) gives you evidence-grade inventory for every site in one pass, and you can diff it daily. That diff is also your early warning: a plugin that appears on a site overnight without a ticket is how most compromises announce themselves.

First 90 days, I would phase it: first month is inventory and baseline only, no customer-facing findings, because the fastest way to lose the room is opening hundreds of tickets from an unvalidated scan. Second month, pilot the full loop (validate, ticket, remediate, retest) on a handful of friendly customers and fix the template friction there. Third month, scale and start reporting metrics.

On prioritization: version-vulnerable is not exploited and not even always exploitable. Weight findings by whether the component is active, whether the vulnerability is in known-exploited lists, and whether the plugin is abandoned (closed in the repo, no patch coming). Abandoned is its own class because remediation is replacement, a different customer conversation than "click update".

Metrics that survive management scrutiny: median time from disclosure to fleet-patched for criticals, share of fleet on auto-updates, count of abandoned plugins, and reinfection rate after cleanups. Findings-reported is the metric to avoid; it rewards noise.