Justifying target security levels to auditors or customers is about showing a traceable, risk-based rationale, not about claiming you are perfectly secure. In industrial and regulated environments, you need to show how you chose security targets, what you considered, and where the limits are.
1. Anchor target levels in a documented risk assessment
Auditors and customers generally accept target security levels when they are clearly derived from a structured risk assessment, not from generic best-practice claims.
In practice, this usually means:
- Using a recognized method (e.g. ISO 27005-style risk assessment, IEC 62443 risk-based approach, NIST CSF/800-30) appropriate for OT/ICS.
- Identifying critical assets and processes (e.g. safety-instrumented systems, batch records, release decisions, serialization, export-controlled data).
- Defining impact categories that matter: safety, regulatory nonconformity, product quality, supply disruption, IP loss, data protection, environmental harm.
- Explicitly rating likelihood and impact with criteria that are written down and repeatable, not implicit.
- Tracking inherent risk, existing controls, and residual risk in a way that can be reviewed.
The key is traceability: you should be able to show, for any target security level, how you got from threats and impacts to the chosen level.
2. Map to recognized standards without overpromising
In industrial environments, target levels are often expressed using external standards or reference models. This can help, provided you are clear about scope and limitations.
Common patterns include:
- Referencing IEC 62443 security levels (e.g. SL-T) for specific zones or conduits and showing how your target levels align with a documented threat model.
- Using NIST CSF tiers or NIST 800-82 guidance to explain maturity and control coverage for OT systems.
- Referencing ISO 27001/27002 controls where IT and OT controls intersect (identity, access, logging, incident response, vendor access).
When you do this, avoid stating or implying that adherence guarantees compliance or that all controls are fully implemented everywhere. Emphasize that these frameworks are reference points for your targets and that the actual implementation is scoped, prioritized, and constrained by the environment.
3. Show asset-based rationale, not generic “corporate policy”
Auditors and customers are more persuaded by asset- and process-specific reasoning than by broad policy statements.
For each key asset, zone, or system type, be prepared to explain:
- Role in operations: What process it supports, including safety, product quality, release, batch traceability, or export control.
- Criticality: What happens if it is unavailable, corrupted, or misused (production stop, batch discard, recall risk, regulatory finding).
- Exposure: How it is connected (segmented OT network, remote access, vendor connections, wireless, internet-facing services).
- Constraints: Legacy OS, vendor support limits, validation burden, real-time performance, and maintenance windows.
Then explain how these factors drove the target security level (for example, higher targets for safety- and quality-critical systems, intermediate levels for ancillary support systems, lower levels for isolated test labs with strong procedural controls).
4. Make tradeoffs explicit, especially in brownfield environments
In regulated, brownfield plants, achieving the theoretical maximum security level is often impossible without unacceptable downtime, revalidation cost, or loss of vendor support.
To justify realistic target levels, make the tradeoffs explicit:
- Document where you deliberately accept a lower technical security level but compensate with procedural or detective controls (e.g. manual review of logs, stricter change control, physical access restrictions).
- Explain legacy constraints (unsupported OS, proprietary protocols, fixed vendor images) and how they affect which controls are feasible.
- Highlight validation and qualification impacts: some changes that would increase security have a high revalidation cost or extended downtime that is not acceptable for critical assets.
- Show that you evaluated options (e.g. isolation, jump hosts, monitored remote access) instead of simply saying “we cannot change this system.”
Auditors usually respond better to a transparent description of considered options and residual risk than to unrealistic claims of full compliance or full hardening.
5. Use a consistent scale for target security levels
Justification is easier when your target levels are defined on a clear, documented scale.
Elements of a defensible scheme:
- A small number of levels (for example, 3 to 5) with written definitions tied to attacker capability, required controls, and risk tolerance.
- Explicit linkage between each level and example controls (network segmentation, authentication strength, logging depth, backup/recovery expectations, supplier remote access requirements).
- Criteria for assigning levels based on impact categories (e.g. patient safety, regulatory nonconformity, recall potential, extended downtime).
When you can show that this scheme was defined centrally, reviewed, and applied consistently across sites, it is much easier to defend specific targets to external parties.
6. Demonstrate traceability from risk to controls
Auditors and sophisticated customers typically want to see more than high-level targets. They want traceability from risk through to actual mitigations.
Strong evidence packages usually include:
- Risk registers that link threats and scenarios to specific assets or zones.
- Assigned target security levels with documented rationales.
- Mappings from target security levels to control sets or baseline configurations.
- Implementation status of controls, including exceptions and compensating measures.
- Change control records for significant security changes to validated or qualified systems.
The objective is not to prove perfection but to prove a deliberate, managed approach.
7. Acknowledge residual risk and continuous improvement
In regulated manufacturing, it is rarely credible to claim that all reasonable controls are in place. Instead, you need a structured way to acknowledge residual risk and show how you manage it over time.
To do this credibly:
- Document residual risks at the asset or zone level, with ownership and review cadence.
- Show how new threats (e.g. recent ICS vulnerabilities, vendor advisories) are evaluated against existing targets.
- Demonstrate use of periodic reassessments, penetration testing, or third-party reviews aligned with change control and validation.
- Connect improvement actions to realistic windows for downtime, validation, and vendor involvement.
This reinforces that your target levels are part of an evolving program, not a one-time paper exercise.
8. Communicating with auditors vs. customers
While the underlying justification should be the same, the emphasis differs slightly:
- Auditors: Focus on governance, risk methodology, evidence of control design and operation, and alignment with your own procedures and standards. They will often test that your practice matches your documented process.
- Customers: Focus on what your targets mean for supply continuity, data handling (including export-controlled information), and product quality or patient/user safety. Be prepared to share high-level architecture, access control practices, and incident response expectations without exposing sensitive internals.
In both cases, avoid language that could be interpreted as a guarantee of compliance or security outcomes. Describe capabilities, processes, and boundaries.
9. Why “rip-and-replace” is rarely a justifiable security argument
Some customers or internal stakeholders may ask why you do not simply replace legacy systems to reach the highest possible security level. In regulated, long-lifecycle environments, this is often not a viable or justifiable path.
Your justification can legitimately include:
- High qualification and validation burden for new equipment or major system changes.
- Downtime risk for critical lines or assets where extended outages are unacceptable.
- Integration complexity with MES, ERP, QMS, historians, and specialized test or inspection systems.
- Vendor constraints, such as fixed software baselines that are the only supported and qualified configurations.
Explain that instead of wholesale replacement, you prioritize layered defenses, segmentation, strict remote access control, and procedural controls that are achievable within those constraints. This can support a realistic target security level even when some components remain legacy.
10. Minimum documentation you should be ready to show
To make target security levels defensible, you should at least be able to produce:
- A documented risk assessment approach and example risk assessments for representative assets or zones.
- Definitions of your security level scale and how levels map to control expectations.
- Architecture diagrams or zone/conduit models with target levels annotated.
- Policies and standards that connect target levels to specific configurations and controls.
- Evidence of implementation, exceptions, and compensating controls, under change control where systems are validated or qualified.
Putting these elements together gives auditors and customers a coherent story: you understood your risks, selected target security levels on a defensible basis, applied them consistently, and operate within the real constraints of regulated, brownfield manufacturing.
