<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Stephen Foskett, Pack Rat &#187; record retention Archives  &#8211; Stephen Foskett, Pack Rat</title>
	<atom:link href="http://blog.fosketts.net/tag/record-retention/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.fosketts.net</link>
	<description>Understanding the accumulation of data</description>
	<lastBuildDate>Fri, 10 Feb 2012 17:40:43 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
	<atom:link rel="hub" href="http://superfeedr.com/hubbub" />
			<item>
		<title>The Deletion Dilemma</title>
		<link>http://blog.fosketts.net/2011/04/10/deletion-dilemma/</link>
		<comments>http://blog.fosketts.net/2011/04/10/deletion-dilemma/#comments</comments>
		<pubDate>Sun, 10 Apr 2011 15:00:35 +0000</pubDate>
		<dc:creator>Stephen</dc:creator>
				<category><![CDATA[Enterprise storage]]></category>
		<category><![CDATA[Personal]]></category>
		<category><![CDATA[Andres Rodriguez]]></category>
		<category><![CDATA[delete]]></category>
		<category><![CDATA[deletion]]></category>
		<category><![CDATA[legal hold]]></category>
		<category><![CDATA[Nasuni]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[record retention]]></category>
		<category><![CDATA[seminar]]></category>
		<category><![CDATA[webinar]]></category>

		<guid isPermaLink="false">http://blog.fosketts.net/?p=5160</guid>
		<description><![CDATA[When was the last time you deleted data? Even at home, where we have autonomy and authority over our own data, many of us are digital pack rats. But at work? Never! No one ever deletes anything! Let's talk about why this is.]]></description>
			<content:encoded><![CDATA[<div id="attachment_5162" class="wp-caption aligncenter" style="width: 239px;  border: 1px solid #dddddd; background-color: #f3f3f3; padding-top: 4px; margin: 10px; text-align:center; display: block; margin-right: auto; margin-left: auto;"><a href="http://static.fosketts.net/wp-content/uploads/2011/04/Delete-by-blmurch.jpg" ><img class="size-full wp-image-5162 " title="Delete by blmurch" src="http://static.fosketts.net/wp-content/uploads/2011/04/Delete-by-blmurch.jpg" alt="" width="229" height="300" /></a><p style=' padding: 0 4px 5px; margin: 0;'  class="wp-caption-text">Deletion of data is not a high priority for most IT shops, but this ought to change</p></div>
<p>When was the last time you deleted data? Even at home, where we have autonomy and authority over our own data, many of us are digital pack rats. But at work? Never! No one ever deletes anything! Let&#8217;s talk about why this is.</p>
<h3>Retention vs. Deletion</h3>
<p>Just about everything we do in IT infrastructure is focused on retention. We back up our data and implement other data protection tools like snapshots and mirrors. We might also archive data so that the General Counsel can place legal hold on it, as well as perform data discovery during litigation. And then there&#8217;s the whole field of data security, focused on locking people out of data, keeping it intact and un-viewed.</p>
<p>But what about deletion? Almost no effort is put towards removing data, though the rapid growth of storage might lead one to think this is a key area for IT. We certainly could put some effort on revision control, and especially deleting drafts and outdated data. We could easily expire content that was no longer needed, if only we had some way to know that. And we&#8217;ve talked a lot about secure deletion, even though we hardly ever actually perform that task except when moving to new physical storage hardware.</p>
<p>The greatest challenge for deletion is a simple question: What should we delete and when?</p>
<p>IT can not answer these questions. They must be put to the business people who really own the data. Without permission and buy-in, IT is in serious legal peril when it comes to deleting data: Any deletion must be in accordance with policy and must be legal, that is there is no legal or regulatory hold on it. And there is no way most IT staff feel empowered to do that!</p>
<h3>Some Data Should Be Deleted</h3>
<p>Certainly, not all data should be saved. There is &#8220;low-hanging fruit&#8221; in every storage estate that can and should be deleted:</p>
<ul>
<li>Ephemeral copies &#8211; Drafts, temporary data, working copies</li>
<li>Time-limited projects – Third-party or client data, test and development</li>
<li>Expired data – Retention policies that are expired and no legal hold remains</li>
<li>Legally required &#8211; Data that isn&#8217;t yours, or that legal demands deleted</li>
</ul>
<p>Tackling these data sets is much easier to tackle than cleaning out primary data stores, since it doesn&#8217;t require as much sifting and sorting: These data sets can often be identified programmatically! If you have data sets like these, this is the ideal place to start a deletion effort.</p>
<h3>Delete on Demand</h3>
<p>Regardless of the type, however, IT should not delete data without direction. It is perilous in today’s legal environment to destroy data without a policy directing that action. So we should continue to focus on retention for most data, while we work with legal to determine which data can be deleted and come up with a process for approval.</p>
<p>But it&#8217;s important to start offer a deletion-friendly environment for certain data types. Such a storage system would reduce the difficulties associated with data deletion. Really, only an integrated solution can truly delete data:</p>
<ul>
<li>It must maintain custody of data from start to end and not allow it to leak all over the organization</li>
<li>It must be accessible since any restrictions tempt users to create &#8220;working copies&#8221;, thus thwarting deletion</li>
<li>It must be secure – Data must always be encrypted to avoid remnants on media</li>
<li>It must be protected so data will not spread to external systems and sites</li>
</ul>
<h3>Stephen&#8217;s Stance</h3>
<p>Data deletion is a real problem for most IT shops. I&#8217;m just getting my head around the ramifications, and continue to look for an ideal deletion-friendly storage solution.</p>
<p>If you&#8217;re interested in the topic of data deletion, I recommend joining me for a webinar on the topic on Wednesday, April 13. Sponsored by Nasuni, I will discuss the dilemma of deletion and CEO Andres Rodriguez will weigh in about the capabilities of his cloud storage solution. <a href="http://www.nasuni.com/resources/cloud-storage-webinars/deletion-dilemma/?utm_source=FoskettServices&amp;utm_medium=ODG&amp;utm_campaign=DeletionWebinar" >Register now!</a></p>
<blockquote><p>Note: Nasuni is sponsoring this webinar, but the content was created by me. This blog post is intended to engage my audience in discussion of the subject, and is not a paid promotion or advertisement.</p></blockquote>
<p><em>Image credit: &#8220;Delete&#8221; by </em><a rel="nofollow" href="http://www.flickr.com/photos/blmurch/" ><em>blmurch</em></a></p>
<div id="crp_related"><h3>You might also want to read these other posts...</h3><ul><li><a href="http://blog.fosketts.net/2011/05/17/5476/"  rel="bookmark" class="crp_title"></a></li><li><a href="http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/"  rel="bookmark" class="crp_title">Answering Your Email Archiving Questions</a></li><li><a href="http://blog.fosketts.net/2007/09/20/enterprise-storage-is-nearing-its-demise/"  rel="bookmark" class="crp_title">Enterprise Storage Is Nearing Its Demise!</a></li><li><a href="http://blog.fosketts.net/about/stephen-foskett/multimedia/"  rel="bookmark" class="crp_title">Multimedia</a></li><li><a href="http://blog.fosketts.net/2008/02/07/how-long-should-companies-retain-email/"  rel="bookmark" class="crp_title">How Long Should Companies Retain Email?</a></li></ul></div><script src="http://feeds.feedburner.com/~s/sfoskett?i=http://blog.fosketts.net/2011/04/10/deletion-dilemma/" type="text/javascript" charset="utf-8"></script><hr />
<p><small>© sfoskett for <a href="http://blog.fosketts.net">Stephen Foskett, Pack Rat</a>, 2011. |
<a href="http://blog.fosketts.net/2011/04/10/deletion-dilemma/">The Deletion Dilemma</a>
<br/>
This post was categorized as <a href="http://blog.fosketts.net/category/everything/enterprisestorage/" title="View all posts in Enterprise storage" rel="category tag">Enterprise storage</a>, <a href="http://blog.fosketts.net/category/everything/personal/" title="View all posts in Personal" rel="category tag">Personal</a>. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.<br/>
</small></p>]]></content:encoded>
			<wfw:commentRss>http://blog.fosketts.net/2011/04/10/deletion-dilemma/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Long-Term Versus Longer-Term Archiving</title>
		<link>http://blog.fosketts.net/2008/12/02/long-term-archiving/</link>
		<comments>http://blog.fosketts.net/2008/12/02/long-term-archiving/#comments</comments>
		<pubDate>Tue, 02 Dec 2008 14:46:03 +0000</pubDate>
		<dc:creator>Stephen</dc:creator>
				<category><![CDATA[Enterprise storage]]></category>
		<category><![CDATA[Personal]]></category>
		<category><![CDATA[AIIM]]></category>
		<category><![CDATA[archiving]]></category>
		<category><![CDATA[ASCII]]></category>
		<category><![CDATA[data archive]]></category>
		<category><![CDATA[disk]]></category>
		<category><![CDATA[media]]></category>
		<category><![CDATA[paper]]></category>
		<category><![CDATA[papyrus]]></category>
		<category><![CDATA[PDF]]></category>
		<category><![CDATA[record retention]]></category>
		<category><![CDATA[records]]></category>
		<category><![CDATA[tablet]]></category>
		<category><![CDATA[tape]]></category>
		<category><![CDATA[toot toot]]></category>
		<category><![CDATA[webinar]]></category>
		<category><![CDATA[XML]]></category>

		<guid isPermaLink="false">http://blog.fosketts.net/?p=1163</guid>
		<description><![CDATA[How will you retain records for the long haul? It depends on how you define &#8220;long&#8221;. Nearly everyone (individual and business alike) has certain records to retain for years, and some may need retention for decades or centuries. How can you accomplish this? First, consider whether to store records as atoms or bits. You can [...]]]></description>
			<content:encoded><![CDATA[<p>How will you retain records for the long haul? It depends on how you define &#8220;long&#8221;. Nearly everyone (individual and business alike) has certain records to retain for years, and some may need retention for decades or centuries. How can you accomplish this?</p>
<p>First, consider whether to store records as atoms or bits. You can convert paper to data or vice versa, and there are pros and cons to both:</p>
<ul>
<li>Properly handled physical (paper or film) records should last for hundreds of years and can remain readable without software or devices. But they&#8217;re hard to search (you need an index), and paper is bulky, heavy, and difficult to work with.</li>
<li>Digital records can either be stored offline or kept &#8220;alive,&#8221; but questions remain about their long-term reliability and readability. Living records can be easy to search and use, and digital storage can be very space-efficient, but data tends to pile up &#8220;out of sight.&#8221;</li>
</ul>
<p>Long-term storage of records on physical media is proven &#8211; think about papyrus, tablets, gold or nickel discs, film, and paper. But will digital media fare as well? Data tapes and disks can degrade over time, and manufacturer reliability specs are based on accelerated testing, not actual experience. Regardless of media type, careful handling can extend media life.</p>
<p>But will you still be able to read it? Tapes and optical disks require additional hardware to read, while disk drives are paired with their read heads. Software applications are needed to read and interpret data (backup, archiving, compression, encryption, deduplication, database) as well. What about content format? Should you use ASCII, XML, PDF/A?</p>
<ul>
</ul>
<p>I&#8217;ll be presenting a webinar on this topic tomorrow, Wednesday, December 3, at 2:00 PM Eastern time. <a href="http://www.aiim.org/Events/register.aspx?id=288"  target="_blank">Register on-line</a> at the AIIM web site and join me for the discussion!</p>
<div id="crp_related"><h3>You might also want to read these other posts...</h3><ul><li><a href="http://blog.fosketts.net/2008/12/03/thoughts-longterm-archiving/"  rel="bookmark" class="crp_title">Thoughts on Long-Term Archiving</a></li><li><a href="http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/"  rel="bookmark" class="crp_title">Webcast: Automating Policy With Email Archiving Technology</a></li><li><a href="http://blog.fosketts.net/2008/02/07/how-long-should-companies-retain-email/"  rel="bookmark" class="crp_title">How Long Should Companies Retain Email?</a></li><li><a href="http://blog.fosketts.net/2008/12/04/enhanced-archive-platforms-netapp/"  rel="bookmark" class="crp_title">White Paper: Enhanced Archive Platforms with Agility for NetApp</a></li><li><a href="http://blog.fosketts.net/2008/10/20/managing-email-e-discovery/"  rel="bookmark" class="crp_title">Six Critical Steps For Managing Email E-Discovery</a></li></ul></div><script src="http://feeds.feedburner.com/~s/sfoskett?i=http://blog.fosketts.net/2008/12/02/long-term-archiving/" type="text/javascript" charset="utf-8"></script><hr />
<p><small>© sfoskett for <a href="http://blog.fosketts.net">Stephen Foskett, Pack Rat</a>, 2008. |
<a href="http://blog.fosketts.net/2008/12/02/long-term-archiving/">Long-Term Versus Longer-Term Archiving</a>
<br/>
This post was categorized as <a href="http://blog.fosketts.net/category/everything/enterprisestorage/" title="View all posts in Enterprise storage" rel="category tag">Enterprise storage</a>, <a href="http://blog.fosketts.net/category/everything/personal/" title="View all posts in Personal" rel="category tag">Personal</a>. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.<br/>
</small></p>]]></content:encoded>
			<wfw:commentRss>http://blog.fosketts.net/2008/12/02/long-term-archiving/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Webcast: Automating Policy With Email Archiving Technology</title>
		<link>http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/</link>
		<comments>http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/#comments</comments>
		<pubDate>Wed, 08 Oct 2008 17:30:22 +0000</pubDate>
		<dc:creator>Stephen</dc:creator>
				<category><![CDATA[Enterprise storage]]></category>
		<category><![CDATA[Personal]]></category>
		<category><![CDATA[AIIM]]></category>
		<category><![CDATA[Email archiving]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[record retention]]></category>
		<category><![CDATA[toot toot]]></category>
		<category><![CDATA[webcast]]></category>

		<guid isPermaLink="false">http://blog.fosketts.net/?p=851</guid>
		<description><![CDATA[If you&#8217;re interested in email archiving or record retention policy automation, I just recorded a webcast for AIIM titled Automating Policy with Email Archiving Technology. I talked about email retention best practices, matching technology to your needs, and making it happen in the real world. I&#8217;ll update this with a link to the recording when it&#8217;s [...]]]></description>
			<content:encoded><![CDATA[<p>If you&#8217;re interested in email archiving or record retention policy automation, I just recorded a webcast for <a href="http://aiim.org"  target="_blank">AIIM</a> titled <a href="http://www.aiim.org/Events/register.aspx?id=283"  target="_blank">Automating Policy with Email Archiving Technology</a>. I talked about email retention best practices, matching technology to your needs, and making it happen in the real world. I&#8217;ll update this with a link to the recording when it&#8217;s available.</p>
<div id="crp_related"><h3>You might also want to read these other posts...</h3><ul><li><a href="http://blog.fosketts.net/2008/02/07/how-long-should-companies-retain-email/"  rel="bookmark" class="crp_title">How Long Should Companies Retain Email?</a></li><li><a href="http://blog.fosketts.net/2008/07/01/10-key-considerations-for-email-archiving/"  rel="bookmark" class="crp_title">10 Key Considerations for Email Archiving</a></li><li><a href="http://blog.fosketts.net/2008/08/20/get-email-archiving-project-approved/"  rel="bookmark" class="crp_title">Trying To Get An Email Archiving Project Approved?</a></li><li><a href="http://blog.fosketts.net/2011/05/17/5475/"  rel="bookmark" class="crp_title"></a></li><li><a href="http://blog.fosketts.net/2008/12/02/long-term-archiving/"  rel="bookmark" class="crp_title">Long-Term Versus Longer-Term Archiving</a></li></ul></div><script src="http://feeds.feedburner.com/~s/sfoskett?i=http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/" type="text/javascript" charset="utf-8"></script><hr />
<p><small>© sfoskett for <a href="http://blog.fosketts.net">Stephen Foskett, Pack Rat</a>, 2008. |
<a href="http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/">Webcast: Automating Policy With Email Archiving Technology</a>
<br/>
This post was categorized as <a href="http://blog.fosketts.net/category/everything/enterprisestorage/" title="View all posts in Enterprise storage" rel="category tag">Enterprise storage</a>, <a href="http://blog.fosketts.net/category/everything/personal/" title="View all posts in Personal" rel="category tag">Personal</a>. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.<br/>
</small></p>]]></content:encoded>
			<wfw:commentRss>http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Answering Your Email Archiving Questions</title>
		<link>http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/</link>
		<comments>http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/#comments</comments>
		<pubDate>Fri, 05 Sep 2008 16:00:36 +0000</pubDate>
		<dc:creator>Stephen</dc:creator>
				<category><![CDATA[Enterprise storage]]></category>
		<category><![CDATA[archiving]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[business case]]></category>
		<category><![CDATA[data archive]]></category>
		<category><![CDATA[data backup]]></category>
		<category><![CDATA[e-discovery]]></category>
		<category><![CDATA[Email archiving]]></category>
		<category><![CDATA[litigation hold]]></category>
		<category><![CDATA[Mimosa]]></category>
		<category><![CDATA[PST files]]></category>
		<category><![CDATA[record retention]]></category>
		<category><![CDATA[retention schedule]]></category>
		<category><![CDATA[webinar]]></category>

		<guid isPermaLink="false">http://blog.fosketts.net/2008/09/05/answering-your-email-archiving-questions/</guid>
		<description><![CDATA[My webinar on building a business case for email archiving was very well-attended, so I was not able to get to everyone during the question and answer section. Since the questions were really excellent, I thought I would include them (and my responses) here. How to improve the receptivity of the e-mail archieve message to [...]]]></description>
			<content:encoded><![CDATA[<p>My <a href="http://blog.fosketts.net/2008/08/20/trying-to-get-an-email-archiving-project-approved/"  target="_self">webinar on building a business case for email archiving</a> was very well-attended, so I was not able to get to everyone during the question and answer section. Since the questions were really excellent, I thought I would include them (and my responses) here.</p>
<p><span id="more-599"></span></p>
<ul>
<li><strong>How to improve the receptivity of the e-mail archieve message to management to overcome the biases you mentioned?</strong> Consider what management is interested in most: They don&#8217;t necessarily care about email archiving, but they will respond to well-presented solutions to business objectives like cost avoidance for litigation and e-discovery or future reduced spending on IT infrastructure (storage).</li>
<li><strong>How do you get things moving when Legal is sponsor and can demonstrate that one lawsuit discovery failure will be the same cost as the project?</strong> This would be an ideal scenereo. Legal probably already understands the high cost of e-discovery and potential risk of adverse judgement. Now demonstrate the ways that email archiving can help. But be realistic &#8211; an email archiving app will help with e-discovery, but is definitely not a complete solution. You will still need policy and process for hold and discovery, and may even need additional e-discovery tools.</li>
<li><strong>Have you seen standard or default retention periods for email, and how are they determined?</strong> I would not want to suggest standard or &#8220;rule of thumb&#8221; retention periods. In my experience with many organizations, I have seen such a wide variety of carefully considered retention schedules that I have come to believe that there is no such thing as a standard. However, I would like to suggest not making a too-short maximum (say, less than three months) or else you will drive end users to underground archiving to get around the policy. Such a short retention period can work for certain classes of messages (company picnic, lunch invites, mass mailings), but I can&#8217;t imagine a business where no one would need to keep messages longer. Try to be realistic in setting your retention, balancing productivity with compliance. Setting retention periods is an exercise in consensus building, with representatives from IT, Legal, HR, Compliance, and others each contributing their own needs. It&#8217;s doable, though &#8211; I do it for a living!</li>
<li><strong>How many years back do people hold on to mail typically?</strong> Most organizations lack standards or policies for retention, so their typical retention varies based on employee actions. When they do have retention policies for email, they tend to classify messages (by organization or user, keywords, or through user action) into a few &#8220;buckets&#8221; with appropriate retention for each. Most have short retention (3 to 9 months) for some content, and longer retention (on the order of a few years) for other types. Most also have a &#8220;keep forever&#8221; category for special record types.</li>
<li><strong>Do you have an opinion on whether journaling is better or not for meeting legal requirements?</strong> Most legal groups desire the most complete set of messages possible. Both journaling and log shipping should meet this need.</li>
<li><strong>Have you seen much use for email archiving for supporting Audit to prove that an event was reviewed and approved?</strong> Many organizations use email as part of their workflow. In these cases, maintaining a complete set of messages is critical for audit and compliance. Many certainly do use email archives for this purpose, while others prefer to route such approvals to other content management systems to maintain these records.</li>
<li><strong>Is there a legal argument to be made that getting rid of pst files and having a central archive will help with privacy law issues?</strong> Decentralized personal archives like PST files are a privacy nightmare waiting to happen &#8211; they are highly mobile, can be copied and viewed easily, and tend to &#8220;live&#8221; on theft-prone devices like laptops and portable drives. Replacing PST files with a centralized archive has many many benefits, and the reduced risk of privacy breaches is certainly among these. However, most mail clients still maintain offline caches of mail server (and archive) data, so simply replacing PST with an archive will not elimate the privacy risk.</li>
<li><strong>You might want to mention that accelerating volumes of stored email are not necessarily bad because it is electronic and therefore searchable. Offline stuff dumped into file servers with no meta data is actually more of a nightmare because no one knows who created it or why it is needed (or not).</strong> Adding structure to electronic stored information is always valuable, and email archives certainly do make that data much more organized and searchable, along with enabling retention policies to be applied (assuming they exist!) Unstructured data on file servers is indeed a nightmare, and can pose a serious risk. There are other tools to tackle this type of data, however, and they might do a better job than relying on an email archive as a primary repository of critical records.</li>
<li><strong>Can you elaborate on user training needs? I was under the impression that changes to the end user were minimal.</strong> The amount of impact an email archiving system has on end users can vary from minimal to significant, based mostly on how much user interaction is desired for classification. However, even the most unobtrusive system is likely to change certain aspects of user behavior, from PST files to searches to stubbing and deletion of messages. Therefore, training is probably needed with every email archiving implementation.</li>
<li><strong>Litigation holds can last for YEARS !! Tape is DEAD especially to try to rebuild mail boxes.</strong> Tape remains non-dead for certain applications like backup, despite years of prognostication. However, you are correct that e-discovery of data on tape is incredibly difficult and time-consuming for most systems. There are tools to help, but an online archive is vastly more flexible and speedy than recovering backup data from tape. I&#8217;ve seen backup-sourced e-discovery costs rise into the millions of dollars, too!</li>
<li><strong>How important is classification in an archive solution?</strong> The importance of classification depends on the business objectives that an archive is meant to serve. However, most implementations will require at least some message classification mechanism in order to determine how long different messages should be retained, since a one-size-fits-all retention schedule is unlikely to meet anyone&#8217;s needs. Therefore, it is important to begin developing an overall record retention policy for email when implementing an email archive, and to consider how messages will be classified. Classification of email messages is a complicated topic &#8211; worthy of its own webinar at least!</li>
<li><strong>We are a globally dispersed organization which increases the complexity and cost. Do you feel implementation is an all or nothing scenario or does it make sense to focus on domestic and large campuses and then in a second phase chase funding for remote and international sites?</strong> Dispersed organizations face many unique technical challenges, especially when implementing email archiving. Certainly it is better to have some archiving than none at all, but unless your retention requirements are also segmented by geography, focusing on only a single location can be risky. I&#8217;d definitely suggest starting with the biggest fish, but you will probably have to get to everyone fairly soon afterward.</li>
<li><strong>Are there solution that do both email and file data (shared folders) archiving?</strong> Yes, some email archiving products also do file archiving. However, some choose to implement these functions separately to keep one from standing in the way of the other &#8211; it&#8217;s more important to have some archiving than to wait and wait for a complete solution.</li>
<li><strong>Not to mention, extremely short retention periods for email messages will NOT allow an enterprise to comply with litigation hold needs&#8230;</strong> Once a litigation hold is ordered, all retention schedules for covered data must be suspended. Therefore, a short retention schedule does not necessarily preclude compliance with a legal hold order. However, unreasonably short retention will not look good in court!</li>
</ul>
<div id="crp_related"><h3>You might also want to read these other posts...</h3><ul><li><a href="http://blog.fosketts.net/2008/02/07/how-long-should-companies-retain-email/"  rel="bookmark" class="crp_title">How Long Should Companies Retain Email?</a></li><li><a href="http://blog.fosketts.net/2008/07/01/10-key-considerations-for-email-archiving/"  rel="bookmark" class="crp_title">10 Key Considerations for Email Archiving</a></li><li><a href="http://blog.fosketts.net/2008/03/31/key-technical-differences-between-email-archiving-products/"  rel="bookmark" class="crp_title">Key Technical Differences Between Email Archiving Products?</a></li><li><a href="http://blog.fosketts.net/2008/10/20/managing-email-e-discovery/"  rel="bookmark" class="crp_title">Six Critical Steps For Managing Email E-Discovery</a></li><li><a href="http://blog.fosketts.net/2008/10/08/automate-policy-email-archiving-2/"  rel="bookmark" class="crp_title">Webcast: Automating Policy With Email Archiving Technology</a></li></ul></div><script src="http://feeds.feedburner.com/~s/sfoskett?i=http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/" type="text/javascript" charset="utf-8"></script><hr />
<p><small>© sfoskett for <a href="http://blog.fosketts.net">Stephen Foskett, Pack Rat</a>, 2008. |
<a href="http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/">Answering Your Email Archiving Questions</a>
<br/>
This post was categorized as <a href="http://blog.fosketts.net/category/everything/enterprisestorage/" title="View all posts in Enterprise storage" rel="category tag">Enterprise storage</a>. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.<br/>
</small></p>]]></content:encoded>
			<wfw:commentRss>http://blog.fosketts.net/2008/09/05/answering-email-archiving-questions/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

