Depending on how sophisticated the review process must be "prior" to requested changes actually being committed to the master table, I would suggest using two tables. One as the master and one that keeps the current state of the record along with all previous "states" of the record as some sort of "audit".
Using Employee and EmployeeAudit as your two tables, Their schemas would be the same. However, the EmployeeAudit table would have additional columns for ModifiedByUserID, ModifiedDateTime, StatusID, and NextLevelStatusID indicating what level up the management tree is needed for approval. Perhaps even a NextUserID oriented column instead indicating who needs to approve it next. Of course, you'd always grab the most recent state of the record by getting the last entry for that Employee key in the EmployeeAudit table.
At some point in the process, you reach the point of final approval and the applicable columns are copied from EmployeeAudit back to Employee.
All of that said, I've seen guys use a gazillion different methodologies for comparing old records to new one's. Some use XmlDocuments instead of columns in a database. Others use an Audit table with a row that includes FieldName and FieldValue instead of creating an identical base schema as the master table.
The basic jist is that you want to store the current "state" of the record outside the master table and only overwrite the master table once you've reached the appropriate approval state.