Differences

This shows you the differences between two versions of the page.

--- how_do_we_move_away_from_trust_but_verify_approach_to_compliance [2022/11/07 10:10] – created hans
+++ how_do_we_move_away_from_trust_but_verify_approach_to_compliance [2023/03/07 09:03] (current) – Testing hans
@@ Line 17: / Line 17: @@
 As people do work, they will react to changes based on their understanding of what needs to be done. This means that a team, for example, might decide that the designated compliance approach does not make sense for the particular work they are doing; the implementation is now “out of compliance.” While this sounds bad, it is actually a good thing. We have a potential learn from the experience. Perhaps the issue is a result of a lack of understanding of the compliance implementation. Perhaps the issue is a result of something that really needs to be adjusted. Perhaps the issue is that it really does not make sense to apply this compliance to this specific situation.
-No matter what we have a potential learning. So rather than a “trust but verify” approach we need to use an “assume (compliance) has drifted and address (correct)” approach. If you have set things up appropriately it will be easy to detect drifting compliance. Treat this as a signal and don’t just assume the product needs to be brought into compliance. Let the organization learn.
+No matter what we have a potential learning. So rather than a “trust but verify” approach we need to use an “assume (compliance) has drifted and address (correct)” approach. If you have set things up appropriately (automation is your friend😀) it will be easy to detect drifting compliance. Treat this as a signal and don’t just assume the product needs to be brought into compliance. Let the organization learn.
 {{tag>FAQ Behavior Culture Transformation Compliance}}