Separation of Duties within Information Systems

Seton Hall University strives to maintain a cohesive technology environment that provides high levels of reliability, consistency, integration, and consolidation.   The University’s IT environment should maintain high levels of security, and critical decision support systems should provide a trusted, authoritative source for key University data.

Separation of duties is one tool used to ensure the integrity and security of the University’s data and information systems.  Separation of duties is both an IT “best practice” and an audit and control standard that reduces the risk of a malicious or inadvertent breach of system security, data integrity, or the disruption of normal business processes, by requiring that individuals or workgroups not be in a position to control all parts of a transaction or business process.  Separation of duties is fundamentally about reducing the risk of loss of confidentiality, integrity, and availability of the University’s information.

Seton Hall University’s data security policies are guided by the information technology data security industry standard ISO 17799.  Requirement 8.1.4 of this standard states, “Duties and areas of responsibilities shall be segregated in order to reduce the opportunities for unauthorized modification or misuse of information or services.”  Additionally, separation of duties is a basic internal control requirement in several laws including the Graham-Leach-Bliley Act of 1999 (i.e., GLB Act), Sarbanes Oxley, Health Insurance Portability and Accountability Act of 1996 (HIPAA), etc.  Because of these regulations, organizations such as Seton Hall University strive to maintain separation of duties by separating across multiple work units the access required to conduct normal day-to-day business operations. 

Sample separation-of-duties requirements include (but are not limited to) the following:

• Development staff should not have access to production data, unless specifically authorized by the functional data owner to repair a limited number of records.
• Development staff should not access system level technology or database management systems.
• End users should not have access to production data except through the features and functions of the administrative applications; in particular, they should not have the ability to bypass or circumvent the applications’ validation and audit procedures.
• Functional users should not access or modify application code.
• Systems programmers should not access application code.
• Accounts should be approved by the data steward and subsequently created by a separate, independent system security administrator.
• Access to system logs and system audits should be limited to the system security analysts, and all such access should be reviewed by IT management.
• Access to firewalls and other network security systems should be limited to the network security analysts, and all such access should be reviewed by IT management.

By separating these functions, each area is a "check and balance" of the functions of the other area.  This prohibits one person from giving an account unauthorized access levels (e.g., the authority to change pay rates, update grades, view confidential data, etc.), modifying the underlying system security (i.e., modifying a user’s roles, disabling audit functions, etc.), and reviewing system logs or audit reports which could alert an independent reviewer of potential system misuse.

Approved by Banner and Administrative Computing Steering Committee
January 2008

Effective Date
January 1, 2008