Practical questions for a security evaluation.

Review a Linux server before changing it

Question: what do we know about the host and the services it runs? The Linux inventory and assessment code can gather local configuration, software, account and workload facts within its permissions. A reviewer can connect a finding to the host’s actual role before proposing work.

A pilot should compare the collected report with a known host and record omissions. It cannot establish the posture of uninspected systems, a whole cloud account or every network device from one host collector.

Investigate an unexpected configuration change

Question: was the changed state expected? Periodic hashes and configuration observations can identify selected differences for review. The operator compares them with maintenance history and decides whether the baseline needs an authorised update or a correction.

This is a useful change-review workflow. It is not proof of compromise, complete ransomware telemetry or an assurance that all file changes between samples were observed.

Evaluate whether a correction achieved its purpose

Question: does the relevant evidence support the claimed result? A local check can examine the post-change condition; the central development model can represent additional validation requirements. The product tour illustrates a local pass alongside unavailable independent evidence.

A missing Windows or network production prober remains a coverage gap. The current evidence does not establish a fully integrated independent closure guarantee. Required checks and the method for obtaining them must be agreed before relying on the result.

Make a pilot’s coverage understandable

Question: which checks can run in this environment, with these permissions? Use the capability guide and a sample report to distinguish inspected facts, configuration-dependent paths and unavailable modules. That helps an evaluator define a realistic first deployment.

A complete AI Defence fleet coverage dashboard has not been verified. The separate Remedy host dashboard tracks runtime facts and communication; do not interpret those health signals as security clearance.

Fit alongside existing security operations

An organisation can use the proposed assessment and evidence workflow alongside its existing monitoring, endpoint protection, change management and backup arrangements. Any actual data exchange requires a verified integration. No native SIEM connector is claimed here.

For availability-sensitive or critical infrastructure environments, agree approved methods, maintenance constraints, operator authority and recovery requirements before a pilot. No critical-infrastructure deployment or accreditation is asserted.

UK SMEs: make the protections you own understandable

An SME may already have endpoint protection, cloud identity, a firewall and backups. The difficult questions are whether the controls are enabled, whether settings have drifted, whether an unfamiliar attachment gets too much access and whether a usable restore has actually been demonstrated.

The Remedy architecture aims to connect those questions into an understandable picture: what changed, why it matters, what needs approval and what evidence supports the result. A practical starting point is a bounded Linux assessment or a technical review of one important workflow, based on available implementation.

An ordinary employee should not have to interpret a long stream of technical warnings. Expected activity can use an appropriate fast path, while meaningful uncertainty receives a clear explanation and proportionate review.

MSPs: a tenant-specific view of each customer estate

The planned HQ experience would let an MSP review customer device posture, security drift, incidents, quarantine, Glass events, integrity changes, remediation, recovery and verification. The useful output is a clear evidence trail for each customer, rather than another unqualified alert count.

Tenant isolation is a requirement across identities, policy, collected evidence and action authority. An approval for one customer cannot become authority over another customer’s estate. Access roles, retention and reporting scope need explicit implementation and acceptance tests.

The website does not claim a released multi-tenant MSP security console, native PSA/RMM connectors or an existing partner programme. An MSP enquiry can identify required boundaries, supported first scenarios and the evidence needed before a service is offered to customers.

Higher-security teams: make the decision auditable

Finance, healthcare, transport, professional services, government suppliers and other sensitive environments need clear authority, segmentation and recovery responsibilities. The design supports discussion of least privilege, strong authentication, bounded evidence and validation after changes.

Support for these practices does not establish compliance with a particular standard or approval for a regulated workload. Requirements, data handling, deployment constraints and operational assurance must be assessed for the actual engagement.

A useful evaluation starts with one meaningful condition: an unexpected application change, an endpoint leaving quarantine or evidence after a permitted host correction. Define the allowed scope and the checks that make the outcome credible.