When one client gets hacked, the question your team should ask is not only “how do we clean this site” but “how many others share the same vulnerable plugin.” This playbook covers both the single-site recovery and the fleet-wide containment that keeps it from happening again.

The instinct is to start deleting suspicious files. Resist it. The first hour is about containment and evidence, because a hasty cleanup can destroy the forensic trail you need to find the entry point — which means you’ll clean the site and get reinfected within days.

1. Take the site offline or into maintenance mode to protect visitors and stop active data theft.
2. Snapshot the compromised state — files and database — before changing anything, for forensics.
3. Rotate all credentials: admin users, database, hosting, SFTP, and any API keys.
4. Check whether the same host account or shared credentials touch other client sites — assume lateral movement until proven otherwise.
5. Notify the client with facts: what you know, what you’re doing, and the expected timeline.

You can’t clean what you can’t see, and you can’t prevent reinfection until you know how they got in. Most WordPress compromises trace back to a vulnerable or nulled plugin or theme, weak admin credentials, or an out-of-date core. Work both ends: find the malicious code, and find the door it walked through.

• Compare core, plugin, and theme files against clean copies from the official repositories to spot injected code.
• Scan for common indicators: obfuscated PHP, base64-encoded payloads, unfamiliar admin users, and modified .htaccess or wp-config.php.
• Review access and server logs around the first sign of compromise to find the exploited endpoint.
• Check Google Search Console for security warnings and blacklist status so you know the external impact.

You have two recovery paths. Restoring from a known-good pre-infection backup is fastest and cleanest when you have one and the compromise is recent. Manual cleaning is necessary when the infection predates your backups or the site has changed too much to roll back. Often the right move is a hybrid: restore core and plugins from clean sources, keep the current database after scanning it, and re-merge legitimate recent content.

• Restore path: roll back to the last verified clean backup, then immediately patch the vulnerability that caused the breach — otherwise you restore the hole too.
• Clean path: replace core/plugins/themes with fresh official copies, remove injected code, delete rogue users and unknown files in uploads.
• Always: update everything to current versions, regenerate salts, and force a password reset for all users.
• Verify: rescan, confirm the site is clean, then request review to clear any search-engine blacklist.

This is exactly why a tested backup and rollback discipline pays off: a clean pre-update or pre-infection snapshot turns a multi-day cleanup into a controlled restore. Recovery is only as fast as your last verified backup.

How you communicate during a hack often matters more to the relationship than the cleanup itself. Clients don’t expect you to guarantee a site never gets attacked; they expect you to handle it calmly and keep them informed. Silence reads as incompetence even when your team is working flat out behind the scenes.

• Lead with facts, not blame. State what was compromised, what data may be affected, and what you’re doing about it.
• Set a realistic timeline and update against it, even if the update is “still working, next check-in at X.”
• Flag any data-breach obligations early — if customer data was exposed, the client may have notification duties under privacy law.
• Close with a hardening summary so the client sees the breach made their site stronger, not just patched.

After the site is clean and the entry point is closed, run a short post-incident review while it’s fresh. Document the vulnerability, the dwell time, the cleanup steps, and what would have caught it sooner. That record is what turns a painful incident into a permanent improvement to your security baseline — and it’s the raw material for the fleet-wide hardening below.

One hacked site is an incident; the same vulnerable plugin on twenty client sites is a crisis waiting its turn. The moment you know the entry point, the priority shifts from one site to the fleet. This is the part single-site malware guides never cover, and it’s where agencies either contain the damage or spend the next month firefighting.

• Inventory which other client sites run the same vulnerable plugin, theme, or core version.
• Patch or disable the affected component across all of them as a priority sweep.
• Run a security audit across the fleet to catch sites already compromised but not yet noticed.
• Harden the baseline: remove nulled plugins, enforce strong admin auth, and standardize the update cadence.

Doing this sweep by hand across 25 to 50 sites is slow, and slow is how reinfection wins. Running audits and remediation through a structured execution layer is what makes fleet-wide containment practical. WPOS is an AI-native operating system for WordPress — the independent system that runs WordPress through a structured execution layer, working across any host and any builder rather than locking you to one stack. Its application-layer operate capability today includes automated audits and ongoing content management, which is precisely the work of scanning the fleet, identifying exposed sites, and pushing remediation.

