Web Development • HIPAA-Aware Healthcare Web • SEO • AI Search Optimization (407) 409-8383   |   [email protected]
Healthcare Security Maintenance

Keep the safeguards working after launch.

A retainer for the ongoing upkeep a healthcare site needs once it is live: dependency and security patching, roughly six-month vulnerability scans, annual penetration-test coordination, patch-window SLAs, CSP and tracker drift checks, backups, and uptime and integrity monitoring, plus breach-readiness runbooks and re-checks of your accessibility and tracking posture as the rules move. The aim is plain: keep the technical layer we built actually working, instead of letting it quietly decay into the part of your posture that fails.

// this is security maintenance and monitoring, not a compliance sign-off. No website is HIPAA compliant on its own; compliance is an organizational posture across your whole practice. We keep the technical layer current and documented; we do not issue a formal attestation, certification, or verification document, because that is a posture only your organization can hold.

ONGOING UPKEEP PATCH-WINDOW SLAS NOT AN ATTESTATION
The overview

A healthcare site is not a thing you launch and forget.

Most real exposure does not arrive on launch day. It creeps in over the months after, when a dependency falls out of date, a tracker drifts back onto a page it should never touch, a backup nobody has tested turns out not to restore, or a Section 1557 deadline quietly moves the bar. A site that was carefully built to be HIPAA-aware can slide out of that posture without anyone touching it, simply because the world around it kept moving. This retainer exists to keep that from happening.

The work is unglamorous on purpose. We patch the dependencies your site and any portal run on, scan for known vulnerabilities on a regular cadence, coordinate a deeper annual penetration test, re-validate the Content Security Policy and the tracker inventory, keep sensible backups that we test rather than assume, and watch uptime and integrity so a problem surfaces as an alert rather than as a patient phone call. None of it is exotic. All of it is the difference between a posture that holds and one that decays.

We are careful about what this is and is not, because the temptation to oversell maintenance is real. This is security maintenance and monitoring. It keeps the technical layer current and documented, and it keeps you ahead of the drift. It is not a compliance certification, and we will never dress it up as one. The posture that makes your practice compliant lives at the organization level, and we keep our claims firmly inside the part we can actually own.

What the retainer keeps current

The upkeep that keeps a healthcare site from quietly decaying after launch.

  • Dependency and security patching on a regular cadence
  • Roughly six-month vulnerability scans, acted on
  • Annual penetration-test coordination and remediation
  • CSP and tracker drift checks over time
  • Backups, uptime, and integrity monitoring
  • Breach-readiness runbooks kept current
What is included

The upkeep, named plainly.

Every retainer covers the same backbone of maintenance, scaled to what your site actually is. A marketing-only site needs less than a portal handling ePHI, so we size the cadence and the scope to the real surface rather than charging for monitoring a brochure site does not need.

The patching and scanning cadences, and the MFA, encryption, and audit logging we keep watch over, align with the proposed December 2024 Security Rule update. That rule is proposed as of mid-2026, not current law, but building to it now is prudent because it is where the rules appear to be heading. We will not call it a mandate before it is one.

What is included

  • Dependency and security patching on a regular cadence
  • A patch-window SLA for high-severity vulnerabilities
  • Roughly six-month vulnerability scans
  • Annual penetration-test coordination
  • CSP re-validation and tracker drift checks
  • Backups that are tested, not just taken
  • Uptime and file and content integrity monitoring
  • Breach-readiness runbooks kept current
  • Re-checks of accessibility and tracking as rules change
  • A record of what was patched, scanned, and changed

// maintenance and monitoring, not a compliance attestation, certification, or verification document

The real risk

Drift is how a safe site goes wrong.

A site is rarely undone by a dramatic attack on launch day. It is undone by drift: small, slow changes that accumulate until the posture no longer holds. A dependency ages into a known vulnerability. A marketing team adds a tag, or a vendor script silently changes what it loads, and an analytics snippet creeps back onto a page that touches health information. A Content Security Policy that was tight at launch loosens one exception at a time.

Trackers are the most common offender, and the most consequential. More than 100 million dollars in pixel-tracking settlements have landed since 2023, and the OCR online-tracking bulletin still binds authenticated and portal pages even after American Hospital Association v. Becerra vacated only the unauthenticated-page theory in 2024. A pixel that drifts back onto a portal page is exactly the channel that hands protected health information to a vendor you have no agreement with, and a cookie banner is not a valid HIPAA authorization.

So we treat drift as the thing the retainer is really for. We re-inventory the tags and trackers, re-validate the CSP, and flag anything that has wandered back in, before it becomes the exposure. The point is to catch the small change while it is still small, rather than discovering it in a breach review.

What we watch for drifting

  • Aging dependencies with known vulnerabilities
  • Trackers and tags that creep back in over time
  • Vendor scripts that change what they load
  • A Content Security Policy loosening exception by exception
  • Analytics reappearing on PHI-handling pages
  • Consent enforcement that quietly stops covering a path
  • Accessibility regressions from new content
  • Backups that have never actually been restored
How we work

A steady cadence, not a heroic scramble.

Good maintenance is rhythm, not rescue. We patch on a schedule, scan on a cadence, coordinate the deeper test once a year, and re-check the posture as the rules move, so problems are caught small instead of being discovered in an incident. The reactive part, the patch-window SLA, exists for the days the schedule is not enough.

