How do I know whether to use the Low, Moderate, or High baseline?

“Low, Moderate, and High baselines” typically refer to pre-defined control baselines from frameworks like NIST 800-53 / 800-82 (often via the NIST Risk Management Framework) or similar profiles used for OT and manufacturing. In regulated industrial environments, you do not pick a baseline by preference; you select and justify it based on a structured risk and impact assessment.

1. Start from the applicable standard or mandate

Before deciding on a baseline, you need to know which framework and regulatory drivers actually apply. Examples include:

• NIST 800-53 / 800-82 baselines mapped to Low / Moderate / High impact systems.
• IEC 62443 security levels or profiles that your organization has mapped to Low / Moderate / High internally.
• Customer or government contract clauses that prescribe specific minimum control sets.

The correct baseline is constrained by these obligations. If your customer, corporate security, or regulator mandates a minimum level, you cannot choose a lower baseline even if your local plant risk seems small.

2. Assess impact in four key dimensions

Baselines are normally tied to potential impact, not likelihood. A common pattern is to assess impact of compromise or failure in at least these areas:

• Safety and environment: Could loss of control, integrity, or availability create realistic scenarios of serious injury, fatality, or major environmental release?
• Product quality and compliance: Could a failure or breach directly affect conformance to specifications, batch release, airworthiness, lot genealogy, or other regulated quality outcomes?
• Regulated / sensitive data: Does the system store or process export-controlled data, controlled unclassified information (CUI), PHI, PII, or customer proprietary technical data?
• Operational and business continuity: Would a prolonged outage materially affect delivery to critical customers, defense programs, or safety-critical aftermarket support?

In many formal schemes, these factors are translated into impact levels for confidentiality, integrity, and availability, which then drive the baseline selection.

3. Typical characteristics of Low, Moderate, and High

The exact definitions vary by organization and framework, but the following patterns are common in manufacturing and OT:

• Low baseline
  • Systems with limited safety or quality impact and no regulated/sensitive data.
  • Loss or compromise is inconvenient but does not materially affect regulated product, worker safety, or contractual obligations.
  • Examples: non-critical utility dashboards, training kiosks, non-sensitive internal informational sites.
• Moderate baseline
  • Systems where compromise could significantly affect product quality, traceability, or operations, but not typically cause catastrophic safety or national security impacts.
  • Often includes plant-floor MES functions, batch records, maintenance systems, and many engineering tools.
  • Common default for mixed-use OT networks where some safety and compliance impact exists but is managed with layers of protection.
• High baseline
  • Systems where compromise could plausibly lead to serious injury/fatality, major environmental damage, or severe regulatory or mission impact.
  • Includes safety-instrumented systems, systems controlling high-hazard processes, or systems processing highly sensitive defense or regulated data.
  • Often requires strict configuration control, segregation, enhanced monitoring, and strong assurance measures.

In many regulated industrial environments, very few systems truly qualify for Low. Most business-critical and quality-relevant systems fall into Moderate, with a targeted subset at High.

4. Apply a repeatable, documented decision process

To avoid inconsistent or optimistic baseline selection, use a structured, auditable approach, for example:

1. Define criteria: Adopt clear written definitions for Low, Moderate, and High aligned to your corporate risk framework and any mandated standard.
2. Classify each system: For each application or asset (MES, QMS, SCADA, historian, PLC cells, document control, etc.), assess safety, quality, data sensitivity, and operational impact.
3. Map impact to baseline: Use your organization’s mapping (for example, any system with potential severe safety impact or highly sensitive data defaults to High).
4. Document justification: Record the rationale for the chosen baseline, including assumptions about safeguards, network segmentation, and procedures.
5. Review through governance: Have security, quality, operations, and IT jointly review classifications, especially for systems proposed as Low.

This documentation is critical in regulated settings where auditors and customers will challenge why controls differ between apparently similar systems.

5. Consider brownfield and coexistence constraints

In existing plants, you often cannot immediately raise every legacy system to a High baseline without creating significant validation, downtime, and integration burdens. Practical implications include:

• Mixed baselines on shared infrastructure: High and Moderate systems often share networks and support teams with Low systems. Network design, zoning, and access control may need to meet the highest baseline present in a zone or cell.
• Legacy systems that cannot meet High: Older PLCs, control panels, or homegrown apps may not realistically satisfy all High-baseline controls without hardware changes, wrappers, or compensating controls.
• Validation and qualification cost: Increasing the baseline for a GxP or aerospace-relevant system cascades into more rigorous validation, documentation, and change control. This is sometimes more constraining than the technical implementation.
• Downtime and cutover risk: Raising baselines often involves patching, segmentation, or architecture changes. In 24/7 plants, the operational windows may force phased or partial implementation.

Because full replacement strategies are expensive and risky, a common approach is to classify systems, set target baselines, and then define a risk-based, multi-year roadmap to close gaps through upgrades or compensating controls instead of immediate wholesale change.

6. When you should not choose the Low baseline

In many organizations, “Low” is overused to reduce control overhead. Situations where Low is usually not appropriate include:

• Systems that directly record, control, or release regulated product.
• Any system involved in electronic records or signatures that support audit trails or batch/lot release decisions.
• Systems storing or transferring export-controlled designs, CUI, or customer-proprietary technical data.
• Supervisory systems where loss of visibility would impair safe operation or emergency response.

If there is reasonable debate between Low and Moderate for a system with compliance or quality impact, most regulated organizations err on the side of Moderate to avoid difficult audit justifications later.

7. Operational guidance for getting started

If your organization has not yet formalized baseline use, a pragmatic approach is:

1. Adopt a reference scheme (for example, NIST 800-53/800-82 or an IEC 62443-based profile) if corporate has not already mandated one.
2. Define a short, plant-appropriate set of impact criteria in terms operations and quality leaders recognize.
3. Run a pilot classification exercise on a small set of systems: one MES or SCADA instance, a QMS or LIMS, and a couple of OT cells.
4. Refine criteria and decision rules based on where disagreements occur, then scale across the asset inventory.
5. Integrate baseline selection into change control, system onboarding, and project approval workflows so it is not a one-time activity.

Across all of this, the most important point is that baseline choice is a documented, risk-based decision tied to impact and obligations, not an ad hoc local preference. In regulated, long-lifecycle manufacturing, the cost of under-classifying a system usually surfaces later in audits, incidents, or difficult retrofit projects.