This step is provided to allow the receiver to request additional information about the request from the requester. The receiver now attempts to ask for more information about the request to better understand the request. The step can also be repeated if additional information is required; however, when no additional information about the request can be obtained, the "no" option is selected. The "no" option leads the receiver to either defer or refer the request. Every time more information is obtained, the "yes" option is selected and a test is once again performed to determine whether the receiver understands what is requested.

It is very important to determine whether the receiver is knowledgeable enough to perform the request in full. This step differs from the first step, because the receiver has to measure whether he/she has the required knowledgeable to perform the request and not whether the request itself is understood. The receiver performs this measurement based on the own capability to understand the procedure required to perform the request. If the receiver has the necessary knowledge to perform the request, the "yes" option is chosen and the receiver proceeds to the following step. In the case where the receiver does not understand how to perform the request, the "no" option is chosen.

Once the receiver has verified that he/she understands how to perform the request, it needs to be determined whether the receiver is capable of performing the request. This step measures whether the receiver has the means or capability to perform the request, in other words whether he/she is able to determine which option to choose. If the "no" option is taken, the request is deferred or referred to another individual. Otherwise, the "yes" option is selected and the next step involves the receiver's authority to perform the request.

The receiver needs to measure whether he has the required authority to perform the request. Even though at this step the receiver may already have determined that he/she understands how to perform the request and is capable of performing it, it must still be determined whether the receiver has the authority to perform the request. This step therefore measures whether the receiver, as part of his or her duty, has the authority to provide the requester with the requested action or information. If the receiver has the necessary authority, the "yes" option is taken, otherwise the "no" option is selected. This is the last step for the receiver to measure him- or herself --- the next two steps focus on the request itself.

This is the first step that may lead to a request being performed, as it is here determined whether the requested action or information is already publicly available. In the case where the request involves an action, it must be determined whether this requested action is available to the public or whether the requester should possess any level of authority to request the specific action. In the case where the requested action is available to everyone, the "yes" option is taken and the request is performed. If any type of authority is required for the specific action, the "no" option is chosen and the receiver proceeds to the next step. The procedure is similar for requested information, since it needs to be measured whether the information is public or private. The receiver should have a clear understanding of what information is readily accessible to the public. For example, information in the public domain for an institution could include contact details and working hours, which could be available on the institution's website and may thus be provided to a requester.

The receiver needs to assess the urgency of the request and the consequences for the requester if the request is not performed. If the request does not constitute a life-threatening emergency, the "no" option must be taken. An example of a life-threatening emergency is where an individual's medical insurance number is required because he/she was injured in an accident. This is a very difficult step to measure, because a skilled social engineer can use a life-threatening emergency to get the receiver to perform an unauthorised request. It should be noted that a request must be performed when an individual's life could be at risk upon denial of the request and could potentially cause harm to the individual. For this specific step, the receiver must be able to clearly determine what constitutes a life-threatening emergency and which requests may be performed during a life-threatening emergency. If the list of requests that may be performed is continually revised, the social engineer will be limited and thus it can be deemed safe to provide the limited set of requests during a life-threatening emergency. In the case where it is known that an organisation does not deal with life-threatening emergencies, this step can be omitted from the model.

In this step, it is determined whether there are any conditions that can constitute a refusal to perform the request. Only four conditions are provided in the model, therefore they do not constitute an exhaustive list. These conditions can be developed to cater for specific organisations, depending on where the model is implemented. The four conditions that are provided are of a very generalised nature to cater for the most probable conditions without mentioning the specific requirement. If any condition here constitutes a sufficient reason for refusal, the "yes" option is taken; otherwise, the request is performed. The following subsections elaborate on the conditions used in the refusal component of the model.

This condition refers to all the possible administrative reasons that may constitute a sufficient reason for refusal. For example, the requester may be required to provide information if there is an administrative process in place that requires a specific level of authority for requesting the receiver to perform the request. The term "administrative reason" is used to refer to a wide variety of reasons and keeps the model more generic.