// keep it current, keep it documented, keep the claims modest

  1. Establish the baselineWe start by understanding what we are maintaining: the stack and its dependencies, where PHI flows, the current tracker and CSP posture, and the state of the backups and monitoring. If we did not build the site, that baseline is an assessment first, and we will name anything that needs fixing before an honest retainer can stand behind it.
  2. Patch on a cadence, with an SLA for the urgentRoutine, lower-risk updates ride a regular schedule so we are not churning the site for its own sake. High-severity vulnerabilities trigger the patch-window SLA: a defined response time to get the fix tested and deployed, rather than a vague promise to get to it eventually.
  3. Scan regularly, test annuallyWe run vulnerability scans on roughly a six-month cadence and act on what they find, and we coordinate a deeper annual penetration test, often through an independent third party, then remediate against it. A scan finds known issues to fix; a pen test probes harder. Neither is a pass-fail compliance grade.
  4. Check for driftWe periodically re-inventory tags and trackers, re-validate the Content Security Policy and consent enforcement, and re-check the accessibility posture against the approaching deadlines. Anything that has drifted back in, especially anything that could leak PHI, gets flagged and fixed while it is still small.
  5. Stay ready, and documentWe keep breach-readiness runbooks current and the backups tested, so the technical response is rehearsed rather than improvised. We record what was patched, scanned, and changed, so the history is there for your risk analysis, while breach determination and notification stay yours to own.
Questions, answered honestly

Frequently asked questions

No, and we are deliberate about saying so. No website is HIPAA compliant on its own; compliance is an organizational posture across your whole practice, not a deliverable a vendor can issue. This retainer is security maintenance and monitoring: we keep the technical layer patched, scanned, and watched, and we keep the documentation current. We do not produce a formal written attestation, certification, or verification document, because that is a posture only your organization can hold, through its Security Risk Analysis, its signed agreements, its workforce training, and its breach procedures. We keep the work real and the claims modest.

We track the dependencies your site and any portal run on, and we apply security patches on a regular cadence rather than waiting for something to break. When a high-severity vulnerability lands in a component you depend on, the patch-window SLA is our commitment to a defined response time for getting the fix tested and deployed, rather than a vague promise to get to it eventually. Routine, lower-risk updates ride a slower, scheduled cadence so we are not churning your site for its own sake. We document what was patched and when, so the history is there if your risk analysis ever needs it.

We run vulnerability scans on roughly a six-month cadence, and we coordinate an annual penetration test. The distinction matters: a scan is an automated sweep for known issues that we run regularly and act on, while a penetration test is a deeper, human-led probe, often performed by an independent third party, that we coordinate and then remediate against. These cadences mirror the direction the proposed December 2024 Security Rule update points, so building to them now is prudent. We will be clear that the scan and the test find issues to fix; they are not a pass-fail compliance grade.

A Content Security Policy and a clean tracker inventory are not set-and-forget. Over time a marketing team adds a tag, a vendor script changes what it loads, or an analytics snippet creeps back onto a page it should never touch. Drift checks are how we catch that: we periodically re-inventory the tags and trackers, re-validate the CSP, and flag anything that has wandered back in, especially anything that could leak protected health information to a vendor you have no agreement with. This is the most common way a healthcare site quietly slides out of a safe posture after launch.

Both, because a recovery you cannot trust is its own kind of security failure. We keep sensible backups and we test that they actually restore, rather than assuming a backup that has never been exercised will work when you need it. We monitor uptime and we watch file and content integrity, so an unexpected change or an availability problem surfaces as an alert rather than as a patient phone call. The point is to know about a problem before your patients do, and to have a real way back when something goes wrong.

We keep breach-readiness runbooks current so the technical response is rehearsed rather than improvised: how to preserve logs, what to isolate, who to contact, and how to reconstruct activity from the audit trail. Be clear on the line, though. We support the technical side of incident response, but determining whether a reportable breach occurred and carrying out any required notifications is your organization's responsibility, not a vendor's. We give you the technical facts and the runbook; your practice, with its counsel and its compliance process, makes the breach determination and handles notification.

Yes. The regulatory ground moves, and a posture that was current at launch can fall behind. We re-check the accessibility posture against WCAG and the Section 1557 and ADA Title II deadlines as they approach, and we re-check the tracking and consent posture as the OCR online-tracking guidance and any finalized Security Rule update shift the bar. We will keep the honest hedge in place: we build and re-check to WCAG, but legal conformance also depends on your organization's ongoing content and process, so an unlabeled PDF or an uncaptioned video uploaded after our last pass can still introduce drift.

Often, yes. We start with an assessment of what you have: the stack, the dependencies, where PHI flows, the current tracker and CSP posture, and the state of the backups and monitoring. If the foundation is sound, we can take over the upkeep. If the assessment turns up something that needs fixing first, we will tell you plainly what it is and scope that remediation separately rather than quietly absorbing it or papering over it. We would rather start an honest retainer on a site we understand than inherit a posture we cannot actually stand behind.

Have a healthcare site live and want it kept safe?

Tell us what you are running. We will give you a straight read on the upkeep it actually needs, what the patching, scanning, and drift checks should cover, and exactly where the line sits between the technical maintenance we own and the compliance posture your practice has to hold.