Governance and control across a large WordPress estate
Organisations running dozens or hundreds of WordPress sites across brands, regions and business units need access control, auditability and evidence, not just a dashboard.
Free during early access. No credit card required.
Large estates fail on governance before they fail on tooling
An organisation with a hundred and forty WordPress sites rarely has a technology problem. It has a coordination problem: nobody has a complete inventory, sites were built by agencies who have since moved on, credentials are shared informally, and no single person can say with confidence which sites hold personal data.
The consequences surface during audits and incidents. Security review asks which sites run an end-of-life PHP version and the answer takes two weeks to assemble. A vulnerability is disclosed in a widely used plugin and nobody can say how many properties are affected. A contractor leaves and their access persists on sites nobody thought to check.
Consolidating management is only half the answer. The other half is that access, actions and evidence must be governed: who can do what, on which sites, with what approval, recorded in a way that survives scrutiny.
What governance requires
- Complete, continuously updated inventory of every property
- Role-based access scoped to specific sites and specific actions
- Approval workflows for changes to production properties
- Immutable audit trail of who did what and when
- Single sign-on integrated with your identity provider
- Data-processing terms and documented sub-processors
- Evidence exports that satisfy internal audit
How control is structured
Permissions are scoped along two axes: which sites a person can reach, and which actions they can take there.
Site-scoped access
Users and teams are granted access to specific sites, groups or business units. Someone responsible for one regional brand cannot see or act on properties belonging to another.
Action-scoped permissions
Separately from site scope, roles determine what a person can do: view only, run updates, restore backups, change policies, manage billing or manage users. Read access does not imply write access.
Approval workflows
Changes to designated production properties can require approval before execution. The requester and approver are both recorded, which is usually what internal audit is actually asking for.
Audit and evidence
Every action is logged with actor, timestamp, target and outcome. Logs are exportable, and retention is configurable to match your records policy.
Enterprise capabilities
SSO and provisioning
Integrate with your identity provider so access follows joiners, movers and leavers automatically rather than manually.
Granular permissions
Site-scoped and action-scoped roles, so access is granted narrowly rather than by convenience.
Immutable audit trail
A complete record of every action with actor and timestamp, exportable for audit and retained per your policy.
Approval workflows
Required approval before changes to designated production properties, with both parties recorded.
Multi-brand structure
Business units, regions and brands modelled as separate scopes within one estate view.
Data-processing terms
A DPA, documented sub-processors and defined data handling for procurement and legal review.
Inventory is the foundation everything else sits on
Every enterprise engagement starts the same way: discovering that the site list is wrong. There are properties nobody remembered, properties that were decommissioned but are still serving, and properties running software versions that predate the current team.
Building an accurate, continuously updated inventory is therefore the first deliverable rather than a side effect. Once it exists, the questions that previously took weeks become instant: which properties run this plugin, which are behind on PHP, which have certificates expiring this quarter, which have administrator accounts belonging to people who have left.
That inventory is also what makes risk arguable internally. Saying that fourteen properties carry a critical unpatched vulnerability, three of which process transactions, is a very different conversation from saying that WordPress security ought to be improved.
Common findings in a first estate audit
- Properties absent from the official inventory entirely
- Administrator accounts belonging to departed staff or former agencies
- End-of-life PHP versions on production properties
- Backups configured but never successfully restored
- Certificates renewing manually with no owner assigned
Enterprise questions
Yes, via SAML and OIDC with your identity provider, including automated provisioning and deprovisioning so access follows your joiner, mover and leaver processes rather than depending on someone remembering.
Yes. Permissions are scoped by site and by action independently, and designated properties can require approval before any change executes. Requester and approver are both recorded in the audit trail.
A data-processing agreement is available and our sub-processors are documented. See the DPA and security pages, and raise any specific procurement requirements early rather than after a trial.
Yes, in machine-readable format, with configurable retention. Audit evidence that cannot leave the vendor's system is not usually acceptable to internal audit, so exportability is a design requirement rather than a feature.
In phases. Discovery and inventory first, because the site list is usually incomplete. Then connection in batches by business unit, then permissions and approval structure, then policies. Attempting all of it in one pass is how large rollouts stall.
Bring the estate under control
Start with an accurate inventory of what you actually run, then layer access control, approvals and evidence on top.
Free during early access. No credit card required.