SQL Server doesn't track this information (I half expected to see it in the default trace, but it's not there either). Enable/disable will update modify_date, but you won't be able to distinguish that from a rename or code modification. Also, it will only show you when the last change took place. If you want any other tracking (such as who did it), you'll need to implement auditing or trace. I thought perhaps a DDL trigger could be used as well, but this seems like an intentional functionality gap:
Here is how you can capture this information going forward using an audit:
USE master;
GO
CREATE SERVER AUDIT MyAudit
TO FILE (FILEPATH = 'C:\temp\', MAXSIZE = 1 GB)
WITH (ON_FAILURE = CONTINUE);
GO
ALTER SERVER AUDIT MyAudit WITH (STATE = ON);
GO
USE [your_database];
GO
CREATE DATABASE AUDIT SPECIFICATION schema_db_change
FOR SERVER AUDIT MyAudit
ADD (SCHEMA_OBJECT_CHANGE_GROUP),
ADD (DATABASE_OBJECT_CHANGE_GROUP);
ALTER DATABASE AUDIT SPECIFICATION schema_db_change WITH (STATE = ON);
GO
Now go and disable your trigger, and then run:
SELECT event_time, succeeded, server_principal_name, [object_name], [statement]
FROM sys.fn_get_audit_file ('C:\Temp\MyAudit*', NULL, NULL);
If you can't use audit due to edition or other issues, you could do this relatively inexpensively using a server-side trace. Just capture SQL:BatchCompleted and optionally filter on TextData LIKE '%disable%trigger%' (You'll have to test if it's better in your scenario to pay the cost for the filter to avoid collecting too much, or just collect more and whittle it down later. Filters can be quite expensive but it depends on the system.)
I'm sure there is also a way to do this with extended events. But XEvents and audit both require 2008+ and you didn't specify version...
Better yet, remove the ability to modify triggers for users who bypass change management. Ideally, you should be able to determine who enabled or disabled a trigger without ever looking at the database, because nobody should be doing that without documenting it.
Only you can answer if the jobs can be dropped completely. If they are not jobs like from the import/export wizard I would probably script them out. This can be done easily with PowerShell.
A quick way of dropping them is via Object Explorer details pane, it allows multiple selections and then just hit the delete key or right click and delete.
Best Answer
Simple answer would be no. I don't think there is any system table that captures or logs this change. However you can find the details from last modified date of sql job for any change.
Please refer to some great insights as answered here by Aaron and Crafty DBA. This should help for future reference.