Naturally, sometimes sensitive or confidential information must be stored in the document manager. For example, you may have documentation related to people’s salaries, documents containing business secrets, people’s medical information or any kind of personal information (PII – Personally Identifiable Information). That’s what a document manager is for, isn’t it? To store any type of digital asset with value for the company. Below we review the options you have to protect documents and field values when they contain sensitive information.
The first level of defence of this information is permissions. You can, for example, store sensitive documentation in a certain space and ensure that only certain authorised users can consult the documents in this space. This would be the basic option you have, using the permissions of the spaces. This has the advantage that it is easy to maintain. You simply add or remove users from the groups with permissions on the space.
However, we do not always have the possibility to segregate all documentation or sensitive information in a specific space. Sometimes, only part of the documentation of a file, specific documents, etc. is sensitive. For these cases, a more granular system of permissions must be used: permissions by object.
Permissions by object in Athento allow you to grant and control access at the document level. In this way, I can have a file with 100 documents and each of those documents could have specific access permissions. One user could see only 88 documents in the file, while another user could see the whole file.
Of course, such a granular system of permissions is much more complex to maintain than the first option we discussed. That’s why we always recommend using them judiciously.
Permissions per object in Athento can be assigned by means of automatisms. Since Athento has the possibility to execute automatisms in the edition of fields, we can, for example, use a field of type users to assign dynamically and on demand the permissions, or, we can have a field “Confidentiality Level” with a dropdown that shows options like “Confidential“. As soon as the user adds a confidentiality classification, Athento can assign permissions dynamically.
Another option that can be considered is author-only permissions. That is, users can only view documents that they have created themselves.
The staff of the service or software provider will have access to the documents on an ad hoc basis for support, troubleshooting or maintenance purposes. These accesses must of course be logged in the software so that they can be traced. The supplier must have a secure access policy and all guidelines related to data processing.
However, it is recommended that if we have confidential, sensitive or PII information, we take some measures. In this sense, Athento offers us the ability to anonymise the value of a field so that support staff cannot see its content. For example, if we have a “Salary” field in the employee files, we can indicate to Athento that the field contains sensitive information that we don’t want its staff to have access to. This is done from the field configuration.
If what we want is that the file that is part of the document in Athento – PDF, Word, JPG or whatever format – cannot be viewed by Athento staff, we can indicate in the space that it contains sensitive information. In this case, the preview of the documents is disabled for Athento staff users.
As you can see, there are multiple options for protecting the confidential or sensitive information we work with. In addition, it is important to bear in mind that a document management system is characterised by maintaining an audit trail of the actions carried out on documents. This is essential in order to – while not preventing unwanted access – measure the extent or impact of such access.
Permissions, authentication and censorship functionalities such as those we have seen in this article can help us to keep our information secure.