Understanding DCAR

The first real step toward implementing a DCAR system is deciding whether you need one. That decision begins with understanding the four components or basic requirements of a DCAR system: discovery, compliance, archive, and retrieval. This understanding, in turn , requires you to build up a set of concepts and buzzwords .

Disclosure

If you are disclosing something, you are providing information relevant to an issue or problem ”but in DCAR terms, disclosure is proactive and closed-ended. You decide what gets disclosed, to whom, and how much. When you put a DCAR policy in place, your organization has the opportunity to selectively reveal information when it s useful to do so. This is particularly handy when the information being released is relevant to a suit, public opinion, or even FOIA requests to government agencies. Moreover, when internal disputes arise between departments or between individuals, your human resources group can use the disclosure policies to find information related to internal debates.

Discovery

Simply put, discovery just means that you can find particular data when you want it. The term discovery has a specific legal meaning that s discussed more fully in Chapter 20; for now, suffice it to say that discovery is something you re usually compelled to do by a law enforcement agency, civil or criminal subpoena, or other legal requirement. Disclosure and discovery appear to be the same, but they re not: disclosure is closed-ended and proactive, whereas discovery is reactive (usually beginning when your legal counsel gets one or more subpoenas) and can be ongoing. In a real discovery, companies are faced with ongoing requirements to manage the location and report information relevant to the subpoenas, versus the one-off approach of disclosing some information.

Your business framework and policies will define who is responsible for initiating a discovery request within the DCAR system. Regardless of who initiates it, you ll need to have an IT tool that facilitates managing the subpoena or case. Considering 60 percent of the information a user needs to do his or her job is in e-mail (according to a report issued by Osterman Research in March 2003) you ll want a tool to manage discovering electronic mail.

In a discovery, the easiest approach is typically to mark items as either relevant or not relevant to a particular discovery request. Alternatively, your firm might be required to produce e- mails for a particular group of people for a specified time frame, so your discovery tools should facilitate the production and allow for internal review, without modifying the existing contents. The subpoena or discovery request might also have specific requirements to show that you haven t modified the contents.

Retention and Deletion

Of course, any DCAR setup has to begin with a retention policy. You cannot just delete your e-mail within 90 days as a company-wide policy; in McCabe v. British American Tobacco (BAT) , the defendant was cited for destruction of evidence when they had knowledge the information could be used in a legal case. It s safe to say that having no policy at all is inappropriate for most companies; that leaves you to identify, along with your cross-division team, whether you want to retain e-mail for everyone in the company or just a select few. For example, if you are a pharmaceutical company, you d want to keep mail related to the engineering and creation of new drugs, screenings, clinical trials, FDA approvals , and so on. Laws protect people, so always keep in mind who the laws that apply to you are supposed to protect ”that will help you decide what e-mail you need to keep, based on its impact on those protected people.

Storing the content for the long term is also a challenge. Some firms in certain industries suffer subpoenas on a daily basis, so they need the retained information to be available in near real time to satisfy frequent discovery requests. Other companies receive only one or two major subpoenas in as many as five years , so storing the content on slower, lesser expensive media makes economic sense given the limited demand.

Do you have to keep content forever? The answer is dependent on the laws, regulations, and case law that currently exist. For example, in the case of McCabe v. BAT , the information McCabe requested was for a previous suit, and BAT had already deleted it under the pretense that it was no longer relevant. However, given the markings used for the content, such as knock out, the judge ruled that BAT had knowingly deleted information relevant to future litigation. Because McCabe v. BAT was the future litigation, BAT was fined. So, knowing when you can delete and when you can t is a tough situation. At a minimum, you ll be keeping relevant e-mail around for up to five years and in some cases (as with health care organizations that are subject to the U.S. HIPAA regulations) as long as 20 years. Also, you must ensure that your retention and deletion process offers the ability to put information soon to be expired on hold so it s not deleted.

Compliance

Compliance can be simply explained: you follow the law and no one ( especially you) gets fired or goes to jail. Of course, this is a pretty unsubtle definition; there are certainly nuances that can affect the details of your compliance processes.

Corporate governance is the first element. It is the business framework developed by your legal, compliance, and internal audit groups to control your messaging systems and policies. Your company must take a distinct look at the three drivers to a compliance policy: statutes, regulations, and case law. How do legal, compliance, and internal audit groups go about affecting the business framework of best practices?

The legal department is responsible for interpreting the company s response to the current case law and statutes. In some cases they might be called to review and establish corporate opinion on the regulations. As a messaging administrator or consultant, you won t generally be blessed, or cursed, with the accountability, authority, or responsibility to make these judgments . Your legal department is the place to take all questions and concerns regarding business as such as defined in SEC rule 17-a4.

The compliance team is usually made up of representatives from several groups (more on that in a bit). The team is responsible for driving the business framework on a day-to-day basis. They will play a key role in helping the legal staff define frameworks to meet whatever regulations apply to the company; besides industry- specific regulations like those issued by the NASD, NYSE, or SEC, there might be laws (or statutes, to use a more precise term) that apply, like the USA Patriot Act, the Graham-Leach-Bliley Act (GLBA), or the Sarbanes-Oxley Act.

