RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US
Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0 (1.0)
Content-Type:
text/plain; charset=utf-8
Date:
Thu, 9 Feb 2017 14:49:07 -0800
Reply-To:
Records Management Program <[log in to unmask]>
Subject:
Re: NAS storage reduction project
From:
RIMMAN <[log in to unmask]>
In-Reply-To:
<[log in to unmask]>
Content-Transfer-Encoding:
8bit
Sender:
Records Management Program <[log in to unmask]>
Parts/Attachments:
text/plain (18 lines) 
One of the larger considerations should be understanding the procedures/policies that result in data/information/records being written to NAS.  Maybe "stuff" is being written there that shouldn't be and it's turned into the proverbial digital haystack. 

So I'd suggest understanding the above, then changing policies/procedures to ONLY write "stuff" that has a required retention to NAS (and segregate content by retention requirements) and tag that content accordingly to enable methodical destruction on a day forward basis. 

Access frequency doesn't determine retention or value of the information... ESPECIALLY in the highly regulated financial services sector! 

I'd also say if ANYONE issues an edict or makes a unilateral knee-jerk decision to act on that stored content, get something in writing from them accepting responsibly for the actions. 

Larry Medina
[log in to unmask]

Sent from MY iPhoneSeís

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]

ATOM RSS1 RSS2