Coverage
Which systems are included, when they were last checked and what cannot currently be seen.
SHIELD MONITOR
Keep risks visible.
Keep confidentiality in focus.
A fixed issue should not disappear from view when systems change. The Shield Monitor design keeps supported changes, unresolved risks and monitoring gaps visible, with human review and a responsible owner for the next step.
Business inquiries welcome · Shield services are in development · View current availability
01 / THE PRIVATE CYBERSECURITY MONITORING SYSTEM
The signal.
And the context around it.
- Internet exposure
- Enrolled websites, domains and approved remote-access surfaces. Match observed software and configuration to applicable advisories; an exposed service is not proof of compromise.
- Identity and business email
- Supported sign-ins, privileges, forwarding and staff or contractor departures. Review who retains access and who is responsible for correcting it.
- Patient media and record access
- Sharing settings, external links and supported access/export metadata. Clinical photographs, scans and renders keep their source, purpose and permission context.
- Websites and intake
- Trace agreed form destinations and third-party transfers with fictional submissions. Distinguish an observed transfer from a configuration that needs review.
- Marketing and AI use
- Compare the asset, approved purpose, recipient and destination before publication or transfer where a reliable integration exists. Treatment permission is not marketing or model-training permission.
- Devices and recovery
- Use existing endpoint, device-management and backup evidence. Separate a successful backup job from a tested restore and necessary clinical availability.
- Monitoring health
- Surface stale sources, permission loss, missing event ranges, backlog and failed test signals. No alerts is not the same as no risk.
- Investigation and response
- Connect evidence, responsible people, permitted corrections and fresh checks. Keep accepted risks, incomplete changes and returning issues visible.
02 / THE OWNER EXPERIENCE DESIGN
Five views.
Clear answers for your team.
Findings
What needs review, the information behind it and the questions that remain unanswered.
Actions
Who owns the next step, which approvals are needed and when the next update is expected.
Reports
What remains open, which risks were accepted and which corrections were checked. Acceptance is not the same as a fix.
Privacy
What information is used, where it may be processed and who is allowed to access it.
03 / FICTIONAL OWNER-REPORT EXAMPLE
Useful visibility.
Without false certainty.
This is a static example, not a connected customer dashboard or a report on your practice.
FICTIONAL REPORT EXAMPLENot a live dashboard
What needs attention?
A future owner report would make both findings and unanswered questions visible.
- Staff accounts
- Access review needed
- Patient-photo sharing
- Permissions not checked
- Website forms
- Destinations not assessed
- Backups
- Restore test not verified
Illustrative states only. No practice has been assessed by this page.
04 / SOFTWARE AND PEOPLE ARE DIFFERENT COMMITMENTS
Agree the review hours.
Know who will respond.
- Collection schedule
- Each connection has its own update frequency and provider delay. A daily export does not support a promise of instant detection.
- Human review
- Named reviewers, working hours, escalation routes and reporting frequency would be set in a future agreement.
- After-hours support
- Automated collection is not 24/7 staffed response. No such response service is active or promised here.
MONITORING HEALTH
Watch the monitoring itself.
Keep blind spots visible.
- Collector status
- Is the collector alive, and are its permissions and expected record fields still available?
- Source completeness
- Which event ranges were actually received? Retain missing ranges and backlog rather than assuming a new heartbeat fills an old gap.
- End-to-end test signals
- Did an agreed synthetic test signal travel through the source, collection and case path? A heartbeat alone cannot answer that.
- Visible degradation
- The local scheduler records silence, sequence gaps, backlog and failed test signals. Production host supervision and provider behavior still require separate qualification.
OWNER REPORTING
Metrics with a visible basis.
Not a mystery score.
Explore the report definitions
Implemented local report calculations use validated retained records and explicit time windows. They do not establish customer outcomes or a live SLA.
- Coverage and freshness
- Healthy streams out of all exported streams, unresolved gaps, source verified-through time and the last independent health check. This is not a percentage of the practice’s entire digital estate.
- Decisions and open work
- Open cases, owner decisions, named handlers, missing assignments, accepted risks and reopened cases. Accepting a risk does not count as fixing it.
- Verified corrections
- Current verified cases need linked fresh verification evidence. A case that later reopens is excluded from current verified corrections; a snapshot is not a complete historical incident ledger.
- Time to verified correction
- For eligible cases, show correction-request-to-verification duration, the median, included sample count and missing-time exclusions. This is not attacker dwell time or a containment guarantee.
- Recorded service effort
- Separate customer, analyst, connector-support and escalation minutes, with entry counts and the report window. No entry means not recorded—not zero work, money saved or prevented loss.
IMPLEMENTED LOCAL WORKFLOWS
Three concrete examples.
Fictional data, real local code.
Patient-photo sharing
A fictional sensitive-media resource becomes publicly shared. The local workflow creates a case, assigns the next step and checks fresh fictional permission evidence.
Departed-worker access
A fictional account remains usable after a recorded departure. Review identity and exceptions, then verify a corrected state. The demo does not disable a real account.
An intake destination
A fictional intake route reaches an unapproved destination. The local workflow records the mismatch and verifies a changed fixture. It is not a real website scan or submission.
YOUR NEXT STEP
Identify the weak points.
Plan the next step.
Tell us which systems your practice uses and what you want to protect. We’ll discuss the relevant scope, readiness and responsibilities before any work.