Your website is part of your security perimeter, even when a supplier manages it.

On 20 July 2026, New Zealand's National Cyber Security Centre published an alert for two actively exploited vulnerabilities affecting WordPress. The alert says affected versions include WordPress 6.9.0 through 6.9.4, WordPress 7.0.0 through 7.0.1, and the WordPress 7.1 beta release, with a narrower SQL injection issue affecting some WordPress 6.8 versions when one vulnerability is exploited by itself.

The WordPress project released WordPress 7.0.2 on 17 July 2026. Its release note says the update addresses one critical and one high severity security issue, with backported fixes for affected 6.9 and 6.8 versions.

For legal, financial, accounting, and advisory firms, the point is not to become WordPress specialists. The point is to know whether any website that carries your name, client enquiries, forms, landing pages, or recruitment content is covered by a clear security and supplier-governance process.

The current NZ signal

NCSC-NZ encourages New Zealand organisations using affected WordPress products to review the vendor advisory and apply remediation. That is a direct and timely prompt for firms to check the websites and web suppliers that sit just outside everyday Microsoft 365 management.

A website compromise may not start inside your document system, but it can still affect reputation, client trust, form data, analytics, email deliverability, redirects, and incident workload. It can also expose gaps in who is responsible for urgent supplier-led technology work.

1. Confirm what you actually run

Start with a plain inventory. List the main website, old websites, recruitment pages, campaign landing pages, client portals, payment pages, microsites, and any pages hosted by marketing or software suppliers.

For each one, record the platform, hosting provider, domain owner, DNS provider, administrator accounts, agency contact, and business owner inside the firm. If the answer is "the web company handles it", ask for the platform and update evidence rather than broad reassurance.

2. Ask for update evidence

A useful response should say whether WordPress is present, which version is running, whether affected versions applied, what update was completed, when it was completed, who completed it, and whether plugins or themes needed separate action.

That evidence does not need to be complicated. A dated supplier note, update log, screenshot, ticket, or change record is often enough to show the issue was checked and the outcome was recorded.

3. Review administrator access and supplier accounts

Website administrator accounts are often created for staff, agencies, SEO contractors, developers, plugin vendors, and past suppliers. Over time, that access can become wider than anyone intended.

Check who can sign in, whether MFA is enabled where available, whether shared accounts exist, whether old supplier access has been removed, and whether emergency access is documented. Treat website access as part of the firm's broader access governance.

4. Check backups, logs, and recovery notes

If a website has to be restored, isolated, or rebuilt, the firm needs more than a promise that backups exist. Confirm where backups are stored, how often they run, when they were last tested, and who can restore them.

Logs also matter. They can help identify suspicious changes, unknown administrator activity, unusual redirects, or unexpected file changes. Make sure the supplier knows what logs are available and how long they are retained.

5. Look at forms, redirects, and connected services

Many professional services websites collect enquiry details, CVs, event registrations, newsletter sign-ups, or booking requests. Some send data into email, CRM tools, spreadsheets, marketing platforms, or practice-management workflows.

Review where form submissions go, who receives them, whether sensitive information is being requested unnecessarily, and whether redirects or embedded scripts have changed. Keep the check practical: the goal is to understand the path from website visitor to internal system.

6. Keep AI and marketing tools in scope

Website tools increasingly connect to AI chat, analytics, lead scoring, content assistants, and automation platforms. Before connecting those tools, confirm who approved them, what data they can see, and whether they can alter public-facing content or collect user information.

Safe AI adoption is easier when the underlying website, account access, and content workflow are already tidy.

What should firm leaders ask this week?

Use these questions to start a focused conversation with your internal team, web agency, or IT provider:

• Do any of our websites, landing pages, portals, or campaign pages use WordPress?
• If yes, which WordPress version is running and who is responsible for updates?
• Has the 20 July 2026 NCSC-NZ alert been checked against our websites?
• Are plugins, themes, and hosting components reviewed as part of the same process?
• Who has administrator access, and is supplier access still current?
• Are backups running, and has a restore been tested recently?
• Where do form submissions go, and are we collecting only what we need?
• What is the first-hour response if the website is defaced, redirected, or taken offline?

If the answers are unclear, start with a narrow website governance review. Inventory, update evidence, access, backups, logs, connected forms, and response ownership are enough to make the risk visible.

Common questions

Is this article legal, financial, regulatory, privacy, or compliance advice?

No. It is general technology-risk information for professional services firms. Firms should take appropriate professional advice for their own legal, financial, regulatory, privacy, or compliance obligations.

Does every professional services firm use WordPress?

No. The practical first step is to confirm whether the firm, a supplier, or a campaign microsite uses WordPress, and whether it is covered by a clear update, backup, and access process.

What should firm leaders ask first?

Ask who owns each website, which platform it runs on, whether WordPress updates have been applied, who has administrator access, and where backup and incident records are kept.

Source note

Compliance note: This article is general information only. It is technology-risk and cybersecurity governance guidance, not legal advice, not financial advice, not regulatory advice, not privacy advice, not product assurance, and not compliance advice. Firms should take appropriate professional advice for their own obligations and circumstances.