IoTOSI+

In order to get proper information risk management and audit in place for IoT, on top of IoTsec, the frames of mind should be grown and extended so at least they touch, if not overlap in a coherent way.
Where IoTsec-and-IRM-and-audit is about the I and C of All Of ICT, we could do worse than to have a look (back) at the OSI stack. All People Seem To Need Data Processing, remember. (Not even a question mark but a period Or else go back and study, a lot.)
Which we should extend, clarify for IoT, and deepen in detail, downwards towards the sensors and actuators, and upwards beyond the A level into … Meaning, like, Information and stuff ..?

As an interlude, you already deserve:

Heh, ‘smart’phone pic; not FLlW but Van ‘t Hoff’s Villa Henny. As here in Dutch, though that states the style would be related to FLlW only – wiping the ‘near-perfect carbon copy’ aspect under the rug…
Now here’s a few actual FLlW’s…:

How’zat for copying ‘in a style related to’…!
[Sorry for the pic quality; these scanned from analog…]

Now then, back to the OSI stack and the absence of Security in that. Audit is even further away; the orphaned nephew (role, function!) will be attached later to the whole shazam.
Given that the A is there for Application, do we really have anything like the function of the communications/data at that level or higher up ..? Well, it seems Higher Up is where we should aim indeed, as a starting point. And end point. Because the information criteria (being the quality criteria that information may or may not meet) play at that level. Resulting in all sorts of security measures being applied everywhere ‘in’ the OSI stack itself [as a quick Google shallows shows] for safeguarding these criteria at lower levels; lower in the sense of below the Meaning level i.e. A and down.

Because, the CIAEE+P (as partially explained here and here) regard quality criteria in order to ‘have’ appropriate data as medium in which Information may be seen, by interpretation, and by letting it emerge from it. (Sic, times two.) Above which we might, might possibly, even have Meaning getting attached to Information. (Big Sic.)

Oh, and, the even-below P-level implementation I’d relegate to the, usually not depicted, physical not-comms-box-but-signal-source/destination physical objects of sensors and actuators… Obviously.

So, all the Security in the picture regards the quality criteria, and the measures taken at all levels to enhance their achievement. Enhance, not ensure. Because whoever would use ‘ensure’ should be ashamed of their utter methodology devastation.
And, to be honest, there is some value in having measures at all levels. Since the grave but too common error of doing a top-down risk analysis would require that. And a proper, due, sane, bottom-up risk analysis would still also have this, in a way.
Where the conclusion is: Requirements come from above, measures to enhance meeting any requirements, should be built in as extensively and as low down as possible, only extended upwards as needed. Note that this wouldn’t mean we could potentially do without measures at some level (up), since the threats (‘risks’) would come in at intermediate and upper levels, too, not having been taken care of at lower levels ‘yet’.
Audit, well… just checking that all is there, to the needs whims of apparently unintelligent requirement setters…

I’ll leave you now; comments heartily welcomed…