If you're reading this, you probably work in an industry with compliance mandates around protecting specific data types from misuse. And, like most businesses today, you probably use some kind of industry-specific set of applications that host that data — a health information management system in a healthcare setting, for example. So, your compliance focus — specifically those objectives around securing protected data – usually is on the application hosting that data, and not file servers on the network.

You might think the answer really depends on whether protected data resides on a given server. But you couldn’t be more wrong. As you’ll see in a moment, if your organization works with protected data, it definitely exists on file servers.

There are three reasons why you need to consider including your file servers as part of your compliance efforts:

Assuming you have an on-premise application hosting your protected data, that application runs on the same Windows server that also hosts file services. At the core of your industry-specific application is a database, right?  And what is that database? A file, of course! So, if you’re truly concerned about the security and compliance of your protected data, you need to be auditing the access to, and usage of those files (with the specifics dependent on your compliance mandate).

If you’re not watching those databases at a file level, it’s possible (with some careful planning) for someone to make copies of the databases. And, suddenly, you’re not longer compliant!

Some business models require the transmission of protected data. Credit card details come to mind, as does healthcare information being sent to process claims. That means data that was once safely housed in your industry-specific application, is now exported to a folder to be sent using some kind of file transfer application.

In theory, you should be using some kind of managed file transfer solution, but if you’re still using plain old FTP over an SSL connection, there is a period of time when your protected data is potentially exposed.

The moment a user saves a PDF report, performs an export of data, or writes correspondence in a Word doc that includes protected information, the server hosting any of these files is now subject to compliance.

In each of the three scenarios above, the onus is put upon IT to understand how protected data exists in their organization outside the application. The first two scenarios above are relatively easy – just identify where the databases and exported files are located, and put the necessary controls in place, such as file auditing, to monitor access to these data sets.

The third scenario is where it gets a bit tricky. Without some kind of DLP solution, or something that monitors file contents for protected data formats (e.g. a social security number format of ###-##-####), you’re never going to know. So, to certain you have compliance under control, you need a) a solution to tell you where your protected data is, and b) a file auditing solution to monitor access.