“Strongly recommended” does not mean “optional”

This is part 4 of 12 of the “Common language” series on industrial cybersecurity; it continues with part 5, who decides, executes, checks.

An audit reaches the line on anti-malware for the operator panels of a filling line. The standard says “strongly recommended”. The site says it was not done. Asked why, the engineer shrugs: it was only a recommendation. Nobody wrote down whether the vendor supports an agent, what was put in its place, or who keeps an eye on it. Two years later the same line is still open in the register, and the recommendation has become an exemption that nobody ever decided.

Most industrial groups end up writing one security standard for the whole site, office network and production floor alike. They are right to. One document gives one set of objectives, one audit baseline and one conversation with management. It also creates a problem that shows up the first time the standard meets a twenty-year-old controller: some requirements cannot be applied in OT as written.

Lowering the bar for everyone is the wrong answer. So is pretending the controller will cope. The flexibility has to be written into the standard itself, with rules tight enough that nobody can hide behind it, and that starts with the words each requirement is written in.

Why OT resists a copy of the IT rulebook

The reasons are technical and well known; the previous article in this series went through them. Better to write them into the standard once than to hear them again as case-by-case excuses.

Priorities differ. Office IT usually puts confidentiality first. NIST SP 800-82 Rev. 3 describes OT security objectives as typically putting integrity and availability ahead of confidentiality, with safety as an overarching priority. Some OT systems are simply limited: an operating system out of support, a controller with no native authentication, firmware that cannot be touched without requalification. Industrial protocols such as Modbus or PROFINET, in their classic form, offer no directory integration and no encryption; secured variants exist, but an installed base changes slowly. Downtime and latency tolerance is close to zero. And modifying a qualified system, SIL-rated, GMP-validated or type-approved, can put a certification or a vendor warranty at risk.

Standards already have a grammar for this

Standards bodies sorted out the wording problem long ago. The ISO/IEC Directives, Part 2, which set the drafting rules for ISO and IEC documents, give each verbal form a fixed meaning in clause 7: shall for a requirement (7.2), should for a recommendation (7.3), may for a permission (7.4), can for a possibility or capability (7.5). The definitions are precise. A requirement is an expression “from which no deviation is permitted if conformance with the document is to be claimed” (3.3.3). A recommendation conveys “a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others” (3.3.4). The Directives even rule out the easy synonym: “Do not use “must” as an alternative for “shall”” (7.2).

RFC 2119, from the internet community, says much the same and is explicit about the weight of “should”. In its section 3, the word means “that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.”

People remember the first half of that sentence and forget the second. “Should” never meant “if convenient”. A site standard can borrow the discipline and go one step further, by turning “carefully weighed” into something written down that an auditor can check.

A four-level requirement scale

This is the scale we recommend putting at the top of a site standard. It does not come from any standard. It is a practical way of making the shall/should distinction work across two very different technical worlds.

One requirement, two treatments

Apply the scale to eight everyday requirements and you get a picture most OT engineers will recognise.

Two things stand out. OT is not let off: two of the eight stay fully required in the plant, and three more stay required with adapted means. And every R in the OT column names what replaces the original control. Not one of them says “not done”.

Recommending is not giving up

Everyone who has run a differentiated standard knows the risk. “Strongly recommended” gets read as “optional”, and within a year the R column is the list of things nobody does. The standard has to shut that door in writing.

Our rule is short. An item classified R stands only if it carries four things:

1. Demonstrated impossibility. A written statement of why the requirement cannot be met on this system: the vendor does not support the agent, the protocol has no encryption, the patch would trigger requalification.
2. A compensating measure that covers the same risk another way.
3. A named owner, a person rather than a department, who answers for the measure staying in place.
4. A review date, after which the impossibility is checked again.

Miss one and the item goes back to required. That single mechanism is what keeps necessary flexibility from hardening into a permanent exemption.

Site standards did not invent compensation. IEC 62443-3-3, the system-level requirements part of the industrial series, devotes clause 4.3 to compensating countermeasures, and its introduction notes that they “can be employed to provide the needed functionality to other subsystems, such that the overall SL-T requirements are met.” The four conditions above add the governance the standard leaves to you: proof, ownership, a date. For what such a measure looks like around a controller that cannot be patched, see the legacy PLC article.

On a GMP site, the four fields will feel familiar. They are the fields of a well-written deviation, or of a justified exception in a validation file: what cannot be done, what was done instead, who owns it, when it gets looked at again. Use the same form for security exceptions and quality and engineering will read them the same way.

The classic trap: a standard nobody reopens

Even a good scale decays if the document around it is frozen. A standard written once, circulated and never reopened turns into an administrative fiction surprisingly fast. Review dates on R items slip by, systems change, and the justifications end up describing equipment that went to the skip two years ago.

So the standard is maintained and versioned: at each remediation milestone, at each regulatory change, after each exercise or incident debrief. One review a year with a named owner is the minimum we recommend; two is better. Each review is also the moment to walk the R register, item by item, and ask whether the impossibility still holds. Some will have gone with a firmware upgrade or a system replacement, and those items move back up the scale.

Where to start

The scale is only as good as the register behind it, so start with the exceptions you already have, written down or not.

1. Put the four levels and their wording on page one of the standard, next to the glossary.
2. Collect every existing exception, including the unwritten ones hiding in audit reports and in the phrase “it was only a recommendation”.
3. Give each one its four fields. Those that cannot be completed go back to required.
4. Link each compensating measure to evidence an auditor can check on the system itself, not only in a document.
5. Book the first register review and tie it to the next remediation milestone.

Five common mistakes

• Reading “should” as “if convenient”. The ISO/IEC Directives and RFC 2119 both give it a precise weight, and the standard should say so.
• An R with no compensating measure. An exception that names nothing in its place is a gap with a label on it.
• A department as owner. “Engineering” does not notice when the measure is removed. A named person does.
• Review dates nobody watches. An R item past its date should drop back to required automatically, not stay green in the register.
• Never moving items back up. A firmware upgrade or a new system can remove the impossibility; the level has to follow.

What cannot be applied in OT is never simply dropped. It is compensated, traced, dated and reviewed.

References

• ISO/IEC Directives, Part 2:2021 (9th edition), Principles and rules for the structure and drafting of ISO and IEC documents, clauses 3.3 and 7. cta.tech
• RFC 2119, Key words for use in RFCs to Indicate Requirement Levels (BCP 14), March 1997. rfc-editor.org
• IEC 62443-3-3:2013, System security requirements and security levels (clause 4.3, compensating countermeasures). webstore.iec.ch
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. nvlpubs.nist.gov