Liszt Systems Development Life Cycle (SDLC) Policy

Effective Date: October 3, 2025

Last Updated: May 28, 2026

This Systems Development Life Cycle (“SDLC”) Policy defines the process used by Liszt to develop, test, review, deploy, and maintain software changes in a secure and controlled manner.

1. Purpose

This policy establishes the SDLC process for Liszt to ensure that changes, enhancements, integrations, and new features are developed, tested, reviewed, and deployed with appropriate attention to security, reliability, and operational continuity.

The SDLC process is intended to support the confidentiality, integrity, and availability of institutional and student data while aligning with operational best practices and applicable compliance obligations, including FERPA.

2. Scope

This policy applies to all development and maintenance activities associated with the Liszt platform, including:

• Feature development
• Bug fixes
• Security updates
• Infrastructure changes
• Third-party integrations
• Administrative tooling
• Database and API modifications

3. Roles and Responsibilities

3.1 Developer/Administrator

The Developer/Administrator is responsible for carrying out all phases of the SDLC process, including:

• Requirements analysis
• Secure system design
• Development and testing
• Deployment management
• Security review
• Operational monitoring
• Documentation and maintenance

3.2 Institutional Contacts

Institutional partners may be informed of major operational or security-related changes that could affect functionality, integrations, availability, or institutional workflows.

4. SDLC Phases

4.1 Requirements Gathering

Functional, operational, and security requirements are identified based on:

• Institutional needs
• User feedback
• Compliance obligations
• Operational risk considerations
• Platform maintenance requirements

Changes are classified according to operational impact and security risk. Higher-impact changes may require additional testing, documentation, or deployment planning.

4.2 Design

System design follows secure development principles, including:

• Least-privilege access
• Minimal data collection
• Separation of responsibilities
• Secure authentication and session handling
• Input validation and output encoding practices

Development, testing, and production environments are logically separated where practical to reduce operational and security risk.

Third-party services, libraries, and dependencies are periodically reviewed for:

• Security advisories
• Support status
• Operational suitability
• Compatibility with platform requirements

4.3 Development

All code is maintained in version-controlled repositories using Git.

Development practices include:

• Secure coding practices
• Change tracking through version history
• Controlled configuration management
• Dependency management and update review
• Protection of credentials and secrets

Access to development and production systems is restricted to authorized administrative accounts using secure authentication methods.

4.4 Testing

Changes are deployed first to a development or testing environment prior to production release where practical.

Testing activities may include:

• Functional validation
• Security impact review
• Integration testing
• User workflow verification
• Regression testing for critical systems

Issues identified during testing are resolved prior to production deployment when feasible.

4.5 Review and Approval

Changes are reviewed for alignment with functional, operational, and security requirements prior to deployment.

Major changes may include:

• Documented impact analysis
• Additional testing procedures
• Deployment planning
• Rollback considerations

Emergency changes necessary to maintain platform availability or security may be implemented on an expedited basis and documented afterward.

4.6 Deployment

Approved changes are deployed from version-controlled repositories to production systems.

Deployments are designed to:

• Preserve institutional configurations
• Minimize operational disruption
• Maintain service continuity where practical
• Support rollback or restoration procedures if needed

4.7 Maintenance and Monitoring

System logs, operational behavior, and security alerts are monitored to support platform reliability and security.

Vulnerabilities, operational issues, and bug reports are addressed according to severity and operational impact.

Security incidents and operational failures may be reviewed to identify improvements to development practices, testing procedures, or system architecture.

5. Documentation

Major system changes are documented through:

• Git commit history
• Release notes
• Administrative documentation
• Configuration records where applicable

Emergency changes are documented after implementation and reviewed for long-term mitigation or process improvement opportunities.

6. Review Cycle

This SDLC Policy will be reviewed annually and updated as needed to reflect changes in operational practices, security requirements, infrastructure, or applicable compliance obligations.