Tracing a Users Steps

You can check the audit logs if auditing is enabled. If not then you can't retroactively get the information.

minimally leverage on Windows audit trail to capture anomalies

consider some recommended Baseline Audit Policy for Windows Server 2008
http://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Recommended-Baseline-Audit-Policy-for-Windows-Server-2008

and in particular track an account via auditing user accounts in Windows Server 2008 R2
http://www.techrepublic.com/blog/the-enterprise-cloud/auditing-user-accounts-in-windows-server-2008-r2/

furthermore, track important repository such as (1) securing and Auditing High Risk Files on Windows Servers and (2) auditing Windows Server File and Folder Access, including (3) File servers and (4) AD DS activities.
(1) http://www.windowsecurity.com/articles-tutorials/windows_server_2008_security/securing-auditing-high-risk-files-windows-servers.html
(2) http://www.techotopia.com/index.php/Auditing_Windows_Server_2008_File_and_Folder_Access
(3) http://blogs.technet.com/b/mspfe/archive/2013/08/27/auditing-file-access-on-file-servers.aspx
(4) http://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx

but we do also need to Indicators for detecting anomalous activity among the log as it can be noisy specifically to have the below objective in mind:
▪▪Where the account was used (source or destination).
▪▪When the authentication was performed (such as when a user is on leave or vacation or outside of working hours).
▪▪Unusual or unexpected account creation (for example, domain accounts created outside of provisioning system or local accounts created on a server).
▪▪Unusual activity performed with the account (for example, settings changed and authentication policy failures).
▪▪Known and unknown malicious executables detected.
▪▪Multiple unrelated high-value accounts used from the same host (for example, domain admin credentials and service accounts used from same host).
▪▪Multiple accounts from different owners authenticating in a short period of time from the same computer in the same session.
▪▪Modification of sensitive objects (for example, a change to the membership of Domain Admins).

but if it is too noisy you can consider reviewing this to minimise and not to extend of missing out and really not have log override or rotated unnecessarily
http://blogs.msdn.com/b/ericfitz/archive/2005/01/11/keeping-the-noise-down-in-your-security-log.aspx

always good to have (if $$ is avail to spare) some sort of SIEMS (e.g. ManageEngine, Splunk (pdf)) to managed all the log and give you that extra edge to alert and detect on anomalies. Below are some possible list of events worth collecting for detecting credential theft for info

Application execution events (on any monitored computer)
=======================================
Event ID 4688 - A new process has been created.
Key fields: Account Name, New Process Name

Authentication events (on any monitored computer)
=======================================
Event ID 4648 - A logon was attempted using explicit credentials.
Key fields: Account Name (Subject), Account Name (account whose credentials were used), Process Name
Event ID 4624 - An account was successfully logged on.
Key fields: Account Name, Logon type

Kerberos events on domain controllers
=======================================
Event ID 4769 - A Kerberos service ticket was requested.
Key fields: Account Name, Service Name, Client Address
Event ID 4768 - A Kerberos authentication ticket (TGT) was requested.
Key fields: Account Name, Service Name, Client Address
Event ID 4776 - The domain controller attempted to validate the credentials for an account.
Key fields: Logon Account, Source Workstation

You should get a forensic image of the computer first, before checking and potentially changing the evidence. You don't want your attempts to check what he was accessing to leave traces of their own. After ensuring that you have a valid copy, make another copy to work from. If he was opening the files, you should be able to find lnk files (shortcuts) in the 'recent' folder on his profile. There are other traces in the Registry that can point to what folders he was accessing, even if he didn't open documents.
As for browser history, a special tool is usually required to view someone else's browser history. You may want to check the list of installed applications.
Ken

If really want to go deeper and in "near real time" basis, organisation asset can be monitored as well on specific activities such as file accesses..

Privileged User Monitoring for Compliance (log revealed) - SANS reading
http://www.sans.org/reading-room/whitepapers/analyst/keys-kingdom-monitoring-privileged-user-actions-security-compliance-34890

File Activity Monitor - http://www.imperva.com/Products/FileActivityMonitor

File integrity monitor - https://www.netiq.com/issues/file-integrity-monitoring.asp

SSH Audit: Record SSH, Telnet and Console Sessions
RDP Audit: Record RDP, Terminal and Console Windows Sessions
http://www.observeit.com/Products/Features/Privileged_User_Identification

User audit trails can usually log:

     -    all commands directly initiated by the user;
     -    all identification and authentication attempts; and
     -    files and resources accessed.

It is most useful if options and parameters are also recorded from commands.  It is much more useful to know that a user tried to delete a log file (e.g., to hide unauthorized actions) than to know the user merely issued the delete command, possibly for a personal data file.

Ref NIST handbook - http://csrc.nist.gov/publications/nistbul/itl97-03.txt

Areas to look out

System-Level Audit Trails
If a system-level audit capability exists, the audit trail should capture,
at a minimum, any attempt to log on (successful or unsuccessful), the
log-on ID, date and time of each log-on attempt, date and time of each
log-off, the devices used, and the function(s) performed once logged on
(e.g., the applications that the user tried, successfully or
unsuccessfully, to invoke).  System-level logging also typically includes
information that is not specifically security-related, such as system
operations, cost-accounting charges, and network performance.

Application-Level Audit Trails
System-level audit trails may not be able to track and log events within
applications, or may not be able to provide the level of detail needed by
application or data owners, the system administrator, or the computer
security manager.  In general, application-level audit trails monitor and
log user activities, including data files opened and closed, specific
actions, such as reading, editing, and deleting records or fields, and
printing reports.  Some applications may be sensitive enough from a data
availability,  confidentiality, and/or integrity perspective that a "before" and "after"
picture of each modified record (or the data element(s) changed within a
record) should be captured by the audit trail.

Windows specific (target Audit object access policy)
http://blog.windowsnt.lv/2011/11/15/tracking-user-activity-english/

Considering the described incident, few questions immediatelly arise:
At what date and time the incident took place?
Which backup should be used to restore the data?
Was that an accident or an intentional user action?
Or maybe that was some system failure that could happen again?

Auditing is the best way to track what's happening e.g. Once you audit object access, you can use the Auditing tab to set auditing policies on individual files and folders.

Advanced Security Settings Properties Page - Auditing Tab
http://technet.microsoft.com/en-us/library/cc753927.aspx

Each object has a set of security information, or security descriptor, attached to it. Part of the security descriptor specifies the groups or users that can access an object and the types of access (permissions) that are granted to those groups or users. You can apply auditing to an object, and any child objects can inherit the auditing. For example, if you want to audit failed access to a folder, this auditing event can be inherited by all files within the folder. To audit files and folders, you must be logged on as a member of the Administrators group.

http://technet.microsoft.com/en-us/library/cc755115.aspx

If you choose to audit access to objects as part of your audit policy, you must enable either the audit directory service access category (for auditing objects on a domain controller), or the audit object access category (for auditing objects on a member server or workstation). Once you have enabled the object access category, you can specify the types of access you want to audit for each group or user.

Very good responses war supplied.  Thank You