Maureen Cusack wrote:
> <is IT a "function" or is everything they do pretty much show up in other
> functions>
>
> IT functions are definitely unique to IT but how important is it to document
> them and control them with a retention schedule? I think the rigour applied
> to defining IT functions and assigning retention periods to IT records
> depends on the litigation risk.
>   
As a Technical Writer, I've helped IT groups document various things. 
Some of it is ephemeral, like the procedure to follow if mains power is 
lost, or to start everything up after a shutdown. Other docs, like SOX 
procedures, may actually have retention requirements. I haven't seen 
retention systems in my activities, but I'm keeping an eye out!

> Federal and state discovery rules require better identification of ESI than
> ever; who is going to do the identifying? The business unit can't; they
> think IT 'manages' ESI and they asume IT documents this management
> activity. 
Well, the business unit must, regardless of what they think IT does. If 
they have a DM system, then retention could be managed through that- but 
there has to be some mechanism to actually purge/destroy data when its 
time has come. That means that  IT and business (probably through 
Business Analysts?) figure out how to implement.
Then the IT procedures should be documented and followed, and 'those' 
procedures should have a retention as well.
> IT documentation rarely describes the details required by state
> and federal rules such as what the data is about, exactly where it is (what
> application is on what server that then gets put on what backup tape), the
> name of the IT person who manages it, retention and migration schedules. 
Right - as far as I've seen, It makes the systems and applications run. 
They try to keep the bad guys out. They fix stuff that users foul up.
And, they generally provide places to put information. The content is 
generally not their concern.
> To
> meet ESI identification rules, and to be able to preserve or produce
> anything, the records manager has to spell out to IT what ESI details IT
> must document, how often to update these details, what media is
> 'inaccessible'.
>   
> The business unit might own the intellectual content but that doesn't really
> mean much since IT controls the systems and processes that process the data
> (eg 'alter' it), store it, provide access to it, protect its authenticity,
> make it accessible or 'inaccessible', and destroy it. If a record cannot be
> produced for a law suit then evidence of those IT actions (eg change
> management logs, batch upload reports, LAN/WAN security/intrusion logs,
> backup tape procedures and inventories etc.) might be required or might be a
> good idea to volunteer. Also, business decisions are embedded into system
> functionality: people choose how to make a system process data and what data
> to process. Those choices might be the contentious issues in a law suit.
> Those choices are reflected in IT records like change logs etc.
>
> But, on second thought, even if litigation is not a big concern, and it's
> only customers and regulators who care about compliance with retention laws
> or the retention schedule,  IT are still the only ones who can provide proof
> of that compliance by means of IT records. So some IT records are definitely
> needed and IT needs help understanding what they need to identify.
>   
"only" regulators?!

Regards
Jay

-- 
Jay Maechtlen
626 444-5112 office
626 840-8875 cell
www.laserpubs.com


List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]