Background
What is Confidential Information?
Confidential information, in this context, refers to any information that must not be disclosed outside the organization. This can include sensitive information such as employee personal data and customer personal information, as well as unpublished essential data that could lead to insider information. It could also be merely rules or processes decided within the company.
People Who Overprotect Confidential Information
As an engineer, you might have heard complaints such as "We can't use the cloud" or "We can't use generative AI services" at least once.
But why is that? Is it really impossible to use these services?
In reality, it might just be overprotection. To be blunt, it's the adamant refusal to disclose information that, quite frankly, isn't a big deal. It's akin to treating it like a sheltered daughter.
Of course, there are indeed important and sensitive pieces of information that truly cannot be disclosed. However, many of the information we possess isn't of that nature. Nevertheless, there's a tendency to assume that all internal information is sensitive and shouldn't be disclosed. It's as if people haven't even heard of .gitignore. Overprotection is not only antique; it's a stubborn, bad culture. Because of it, we can't use the cloud or web services.
Stop the Overprotection
I propose that we should stop overprotecting confidential information. As a Knowledge Architect, I often provide this suggestion when addressing client issues.
So how do we reduce overprotection? It's straightforward and boils down to the following two points:
- Define and categorize the nature and types of confidential information.
- Specify the "truly confidential information" as a refusal list.
It's just like .gitignore. Identify and specify what you don't want to disclose. Let's call this refusal list a protection policy.
Implementing the Protection Policy
The protection policy should have two tiers:
- 1: What is defined uniformly across the company
- 2: What is defined within teams or projects
In other words, a minimum company-wide policy must exist, and it must be adhered to. Put differently, as long as you're following the company-wide policy, other information can be disclosed (uploaded to the cloud or input into generative AI).
However, this alone isn't practical (since the confidential information handled varies by team or project), so there should also be room for individual policies. That's where point 2 comes in.
By the way, how successfully you can relax the company-wide policy in 1: will determine how functional the protection policy is. After all, we're calling strict company-wide policies "overprotection."
Proposing to Clients
Topics such as overprotection and protection policies can also be proposed to clients. In fact, to perform engineering properly, it's beneficial to actively suggest this approach and collaborate to develop policies together. Professionally, this might be taken on by a Knowledger. Alternatively, software engineers can be trained to handle this.
If you can't reduce the client's overprotection, the only thing awaiting you is a nightmare; engineering must be done with overprotection as a given. This leads to unnecessarily large development efforts or excessive security on things that don't need protection. Naturally, this results in increased costs and timelines, leading to a less favorable impression from the client. Justifying this with claims of security or confidentiality is a path to hell.
If you're tired of these nightmares, consider addressing overprotection.
Top comments (0)