The scale that work runs at is concrete: 286 connected sites, more than 70 active users, and over 20,000 agent tool-executions per month across the fleet. To be precise on the seam, the deeper host-layer capabilities — self-healing infrastructure and automatic rollback at the server level — are on the roadmap, not delivered today. Containment still depends on your tested backups and a human-directed remediation process; the execution layer is what lets you run that process across the whole fleet at once. If you want to put that to work on your own sites, the WPOS beta is the way in, and you can review the supported tooling on the connectors page.

Single-site backup advice doesn’t survive contact with a fleet. What works for one site becomes a liability when you’re managing dozens with different hosts, plugins, and update cadences. This guide lays out a backup and rollback strategy built for that reality.

On a single site, a backup plugin and a weekly snapshot are enough. Across a fleet, the failure modes multiply: one site’s backup silently stops running, another’s offsite storage fills up, a third can’t be restored because nobody ever tested it. The risk isn’t that you have no backups — it’s that you have inconsistent ones and no way to know which sites are actually protected.

The strategic shift is from “each site has backups” to “the fleet has a backup policy that is uniformly enforced and continuously verified.” Uniformity is what lets you restore any site the same way under pressure, instead of relearning each client’s setup during an outage.

Define one policy and apply it to every site, with overrides only where a site genuinely needs them. The classic 3-2-1 rule — three copies, on two media types, with one offsite — is the right backbone. Translate it into concrete frequencies and retention windows so there’s nothing to interpret.

• Always keep an offsite copy — separate from the host. If the host account is compromised or suspended, host-only backups disappear with it.
• Take a pre-update snapshot before every core, plugin, or theme update. This is your fastest rollback point.
• Back up the database and files separately so you can restore content without overwriting code, and vice versa.
• Encrypt offsite archives and limit access — a backup is a full copy of the client’s data.

A backup you’ve never restored is a hypothesis. The real deliverable is a rollback runbook: a documented, rehearsed sequence anyone on your team can follow to bring a site back to a known-good state. The most common rollback trigger isn’t a hack — it’s a routine update that breaks layout or checkout.

1. Detect the regression (monitoring alert, client report, or post-update check).
2. Identify the last known-good snapshot — ideally the pre-update one.
3. Restore to staging first, verify the site renders and functions, then promote.
4. For a live commerce site, capture orders placed since the snapshot so you don’t lose transactions on restore.
5. Log the incident: what broke, which version, and the fix, so the next update avoids it.

Staged updates with a rollback point are the difference between a five-minute fix and a panicked evening. Apply updates to a copy, check, then promote — and keep the pre-update snapshot until you’re confident the change is clean. Define the rollback decision threshold in advance, too: if a regression isn’t resolved within a set window, roll back first and diagnose on staging rather than debugging on a live client site while traffic suffers. A clear threshold removes hesitation in the moment, which is exactly when teams tend to waste time hoping a broken page will somehow fix itself.

The metric that matters is restore success rate, not backup count. Schedule a rolling restore test so that over each quarter every site in the fleet has been restored to staging at least once and confirmed working. This is the single practice that separates agencies that recover quickly from those that discover their backups were corrupt at the worst possible moment.

• Rotate restore tests so a few sites are verified each week rather than all at once.
• Confirm the restored site renders, logs in, and — for commerce — completes a test checkout.
• Track two numbers per site: time-to-restore and last-verified-restore date.
• Alert on missed backups immediately; a silent failure is worse than a visible one.

The quiet killer of fleet backups is drift. A new site gets onboarded but never added to the schedule. A plugin change breaks a backup job and nobody notices for weeks. A client migrates hosts and the offsite destination silently stops receiving archives. None of these throw an alarm on their own, and each one means a site you believe is protected isn’t.

The fix is a single source of truth: a backup inventory that lists every site, its schedule, its offsite destination, its last successful backup, and its last verified restore. Review it on a fixed cadence so a gap is a visible row, not a surprise during an incident. Treat onboarding a new client site as incomplete until it appears in that inventory with a confirmed first backup.

• Every site appears exactly once, with its policy tier and host noted.
• Last-successful-backup and last-verified-restore dates are visible at a glance.
• Offsite destination and retention window are recorded per site.
• A weekly review flags any site whose last backup is older than its schedule allows.