This condition refers to all the possible procedural reasons that may constitute a sufficient reason for refusal. For example, the receiver may have stumbled on a portable storage medium and wants to return it to its rightful owner. However, there is a procedural policy in place that forbids the receiver to plug in any storage medium into a workstation at the organisation and this will then constitute a valid reason to refuse the request and take the "yes" option. The term "procedural reason" is used to refer to a wide variety of reasons and it keeps the model more generic.

One also needs to consider the case where the type of request has not yet been defined in an organisation or where the receiver has never before dealt with such a type of request. In this case, the unusual or novel nature of the request will be sufficient reason to refuse it and take the "yes" option to further ascertain the requester's identity. For example, the receiver may receive a request to perform a password reset for a colleague; however, the request is received via e-mail and not telephonically as it is usually done. In this case, it is sufficient reason for the receiver to refuse the request.

This condition is open-ended as the receiver may feel uneasy with the request or there may be a reason why the receiver intuitively does not want to perform the request. Although it is added as an additional safeguard to the model, this step is not seen as redundant, as it provides the receiver with an additional means to check out information about the requester. Because the receiver will have the ability to further verify the requester in the steps that follow, it may put the receiver at ease to perform the request.

The receiver now needs to verify the identity of the requester to be able to make an informed and rational decision about whether the request should be performed. If at this stage of the model the requester's identity cannot be verified, the "no" option is taken and the request is either deferred or referred. In the case where the receiver can perform steps to identify the requester and the associated roles, authority or additional details, the "yes" option is chosen to determine the number of levels on which the requester can be verified.

Depending on the extent to which the requester's identity can be verified, a different set of states will be examined to determine whether the request should be performed. Important to remember is that the social engineer may be portraying him- or herself as an authority figure in the institution; a computer technician, or any other persona that may elicit compliance. As people, we are inclined to make quick assumptions regarding others and their status, sometimes even based on trivialities such as clothing. If someone is dressed in the proper attire, uses the appropriate institutional jargon or uses an important individual's name, it does not necessarily indicate that such individual is trustworthy. The same holds for physical objects, as individuals are inclined to help other people. If an individual finds a storage medium lying around and the storage medium is marked to be important, the individual will likely feel the urge to either return the storage medium to its rightful owner or curiosity may drive the individual to examine the contents on the storage medium. If the receiver feels unsure at any time, a super user should be contacted to obtain the authority to provide or decline the request.

The following verification requirements should be taken into account and used as a basis for a decision on whether to perform or not perform the request: authority, credibility, previous interaction, and knowledge of the person's existence. The model has only four verification requirements and hence does not constitute an exhaustive list --- additional requirements can be added to cater for specialised environments and specific to particular organisational contexts. The current list of requirements is very broad and only includes the most common verification requirements.

For example, some of the techniques that can aid in the verification of an individual's identity, specifically in a call centre environment, are the following: Caller Identification; Calling back the requester on a predetermined phone number; Requesting an organisational email address; Requesting a secure password; Requesting face-to-face interaction with the individual where proper identification can be provided; Having another employee to vouch for the requester; Contacting the requester's immediate supervisor to verify the former's identity; Using an employee directory. This illustrates how the verification requirements can be changed based on the environment and organisation where the model is implemented.

It is not always possible to verify all of the requirements, so the model has three different outcomes for this specific step. If none of the verification requirements hold, the "none" option is selected and the request is either deferred or referred. In the case where only one to two requirements hold, the path to further verify the information from a third party source is selected. Lastly, if three or more requirements hold, the receiver proceeds to the final step of the model where it is measured whether the requester has the necessary authority to request either the action or the information. The strictness of this step can also be changed depending on the environment or organisation where this model is implemented. The strictness of this step is highly dependent on the verification requirements that are utilised. Each of the verification qualities is addressed in the next subsection.