Internal audit groups are responsible for attesting to the validity of the IT and financial systems. In some cases, these internal audit groups will consist of a Certified Information Systems Auditor (CISA) or Certified Financial System Auditor (CFSA). The audit group will work with legal and compliance to establish tests and procedures to ensure the corporate governance (framework, controls, and so on) is followed. In some cases, the audit group might be an outside firm representing the interests of regulators, stockholders , and others.

Archival and Retention

Your compliance policy will dictate three things:

• What mail has to be archived; for example, which senders, recipients, subjects, topics, or date ranges of messages have to be kept for however long is required.

• How long messages have to be archived.

• Exactly how they have to be archived. (Paper copies? Magnetic tape or disk? Optical media? We ll cover the details a bit more later.)

The archival and retention policy and system you use has to be designed to meet these three dictates: it has to capture mail from the right people, store it safely, and allow messages to be retrieved when necessary. Obviously, a system that can do cool tricks like perform keyword searches of archived traffic is superior to one that just blindly dumps every message into a folder somewhere.

Ongoing Surveillance

If you are a financial firm or a health care institution, you are required to protect the privacy and authenticity of information leaving your organization. Most documents created and distributed to the public are examined to make sure they don t contain anything sensitive; however, e-mail is ad hoc, and the free flow of e-mail would significantly dilute the successful processes most organizations have come to accept. Therefore, most regulations that require surveillance suggest that post hoc review is sufficient to protect against fraud, especially that which grows over time. Simply put, surveillance is reading a subset of all e-mails being sent and received within certain groups at your company. Those same groups might have all outgoing mail monitored as well. It is up to your compliance, audit, and legal groups to define the matrix of people and e-mail delivery for you to capture and provide for surveillance.

Surveillance differs from discovery in that the period of management is typically the previous day or week and includes a random subset (between 1% and 10%) of e-mails. Your surveillance tool should allow your compliance group to have daily pools of e-mail to process, as well as provide a relevant marking scheme directed at compliance. Items of record in compliance are marked as reviewed, not reviewed, or questioned. The whole point behind surveillance is for your firm to make a credible attempt at showing that it is meeting the surveillance requirements imposed by an outside entity (like the SEC or the NASD).

The Key Players

As a messaging person, DCAR systems put you in a somewhat odd position. After all, you manage the systems that create and store the data that need to be captured, but you re probably not involved with the teams that are going to be driving the DCAR creation and maintenance process. The best way for most organizations to address this gap is to create a cross-functional team with members from various units of your organization. Teams made up of members from various departments ensure you are getting an enterprise compliance picture, versus a solution that focuses on IT s preferences and biases. Ultimately, business groups will define what must be done. IT will need software with the flexibility to execute services that empower the users to perform under the business goals. There are a variety of groups that can contribute useful knowledge or skills:

• Internal audit departments have the necessary expertise to help you understand what regulations need to be met. In some regulations there are minimums to e-mail surveillance. Typically, you ll have someone who carries a certification in financial systems or information systems auditing (CFSA/CISA).

• The compliance department will be assisting you with the user interface requirements. This department is a critical stakeholder, considering the department members will be the day-to-day users of the compliance solution you implement in conjunction with the DCAR. In addition, they have practical expertise around the execution of the business frameworks. Your solution will impact their ability to perform under the business requirements.

• The office of the general counsel (or whatever your company calls its chief lawyer) will be critical when asking questions about company requirements under regulations and statutes. Always be on the look out for case law changes and make sure the system you choose is flexible enough to deal with changes on an ongoing basis. New regulations and statutes surface slowly, but a judicial decision can occur overnight.

• Your network services folks will notice an uptick in network traffic when your DCAR system starts ingesting e-mail. They will need to know what is going on and should provide you with the necessary bandwidth to support the DCAR requirements. Always keep in mind that this is an important service and not just an additional application. If you have trouble with network services, talk to the legal, compliance, and audit departments to gain management support.

• If your organization has a group in charge of document management (and the odds that they do are excellent if you re legally obligated to keep e-mail), they can help you build business retention categories for the system. Document management is very different from e-mail DCAR, so don t get talked into buying or using a document management system for e-mail retention. On the other hand, if you can reuse a taxonomy someone in the company already built, that will save you a significant amount of work both now and later.

• You ll have to put all this archived data somewhere, so if your company has a storage management team, they ll need to be involved. Of course, buying more storage is expensive, but because the goal of DCAR systems is to reduce your legal costs, buying more storage might turn out to be a better deal.

• Your corporate security group can help you identify specific classes of information that are high, medium, and low risk. It s always helpful to get their blessing on your DCAR system, because a single archive of all your dirty messaging laundry is a terrifically tempting target for an attacker. In many organizations, the legal and security divisions co-own and comanage DCAR systems for this very reason.

• Users are worried about performing their work, not compliance issues. However, compliance and IT services collide at the user s desktop. This means you need to be prepared for conflict negotiation between the corporate governance planners and end users, or their representatives. The bottom line is that your DCAR system will have to meet the compliance requirements you re subject to without needlessly making users jobs harder.