Yes. Different foundational requirements can have different security levels, and in regulated industrial environments they usually should. The important point is that the security level is not arbitrary: it must be driven by risk, applied consistently, and kept under traceable change control.
What it means in practice
When you decompose your cybersecurity or operational requirements into foundational requirements (for example around access control, system integrity, data confidentiality, change management, or logging), you can assign different target security levels to each area. Typical drivers include:
- Process safety impact (risk of injury, environmental release, or critical quality impact)
- Regulatory exposure (GxP, export control, ITAR/EAR, aerospace/defense contracts, customer-specific security clauses)
- Business impact (downtime cost, IP sensitivity, supply chain implications)
- Integration surface (degree of connectivity to corporate IT, partners, cloud, or remote services)
It is common, for example, to require a higher level of security for requirements around remote access or configuration changes on safety-related systems than for read-only viewing of non-sensitive production KPIs.
Key constraints and dependencies
Being able to set different security levels by foundational requirement depends on:
- Clear requirement hierarchy: You need documented foundational requirements that are traceable up to policies/standards and down to specific controls on specific systems.
- Defined security level criteria: Whether you use IEC 62443 concepts or an internal schema, the meaning of each level must be written, approved, and stable enough to be auditable.
- System capability and vendor constraints: Some legacy PLCs, DCS, MES, or lab systems cannot technically meet higher levels without workarounds or compensating controls.
- Validation and qualification burden: In regulated plants, tightening a security level on a foundational requirement may trigger revalidation, regression testing, and documentation updates.
Common patterns in brownfield environments
In mixed, long-lived industrial stacks, you will often see:
- Different levels by requirement, not by asset: For example, all systems handling export-controlled technical data have higher requirements for access control and data handling, even if the underlying machines are similar to those in non-controlled areas.
- Use of compensating controls: Where an older system cannot meet a higher security level natively, requirements may be met through network segmentation, jump hosts, procedural controls, or stricter change management.
- Uneven implementation: Plants may declare a higher level for a requirement but apply it inconsistently across sites or vendors. This is a frequent audit and risk gap.
Tradeoffs and failure modes
Allowing different security levels per foundational requirement introduces both flexibility and risk:
- Pros:
- Lets you focus strict controls on high-risk areas without over-burdening low-risk operations.
- Reduces friction for manufacturing teams where tighter controls are not justified by risk.
- Improves odds of adoption in brownfield plants by aligning with technical and downtime constraints.
- Cons:
- Complexity: Harder to explain, audit, and maintain than a single uniform level across all requirements.
- Drift: Over time, controls may no longer match the documented level if changes are not governed.
- Integration issues: Interfaces between systems at different effective levels can become weak links.
Governance expectations in regulated environments
If you assign different security levels to foundational requirements, you should be prepared to demonstrate:
- Documented rationale: Why a given requirement is set at that level, including risk assessment inputs.
- Traceability: Mapping from security level to specific technical and procedural controls, and from those controls to systems, sites, and versions.
- Change control: Evidence that any change to levels or controls went through a defined review, impact assessment, and approval workflow.
- Verification and validation: Test or verification activities showing controls perform as intended, especially where changes could affect validated processes.
Why this usually coexists with, not replaces, existing systems
In most aerospace, pharma, and similar environments, you will not replace major MES, SCADA, or control systems just to standardize security levels. The qualification burden, downtime risk, integration complexity, and long equipment lifecycles make full replacement strategies brittle and expensive. Instead, plants typically:
- Define foundational requirements and security levels at the policy/standard layer.
- Map those requirements onto existing systems and networks.
- Use segmentation, gateways, and compensating procedures to close gaps where replacement is not feasible.
So yes, different foundational requirements can legitimately carry different security levels, but the benefit comes only if you anchor levels in risk, implement them consistently across your brownfield landscape, and maintain validation-grade traceability over time.
