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 newly published CVE matches an asset in your environment with high confidence, an alert is sent by email to members with email alerts turned on, and to your organization's webhooks. Per-environment routing to different teams is not currently applied. See How Alerts Work.

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

Plans also cap total assets and team members: Standard allows 50 assets and 2 members, Professional 1,000 assets and 5 members, and Enterprise 5,000 assets and 25 members. Existing items above a cap are kept and stay usable after a downgrade; only adding new ones is blocked until you are back under the limit. If you need more than the Enterprise limits, contact sales for a custom plan with raised limits.

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.