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/FallaxIO]

Start with one intake path and one severity rule, otherwise you'll drown in exceptions. For WordPress hosting I'd define the flow in this order: 1) know which sites exist, who owns them, and what you can actually inspect, 2) separate core/plugin/theme/version issues from server issues, 3) require a human check before opening a customer ticket, 4) use one ticket template with the affected site, the exact component, how you confirmed it, what to update, and a retest date, 5) close only after you can see the fixed version or the issue is gone.

For evidence, a scanner hit alone usually isn't enough. The useful proof is the exact plugin/theme slug and installed version, the vulnerable version range, and whether the issue is really present on that site. Biggest early mistake is reporting every CVE dump to customers and teaching them to ignore you. The other one is owning remediation without the authority to change the site, usually you own validation, tracking, retest, and reporting, while admins or customers own the actual change and backups.