Another index might help you, but we can't know for sure. It depends on the selectivity of the other columns and on the values that are being used for the parameters. For example, if the column DESP_STATUS is not selective at all (for example 70% of the rows have one value and the rest 30% have another value), then an index on that column won't be helpful at all. On the other hand if the column SITE_CD is very selective, but the procedure gets an empty string as the value for @SITE_CD, then again an index won't be helpful at all.

If you don't have the primary key as one of the parameters, then currently the only plan that can be used is table scan. Take into consideration that if you'll have other indexes that sometimes can be used or one of the parameters is the primary key, but it is being passed only some times, then you'll have another problem because you'll might have in the plan cache a query plan that was very good plan to the values of the parameters that were sent to the procedure earlier, but with the new parameters that were sent the next time that the procedure was activated, the query plan will be a terrible one. Whenever I have a procedure that that its query plan should have different plans according to the input parameters, I try to work with few procedures instead of one so each one will have its own query plan or create it with recompile.

Adi