Once the record is updated and the status changed to 8=Rejected then the previous value for that column is no longer available. You will have to store it somewhere.
I would create an additional column of either PreviousStatus or StatusBeforeRejection.
PreviousStatus would store the Status whenever it changes. Thus if the status then changes from Rejected to Candidate Withdrawn you won't be able to show the earlier status any more.
StatusBeforeRejection would only store the status when a new status of "Rejected" is applied. The "problem" with this is if the status is changed from Rejected to "something earlier" - for example, someone changed the status to Rejected by mistake (e.g. on the wrong record) and then back to the correct status. What now for the
StatusBeforeRejection column? Will it store the Status next time the Status is changed, again, to Rejected? (which will lose the value it had before) and in the meantime StatusBeforeRejection will be showing a value even though the main Status is showing a value earlier than Rejected ...
It might be that an error is made and to correct it the status changes from Candidate Withdrawn to back to Rejected - that would then store "Candidate Withdrawn" in the StatusBeforeRejection? which is clearly daft! (Of course you could program around that, but I am sure you get my point - a single StatusBeforeRejected column may not contain enough "granularity" to accurately provide information to the user)
An alternative is that you create a "History" table and store every previous change to Status (along with Date, Time [of the change] and UserID if you have one, and the ID of the record being changed). You can then report on "Most recent previous status" but also "All previous status changes" if you need that. (We do this for all columns, in almost every table we have; there are always questions about "How did that value get there?" which a History table answers, It enables the Goofy data to be fixed, based on how it used to be, and top-up-training to be provided for anyone who is consistently, but wrongly, updating records. But you do have to, also, create a housekeeping routine to purge history records after a suitable length of time.
Personally I would use a trigger to handle this so that the StatusBeforeRejection is always maintained, whether the Status is updated via an APP (i..e the "normal" route) or some adhoc SQL statement, or some "new process" in the future.
CREATE TRIGGER dbo.MyTriggerName
ON dbo.MyTableName
AFTER UPDATE
AS
SET NOCOUNT ON
SET XACT_ABORT ON
SET ARITHABORT ON
UPDATE U
SET StatusBeforeRejection = D.Status
FROM inserted AS I -- New version of row(s)
JOIN deleted AS D -- Old version of row(s)
ON D.MyPKey = I.MyPKey
JOIN dbo.MyTableName AS U
ON U.MyPKey = I.MyPKey
WHERE I.Status = 8 -- Changed to Deleted
AND D.Status < 8 -- Originally an earlier status
AND (U.Status <> D.Status OR U.Status IS NULL) -- Only update if not already set to correct value