The hard part at fleet scale is consistency: confirming every site is actually backed up, applying updates safely, and keeping the pre-update snapshots organized. Doing this by hand across dozens of sites is where the policy quietly decays. The answer is to run backup, update, and verification as a structured, repeatable process rather than per-site manual work.

This is where the architecture of your tooling matters. WPOS is an AI-native operating system for WordPress — the independent system that runs WordPress through a structured execution layer, working across any host and any builder rather than locking you into one. Because it isn’t tied to a single host, your backup and rollback policy can stay uniform even when clients sit on different infrastructure, and it integrates with the backup, security, and staging tools you already use through its connectors.

What’s live today operates at the application layer: automated audits, content management, and store operations across the fleet — useful for catching regressions and verifying site health after updates. Across the WPOS fleet that’s run roughly 300 updates in a recent 90-day window over 286 connected sites. Worth being precise on the seam: deeper host-layer automation such as self-healing infrastructure and fully automatic update rollbacks is on the roadmap, not a delivered capability today. Your rollback process should still rest on tested, offsite backups and a human-reviewed promote step.

When an agency runs 25 to 50 sites under retainer, “maintenance” is not one job. It is a stack of recurring work that quietly eats senior hours: checking that backups ran, confirming forms still submit, scanning for broken links and layout shifts, keeping content fresh, watching for plugin conflicts after updates, and answering the client question that always comes — “is my site OK?” Each task is small. Multiplied across a fleet, they become the reason your team cannot take on more accounts without hiring.

The useful way to think about AI maintenance is by layer. The application layer is everything reachable from inside wp-admin: pages, posts, products, media, settings, the audit surface a logged-in editor can see. The host and infrastructure layer is everything underneath: PHP versions, server config, core and plugin update execution, file integrity, rollbacks. AI agents handle these two layers on very different timelines, and conflating them is how vendors overpromise.

The maintenance work running in production right now happens at the application layer, executed through a structured execution layer that turns agent intent into logged, reversible actions inside WordPress. This is not a chatbot that suggests edits. It is agents performing tool-executions against real sites, with every step recorded. Across the current fleet that looks like 286 connected sites, 70+ active users, and more than 20,000 agent tool-executions a month.

The word “structured” is the part agencies miss. An agent does not freely poke at a site; it acts through a defined set of tools — read this page, update this field, create this block, publish this product — and each call is a discrete, named operation with inputs, outputs, and a record. That is why the work is reviewable instead of mysterious. For a fleet, that structure is what makes delegation safe at volume: you are not trusting a model’s vibe across 40 sites, you are watching 20,000+ explicit, logged operations a month and intervening only on the exceptions.

Automated audits

Agents crawl a site’s editable surface on a schedule and surface what a human reviewer would flag: missing meta, thin or orphaned pages, broken internal links, accessibility gaps, and content that has gone stale. Instead of one person clicking through 40 sites every month, the audit runs continuously and the team triages exceptions. This is the most reliable form of AI maintenance today: it reads and reports, and any change lands as a tracked edit you can review.

Concretely, a scheduled audit pass inside wp-admin covers a predictable checklist across every connected site:

• On-page SEO gaps: missing or duplicate titles and meta descriptions, missing alt text, heading-structure issues.
• Link integrity: broken internal links, orphaned pages with no inbound links, redirect chains worth cleaning up.
• Content freshness: pages that have not been touched in months, outdated year references, stale pricing or copy.
• Accessibility and structure: low-contrast or unlabeled elements a logged-in editor can see and correct.

The audit’s value is that it never skips a site because the month got busy. It runs the same checklist on site one and site forty, and human time goes only to the handful of items that need a decision.

Ongoing content management

Keeping content current is maintenance, not just production. Agents refresh outdated copy, build and place new pages, assemble reusable sections, and keep on-page SEO aligned across a fleet. In practice the current fleet ships roughly 800+ pages a month and around 380 widgets a month this way — work that previously required a content team to babysit each site individually.

Store and e-commerce operations

For WooCommerce clients, application-layer maintenance includes catalog hygiene: updating product data, fixing descriptions, adjusting categories, and catching listings that have drifted out of sync. These are exactly the small, repetitive store tasks that pile up between client check-ins, and they run as logged agent actions rather than ad-hoc manual edits.

