Compliance mapping in a security tool looks like content work. Write the control set, map findings to controls, ship the pack. Customers ask for it by name, and it is the kind of feature that demos well.
We measured our own before building an industrial one, and the result reordered the work.
The measurement
The compliance engine attributes a finding to a control through a class token. A finding is classified from its title, description and weakness identifier, and each resulting token is looked up in a framework's map.
We took 22 real finding titles from our own industrial modules and ran them through the classifier. Two classified. Both were wrong.
So a full industrial audit, producing findings about a controller with no protection level, a coil readable without authentication and a safety system reachable from the business network, attributed none of it to any control in any framework. The engine was working. Nothing was producing a token for an OT finding.
The ordering trap
Now consider what happens if the 62443 pack gets built first, which is the obvious order and the order a customer request implies.
The pack lands. Its controls are correct. Its map is keyed on class tokens. The classifier still produces nothing for an industrial finding, so the pack scores zero, and it does so silently: a framework page showing no findings looks exactly like a plant with no problems.
That is worse than not shipping the pack. A compliance surface that reads as clean because nothing reached it is the most expensive kind of wrong, and it is the kind nobody reports as a bug.
What we did instead, and what we refused
The fix was vocabulary, and the first decision was to invent no new tokens.
The framework maps consume around 190 class tokens. We checked which of them had no producer, expecting to find OT-shaped classes waiting to be filled. There were three, all of them unrelated to industrial systems. There was no OT class sitting unused.
So inventing something like an industrial-protocol-exposed token would have produced a token nothing consumes: a finding classified, a control never lit, and coverage that exists only in a log line. That is the failure this codebase repeats, and there is now a guard test that fails if a future rule invents one.
Industrial findings map onto classes that already exist and are already consumed. A controller answering with no authentication is broken authentication. An OPC UA endpoint offering no security policy is cleartext transport and a cryptographic failure, and it earns both because those are different control families. A level crossing is a network segmentation failure, which is the class 62443 zone and conduit requirements will key on when that pack is built.
Proven rather than asserted: the eight classes resolve to 146 control edges across up to 13 shipped frameworks.
The part that is a refusal
Not every industrial finding should classify, and forcing a match rate to look good is its own defect.
An ICONICS server announcing itself, an IEC 61850 endpoint on port 102, a BACnet device answering Who-Is: these are devices behaving exactly as their standards specify. They belong in the inventory, not in a compliance failure. A class token tells the engine to light a control, so classifying an inventory row reports a compliance failure that nobody found. A test pins that boundary, because it is the one a future contributor would relax to raise a number.
Sixteen of the 22 now classify. The six that do not are the identification rows, and that is the correct answer rather than a remaining gap.
The defect that had nothing to do with OT
One more thing surfaced, and it is worth passing on to anyone writing a classifier.
The legacy classifier matched a three-letter token as a plain substring. That token appears inside the word "enforced". So "TLS 1.2 is enforced on this endpoint", "Password policy is not enforced" and "The resource was not found" all classified as remote code execution, including rows whose entire content is that a control is in place. A four-letter token did the same to "SQLite database file readable".
Each one lit a control in the compliance fan-out and showed the customer a critical class the scan never found. Short acronyms match on word boundaries now.
The general lesson is that in a system where a token decides how a finding is treated, the matcher is not a convenience. It is a control, and it deserves the same scrutiny as the thing it feeds.
Frequently asked questions
Why would an IEC 62443 compliance pack show no findings after an industrial audit?
Because the classifier that maps findings to controls had nothing that recognised OT findings. Out of 22 real industrial finding titles tested, only two classified, and both were wrong. A full audit including a controller with no protection level and a safety system reachable from the business network lit zero controls in any framework.
Why build OT compliance vocabulary before an IEC 62443 framework pack?
Building the pack first is the obvious order, but if the classifier still produces nothing for industrial findings, the pack scores zero silently, and a framework page with no findings looks exactly like a plant with no problems. That is worse than not shipping the pack, so the vocabulary had to come first.
How are industrial findings mapped to existing compliance control classes?
No new class tokens were invented. Industrial findings were mapped onto existing, already consumed classes: a controller with no authentication became broken authentication, an OPC UA endpoint with no security policy became both cleartext transport and a cryptographic failure, and a level crossing became a network segmentation failure.
Should every industrial finding classify as a compliance failure?
No. Devices such as an ICONICS server announcing itself, an IEC 61850 endpoint on port 102 or a BACnet device answering Who-Is are behaving exactly as their standards specify, so they belong in the inventory, not as a compliance failure. A test pins this boundary so match rates cannot be inflated.
What classifier bug caused false positive remote code execution findings?
A legacy classifier matched a three-letter token as a plain substring, so it appeared inside the word enforced and misclassified phrases including Password policy is not enforced as remote code execution. A four-letter token did the same to SQLite database file readable. Short acronyms now match on word boundaries.
How many of the tested industrial findings ended up classifying correctly?
Sixteen of the 22 tested finding titles now classify against a compliance control. The remaining six are identification rows, such as a device simply announcing itself on the network, and not classifying them is the correct answer rather than a remaining gap in coverage.