Once the knowledge production is structured, it becomes easier to define a knowledge control/security policy, by assigning a different level of access and responsibility to different organizational units.
A positive side-effect of this definition is: identifying the “knowledge boundaries” for each organizational unit limits the need of cross-functional meetings to those where the subject is new or clearly spans across “knowledge boundaries”.
As each item is classified while being defined, it becomes possible to delegate without losing control : this will reduce the number of resources needed to cope with a larger number of projects, using external resources only when and for how long is really needed, and without any loss of knowledge.
As described above, adopting a sound Knowledge Management policy based on Knowledge Retention makes investment on knowledge and knowledge costing possible.
Why the title of this issue links “knowledge retention” to “embedded security”?
Knowing which items of your knowledge thesaurus are “core” and should be maintained inside your organization ensures that you can improve your business continuity capabilities, also when delegating to third parties one or more processes.
What is “embedded security”? Security management is quite often considered an additional set of processes, almost an afterthought.
But this externalisation of security implies that you try to build up walls (virtual or real), without actually involving those who produce the knowledge and therefore should know its operational sensitivity.
It is true that those above them know how, within the “formal organization”, that knowledge impacts on other areas of business: but also if those managers are promoted from the rank-and-file, eventually they will lose knowledge of the current, real, “informal organization”, and its informal communication flows (more appropriately, “back channels”).
Security (both physical and logical) does not come cheaply, and 100% security is simply impossible.
Our concept of “embedded security” is quite simple: instead of adding security after your processes, try to focus on identifying who is responsible for each specific knowledge subset, and involve them in the definition of the related security profile, with the support of your security experts or “internal audit”.
Maybe you will discover that some of the security can be “embedded” in the actual processes involved in producing the knowledge, minimizing your security overhead.
Knowledge-based security profiling increases the accountability of knowledge producers, while ensuring compliance with your own internal policies.
Further additional layers of security would just (expensively) increase the perceived security, while impeding the knowledge distribution that is needed to actually generate value, and creating a false sense of security in knowledge producers