What Works: Locking Down Requirements for an Email Management Solution

First consider your platform-related requirements. These appear in a number of areas.

• Messaging application and version. Most organizations are standardized on a single type of email server. Even if this is not the case, the requirements should state which application(s) and version(s) are to be supported. For example: “The email archiving application shall archive all messages from within Microsoft Exchange 2007” or “The email archiving application shall support journaling from within Microsoft Exchange 2003 and 2007, including currently available service packs.”
• Email client application and version. This is not generally as important because so many of the email management solutions are either hosted or application servers, but for those that rely on client integration, or a plug-in, this can be critical. For example: “The email archiving application shall allow users to determine which messages to save manually using Microsoft Outlook 2007 or IBM Lotus Notes 8.5.”
• Next, the requirements may specific which protocols and approaches must be supported. This is less common simply because most organizations don’t know or really care which protocols are being used. However, the challenge is that different protocols and approaches allow for different functionality. For example, SMTP relays can interact with all messaging applications, and log shipping is only supported on Microsoft Exchange 2007 but provides robust capture of all changes to the Exchange database and can be used for disaster recovery as well.
• Server operating system and version. This is less important for most solutions but there are some that are required to run on Windows Server 2003, for example.
• User operating system and version. If there is a client or plug-in, it may not run on all operating systems – better to specify and ensure all supported operating systems are identified. For example: “The security client must run on Windows XP, Service Pack 2, and on Windows Vista Ultimate Edition.” Finally, some solutions require a relational database to store archived messages. An organization that runs Oracle or Microsoft SQL Server should specify that the solution be compatible with the particular RDBMS and version that it is running.

The next area to consider is archiving requirements. Archiving-specific requirements might include:

• Whether the system supports single-instance storage of messages.
• Whether the system is to auto-archive, such as by age.
• Whether and how the system will manage personal archive files. For example, a requirement might state, “The system shall allow administrators to prohibit the creation of personal archive files.”
• How the system will address existing messages, whether they are located in the message store, personal archive files, or any other archives. For example, “The system shall be able to import messages from personal archive files.”

A litigation support requirements are key to many organizations. Some considerations for requirements include:

• Support for litigation hold across the entire system, or systems.
• Support for holds of varying granularity, such as for a single user, group of users, or department.
• Review and production of messages and attachments. This includes being able to search across multiple users’ inboxes and multiple systems; it may include a scoped review, such that authorized users could only search on a particular user’s, group of users’, or departmental messages.
• Export of messages in native format, whether in messages (.msg or .eml) or in a personal archive file (.pst or .nsf).
• Annotation and redaction of messages to indicate their status (reviewed, privileged, work product) or to exclude sensitive information such as Social Security numbers. For example, “The system shall allow authorized users to annotate messages to indicate status.”

Requirements relating to records management and retention are common, though many of these requirements focus less on the email management solution and more on exporting messages to another system such as an ECMS or ERMS. Retention-related requirements might include: - Classification of messages as records vs. non-records.

• Classification of messages according to an organizational classification structure such as a taxonomy or retention schedule.
• Retention of messages throughout the lifecycle, however the lifecycle is defined, - Disposition of messages at the end of the lifecycle.
• Tamper-proof storage of messages, attachments, and metadata, particularly for those declared as records. 
• Integration of the formal records retention schedule into the client or messaging application, such that users either can or must declare messages as records.

Email Management technology solutions are very robust and comprehensive. It is critical that you understand what your requirements are before you study the diverse functionality across the many solutions that exist.

Want to learn more about requirements for Email Management technology solutions? AIIM’s EMM Specialist training program provides much more information. 

Carl Weise is a Certified Records Manager and an Industry Advisor for AIIM.