FISMA Role and Responsibilities

The assignment of roles and responsibilities for information security within the federal government was clarified or reiterated within FISMA to cover policy, procurement, standards, and incident response. Although FISMA was the last major legislative framework, over the years the foundation has been built upon by a series of Executive Orders, directives, policies, regulations, standards and guidelines. Within FISMA, several specific roles were identified: 

• Director of the Office of Management and Budget (OMB).

• National Institute of Standards and Technology (NIST).

• Federal Agencies:

• Head of Agency or equivalent.

• Chief Information Officer (CIO).

• Senior Agency Information Security Officer (SAISO).

• Secretary of Defense (SecDef).

• Director of the Central Intelligence Agency (CIA). 

Introduction to FISMA

The Federal Information Security Management Act (FISMA) was signed into law on December 17, 2002 as part of the E-Government Act of 2002 (Public Law 107-347). FISMA permanently reauthorized the framework laid out in the Government Information Security Reform Act (GISRA) of 2000, which expired in November 2002. FISMA is divided into multiple sections, each of which will be briefly described in this section.  

Purpose

FISMA was built upon several existing federal laws designed to ensure the security of federal information and information systems. These federal laws include the Computer Security Act of 1987 (Public Law 100-35), Paperwork Reduction Act of 1995 (Public Law 104-13), and Information Technology Management Reform Act of 1996 (i.e., Clinger-Cohen Act, Public Law 104-106, Division E). The purpose of FISMA, as outlined in Section 3541, is covered in six major objectives

1. Establishment of a framework for ensuring the effectiveness of security controls; 

2. Development of mechanisms for effective government-wide management and oversight of security-related risks; 

3. Development and maintenance of a minimum set of required security controls; 

4. Improvement of oversight of information security programs; 

5. Utilization of commercially developed information security products for protecting critical information infrastructures; and 

6. Selection of commercially developed information security solutions should be left to individual federal agencies. 

CRM Integration Capability/API/Web services

Making an analogy, a dialer is a machine gun of calls, and the CRM database is the ammo depot. Therefore it is important to make sure that the correct agent is calling the list of names or leads that are most appropriate to his or her skills or location as fast as possible. This is the reason why one of the fundamental questions to ask when specifying a dialer solution is if the organization requires the integration of the dialer solution with an existing or future CRM.

It is important to know if the dialer system comes with a list or lead-management database (or integration with an existing one is required) and offers an API or Web services capability to easily move data in and out as required.  

Therefore, when writing the RFP, it is crucial to make sure that all requirements linked with the integration with the support application are very well defined. In addition to clearly stating your needs, you must ask the potential vendors about their experience integrating their products with other clients and ask for references (and, of course, check those references). 

Conventional Dialers (power-dialers)

Conventional dialers (also known as power-dialers or autodialers) execute the basic function of dialing at a constant rate and transferring the call to a human attendant. The dialer device can also perform several other tasks, such as announcing verbal messages, leaving messages on answering machines, or transmitting digital data (like SMS messages). There are typically three types of power-dialers:  

• Conventional 

• Voice-message dialer 

• Click-to-call dialer  

Conventional: This type of dialer executes the basic functions of dialing from a list and transferring the call to a human attendant. In addition, these devices usually can monitor the dialed numbers and change them to seamlessly provide services such as least-cost routing. 

Voice-message dialer: This type of dialer is basically a conventional dialer that automatically dials a list of numbers and detects a live answer or fax/answering machine and plays a prerecorded voice message at the appropriate time. This is often called a voice-messaging dialer, or voice-message broadcasting. It completely automates the dialing process and is able to play a prerecorded message to hundreds or thousands of people in a short period of time. 

Click-to-call dialer: The agent sets the pace, and the function is minimal. This dialer provides very little leverage in that all it does is save the time to dial the phone number from a list. 

Preparing a Dialer Specification (RFP)

It is important to understand your specific needs in order to prepare an adequate RFP that guarantees you get what you need for the right price. Therefore, you need to define your dialing requirements, and based on them, identify the right technology and ideal contracting strategy. Only after that can you search for the adequate vendor. In other words, you can write the RFP only after you have defined your goals clearly. It is advisable to use a systems approach that encompasses: 

Analysis→ Design→ Implementation→ Evaluation  

When writing the RFP, you should be aware that vendors sometimes package their products and services in such a way as to make it difficult to make an easy comparison. For example, some hosted-dialer companies charge by the minute, others separate their charges by dialer port and local/long distance or VoIP minutes, and so on. In addition, vendors usually combine features and functions differently. Some charge more but include more functions, others break out and charge for each individual module or feature. The RFP is your instrument to define what you need and how you want to pay for it (trying to force some sort of the standardization in the proposals). It also helps to avoid paying for unnecessary features or functions. 

Dialing Rate Asynchrony

When there is an asynchrony between the dial rate and the available agents, you have a situation with two possible outcomes:  

1) There are more live parties on call attempts than there are agents available. 

2) There are more agents available than there are live parties on call attempts.  

Usually, when you have a situation like that, both situations occur intermittently.  

If we have more live parties on call attempts than there are agents available to take those calls, the dialer will disconnect or delay distribution of calls that cannot be distributed to an agent. This is known as a silent call or a nuisance call. The called party hears only silence when the predictive dialer does not at least play a recorded message. 

The experience for the clients who receive a silent call can be very unsatisfactory when we have an appreciable period of silence before a call is routed to a sales representative. This annoys people and also gives them a chance to hang up. A high rang-up/dropped calls rate is a clear indicator of asynchrony between the dial rate and the availability of agents. This is a big problem and we should be aware of the following facts:  

1) A very small percentage of the mailings are actual clients, and reaching them and then having no way to treat them is very disappointing from the company perspective. 

2) The client gets upset for getting a silent call. 

3) These calls have a cost which, depending on the hang-up rate, can be very significant. 

Some countries even regulate the number of silent calls that a company can make within a certain time frame. A good reference point on this problem is that a maximum of 3 percent of the calls, measured as a percentage of live calls made, may be dropped. More than that, and you may have a problem.  

In some countries there are regulations defining the need for a mandatory abandon message to be played when no agents are available and there is an obligation to inform the caller ID.  

If you have more agents available than there are live parties on call attempts, you will have agents idle, which reduces your productivity.  

Therefore, it is important to keep in mind that the asynchrony causes problems in both ways. If your predictive dialer is not able to adjust the dial rate properly, you will have moments in which you will have more calls than agents (silent calls and hang-ups/dropped calls) and moments with more agents than calls (low productivity and idle agents).  

It is worth mentioning an aspect, which, although operational, tends to have a big impact in the dialers’ productivity: if you mix databases of numbers already used several times (in which the concentration of bad numbers tends to be higher) and new databases in the same campaign, the results tend to be worse than if you keep them separated.