← WordPress Security for High-Stakes Sites
What do regulated organizations need from a WordPress site?
Four things: controlled access, a controlled change process, an audit trail, and protections that keep working as the site grows. These are properties of how the site is built and run. They do not come from a plugin, and they do not amount to a compliance certification.
When a regulator or an auditor asks how the site is protected, someone has to answer with something concrete, and these four properties are what they can point to.
How do you lock down the live site?
Remove live-site change access from everyone who does not need it, and disable code changes from the admin. The fewer accounts that can modify production, the fewer ways an accidental or unauthorized change gets in.
On one financial services platform, we set it up so that only two authorized administrators can log in, neither can modify the live site directly, and every account requires two-factor authentication. Changes reach the live site only through the release process described next. See a security and uptime program for a financial services platform.
The wp-config.php constants that disable file editing and installs from the admin enforce the lockdown; see hardening and managing WordPress updates safely.
What does a change process an auditor can follow look like?
A written path that every change takes, with a record at each step. Changes are made and checked away from the live site, approved by a named person, and released on a known cadence, and the live site cannot be changed outside that path.
For a reviewer, the useful output is the record. A process nobody wrote down gives a reviewer nothing to read, even if it was followed.
What should an audit trail capture?
At minimum: who logged in, what configuration changed, and what content was edited, each with enough context to reconstruct what happened. The case study for the same platform says: “Login activity, configuration changes, and content edits are all tracked with full context, providing the audit trail needed for both regulatory compliance and incident investigation.”
What a given regulator requires, and how long records must be kept, is for the organization’s compliance team and counsel to decide.
An audit trail serves two readers. A reviewer asks whether the controls operated as described. An investigator, after an incident, asks what happened and in what order. Keep the logs somewhere an attacker with access to the site cannot quietly rewrite, or they help neither.
How do protections keep working as the site grows?
New analytics tags, forms, and verification tools get added over time, and each one is a chance for a protection to break or be loosened to make room. The fix is a control on what is allowed to run on each page, rolled out with the method in hardening: report first, adjust, then enforce.
For a healthcare research organization that needed website security to fit strict data protection regulations, we built a custom security layer that controls what is allowed to run on each page. Per the case study, “Analytics, forms, and verification systems continue to function normally.” See automated security hardening for a healthcare research organization.
How do you keep evidence ready between reviews?
Keep the records as a by-product of running the site, not as a project before each review. If the release record, the access review, and the backup restore test are produced as part of normal operation, there is nothing to reconstruct.
The records a reviewer is most likely to ask for:
- Release records: what changed, who approved it, what was checked, and when it went live.
- Access reviews: who had access on a given date, and what was removed.
- Backup restore tests: when a restore was last tested and whether it worked.
- Logs: login activity, configuration changes, and content edits.
- Monitoring and patching reports: what was patched and what was found, on a regular schedule.
Ask the reviewer early which of these they want and in what form.
What should you ask a provider who maintains a regulated WordPress site?
Ask how the work is done, not only what is promised. The answers show whether controls are properties of the build or claims in a proposal.
- Who can change the live site, and how many accounts is that?
- How are updates tested, who approves a release, and what is the cadence?
- What is logged, where is it stored, and who can alter it?
- How are third-party services kept working when protections are added?
- What does the provider decline to claim, such as compliance with a named regulation?
A provider that guarantees compliance with a regulation for a site whose policies it does not own is promising something it cannot control.
Does 84EM certify compliance?
No. We build and run the controls: locked-down access, a controlled change process, logs, and page protections that keep third-party services working. Which regulations apply to an organization, and whether a given build meets them, is for that organization’s compliance team, counsel, and auditors to decide.
