Essential Eight and Web Apps: A Practical Checklist for SMBs

Why Essential Eight matters for your website

The Australian Cyber Security Centre publishes the Essential Eight as the baseline mitigation strategies for cyber incidents. It was written with corporate networks in mind, which is why most SMBs read it once, decide it does not apply, and move on.

That reading is wrong. Six of the eight controls map cleanly onto the web stack almost every Australian business runs. A Wordpress site, a Shopify store, a custom Laravel or Node app behind Cloudflare, or some mix. Since the 2024 Privacy Act reforms shifted the regulatory bar on what counts as reasonable security, the Essential Eight is increasingly the implicit yardstick the OAIC and insurers use.

This is the version we work through with clients when we are asked to uplift a small web stack to a defensible baseline.

Control 1: Patch applications

The single most common root cause of compromise we see in small business web hosting is an unpatched CMS or plugin. The ACSC target for internet-facing applications is patching within 48 hours of a critical vulnerability being published.

For a Wordpress site, that means enabling auto-updates for core, plugins and themes, and removing anything you do not actively use. A typical site we audit has 18 plugins installed and uses 9. The other 9 are attack surface.

For Shopify you are largely covered for the platform itself, but the apps you install are not. Review them quarterly, delete the ones you have stopped using, and check the remaining ones are still being maintained by their developers.

For custom stacks, automated dependency scanning in CI is non-negotiable. We default to Dependabot or Renovate on every client repo, with security patches auto-merged after CI passes and minor versions batched weekly.

Control 2: Patch operating systems

If you run your own VPS or dedicated server, OS patching is your job. The 48-hour window applies here too for critical CVEs.

The honest advice for most SMBs: stop running your own servers. Push Wordpress onto a managed host that handles patching. Run custom apps on a platform layer (Fly, Render, Vercel, AWS Lightsail with managed updates, or equivalent) where the underlying OS is someone else's problem. The time savings and the reduction in risk almost always outweigh the hosting cost difference.

Control 3: Multi-factor authentication

MFA on every admin login. This is the cheapest, highest-ROI control in the entire Essential Eight and it is still missing from the majority of small business sites we audit.

What actually needs MFA

• CMS admin accounts (Wordpress wp-admin, Shopify admin, Craft control panel, custom admin dashboards)
• Hosting control panels (cPanel, Plesk, AWS, Cloudflare, Netlify)
• DNS registrar (a compromised registrar ends the business, not just the website)
• Email accounts used for password resets
• GitHub or GitLab for the codebase
• Payment processor dashboards (Stripe, Square, Tyro)
• Marketing platforms holding customer data (Mailchimp, HubSpot, ActiveCampaign)

How to enforce it

App-based TOTP using Authy, 1Password or Google Authenticator is the practical default. SMS MFA is better than nothing but is vulnerable to SIM-swap attacks and should be treated as a fallback rather than a primary factor. For higher-risk accounts (the registrar, the payment processor, the production AWS root) use hardware keys such as YubiKeys.

Wordpress needs a plugin (Wordfence Login Security or Two Factor are both fine). Shopify has built-in MFA enabled per user. For custom builds, add MFA at the framework level rather than reinventing it. Almost every modern auth library supports TOTP out of the box.

Control 4: Restrict administrative privileges

The principle: nobody has admin rights unless they are actively doing admin work, and admin accounts are separate from daily-use accounts.

For Wordpress, most clients we audit have five or six people with Administrator role when they should have Editor or Author. Administrator can install plugins and execute PHP. That is a root-equivalent capability, not an editorial one. Audit your user list quarterly, demote aggressively, and delete accounts for people who have left.

For Shopify, use the granular staff permissions. A marketing manager does not need access to financial reports. A copywriter does not need access to orders.

For custom apps, enforce role-based access control from day one. Build a clear distinction between user, staff, admin and owner, and log every privileged action to an audit trail that a non-admin cannot delete.

Control 5: Configure Microsoft Office macro settings

Not directly relevant to your website, but mentioned because clients ask. If you are on Microsoft 365, block macros from the internet by default at the tenant level. Web stack teams rarely touch this control, but your business email is part of the same threat surface as the site.

Control 6: User application hardening

For web apps this translates into the browser-facing hardening you ship in your HTTP headers. The baseline we deploy on every client site:

• Content-Security-Policy restricting script sources to your own domain and explicit third parties
• Strict-Transport-Security with a long max-age and includeSubDomains
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy locking down camera, microphone, geolocation for origins that do not need them

On Wordpress, a plugin like HTTP Headers handles this. On Cloudflare you can set most of them as Transform Rules without touching the origin. For custom apps, middleware in your framework of choice.

Secure cookies are also part of this control. Set Secure, HttpOnly, and SameSite=Lax (or Strict where you can) on every session cookie.

Control 7: Regular backups

The ACSC target is daily backups, stored offline or with access controls that an attacker cannot trivially bypass, and regularly tested by restore.

For Wordpress, UpdraftPlus or BlogVault running daily to an off-site bucket (S3, Backblaze B2 or Wasabi) is the standard setup. Retain 30 days. The detail most people miss: test the restore. A backup that has never been successfully restored is not a backup.

Shopify handles platform data backups internally, but your theme customisations, app configurations and exported customer lists still need your own backup schedule.

For custom apps, automated nightly database snapshots plus point-in-time recovery where your database supports it. Store snapshots in a separate account or tenant. An attacker with access to your production AWS should not be able to delete your backups.

Control 8: Application control

On a corporate endpoint, application control means approved-executable lists. On a web server, the equivalent is locking down what code can run where.

For PHP-based sites (Wordpress, Magento, Craft), disable PHP execution in upload directories. For static-first builds like ours, the attack surface shrinks dramatically because the public site has no server-side execution to compromise. For APIs, a Web Application Firewall (Cloudflare WAF, AWS WAF or equivalent) in front of the origin provides the practical layer of request-level application control most SMBs can realistically deploy.

Putting it together

You do not need to reach Maturity Level 3 on every control. For most Aussie SMBs, Maturity Level 1 across all eight controls is the right target. Consistent, documented and measurable. It covers the overwhelming majority of actual compromises we see in the wild.

If you would like us to audit your current stack against the Essential Eight and produce a prioritised uplift plan, reach out and we will give you a clear assessment with realistic effort estimates.