The product, family by family

The French text governs. This page is the English version of Le produit FR.

OrgGuardian carries 121 capabilities, spread across seven families. This page gives them all, with two pieces of information the pricing grid did not carry: from which offer each is available, and in which state it arrives on installation day.

121

capabilities shipped in the package

7

families carrying them, plus support

14

active on installation day, on the Discovery offer

The seven families

The pricing grid sells those same capabilities as 26 grid rows: one grid row bundles several capabilities of this page — two figures, one single reality. Multi-org has no page of its own: it fits in three capabilities, described below. Service is not a family of capabilities but a support commitment: it carries none of the 121, and lives on the support page.

What these 121 capabilities share

Read only

None of the capabilities removes a permission, closes an access or fixes a line of code. The product detects, costs, ranks and advises; a human decides.

Your rights, not ours

Every query runs with the rights of the user launching the scan. What that user may not see, the product does not see: it writes it into a “not measured” finding rather than concluding “healthy”.

Nothing leaves by default

Hosted viewer, external alert channels, SIEM, ITSM, Tooling API reads: everything that makes a call go out is closed at delivery and opens one by one, inside the org, by an administrator. The detail is on the publisher security page.

How to read “state at install”

It is the least flattering figure on this site, and that is exactly why it is here. Out of 121 capabilities, 14 return something on installation day, on a fresh org on the Discovery offer: 10 in monitoring, 3 in alerts, 1 in integrations. They are the monitoring core, callout and SOQL posture, in-org alerting and its two channels, the read REST API, logging and the console tooling. The other 107 wait either for a higher offer or for an administrator to open them.

A “closed” capability is shipped: it is in the package, it opens with one click in the feature editor, and it needs no reinstall. It is closed because the package deploys without switching on anything that makes an outbound call, a wide read or an unwanted alert. Three gates of the Discovery offer itself are in that state — the finding detail inside the platform event, the same detail in the REST API, and the endpoint registry — because they would widen what the product exposes without anyone asking for it. The pricing grid gives the price of each tier.

Multi-org

Three capabilities, and a single question: how to see ten orgs without opening ten tabs. Multi-org aggregation and white label sit at the Mid-market tier; the EU-hosted viewer is an option, disabled at install, enabled by an administrator after explicit consent, publishing health aggregates only.

Source: read from the package code at the moment this page is built — FeatureGate.FEATURE_TIER for the offer, FeatureGate.CODE_DEFAULTS for the state at install. The label is the one exception: the in-org feature editor is French only, so the English wording in this column was written for this site. Its French counterpart, on /produit/, is the exact string your administrator reads, and the site build fails if the two lists move apart. “Closed” does not mean absent: the capability is shipped, it is waiting for a human to open it inside the org — and a capability whose implementation nothing in the package can reach appears on none of these pages: the build drops it instead of selling it.

Service

Support is not a gate in the code: it is a written commitment, with response times by criticality and an owned volume ceiling. It is detailed on the support and SLA page.