Why KEEP

This page explains the problem KEEP was built to address and the thinking behind its design — not a feature list. For what KEEP does today, see Capabilities; for how it's built, see How KEEP Works.

Why KEEP Exists

Knowing what devices exist on a network is a different question from knowing whether that network is in a known-good, documented state — and whether that can be shown to whoever needs to see it, whether that's an MSP's own management, a client, or an auditor. KEEP was built to answer the second question, not just the first. (Source: KEEP product positioning documentation)

The operational challenges KEEP was designed to address

Organizations responsible for network security and compliance visibility are often working across systems that were not designed to share information with each other — antivirus tooling, hardware and license records, directory services, and network infrastructure. Reconciling those into one trustworthy picture typically requires manual, recurring effort. (Source: KEEP product positioning documentation)

Producing documented evidence of that work — for a client review, an insurance renewal, or an audit — is itself a separate, recurring task layered on top of doing the work in the first place. (Source: KEEP product positioning documentation)

An organization responsible for more than one network needs this picture for each one individually, and a way to see all of them at once without losing the separation between one client's data and another's. (Source: KEEP architecture documentation)

Design principles that guided KEEP

Vendor-agnostic: designed to work across different underlying network equipment and tooling, rather than depending on a single vendor's ecosystem. (Source: KEEP product positioning documentation)

Minimal footprint: designed to avoid installing software on the devices being monitored, relying instead on standard network protocols and a single collector per site. (Source: KEEP product positioning documentation)

Evidence over assumption: a newly deployed collector's first scan is treated as unverified evidence, not an accepted baseline, until a qualified person reviews it. See How KEEP Works for how this applies to onboarding a new site. (Source: KEEP architecture documentation)

Stated boundaries: KEEP is designed to produce supporting evidence for compliance and audit processes, not to certify compliance itself. Compliance determinations remain the responsibility of qualified auditors and legal counsel. (Source: KEEP product positioning documentation)

Who KEEP is intended for

Managed service providers monitoring more than one client network, who need a single place to see all of them without mixing data between clients. (Source: KEEP architecture documentation)

IT teams or organizations monitoring a single network of their own, without needing a separate client-management layer. (Source: KEEP architecture documentation)

Organizations that need documented, reviewable evidence of their security and compliance posture — for internal use, client reporting, or audit and insurance purposes. (Source: KEEP product positioning documentation)

Who KEEP is not intended for

KEEP is not a helpdesk or ticketing system. (Source: KEEP product positioning documentation)

KEEP is not a backup solution and does not replace dedicated backup tooling. (Source: KEEP product positioning documentation)

KEEP does not certify compliance with any standard. Organizations that need formal certification against a specific standard need a qualified auditor — KEEP is not a substitute for that process. (Source: KEEP product positioning documentation)

KEEP is not designed as a large-enterprise IT service-management platform — it is scoped for MSPs and IT teams managing a bounded set of client networks. (Source: KEEP product positioning documentation)

Continue to How KEEP Works

For the architecture behind these principles — the Hub/Spoke model, evaluation flow, data flow, and trust boundaries — see How KEEP Works.