WPOS connects to sites regardless of host or builder — it is the only WordPress AI system that is both independent (locked to no builder, no host) and operates through a structured execution layer. That independence is what makes fleet-wide maintenance feasible: you are not migrating clients onto one stack to get automation. See the range of supported connectors and integrations for how sites attach.

Here is the seam every agency lead needs to be honest about. The deeper, server-side maintenance that people often imagine when they hear “AI maintenance” is on the roadmap — it is where this is going, not what you can rely on today. Treat the following as planned capability, not a live SLA:

• Unattended core and plugin updates with automatic rollback when something breaks.
• Self-healing across hosts — detecting a fault and remediating it without a human in the loop.
• Session-replay monitoring to catch real-user breakage as it happens.
• Proactive delivery and infrastructure-level maintenance scheduled and executed end to end by agents.

For now, updates remain a supervised activity. The platform helps you stay on top of them — roughly 300 updates were handled across the fleet in a recent 90-day window — but the unattended, auto-rollback version of that workflow is roadmap, not a guarantee you should write into a contract today.

You do not have to wait for the host-layer roadmap to get value. The practical move is to automate the application-layer work that is already reliable and keep humans on the infrastructure decisions. A workable sequence:

1. Connect your fleet and let scheduled audits run, so exceptions surface instead of being hunted manually.
2. Route content refreshes and page builds through agents, with a human approving anything client-facing.
3. Hand store hygiene to agents on commerce accounts; review the logged changes weekly.
4. Keep core and plugin updates supervised — use the platform to track them, but have an engineer confirm the risky ones.
5. Set client expectations on the same seam: tell them what is automated today and what your team still does by hand.

Done this way, AI maintenance lets you ship more and maintain more without growing headcount. WordPress itself is fine; the slower-moving agencies are simply being out-executed by ones that have automated the repetitive layer. You can see how teams structure this in the WPOS customer cases.

The today-vs-roadmap seam belongs in your maintenance SLA, not just an internal note — otherwise you will eventually promise something the platform does not yet do unattended. Write commitments around the application-layer work that genuinely runs on its own, and keep host-layer work described as supervised.

• Commit confidently: continuous audits, content freshness and on-page SEO upkeep, store catalog hygiene, and a reviewable log of every change. These are live and auditable today.
• Commit with a human in the loop: core and plugin updates. Position these as monitored and applied with oversight — roughly 300 updates were handled across the fleet in a recent 90-day window — not as unattended, auto-rolled-back patching.
• Do not commit yet: self-healing, session-replay monitoring, and fully autonomous delivery. Mention them as roadmap if a client asks where things are heading, never as a current guarantee.

A practical client update reflects the same split. A monthly maintenance note can show clients the audit findings and content changes the agents made, list the updates your team supervised, and flag anything escalated for a human decision. Because every agent action is a logged tool-execution, you can attach evidence to that report instead of asking the client to take your word for it. That transparency is often what justifies the retainer in the first place — the client sees ongoing, documented work rather than a quiet month followed by a surprise bill.

The terms get used interchangeably, but the distinction matters for how you price, scope, and defend margin. A maintenance plan is defined by tasks: run the updates, take the backups, patch the holes. A care plan is defined by outcomes: the site stays fast, secure, current, and aligned with what the client is trying to achieve — and someone is actively watching, not just reacting to tickets.

Put differently: maintenance is something you do to a site. Care is something you provide for a client. That shift from task-list to outcome is the entire commercial case for charging more.

Here is how the scope typically breaks down. The maintenance column is table stakes; the care column is where differentiation and margin live.

The pattern is clear: maintenance answers “is the site working?” while care answers “is the site working for the client, and getting better?” Every row in the care column is a reason the client stays and a lever you can price against.

Pricing tracks the scope difference. Maintenance plans tend to be commoditized — clients comparison-shop them against $30/month plugin bundles, so margins are thin and churn is high. Care plans escape that comparison because no plugin bundle includes a human who knows the client’s business.

Typical structure

• Maintenance: flat monthly fee per site, narrow scope, anything extra billed hourly. Low price, low margin, high volume needed.
• Care, tiered: good / better / best tiers that scale by included hours, SLA, and reporting depth. Higher price, healthier margin, far stickier.
• Care, value-based: priced against the revenue the site generates rather than the hours you spend. The strongest margin, reserved for clients where the site is clearly business-critical.