Authority is an integral part of any institution, with an almost conditioned response from employees to adhere to an authoritative requester's wishes and demands, combined with a fear of punishment should the receiver appear to undermine the requester. For these reasons, impersonating an authoritative individual is a very effective technique used by social engineers to obtain privileged information or actions. The institution needs to provide an environment in which the employee feels comfortable and is indeed expected to question the authority figure's identity before disclosing sensitive information. The employee also needs to know --- with the help of a clear institutional policy --- on what authorisation level a particular person of authority is rated, in regard to what privileged information or action can be provided.

The same situation applies in our daily lives, where individuals adhere to rules and regulations put in place by an authoritative figure. Examples of such official procedures are road rules and regulations, and individuals tend to follow these rules and regulations because they create a safe environment for everyone to travel in. Theft is also frowned upon. When a storage medium is found by an individual, the individual will rather want to return this storage medium to its rightful owner, otherwise, it might be considered as stealing the device.

The employee needs to judge the level of credibility of the requester. However, this is a challenging task, as establishing credibility is the first aim that the social engineer tries to achieve, and what the attack will be based on. If the requester knows the jargon used by a particular institution, people easily assume that he/she is an employee at their particular institution. The requester could, for example, be an ex-employee who is (still) quite knowledgeable about the jargon and procedures. Such an aggrieved ex-employee may try to seek revenge with the goal of obtaining particular sensitive information. The credibility of the requester is measured on the basis of how well or bad he/she responds to a predefined of set of questions used to determine the credibility of a requester.

Similarly, for objects and items, the credibility of an item has to be measured in terms of whether it conforms to the institution's guidelines. One must examine whether it is the same brand used by the institution or whether the institution's lanyard is attached to it. These are all minor techniques that can be used to ensure that the object or item indeed belongs to or is part of the institution.

If the individual has had previous interaction with the requester, especially a long-standing history of interaction, the decision whether information can be provided will be an easier task. However, limited interactions with the requester, especially by telephone and email alone, should be taken into account in conjunction with other verification techniques, to be able to make an informed and safe decision regarding the request. This test can only be performed on individuals and not on items or objects that have an inherent request.

This refers to the knowledge that the requester exists in the institution or the fact that an outside collaborating partner on a project can support the verification of the requester. However, this should also be used in conjunction with the other verification techniques, as the requester could be a social engineer portraying him- or herself to be some well-known individual in order to get the receiver to perform the request. This awareness test can only be performed on individuals and not when the requester is an object that has an inherent request.

When the requester did not adhere to enough verification requirements and only some of the verification requirements held, this step is reached. It tests whether it is possible to verify the information obtained from the requester through an external source. An example of such a case is where the requester provides information and claims to be part of a specific organisation, as well as to have been requested by his or her organisation to ask the receiver to perform a request. If it is possible for the receiver to contact another individual at this organisation to verify this information, the "yes" option is chosen, otherwise the "no" option is taken and the requested is either deferred or referred.

In this step, the receiver will verify all the verification requirements as obtained from the third party source. Continuing with the previous example, the receiver will attempt to contact the organisation and verify the information received from the requester. If the information matches what has been received from the requester, the "yes" option is taken, otherwise, the request is either deferred or referred.

With the aid of the previous steps the receiver has acquired the necessary knowledge regarding the requester's identity and authority level, together with whether the receiver may perform the request. The receiver can now determine whether the requester has a level of authority on the same level or higher than the level of sensitivity of the request. If the requester has the authorisation on the same authority level as or higher than needed for the particular request, the request is performed. However, if the requester does not have the necessary authorisation, the "no" option is chosen and the request is deferred or referred.

This is the negative result state of the model. In this state the request can either be deferred or handled at a later stage. Deferring the request can also lead to the request never being performed and can be considered as the request having been halted. In the case where the receiver is part of an organisation, there is the option to refer the request to a more authoritative person in the same organisation. This will allow someone else who may have better judgement on whether to perform or halt the request to actually deal with the request.

This is the positive result state of the model. In this state the receiver is allowed to perform the single request from the requester.