In assessing ‘compliance’ of your … [fill in the blanks and then colour the picture], do you actually go for correct set-up and design, and operating effectiveness ..?
If so, you’d be ready when the design is suitable.
Though a great many of you would still consider operating effectiveness proven by repeated measurement and establishing everything runs smoothly according to procedures, including the capture and re-alignment of exceptions.
But you would be wrong. That’s just verification in the weakest form.
Actual operating effectiveness would have been dictated (meant literally, not ‘literally’-figuratively) by an appropriate design. The design should be such that there is no way in which, e.g., any transaction could escape procedures, ever.
Which would require very careful study of procedures, the result of design. Which would fail when the design wasn’t aimed for totalitarian control. Which is the case; the design almost always is focused on obtaining the most basic of functionalities of a system – that includes catering for some exceptions, the bulk of the foreseeable ones; at most – not capture all and everything as that would indeed be impossible ex ante. Hence, the inherent impossibility of total operating effectiveness. There’s always unheard-of, thought to be impossible exceptions at the lowest levels of detail. (Let alone in the infrastructure on which any system would have to run, at about all abstraction layers of ‘system’ that one can study.) And there’s Class Breaks, and penny-wise but pound-foolish type of ‘exceptions’ at higher abstraction layers (all the way up to ‘the CEO wishes this. He (sic) only has to wish for it to be done already’).
So, already in the design phase, you know to fail at Operating Effectiveness later, however perfect you think you’re doing. And you delude yourself further if you’d think that the design will be implemented perfectly. On the contrary, in the implementation the very reality will have to be dealt with, where the nitty-gritty will derail your ideas and something that is a bit workable at all, will be the most you can achieve. Always, ever.
Hence there too, you lose a lot of ‘perfection’.
Whihc may show in operations or not. If you don’t look careful enough, you might arrive at a positive conclusion about somewhat-effective control operations. That has little to do with effective operations by the way; the latter (client service) being greatly disturbed by your ….. (insert expletive describing subpar quality) controls.
If you look careful enough … you don’t even have to; just point out where controls didn’t operate effectively and qualify that as total SNAFU.
Oh yes, in theory (contrasting practice) it just might work, by having all sorts of perfectly stacked control loops on top of control loops (as detailed here) but these have their leakage and imperfections as well and would have to be infinitely stacked to achieve anything approaching closure so nice try but no cigar.
Conclusion:
Set-up/Design and Implementation are everything, Operating Effectiveness follows: OE fails logically.
ISAx Statements Type I or II: Logically inherently deficient hence superfluous money- and paper waste.
Revert to Understanding and opining on your guts. It takes guts, yes, as risky as that is, but pretension of logical reasoning and/or sufficiently extensive proof-of-the-pudding auditing (on the paper-based pudding …) cannot but fail: Non-compliance found: negative rating; no non-compliance found: failed at the task.
I’m done now. For you:
[Just a side corridor, neatly controlled (for!) decoration]
