Quite simply, today's legal system
considers email to be an official form of business communication just
like written memos. This means that any type of legal requirement or
legal action against your organization (regarding business records)
will undoubtedly include email. Unless you work in a specific vertical
market such as healthcare or financials, the emergence of compliance
and governance as topics of import to the messaging administrator is a
relatively recent event. The difference between compliance and
governance can be summarized simply:
Governance is the process of defining and enforcing
policies, while compliance is the process of ensuring that you meet
external requirements.
However, both of these goals share a lot of common ground:
They require thorough planning to implement,
based on a detailed understanding of what behaviors are allowed,
required, or forbidden.
Though they require technical controls to ensure implementation, they are at heart about people and processes.
They require effective monitoring in order to audit the effectiveness of the compliance and governance measures.
In short, they require all the same things you need
in order to effectively manage your messaging data. As a result,
there's a useful framework you can use to evaluate your compliance and
governance needs: Discovery, Compliance, Archival, and Retention, also
known as the DCAR framework.
DCAR recognizes four key pillars of activity, each
historically viewed as a separate task for messaging administrators.
However, all four pillars involve the same mechanisms, people, and
policies; all four in fact are overlapping facets of messaging data
management. These four pillars are described in the following list:
Discovery
Finding messages in the system quickly and
accurately, whether for litigation, auditing, or other needs. There are
generally two silos of discovery:personal discovery, allowing users to find and monitor the messages they send and receive, and organizational discovery,
which encompasses the traditional litigation or auditing activities
most messaging administrators think about. It requires the following:
Good storage design to handle the additional overhead of discovery actions
The accurate and thorough indexing of all messaging data that enters the Exchange organization through any means
Control
over the ability of users to move data into and out of the messaging
system through mechanisms such as personal folders (PSTs)
Control of the user's ability to delete data that may be required by litigation
Compliance
Meeting all legal, regulatory, and governance
requirements, whether derived from external or internal drivers.
Although many of the technologies used for compliance also look similar
to those used by individual users for mailbox management,
compliance happens more at the organization level (even if not all
populations within the organization are subject to the same regimes).
It requires the following:
Clear guidance on which behaviors are
allowed, required, or prohibited, as well as a clear description of
which will be enforced through technical means
The means to enforce required behavior, prevent disallowed behavior, and audit for the success or failure of these means
The ability to control and view all messaging data that enters the Exchange organization through any means
Archival
The ability to preserve the messaging data that
will be required for future operations, including governance tasks.
Like discovery, archival happens on two broad levels: the user archive
is a personal solution that allows individual users to retain and reuse
historical personal messaging data relevant to their job function,
while the business archive is aimed
at providing immutable organization-wide benefits such as storage
reduction, eDiscovery, and knowledge retention. It requires the
following:
Clear guidance on which data must be
preserved and a clear description of procedural and technical measures
that will be used to enforce archival
The accurate and thorough indexing of all messaging data that enters the Exchange organization through any means
Control
over the ability of users to move data into and out of the messaging
system through mechanisms such as personal folders (PSTs)
Retention
The ability to identify data that can be safely
removed without adverse impact (whether immediate or delayed) on the
business. Although many retention mechanisms are defined and maintained
centrally in the organization, it is not uncommon for many
implementations to either depend on voluntary user activity for
compliance or allow users to easily define stricter or looser retention
policies for their own data. It requires the following:
Clear guidance on which data is safe to
remove and a clear description of the time frames and technical
measures that will be used to enforce removal
The accurate identification of all messaging data that enters the Exchange organization through any means
Control
over the ability of users to move data into and out of the messaging
system through mechanisms such as personal folders (PSTs)
If many of these requirements look the same, good;
that emphasizes that these activities are all merely different parts of
the same overall goal. You should be realizing that these activities
are not things you do with your messaging system so much as they are
activities that you perform while managing your messaging system. The
distinction is subtle, but important; knowing your requirements helps
make the difference between designing and deploying a system that can
be easily adapted to meet your needs and one that you will constantly
have to fight. Many of these activities will require the addition of
third-party solutions, even for Exchange 2010, which includes more DCAR
functionality out-of-the-box than any other previous version of
Exchange.
What makes this space interesting is that many of
these functions are being filled by a variety of solutions, include
both on-premise and hosted solutions, often at a competitive price.
Also interesting is the tension between Microsoft's view of how to
manage messaging data in the Exchange organization versus the defined
needs of many organizations to control information across multiple
applications. More than ever, no solution will be one-size-fits-all;
before accepting any vendor's assurance that their product will meet
your needs, first make sure that you understand the precise problems
you're trying to solve (instead of just the set of technology buzzwords
that you may have been told will be your magic bullet) and know how
their functionality will address the real needs.
In our discussion of DCAR, we deliberately left out a common keyword that you inevitably hear about. Journaling
is a common technology that gets mentioned whenever compliance,
archival, and discovery are discussed. However, it often gets
over-discussed. Journaling is not the end goal; it's simply a mechanism
for getting data out of Exchange into some other system, which provides
the specific function that you really want or need.
Very simply, journaling allows Exchange
administrators to designate a subset of messaging data that will
automatically be duplicated into a journal report
and sent to a third party — another mailbox in the Exchange
organization, a stand-alone system in the organization, or even an
external recipient such as a hosted archival service. The journal
report includes not only the exact, unaltered text of the original
message, but additional details that the senders and recipients may not
know, such as any BCC recipients, the specific SMTP envelope
information used, or the full membership list and recipient
distribution lists (as they existed at the time of message receipt).
These reports are commonly used for one of two purposes: to capture
data into some other system for archival, or to provide a historical
record for compliance purposes.
We don't know a single Exchange administrator who
has ever come up to us and said, "I want to journal my data." Instead,
they say, "I need to archive my data and I have to use journaling to
get it to my archival solution." Journaling isn't the end goal; it's
the means to the end. If journaling is a potential concern for you, you
should stop and ask yourself why:
What information am I trying to journal?
What do I want the journaled information for?
Perhaps most important, what am I going to do with the journaled information?
Understanding why you need journaling will give you
the ammunition you need to effectively design your Exchange
organization, journaling requirements, and appropriate add-on
applications and hosted solutions. It will also help you identify when
journaling may not be the answer you need to solve the particular
business problems you're facing.
You should also understand the impact that
journaling will have on your system, as well as know what limitations
journaling has. There are certain types of data that never get
journaled, and if you need that data, you'll have to at a minimum
supplement your solution with something that captures that data.
