Really good stuff. I especially like the different views. It’s quite important to understand the goals, constraints, and challenges from all the angles.
I (admittedly) only scanned through it so I may have missed these, but if not, you may want to consider addressing:
validation of archival / retrieval tools / process
validation of any add-ons / plug-ins used to support the system
when data can be purged
One of the more common issues I run into is DBMS access. Typically, DBMs are able to make changes that don’t trigger an audit trail record. Have you encountered this? Do you have suggestions on how to manage it?
[quote=yodon]
One of the more common issues I run into is DBMS access. Typically, DBMs are able to make changes that don’t trigger an audit trail record. Have you encountered this? Do you have suggestions on how to manage it?[/quote]
Good question and valid point, its not an issue I have come up against before, have you considered some kind of control like an SOP thats states all changes implemented by a DBM must be controlled perhaps through screenshots all of changes.
Its just an idea maybe other people will have suggestions.
That would work for “managed” changes but would not prevent or detect malicious changes. I had one client put a layer on top of SQL - OmniAudit, I believe. At least that can be used to detect malicious (“unmanaged”) changes. Of course, that too requires validation.
Very good and helpful information. I am on the implementation team of a new electronic batch record and documentation system (Pilgrim), and this will come in when dealing with audit trails. It definitely brings up some good points that we need to keep in mind. THANKS FOR SHARING GRAHAM!
