Body
Overview
This standard establishes requirements and expectations for all programmatic instructions, including but not limited to scripting, coding, automation, and application development (collectively referred to as “Code”) used with Oakland University Information Resources.
Alignment with this standard ensures:
- Compliance with institutional policies and regulatory requirements
- Secure handling of University Data
- Consistency, maintainability, and long-term supportability of applications
- Effective collaboration among developers, administrators, and vendorsope
This standard applies to the creation, development, utilization, administration, and maintenance of Code by:
- University Technology Services (UTS)
- Campus IT units
- Faculty and staff developers
- External vendors and contractors
when Code is used to process, store, transmit, or interact with University Resources or University Data.
Standard
The purpose of this standard is to guide developers and administrators throughout the Software Development Life Cycle (SDLC) to ensure Code is:
- Readable
- Testable
- Maintainable
- Secure
All Code must follow a documented approval, testing, and change management process appropriate to its risk and criticality.
Application Lifecycle Management
Departments and vendors developing, maintaining, or supporting applications for the University must implement procedures that ensure applications are properly managed throughout their lifecycle, including:
- Formal documentation and approval from initial proposal through production deployment
- Formal change management with separation of duties and/or management oversight
- Documented testing procedures, including:
- Security vulnerability testing
- Formal user acceptance testing (UAT)
- Use of a version control system
Application Documentation Requirements
Prior to Development
- Developers must document the proposal, approval, development, and change management process for the application.
- A formal written request is required for Code that:
- Interacts with Confidential or Internal Data, or
- Performs business-critical functions
- Approval from all relevant stakeholders is required before development begins.
During the Code Lifecycle
- Code interacting with Confidential/Internal Data or performing business-critical functions must use a version control system.
- Code must be sufficiently documented (e.g., inline comments) to support peer review.
- Developers must follow industry-recognized secure coding practices (e.g., OWASP).
- Authentication mechanisms must be secure, documented, and support credential revocation and rotation (e.g., API keys, service accounts).
- Access to campus databases or data warehouses requires approval from:
- The Data Steward
- The Information Security Office
Minimum Standards for Development
The following minimum standards apply to Code that processes, stores, or transmits Confidential or Internal Data. These practices are recommended for Public Data as well.
- All new administrative development must leverage UTS-approved centralized version control repositories (e.g., Git), unless an exception is approved by the Information Security Office.
- University Data handled by the application must be classified per the Data Classification Standard.
- Code must be:
- Clean and readable
- Structured to support collaboration and concurrent development (“swarming”)
- Applications must prominently display the UTS-approved logon banner and must not display restricted Confidential data.
- Input validation must be restrictive and defensive to prevent common vulnerabilities (e.g., injection, XSS, buffer overflows).
- Error handling must not expose system details or weaken security controls.
- When feasible, applications must authenticate users via Oakland’s central authentication systems.
- Individually granted authorizations must expire and require renewal at least annually.
- University Data must be stored securely and encrypted where required.
- Systems handling Confidential/Internal Data must use encrypted communications.
- Applications must generate logs where feasible; retention must comply with the IT Logging and Management Standard.
- Code must undergo peer security review using a defined methodology (e.g., SWARM) for:
- New applications
- Significant modifications
- The Security Advisory Group (SAG) will complete initial application risk assessments.
- Obsolete applications or code components must be removed from execution environments.
- A formal change management process must be implemented and followed.
- Confidential/Internal Data must not be transmitted via open APIs to unapproved GenAI or LLM systems.
Minimum Standards for Code Administration
- Maintain an inventory of all applications, including:
- Authentication and authorization methods
- Data classification
- Criticality level
- Business owner
- Custodians
- Define and document processes for granting and reviewing authorizations.
- At least annually, review and remove access for:
- Individuals who have left the University
- Individuals who changed roles or departments
Approval Process
To prevent unauthorized changes and ensure alignment with University expectations, application owners must implement an approval process that:
- Documents approval for initial development and all change requests
- Maintains an auditable trail of approvals
- Retains approval records for three (3) years
Separation of Duties
One of the following must be enforced:
- Production deployment approval by an individual/group not involved in development, or
- Management oversight when staffing limitations prevent separation of duties
Security Vulnerabilities
Applications must be assessed for vulnerabilities based on risk and data sensitivity.
- Security testing must be coordinated with authorized individuals.
- All security flaws must:
- Be tracked in a defect tracking system
- Be categorized by severity
- Be remediated prior to release or mitigated with compensating controls
- Vulnerabilities in released applications must be assessed based on:
- Likelihood of exploitation
- Impact to confidentiality, integrity, and availability
- Required access level
- Emergency procedures for addressing security flaws must be defined prior to production deployment.
Application Testing
- Applications must be tested in a pre-production environment prior to deployment.
- Developers must document:
- Changes introduced
- Release timelines
- Impacted users
- Functional users must review and approve application modifications.
Application Version Control
- A version control system must be used to track all changes.
- Access controls must prevent users from accessing or modifying unauthorized data.
- Version control repositories and data must be backed up regularly.
Non-Compliance and Exceptions
If required controls cannot be met for applications handling Confidential/Internal Data or business-critical operations, a Security Exception Request must be submitted for review and approval.
Roles and Responsibilities
Chief Information Security Officer
Information Security Office
Security Advisory Group (SAG)
Others as Necessary
Definitions
Application
Any program, script, automation, API, or code that:
- Interfaces with Confidential or Internal Data
- Performs business-critical functions
- Could disrupt operations if unavailable or inefficient
- Could cause harm through disclosure of sensitive credentials or data
The Information Security Office has authority to classify Code as an Application.
Related Documents, Forms, and Tools
Additional Support
- OU Technology Center
- 44 Oakland Center
- Rochester, MI 48309-4479
- Phone: (248) 370-4357
- Email: support@oakland.edu
- Office Hours: M-F 8:00am - 5:00pm
Last Modified: 8/27/2026
Authority: Approved by University Technology Services (UTS) Chief Information Officer
Category: Security Standards
Status: Approved