The trap most agencies fall into is selling a “care plan” at maintenance-plan prices — promising proactive attention and unlimited small edits, then absorbing the cost when clients take them up on it. The fix is a clear, scoped monthly allowance and a disciplined upsell path for everything beyond it.

Recurring revenue is what makes an agency valuable and predictable. Care plans produce more of it per client, churn less, and create natural touchpoints for additional project work. The catch is in that last clause: if you can deliver them.

Care plans are labor-intensive. Proactive monitoring, content edits, performance tuning, and reporting all consume senior time — and that time is exactly the resource the WordPress talent market makes scarce and expensive. The math that kills care plans is simple: the more you sell, the more skilled hours you owe, and the headcount lever to supply those hours is jammed. Many agencies cap care-plan growth not because demand is missing but because they cannot staff it.

This is the structural problem an AI-native operating system for WordPress is designed to solve: breaking the link between delivery capacity and headcount. WPOS puts AI agents to work inside wp-admin through a structured execution layer, handling the application-layer operate work — automated audits, ongoing content management, and store operations — that consumes most of a care plan’s hours. It does this across any host and any builder, so it fits a mixed fleet rather than forcing one.

That independence is the differentiator. WPOS is the only WordPress AI system that is both independent — locked to no builder, no host — and operates through a structured execution layer rather than acting on the raw site directly. For an agency, that means you can grow care-plan revenue without the scope of edits, audits, and content work scaling one-for-one with hires. To set expectations on what that looks like in practice: across the WPOS base, agents currently produce 800+ pages and around 380 widgets per month and run 20,000+ tool-executions monthly. Host-layer features like auto-rollback and self-healing are on the roadmap; the application-layer care work is what you can offload today.

Most clients do not arrive knowing the difference, so the framing you use shapes what they buy. Lead with the outcome, not the task list. A client does not want “monthly plugin updates”; they want a site that does not embarrass them, does not get hacked, and keeps earning. Sell maintenance as insurance and care as a partnership, and the price gap explains itself.

Language that moves clients up a tier

• Maintenance framing: “We keep your site safe, backed up, and current so it never goes down on you.”
• Care framing: “We watch your site proactively, make the changes you need each month, keep it fast for your customers, and tell you in plain English how it’s performing.”
• The upgrade nudge: when a maintenance client asks for “just one small edit” for the third time, that is the moment to show them how a care tier would already include it.

The recurring small-edit request is the single most reliable upgrade signal in the business. Track it. Clients who repeatedly ask for out-of-scope changes on a maintenance plan are telling you they want a care plan; they just have not been offered the right one.

• Lead with care plans as your flagship recurring offer — that is where margin and retention live.
• Keep a maintenance tier as an entry point for price-sensitive clients and a clear upgrade path into care.
• Scope the included allowance precisely so “proactive care” never quietly becomes “unlimited free work.”
• Automate the application-layer delivery so a bigger care book does not require a proportionally bigger team.

WordPress isn’t dying — but agencies that still deliver care plans entirely by hand are being out-executed by those who automate the repetitive layer and reserve their senior people for strategy and client relationships. The agencies already running on this model are visible in the WPOS customer cases, where the common thread is recurring revenue growing faster than the team behind it.

The strategic takeaway is that the care-versus-maintenance question is no longer only about scope and pricing — it is about delivery capacity. Maintenance plans are easy to staff because the work is narrow and predictable. Care plans are hard to staff because the work is broad, recurring, and senior. Whichever you make your flagship, the constraint that decides how big it can grow is how much of the delivery you can take off human hands without dropping quality.

A site audit answers “is this one site healthy right now?” A care plan audit answers a harder, recurring question: “are we delivering what we sell, across every retainer, every month?” The first is a project. The second is fleet operations — and it is where most agencies quietly leak margin.

When you manage 40, 80, or 200 sites on care plans, the failure mode is rarely a dramatic hack. It is drift: a plugin two major versions behind on one site, a backup that silently stopped running on another, a Core Web Vitals score that slid into the red without anyone noticing. None of it shows up until the client emails — and by then you are doing unbilled emergency work that erodes the exact margin the care plan was supposed to protect.

The audit’s job is to convert that invisible drift into a scored, comparable snapshot you can run on schedule. WordPress isn’t dying, but it is being out-executed by teams who treat maintenance as a measured process instead of a reactive chore. A repeatable audit is how you stay on the right side of that line.

