PART 3: Criteria Group Checklists - Records Management

PART 3:Criteria Group ChecklistsThe following checklists are designed to help you gather information about the information system(s) in your organization. It is divided into fivemain criteria groups as follows: System Documentation, System Security, Audit Trails, Disaster Planning and Recovery and Metadata. These criteriagroups are explained in detail in Part 2 of this manual. An introductory section, Questions to Consider, and a supplementary section on DataWarehousing are also included here.Complete the criteria from beginning to end for total system evaluation or, depending on your agency’s needs, select those criteria groups thatrequire review. How you proceed is entirely up to you. You can use the Top Level Criteria below and/or the Legal Risk Analysis Tool to help you selectthe applicable criteria checklists.Top Level CriteriaThe following criteria should be used to establish a trustworthy information system.If you are unsure or unable to answer Yes to any of the following questions, go to theCriteria Group listed and complete the detailed analysis.In Place?Yes/NoNotes211. System administrators should maintain complete and current documentation of theentire system. If unsure, go to Criteria Group 1 to do an analysis of yourdocumentation procedures.2. System administrators should establish, document, and implement securitymeasures. If unsure, go to Criteria Group 2 to do an analysis of your securityprocedures.3. System administrators should establish audit trails that are maintained separatelyand independently from the operating system. If unsure, go to Criteria Group 3 todo an analysis of your audit procedures.4. System administrators should establish a comprehensive disaster recovery plan. Ifunsure, go to Criteria Group 4 to do an analysis of your disaster recovery procedures.5. Each record should have an associated set of metadata. If unsure, go to CriteriaGroup 5 to do an analysis of your metadata procedures.March 2007, Version 2

Questions to ConsiderWhat laws and/or regulations (state and federal) apply to the data within your system?ResponseWhat are your industry’s standards for system security?What are your industry’s standards for data security?What areas/records might lawyers target?What areas/records might auditors target?What data is of permanent/historical value to you? To others?22March 2007, Version 2

Criteria Group 1: System DocumentationSystem Documentation QuestionsWhat is the system’s unique identifier and/or common name?ResponseWhat is the agency and department(s) responsible for the system?What is the agency and department(s) responsible for applications?What is the name and contact information of the person(s) responsible for systemadministration?What is the name and contact information of the person(s) responsible for systemsecurity?Has a formal risk assessment of the system been completed? Date? Performed by?Methodology? Findings?Were design reviews and system test run prior to placing the system in production?Were the tests documented?23Is application software properly licensed for the number of copies in use?If connected to external systems lacking commensurate security measures, whatmitigation procedures are in place?What other systems might records be migrated to?March 2007, Version 2

