In theory, the concept of “Need To Know” is very logical and straightforward. If when working you need to know something (or use certain information), you will be able to access it. If, however, you don’t need access to that information, you should not have access to it. For example (despite being disputed), in most companies, your salary is something you need to know, but not other employees’ salaries. Another example is that certain teams require access to sensitive financial information, while others don’t require that data to operate.
In this article we’ll discuss:
"Need To Know" vs. "Default To Know"
“Default to know ” is a situation when employees in the organization with access to data, have access to almost all of the data. Although, it may be used to reference a healthy case in which the organization shares data by default in a secure way, it is mostly used to describe a situation where data access is not adequately controlled. The following are some typical cases:
- A very small company where it does not make sense to even place such limitations.
- A company with no meaningful or sensitive data.
- A company that’s growing quickly and prioritizes growth over the implicit risks of not having adequate data access control.
- A company that has an inadequate data access control and lives with the risks involved (until they don’t)
The significance of “default to know” is that these companies can incur significant security risks and compliance risks. The security risks are basically because numerous users can access data (specifically sensitive data), which increases data exposure risk, but they are not providing any value with it. Compliance risks result from improper access control, thus the organization will not meet the compliance requirements.
When & Why Do Companies Adopt A Need to Know Strategy?
It goes without saying that not all companies start from a “default to know” mindset. Some companies have a “need to know”approach from day one. However, there are some compelling events that may cause companies to adopt a “need to know” approach. Here are some of the main reasons:
A typical example is a company that starts its operation without having a CISO (or someone else leading its data security initiatives). Once this position is filled or added as part of the new function in the company, they assess that the current data sharing approach in the organization is risky and may cause a data exposure at one point or another. They then start a project to transform data access within the organization to a “need to know” approach.
This is similar to the above reason. In this case, the organization could have a failed audit, or simply the need to meet new compliance regulations or frameworks (for example: HIPAA or PCI). There is an understanding that having inadequate data access restrictions is simply unacceptable, and the project begins.
M&A Or IPO
In this case, the company is negotiating its next big step, either to be acquired by a larger company, or to go public. The demands (of the SEC or of the other party) are that the data access approach changes, to meet the security and/or compliance requirements of the other party.
Another example is when the company lands an important customer (or does this preemptively). One of the requirements of the new customer is for data to be controlled on a “need to know” basis.
There may be an executive decision, where the board or management places data security, or even directly identifies the issue of uncontrolled data access as a problem that should be fixed.
Why is it hard?
If this concept of restricted access to data is so easy to understand, why is it in many cases so hard to implement a “need to know” approach?
- The first reason is that it requires preliminary groundwork. In many cases, roles have to be defined with regard to data use. There also needs to be an understanding of what data is actually needed by the different users or roles, which could require additional work in discovering and understanding what data the organization even has.
- Another hardship is getting buy-in from all data stakeholders. Since free-for-all data access is very convenient, this is not always an easy task. Both data consumers who feel that this kills their innovation spirit, as well as, data owners who feel like they’re babysitting the data users may become upset. These hardships have to be solved through effective communication from the leadership, explaining why this change is vital, along with making the process as simple and fluid as possible.
- The “need to know” approach can also be hard to implement and get buy-in because it requires overhead that wasn’t previously necessary. Users who in the past were able to freely access data now require an additional authorization layer, which could result in a significant delay time-to-date. A clear data access policy can eliminate this delay, but the possibility of this delay may be the cause of backlash against these controls.
- A final hardship is that some of the requirements are not technically easy to implement. For example, data can be stored across different technologies, accessed by a multitude of tools. Therefore, the requirements may also be quite granular (for example: unless you’re from a certain geographic location you can’t access data of users from that region).
How Does Satori Accelerate the Process?
Satori accelerates and simplifies the process of moving from “default to know” to “need to know” in many ways, some of the main ones are:
- As the process reduces risks mainly when there is access to sensitive data, Satori’s continuous sensitive data discovery capability helps companies quickly and easily identify the data that needs to be classified as “need to know”. In addition, it can simplify the process, as companies can set access according to different data types, and easily mask unneeded sensitive data.
- Satori enables companies to set policies in alert mode. In other words, you can monitor the effect of restrictions prior to setting them, to reduce friction where data users get blocked from data they regularly use.
- With Satori you can apply the access and security policies across the different data platforms you’re using, without being limited by their specific capabilities.
- Using Satori, you can set access and security policies in a simple way that does not require writing any database code. This allows the security and data teams to work faster, where no line of SQL needs to be written.
- As in many cases imposing fine-grained access controls can slow down the project, however, setting them in Satori (for example: dynamic masking or row-level security) in a simple way can accelerate the project.
To learn more, schedule a meeting with one of our experts.