The Document Management solution for compliance to the Sarbanes Oxley Act focuses on section 404 and 409 of the law, specifically Management Assessment of Internal Controls and Real Time Disclosure. The functionality works for all documents regardless of which repository type is used, but is best for document files stored in the database. The recommendation therefore is, if you want SOX-control on document files, you use a repository of Database type.
In practice, this is what is provided by the functionality:
Logging of reads, writes and deletes of document files. The log records can be found in the File Operation Log page under Basic Data. Event messages are also generated on reads, writes and deletions of document files such that event actions can be added to these events. An end-user can only see his own log records unless he has been granted the DOCMAN ADMINISTRATOR system privilege, when he can see every log record.
A document is "read" when a user in some way was able get a copy of the document file to his PC. Examples of operations in the application where this happens are edit (check out), view and print. A document was "written" when a user checks in a document file, either new or modified. A document was deleted when a user removes a document file.
Technically, SOX works by forcing the client to announce that it is going to do a file operation, by calling the method Edm_File_Op_Announce_Api.Announce_File_Operation. For documents stored in a database repository, if the client does not announce a file operation, it will not get access to the document file (because the document is in the database, we have complete control over the access to it). We can control if our own clients does this but we cannot control third party, or rouge (hacked) clients, which is why this announcement concept is needed. In the end, it is the announce method that does the logging and that generates the event. The announce method runs in its own transaction and does a COMMIT in the end to make sure that the client does not make a ROLLBACK to try to avoid a log being created. File operation announcement is not needed to get a copy of the file if it is stored in a FTP or Shared repository, but when running through an official Docman client, these file operations will also be logged even if it is not technically needed to get a copy of the file.
Log records are by default saved in thirty (30) days, but this can be changed using the SYSCFG-Default Value SYSCFG_SOX_LOG_EXPIRE_DAYS. A batch job that deletes old records job is run once per day.
Three templates for SOX Event Actions can be found in the template folder in this release. They are insert files that can be installed from SQL*Plus or similar tool. The Events are already installed.
Apart from using the log as a monitoring tool (for Docman administrators and other) the log information can also be used to write useful saved queries to find documents that an end-user has recently worked with. Here is an example of a WHERE condition for such a saved query that works well for this purpose in the Document Revisions page:
(doc_class, doc_no) IN
(SELECT doc_class, doc_no
FROM &AO.edm_file_op_announce
UNION
SELECT doc_class, doc_no
FROM &AO.document_issue_history
WHERE created_by = (SELECT &AO.person_info_api.get_id_for_user('#USER_ID#') FROM DUAL)
AND date_created < SYSDATE-30)
Use a sorting like "dt_chg desc" to sort the newest documents first.