Criteria Group 1 Checklist (1.A-1.B.)System Documentation Analysis (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as longas the longest retention time applicable to the records produced in accordance with the documentsCriteria In Place? Planned? Rationale/NotesYes/No Yes/No1.A.1 System Documentation: hardware procurement1.A.1 System Documentation: hardware installation1.A.1 System Documentation: hardware modifications1.A.1 System Documentation: hardware maintenance1.A.1 System Documentation: use of only agency-authorizedhardware241.A.2 System Documentation: software procurement1.A.2 System Documentation: software installation1.A.2 System Documentation: software modification1.A.2 System Documentation: software maintenance1.A.2 System Documentation: use of only agency-authorizedsoftware1.A.3 System Documentation: communication networksprocurementMarch 2007, Version 2

Criteria Group 1 Checklist (1.A-1.B.)System Documentation Analysis (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as longas the longest retention time applicable to the records produced in accordance with the documentsCriteria In Place? Planned? Rationale/NotesYes/No Yes/No1.A.3 System Documentation: communication networksinstallation1.A.3 System Documentation: communication networksmodifications1.A.3 System Documentation: communication networksmaintenance1.A.4 System Documentation: interconnected systems(including the Internet) — list251.A.4 System Documentation: interconnected systems —names and unique identifiers1.A.4 System Documentation: interconnected systems —owners1.A.4 System Documentation: interconnected systems —names and titles of authorizing personnel1.A.4 System Documentation: interconnected systems —dates of authorization1.A.4 System Documentation: interconnected systems —types of connections1.A.4 System Documentation: interconnected systems —indication of system of recordMarch 2007, Version 2

Criteria Group 1 Checklist (1.A-1.B.)System Documentation Analysis (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as longas the longest retention time applicable to the records produced in accordance with the documentsCriteria In Place? Planned? Rationale/NotesYes/No Yes/No1.A.4 System Documentation: interconnected systems —sensitivity levels1.A.4 System Documentation: interconnected systems —security mechanisms, security concerns, personnelrules of behavior1.B.1 System Documentation: programming conventions andprocedures1.B.2 System Documentation: development and testingprocedures, including tools261.B.2 System Documentation: development and testingprocedures — periodic functional tests should includeanomalous as well as routine conditions and bedocumented such that they are repeatable1.B.3 System Documentation: applications and associatedprocedures for entering and accessing data1.B.3 System Documentation: applications and associatedprocedures for data modification1.B.3 System Documentation: applications and associatedprocedures for data duplication1.B.3 System Documentation: applications and associatedprocedures for data deletionMarch 2007, Version 2

Criteria Group 1 Checklist (1.A-1.B.)System Documentation Analysis (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as longas the longest retention time applicable to the records produced in accordance with the documentsCriteria In Place? Planned? Rationale/NotesYes/No Yes/No1.B.3 System Documentation: applications and associatedprocedures for indexing techniques1.B.3 System Documentation: applications and associatedprocedures for outputs1.B.4 System Documentation: identification of when recordsbecome official1.B.5 System Documentation: record formats and codes1.B.6 System Documentation: routine performance of systembackups — appropriate labels271.B.6 System Documentation: routine performance of systembackups — secure, off-line, off-site storage1.B.6 System Documentation: routine performance of systembackups — periodic integrity tests1.B.7 System Documentation: routine performance of qualityassurance and control checks (incl. audit trails)1.B.7 System Documentation: routine performance of qualityassurance and control checks — identification devices(e.g., security cards) periodically checked to ensureproper functioning and correctness of identifyinginformation and system privilege levelsMarch 2007, Version 2

Criteria Group 1 Checklist (1.A-1.B.)System Documentation Analysis (e.g., specifications, program manuals, user guides) included in retention schedules, retained for as longas the longest retention time applicable to the records produced in accordance with the documentsCriteria In Place? Planned? Rationale/NotesYes/No Yes/No1.B.7 System Documentation: routine performance of qualityassurance and control checks — storage mediumsundergo regular statistical sampling followingestablished procedures outlining sampling methods,identification of data loss and corresponding causes,and the correction of identified problems1.B.8 System Documentation: migration of records to newsystems and media as necessary, with all recordcomponents managed as a unit throughout transfer1.B.9 System Documentation: standard training for all usersand personnel with access to equipment281.B.9 System Documentation: standard training — usersshould sign statements agreeing to terms of useMarch 2007, Version 2

Criteria Group 2: System SecuritySystem Security QuestionsWho can invoke change mechanisms for object, process, and user security levels?ResponseWho (creator, current owner, system administrator, etc.) can grant access permissionto an object after the object is created?Is there a help desk or group that offers advice and can respond to security incidentsin a timely manner?Is system performance monitoring used to analyze system performance logs inreal-time to look for availability problems, including active attacks and system andnetwork slowdowns and crashes?List internal and external user groups and the types of data created and accessed.Have all positions been reviewed with respect to appropriate security levels?29What are the procedures for the destruction of controlled-access hardcopies?How is information purged from the system?How is reuse of hardware, software, and storage media prevented?March 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.A.1 System Security — User Authorization: useridentification and access procedures should beestablished and documented2.A.1 System Security — User Authorization: users shouldbe authenticated prior to being granted access2.A.2 System Security — User Authorization: uniqueidentifier and password for each user2.A.2 System Security — User Authorization: identifiers andpasswords not used more than once within a system302.A.2 System Security — User Authorization: use of accessscripts with embedded passwords limited andcontrolled2.A.2 System Security — User Authorization: uponsuccessful log-in, users should be notified of date andof last successful log-in, location of last log-in, andeach unsuccessful log-in attempt on user identifiersince last successful entry2.A.2 System Security: where identification codes in humanreadableform are too great a security liability, use ofother forms such as encoded security cards orbiometric-based devices2.A.3 System Security — User Authorization: password rulesinclude minimum password length, expiration dates,and limited number of log-on attemptsMarch 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.A.3 System Security — User Authorization: determinationof what level and frequency of log-on error constitutesa misuse problem which, in turn, would triggernotification of security personnel2.A.4 System Security — User Authorization: users restrictedto only level of access necessary to perform their jobduties2.A.5 System Security — User Authorization: permission toalter disposition/retention codes, and/or to create,modify, and delete records granted only to authorizedusers with proper clearance312.A.5 System Security — User Authorization: modification ofrecord identifiers prohibited2.A.6 System Security — User Authorization: Access toprivate keys for digital signatures limited toauthorized personnel2.A.7 System Security — User Authorization: maintenanceof lists of all current and past authorized users alongwith their privileges and responsibilities2.A.7 System Security — User Authorization: current list ofusers reviewed on a regular schedule to ensure timelyremoval of authorizations for former employees, andadjustment of clearances for workers with new jobdutiesMarch 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.A.8 System Security — User Authorization: personnelduties and access restrictions arranged such that noindividual with an interest in record content will beresponsible for administering system security, qualitycontrols, audits, or integrity-testing functions.2.A.8 System Security — User Authorization: No individualshould have the ability to single-handedly compromisethe system’s security and operations2.B.1 Internal System Security: access to systemdocumentation controlled and monitored322.B.2 Internal System Security: access to output and storagedevices controlled and monitored2.B.3 Internal System Security: controls in place to ensureproper security levels of data when archiving, purging,or moving from system to system2.B.3 Internal System Security: controls in place for thetransportation or mailing of media or printed output2.B.4 Internal System Security: procedures for the completesanitization and secure disposal of hardware when nolonger needed.2.B.4 Internal System Security: procedures for the completesanitization and secure disposal of software when nolonger neededMarch 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.B.4 Internal System Security: procedures for the completesanitization and secure disposal of storage mediawhen no longer needed2.B.4 Internal System Security: documentation ofsanitization and secure disposal should include date,equipment identifiers, methods, personnel names2.B.5 Internal System Security — insecurity-detectionmechanisms constantly monitoring the system2.B.5 Internal System Security: fail-safes and processes tominimize the failure of primary security measures inplace at all times332.B.6 Internal System Security: security procedures and rulesreviewed on a routine basis to maintain currency2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security — access to roomswith terminals, servers, wiring, backup media2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security — data interception2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security — mobile/portableunits such as laptopsMarch 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security — structuralintegrity of building2.B.7 Internal System Security — Access: measures in placeto guard system’s physical security — fire safety2.B.7Internal System Security — Access: measures inplace to guard system’s physical security —supporting services such as electricity, heat, airconditioning, water, sewage, etc.2.B.8 Internal System Security: security administrationpersonnel undergo training to ensure fullunderstanding of the security system’s operation342.C.1 External System Security: additional security measuresemployed in cases of remote access, especiallythrough public telephone lines (e.g., input devicechecks, caller identification checks (phone calleridentification), callbacks, security cards)2.C.2 External System Security: for records originatingoutside of the system, the system should be capableof verifying their origin and integrity2.C.2 External System Security: non-system records —verification of sender or source2.C.2 External System Security: non-system records —verification of the integrity, or detection of errors inthe transmission or informational content of recordMarch 2007, Version 2

Criteria Group 2 Checklist (2.A-2.C.)System Security AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No2.C.2 External System Security: non-system records —detection of changes in the record since the time ofits creation or the application of a digital signature2.C.2 External System Security: non-system records —detection of viruses or worms35March 2007, Version 2

Criteria Group 3: Audit TrailsAudit Trail QuestionsWho can access audit data?ResponseWho can alter audit data?Who can add audit data?Who can delete audit data?How can the audit logs be read?Who can read audit data?36What tools are available to output audit information? What are the formats?Who can output audit information?What mechanisms are available to designate and change activities chosen for audit?Who is able to designate and change activities chosen for audit?How are audit logs protected?March 2007, Version 2

Criteria Group 3 Checklist (3.A-3.D.)Audit Trail AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No3.A Audit Trails: if audit trails are encoded to conservespace, the decode mechanism must always accompanythe data3.A.1 Audit Trails — General Characteristics: audit trailsoftware and mechanisms subject to strict accesscontrols3.A.1 Audit Trails — General Characteristics: audit trailsoftware and mechanisms protected from unauthorizedmodification3.A.1 Audit Trails — General Characteristics: audit trailsprotected from circumvention373.A.2 Audit Trails — General Characteristics: audit trailsbacked up periodically onto removable media toensure minimal data loss in case of system failure3.A.3 Audit Trails — General Characteristics: systemautomatically notifies system administrators whenaudit storage media nearing capacity. Responsedocumented3.A.3 Audit Trails — General Characteristics: when storagemedia containing audit trail is physically removedfrom the system, the media should be physicallysecured as required by the highest sensitivity level ofthe data it holds3.B Audit Trails — System to track password Usage andChangesMarch 2007, Version 2

Criteria Group 3 Checklist (3.A-3.D.)Audit Trail AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No3.B Audit Trails — Password Usage and Changes: useridentifier3.B Audit Trails — Password Usage and Changes: successfuland unsuccessful log-ins3.B Audit Trails — Password Usage and Changes: use ofpassword-changes procedures3.B Audit Trails — Password Usage and Changes: user IDlock-out record3.B Audit Trails — Password Usage and Changes: date ofpassword use383.B Audit Trails — Password Usage and Changes: time ofpassword use3.B Audit Trails — Password Usage and Changes: physicallocation of user3.C Audit Trails — Users: system in place to log and trackusers and their online actions3.C Audit Trails — Users: system in place to log and trackusers and their online actions — details of log-in (date,time, physical location, etc.)3.C Audit Trails — Users: system in place to log and trackusers and their online actions — creation of files/recordsMarch 2007, Version 2

Criteria Group 3 Checklist (3.A-3.D.)Audit Trail AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No3.C Audit Trails — Users: system in place to log and trackusers and their online actions — accessed file/recordidentifiers and accompanying activity (deletion,modification, change of sensitivity/security level, etc.)3.C Audit Trails — Users: system in place to log and trackusers and their online actions — accessed deviceidentifiers3.C Audit Trails — Users: system in place to log and trackusers and their online actions — software use3.C Audit Trails — Users: system in place to log and trackusers and their online actions — production of printedoutput393.C Audit Trails — Users: system in place to log and trackusers and their online actions — overriding of humanreadableoutput markings (including overwrite ofsensitivity label markings and turning-off of labelingmechanisms) on printed output3.C Audit Trails — Users: system in place to log and trackusers and their online actions — output to storagedevices3.C Audit Trails — Users: users made aware that their use ofcomputerized resources is traceableMarch 2007, Version 2

Criteria Group 3 Checklist (3.A-3.D.)Audit Trail AnalysisCriteria In Place? Planned? Rationale/NotesYes/No Yes/No3.D Audit Trails: Logged for each record by audit trails: useridentifier3.D Audit Trails: Logged for each record by audit trails:record identifier3.D Audit Trails: Logged for each record by audit trails: date3.D Audit Trails: Logged for each record by audit trails: time3.D Audit Trails: Logged for each record by audit trails:usage (e.g., creation, capture, retrieval, modification,deletion)40March 2007, Version 2

Criteria Group 4: ChecklistDisaster Planning and RecoveryCriteria In Place? Planned? Rationale/NotesYes/No Yes/No4.A Disaster Plan: periodically reviewed for currency andtested for efficiency41March 2007, Version 2

Criteria Group 5: MetadataMetadata QuestionsResponseWhat are the current components of a complete or final record of the transaction?What are the minimal components necessary to provide evidence of the transaction?(If you went to court, what would be the minimum information you would need?)Are there any laws, regulations, or professional best practices that specify thestructure (including medium, format, relationships) of the record of the transaction orany of its components?What information is necessary to interpret the contents of the record?During which agency business processes might you have to access this record?Who are the external secondary users of the record?42What are the rules, laws, and regulations that restrict or open access to these recordsto external users?How will the record be reproduced to meet the needs of internal and externalsecondary users? What are the reproduction formats?Is there a mechanism in place to indicate sensitivity level on hardcopies? Who canenable/disable this function?What are your industry’s standards for records retention?What is the records disposition plan?Who is responsible for authorizing the disposition of records?Who is responsible for changes to the records disposition plan?March 2007, Version 2

Criteria Group 5: Checklist (5.A)Metadata Analysis5.A.1 Record metadata: unique identifier5.A.2 Record metadata: date of creation5.A.3 Record metadata: time of creationCriteria In Place? Planned? Rationale/NotesYes/No Yes/No5.A.4 Record metadata: creator/agency/organization5.A.5 Record metadata: documentation of creator’sauthorization5.A.6 Record metadata: date of modification445.A.7 Record metadata: time of modification5.A.8 Record metadata: modifier/agency/organization5.A.9 Record metadata: documentation of modifier’sauthorization5.A.10 Record metadata: indication of authoritative version5.A.11 Record metadata: identification of originating system5.A.12 Record metadata: date of receipt from outside system5.A.13 Record metadata: time of receipt from outside system5.A.14 Record metadata: addressee5.A.15 Record metadata: system or mechanism used tocapture record from outside systemMarch 2007, Version 2

Criteria Group 5: Checklist (5.A)Metadata Analysis5.A.16 Record metadata: protection method5.A.17 Record metadata: media type5.A.18 Record metadata: format5.A.19 Record metadata: location of recordCriteria In Place? Planned? Rationale/NotesYes/No Yes/No5.A.20 Record metadata: sensitivity classification45March 2007, Version 2

Data Warehousing QuestionsResponseDo you gather extraction metadata?Do you cleanse the data?Do you document the cleansing procedure?Do you gather cleansing metadata?Do you transform the data?Do you document the transformation procedure?Do you gather transformation metadata?What metadata/documentation do you offer users?Who can access metadata?46Who can alter metadata?Who can delete metadata?Who can add metadata?What are the legal liabilities regarding data ownership and custodial responsibilities?Where do data custody responsibilities reside — with the source systems, thewarehouse system, or both?Are there records retention schedules and policies for warehouse data?Is retention of warehouse data coordinated with retention of data in the sourcesystems?March 2007, Version 2