Principles of Data Integrity

I. Policy

Financial management decisions affect every aspect of the University, but such decisions can only be as good as the data on which they are based. Consequently, each unit must establish and implement a system to ensure data integrity. This system must provide reasonable assurance that transactions are in accordance with management's authorization and are recorded in the University records in an accurate and timely manner.

Each unit head shall be responsible for developing a system to ensure data integrity that adheres to the following principles and responsibilities.

II. Principles

Principle 1: An adequate data control system including independent checks and balances must exist within and between operating units.

Principle 2: All employees engaged in financial management activities are responsible for ensuring that adequate data controls are being employed. If they are not, all employees must take an active role in developing and implementing appropriate corrective actions.

Principle 3: Each unit must ensure that recorded assets match actual existing assets. A mechanism must be in place to spot discrepancies and to ensure that corrective actions are taken.

Principle 4: Each unit must ensure that all financial transactions are recorded correctly. Correct transactions must:

1. reflect the actual values involved,
2. contain sufficient detail for proper identification and classification,
3. be posted on a timely basis in the proper accounting period,
4. be stored securely,
5. be readily retrievable for inquiry or reporting, and
6. be safeguarded against improper alteration.

Principle 5: All systems that affect or are used to report financial data must be secure, reliable, responsive and accessible. These systems must be designed, documented, and maintained according to accepted development and implementation standards. They should be built upon sound data models and employ technology that allows data to be shared appropriately.

Principle 6: All financial systems should meet the users' needs. In addition, all interfaces affecting any financial system must contain controls to ensure the data is synchronized and reconciled.

Principle 7: All technical networks, including electronic mail, through which departmental users access University financial data must be reliable, stable and secure.

III. Responsibilities

A system of data integrity includes:

1. Allowing no one individual complete control over all key processing functions for any financial transactions. Such functions include:

1. recording transactions into the Financial System directly or through an interfacing system,
2. authorizing transactions through preapproval or post audit review,
3. receiving or disbursing funds,
4. reconciling financial system transactions, and
5. recording corrections or adjustments.

If insufficient personnel within the unit requires that one person perform all of these functions, the unit must assign a second person to review the work for accuracy, timeliness and honesty.

2. Ensuring that all employees who prepare financial transactions provide adequate descriptions, explanations, and back-up documentation sufficient to support post-authorization review and any internal or external audit.
    
3. Keeping "office of record" documents (both forms and new paperless transactions) physically secure and readily retrievable. These documents must be retained for the periods specified in the University Records Disposition Schedules Manual.
    
4. Ensuring that staff reconcile transactions appearing on the general ledger at the end of each accounting period.

1. All transactions must be verified for:

1. amount,
2. account classification (FAU),
3. description, and
4. proper accounting period.

2. All reconciliations must be performed in a timely manner.

5. Using exception reporting, variance analysis, and other mechanisms to monitor, review, and reconcile financial activity to ensure that:

1. Employees are adequately trained in preparing and processing financial transactions, 
2. Transactions and balances that exceed control thresholds or counter policies, regulations or laws are questioned and thoroughly analyzed, with corrections or adjustments fully documented and processed in a timely manner, 
3. Locally generated reports do not distort or misrepresent the source data used to prepare them. In particular,

    

   1. one must be able to reconcile reports back to the original data, as it appears in the Financial System, and
   2. any adjustments made in preparing a local report must be documented and recorded immediately, where appropriate in the Financial System,
       
4. All unit assets are properly described and accounted for in the Financial System or other "official books of record", and 
5. Actual physical assets are compared to recorded assets in the Financial System and discrepancies are resolved in a timely manner.

6. Encouraging all employees to report any break down or compromise in the unit's data integrity without fear of reprisal.

For further information, contact Internal Audit

A reliable financial computing environment includes the following components:

1. A long-term administrative computing plan that follows a thorough assessment of all major business processing and data needs. The plan defines the technical infrastructure and each of the system projects required to meet the unit's needs for the next three years. The plan should be updated annually.
    
2. Experienced and well-trained technical professionals to meet the unit's computing needs, including as a minimum, a Computing Support Coordinator.
    
3. Follow these steps in initiating and developing computing projects:

1. Project Initiation.

This includes:

1. gaining appropriate administrative approval,
2. defining the nature, scope, benefits, risks, priorities, timing and most likely development and implementation method for the project,
3. identifying areas and individuals affected by the project,
4. anticipating staffing, equipment and other requirements,
5. determining funding requirements and funding sources for the project life cycle and ongoing maintenance, and
6. naming a project coordinator, if the complexity of the project warrants it.

2. Analysis and Design.

This includes:

1. identifying the functional, informational and technical requirements of the proposed system, and
2. using data models or similar tools to ensure that the systems will be developed separate from the data, data redundancy will be minimized, and overall referential integrity will be satisfied.

3. Acquiring Hardware and Software.

This involves a written proposal when significant hardware and software purchases are being requested. Such proposals should always cross reference specific projects defined in the long-term administrative computing plan.

4. Implementation.

This includes:

1. developing a detailed project plan that identifies all tasks that need to be completed, who will do them and when they will be done,
2. ensuring that all aspects of the project will adhere to central data administrative standards, and
3. testing to ensure that the new system interfaces smoothly with other systems, and that audits, controls and checkpoints function properly.

5. Post Audit.

Once operational, the unit responsible for the new system must ensure that the agreed to level of service provided to the users is being satisfied and that proper maintenance, backup and recovery systems are in place.

4. Ensure that no completed system become operational unless an appropriate level of service to its users is in place. The minimum requirements include:

1. Availability. The system must be available when the users need it,
2. Data Access. The system must provide access to data in ways that are timely, compliment work flow processes, and are retained as specified in University Records Disposition Schedules Manual,
3. Performance. The system must meet users' performance needs,
4. Support. Users must receive training and documentation and have individuals to contact to help resolve problems,
5. Maintenance. The system must provide reliable service, and should be upgraded as technology or user needs change, and
6. Security. Access to the system must be protected at a minimum by user IDs and passwords. The system must also be protected from theft and vandalism.

5. Ensure that technical considerations are fully addressed.

These include:

1. Connectivity.

   If several campus units use the new system, it should operate through the campus backbone network. It should also support TCP/IP, the primary communication protocol for UCLA and UC computing.

2. Hardware.

   Hardware purchases should be evaluated with several criteria in mind, including:

   1. connectivity,
   2. performance,
   3. reliability,
   4. ease of maintenance,
   5. efficiency,
   6. availability of software,
   7. vendor support,
   8. cost.
       
3. Software.

   Software purchases should also be evaluated with several criteria in mind:

   1. The choice of operating system should consider such issues as connectivity,
      consistency of user interfaces, vendor support, and ease of application interfaces.
       
   2. UCLA administrative applications should be based on relational databases, with SQL the standard database access and manipulation language.
       

   3. The selection of a programming language should depend upon code availability, performance, staff skills, development time, interoperability, long-term vendor support, and how well the programs will work with existing programs. 

4. User Interface.

   Administrative applications should provide a standard, consistent and friendly user interface incorporating screen appearance, navigation procedures, menu selections, function keys, colors, messages, on-line help and terminology. 

For further information, contact Administrative Information Services