What is an Environment

An environment is the primary unit of organization in BreachSpider. It represents one physical or logical site -- a water treatment plant, an electrical substation, a manufacturing floor, a refinery unit, a corporate IT network segment, or any other boundary you define.

Everything operational in BreachSpider lives inside an environment: assets, findings, tickets, sites, and summary data. When you add assets to an environment, the matching engine generates findings specific to those assets. When you generate a report, you select which environments to include. When you configure an alert, you can route it to recipients specific to each environment.

Examples of Environments

• Water Treatment Plant Alpha -- Jefferson, GA
• Substation Beta -- Main Distribution Hub
• Manufacturing Floor 3 -- Assembly Line PLCs
• Corporate IT Network -- Engineering Workstations
• Oil Refinery Unit 7 -- DCS Control Room
• Remote Pump Station 12 -- SCADA RTUs

Each of these represents a distinct operational boundary with its own set of devices, its own risk profile, and potentially its own remediation team.

What Lives Inside an Environment

Assets: The devices you operate at this site. PLCs, HMIs, SCADA servers, RTUs, engineering workstations, network switches, firewalls. Each asset has a vendor, product, version, layer, and asset type.

Findings: CVE-to-asset matches generated by the matching engine. Each finding links a specific CVE to a specific asset, with a confidence tier (HIGH, MEDIUM, LOW) based on how precisely the match was resolved.

Sites: Sub-locations within a large environment. If your water treatment plant has three separate buildings or zones, each can be a site within the environment. Sites help you organize assets and route findings without creating entirely separate environments.

Tickets: Remediation tracking records tied to specific findings in this environment. Tickets can be routed to email, Jira, or ServiceNow.

Summary: A risk posture overview for this environment, showing finding counts by severity, layer, KEV exposure, and trend data.

How Environments Connect to Alerts

When a new CVE matches an asset in your environment, an alert fires to whatever destination you configured for that environment. This means:

• Water plant alerts go to the water plant operations team.
• Substation alerts go to the electrical engineering team.
• Corporate IT alerts go to the IT security team.

Per-environment alert routing ensures the right people see the right findings without noise from unrelated sites.

MSSP and Multi-Client Usage

If you are a managed security provider managing multiple clients, each client gets their own set of environments:

1. Create a Client record for each customer under the Clients section.
2. Create Environments under each client.
3. Each client's data is isolated -- they see only their own environments.
4. You, as the operator, see all clients and all environments in the aggregate dashboard.
5. Alert recipients are set per environment, so each client team receives only their own notifications.

This hierarchy -- Clients > Environments > Assets -- keeps multi-client data organized and prevents cross-client data leakage.

Tier Limits on Environments

If you need more than 5 environments, upgrade to Professional. If you need multi-organization support (e.g., managing subsidiaries or acquired entities), Enterprise tier provides that capability.

Naming Conventions

Good environment names are specific and immediately recognizable:

• Use the facility name, not a generic label.
• Include a location if you operate multiple similar sites.
• Avoid abbreviations that only you understand.

Examples of good names: "Jefferson WTP", "Substation 4 - Maple Ave", "Assembly Plant C - Robotic Line".

Examples of poor names: "Site 1", "Test", "My Environment", "Env-001".

The environment name appears on the dashboard, in reports, in the audit log, and in alert notifications. A clear name saves time for everyone who reads it.