Apply to all platforms, not just mobile. Another key principle is that InfoTrust is not a mobile information security standard. It's for all devices: smartphones, tablets, computers, cloud services, and platform technologies yet to be invented. Again, it's not about the device, but the information, which flows across all sorts of devices and apps. The device, app, and service are irrelevant, unless they don't support the standard.
Operating systems, applications, and cloud services will need to support InfoTrust to act on the embedded policies in the documents, just as they need to support EAS today to apply password and encryption policies. But as a lingua franca that enables full participation in the emerging world of anywhere computing, the key vendors have every reason to participate and not end up being excluded. The tech industry has plenty of examples of what happens when companies delay joining such essential bandwagons — just ask what used to be Novell or IBM's former Lotus group.
Not manage more than is necessary. Note what's not included: controls over sharing, an encryption option, controls over allowed applications, access management, and identity management. Sharing controls are not needed because the documents carry their own permissions; if they are shared (lost, stolen, emailed, copied to a thumb drive, whatever), the receiving party has to satisfy the access requirements to gain access. It's the same notion as trusting that encrypted documents are safe in today's privacy-breach regulations. Speaking of encryption, that means the documents are automatically encrypted, unless they have no access rights applied.
There's also no need to worry about what app or service that users have on whatever device or computer they're working with. If the app doesn't support the access and policy requirements, the document can't be opened in that app — end of problem. The goal, as my colleague Terry Retter likes to characterize it, is the ability to be secure even when operating in the middle of Times Square.
If a business has other reasons to enforce the use of specific apps (such as for compliance logging or to monitor and control distribution of supersensitive documents), it should use a MAM-style tool to restrict users to that tool for those specific documents that need the extra compliance. But there is no reason to burden everyone for such a subset of use cases.
Today's MAM and MDM tools are essentially network-based, requiring a device or app to check in with a central server to validate and even enforce its permissions and policies. That's not scalable for information management —you can't require a server call every time a document is opened or is acted upon when in use. Yes, sessions can preserve the policies when offline, but that's cumbersome and is of no help when you're offline before you open the document. Network-based validation needs to be required for only the most critical documents.
Sign up for CIO Asia eNewsletters.