Work through these six categories on every site. Score each line pass, warn, or fail, and roll the per-site results into a fleet view. The categories below are the application-layer health signals you can verify today.

1. Security and access

• Admin user count reviewed; no stale or shared logins.
• Two-factor enforced on all administrator accounts.
• SSL valid and not expiring within 30 days.
• No abandoned plugins (no update in 12+ months) installed and active.
• File-integrity / malware scan run clean in the last 7 days.

2. Updates and compatibility

• WordPress Core on a currently supported version.
• PHP version supported and not approaching end-of-life.
• No plugin or theme more than one major version behind.
• Premium plugin licenses active so security patches keep flowing.
• A documented update cadence with a record of the last run.

3. Backups and recovery

• Automated backups running on schedule and confirmed in the last 24–48 hours.
• Backups stored off-server (not only on the host).
• At least one restore tested in the last quarter — a backup you have never restored is a hope, not a plan.
• Retention window matches what the care plan tier promises.

4. Performance and Core Web Vitals

• Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift checked against Google’s thresholds.
• Caching active and not broken by a recent change.
• Image sizes and database overhead reviewed for bloat.
• Uptime over the period meets the SLA you sold.

5. SEO and content health

• No accidental “discourage search engines” flag set.
• Broken internal links and 404s identified.
• Sitemap valid and submitted; indexation roughly matches expectations.
• Metadata present on key templates and high-value pages.

6. Reporting and billing alignment

• Work logged this period matches the plan tier the client pays for.
• Out-of-scope requests flagged for upsell rather than absorbed.
• A client-facing summary exists for each site.

Per-site checklists are useless if you cannot compare sites at a glance. Convert each category into a simple score, then rank the fleet so attention flows to the sites that need it.

Roll the per-site colors into a single fleet dashboard and a clear pattern appears: a small number of red sites usually consume most of your unplanned support hours. Fixing those first is the fastest way to recover margin — and it gives delivery leadership a defensible number to put against headcount conversations.

A six-category checklist takes 20–40 minutes per site to do honestly. Across 60 sites, that is a full work-week of senior time every quarter — and the moment it gets busy, the audit is the first thing skipped. The audit only protects margin if it actually runs, which means the bottleneck is execution capacity, not checklist design.

This is the link that an AI-native operating system for WordPress is built to break: delivery and maintenance capacity should not be capped by how many people you can hire. WPOS puts AI agents to work inside wp-admin and runs them through a structured execution layer — automated audits, ongoing content management, and store operations across any host and any builder, today, at the application layer.

That neutrality is the wedge. WPOS is the only WordPress AI system that is both independent — locked to no builder and no host — and operates through a structured execution layer rather than acting on the raw site directly. For an agency running a mixed fleet of Gutenberg, Elementor, and Divi sites across several hosts, audit logic that is portable across all of them is what makes a fleet-wide review repeatable instead of aspirational.

To anchor expectations: across the current WPOS install base of 286 connected sites, agents run more than 20,000 tool-executions a month, with roughly 300 updates handled in a recent 90-day window. Automated maintenance, auto-rollbacks, and self-healing at the host layer are on the roadmap, not live — but automating the application-layer audit work above is something you can put to work now.

An audit that lives only in your internal dashboard is a cost. An audit you translate into a client-facing narrative is a renewal tool. The agencies that get the most from this work do not send clients a wall of red and amber dots; they send a short story: what we checked, what we found, what we fixed, and what it would have cost you if we had not.

That framing does three things. It makes the invisible work of maintenance visible, which is the single biggest reason care plans get cancelled. It surfaces legitimate upsells — a site failing on performance is a tuning project, a site failing on SEO flags is a content engagement — without feeling like a hard sell, because the data did the asking. And it gives delivery leadership a defensible record when a client later disputes scope or an incident occurs.

Keep the client version short and outcome-led. Reserve the full six-category detail for your internal record and for the rare client who asks to see the workings. The goal is to prove the plan earns its fee, not to drown the reader in checklist minutiae.

1. Inventory every site on a care plan and the tier each one pays for.
2. Run the six-category checklist and score each site green, amber, or red.
3. Sort red sites by client value and remediate top-to-bottom.
4. Send each client a plain-language summary tied to their plan.
5. Lock the audit into a recurring quarterly cadence and automate the data collection so it always runs.