Learn how Invu interacts with protected documents

Invu Electronic Document Management (eDM) historically had a long-standing behaviour of not allowing users to store protected documents. This stemmed from an underlying principle that the eDM system should be a single source of access control for your business documents. Conceptually it was the system’s role to determine who could and couldn’t view a document within your business.

However, as our customers started getting to grips with GDPR, we started to receive feedback and enhancement requests that they now needed to allow the storage of protected documents. These requests seemed to be primarily driven by the fact that they were receiving an increasing volume of incoming documents with some form of protection applied.

In response to this customer demand, our 6.14 release added a new configuration option to allow protected document storage; however we made it optional and retained the existing default behaviour. Why? Well, as the saying goes, “just because you can, doesn’t mean you should”.

How are documents protected?

It is worth taking a moment to consider what constitutes a “protected document” as the technologies can vary. In practice it is any file, whether it’s an email, a PDF or a Microsoft Office document, to which some sort of protection mechanism has been applied directly to the document in order to control access.

At a practical level, this mechanism might be as simple as a password which controls the opening of the document, but it could be a more complex encryption technology (where the content is converted from readable plain text into scrambled ciphertext) and decrypted based upon pre-shared certificates and private keys. Encryption is particularly common with emails, but in either of these cases it is based on something you know (the password) or something you’re in possession of (the key).

Protection may also take the form of sophisticated Information Rights Management (IRM) technologies such as Microsoft’s Azure Information Protection. In this case, permissions are now being brokered in real-time by a third-party to enforce restrictions such as basic access controls or even the ability to use certain functions such as print or copy within a document.

Why should an eDM product be concerned with whether a document it is storing is protected or not?

At a technical level, we’re actually not.  There is a fundamental concept in eDM that we store a document exactly as provided, returning it to the appropriate user when requested, exactly as it was originally. It is a simple concept that means if you submit a protected document to Invu eDM, that document will be returned exactly as submitted, including any protection.

At a product functionality level, it only really causes us an issue where the software needs to read the document to provide some additional capability. If those document-level protection measures prevent us from opening the document for example, then we will not be able to generate a thumbnail image for it. If we are prevented from scraping the document content, then we will not be able to make that document content searchable. There is a reduction in feature capability, but it does not prevent the system from performing its basic storage and retrieval functionality.

The business challenge of storing protected documents

The issues are more difficult to answer at the business level.  Suppose one of your users stores a password-protected document today.  Are they still going to be an employee, and crucially remember the password, when you need to retrieve that document in 5 years’ time?  With an unprotected document, the answer would be simple: the eDM software determines your right to access the content. However, with a protected document, the eDM system determines your right to access the protected file, but you have another level of protection to pass before you can access the document content.

One could argue that the business challenges of encryption and IRM technologies on documents are even greater. Why? Because the process is often transparent to your end-users. If they open a document and are prompted for a password, it is then a very conscious decision to store that password-protected document in the eDM system.

But technologies like Azure Information Protection do a very good job of making the rights management transparent. If your user opens a Word document and it just opens as normal (regardless of the sophisticated but invisible IRM checks happening in the background) the easy perception for a user to make is that it is “just a normal Word document”. However, in our 5 years later scenario, when the business tries to retrieve said document, that IRM may now refuse access based on a changed security permission or revocation of rights. At a business level, you may have diligently stored the shell of a critical document, but, in reality, you don’t have a guarantee of future access to its content.

Conclusion

In the post GDPR world, where the onus is often on protecting information in transit, it is a very difficult decision as to whether you then allow these protected files to be stored as, and form the basis of, your business-critical documentation. Which is why in Invu eDM we made it an optional configuration.

If you do choose to allow protected document storage, we have made provision on the Data Protection tab to indicate where a stored document appears to be protected, the search implications of that status and to highlight possible future access issues.

To loop back round to the title of this article, Invu eDM will certainly allow you to store protected documents if you wish to, but you might want to give some thought as to whether you should be allowing it.